Down on ASP.Net

First, some random stuff.  I got a free t-shirt from Newegg yesterday and I didn’t even have to buy anything!  It turns out that scammers have been using Newegg’s domain in phishing attacks.  As I was reading through this, I thought to myself: isn’t there some way to counter this?  I came up with a pretty simple solution and emailed it to Newegg’s customer service email: why not just have all account holders, when they enter their information, also enter three code words — for example: “Apple”, “Frankie”, and “Coolio” — and from that point on, any correspondence would include one of these three words, selected at random, in the subject line.  This way, a customer can easily scan emails which appear to be coming from Newegg and tell which ones are spam and filters can also be set up to simply remove anything from Newegg that doesn’t contain one of the code words in the title.

There would be no way for a scammer to overcome this without knowing the codewords (yes, I did think about it for a while and one codeword would probably work just as well since if you compromise even one, you’ve compromised the effectiveness of the entire system).

So simple (simple to program, simple for customers), yet so effective…I like simple things.

On another front, I’ve been working on a consulting project kind of indepenently with a development team in a primarily Java environment.  I’ve been doing some really nifty UI work and the sort of cutting edge web software that I love to do (I know you can’t tell by this webpage 😀 and I know his blog is displaying incorrectly in IE7).

Working with this team has reinforced my belief that web UIs have no place on server side applications except in HTML pages and JS files; server side UIs must die.  The entirety of the work that I’ve done has been in JavaScript classes that are essentially client side renderers which consume data provided by JSP pages as JSON strings.  It’s a beautiful thing to behold from a design perspective.  Those guys that have no clue how to do UI are not tasked with doing any of the UI work; they just provide the data services that I need to render my UI.

Since I first came across AJAX, it has always been in my mind that, given this tool (a gift from the web programming gods, I tell you), the ideal way to write web apps goes sooo far beyond what any server web application platform can offer.  Perhaps some view this as a bit radical, but I have proposed that the application server be completely oblivious to the existance of any UI at all; all functionality is exposed as a web service and it is then up to the consumer of those services to decide what to do with it.  What exactly does this mean?  The server delivers what is essentially a base HTML page and from that point on, the server side app has no further involvement in the UI.  All of the rendering is then accomplished by client side scripts through DOM manipulation.

This has HUGE advantages over traditional postback/getback models.

1. The rendering script can be cached.  That means that while you may bulk up on the scripts, you end up saving a HUGE chunk of bandwidth on not delivering highly redundant HTML.  Using this model, you only ever deliver data, NEVER delivering UI markup.
2. The design is incredibly clean on the server side.  None of this intertwining of UI postback handling and layout garbage.  The application is responsible for providing data services and data services only.  This is a win-win situation as it does not ask the application programmer to build UI (something which most are terribly incompetant at).  At the same time, given a base set of messages, the UI developer can start working on client side code immediately with mocked up messages.
3. The application is highly reusable now.  The same web services powering the web application can be retooled a bit to power ANY client.
4. It offers a better user experience.  This is true for any usage of AJAX.
5. It offers a clean separation of concerns for the two domains of the application: the UI and the server components.  Completely clean.  No half-assed distinction as with ASP.Net and ASP.Net controls.  There is no concept of UI at the server side — NONE — only data.

I can’t be the only one that believes in this, can I?

But in any case, I’m really down on out-of-the-box ASP.Net and I’m really down on people that adhere to it because it’s easy (don’t get me wrong, I love .Net).  It all goes back to the drag-&-drop mentality.  I abhor this approach to software.  When something goes wrong, developers that adhere to this philosophy are like deer in headlights.  Source is your friend.  Get to know Source.  It’ll be good for you in the long run.

Nothing against Infragistics, but has anyone seen the HTML source produced by their ASP.Net controls?  Wow.  Fugly beyond belief and HEAVY to boot (the same is true of SharePoint…it’s unbelievable).  Not only that, the markup in the page is horrendous and completely illegible…how do they stay in business?  Oh yeah, the gigantic cadre of drag-&-drop professionals brought up in the drag-&-drop era.  They’ve sold the idea that these controls save time and money while I would argue that the time & money saved is not that significant it since it leads to hard to maintain code, heavy markup delivered to the client, “cookie” cutter UIs that tend to look alike (even across organizational and business boundaries), and a lack of tailoring to the users.  I mean, it may save what? a few hours of development time?  But you end up with code that is incredibly heavy, hard to read, and hard to maintain.  It’s time for server side UI to die.  Completely.

I’ll admit: not everyone is as comfortable as I am working in the DOM on the client side and working with JavaScript and raw HTML constructs.  But heck, this stuff isn’t brain surgery man.