I've been doing a bit more thinking about AJAX in the last few weeks as I'm trying to prepare for my session and try to get a few different perspectives.  I've done an awful lot of reading about what people are doing with AJAX. It seems there's a heck of a lot more talk about AJAX than actual work being done. <g>

I wrote about the dearth of good solid AJAX examples before. You know the kind of example where you sit there and go – "yup, perfect use case for AJAX. Why didn't I think of that?" Let me tell you there are not many of these. Instead we get a lot of Hello World samples (I plead guilty <g>) or some mismatched samples like ATLAS Wiki that really aren't good examples of applications well suited to AJAX technology. I think a lot of people are struggling with just that – what do I use it for?

As I said, there's a lot of philosophical talk about AJAX as the next big thing to replace traditional Web applications. I personally don't agree with this thinking. I think that AJAX is very useful indeed, but the best use case scenario for the technology today is to utilize it as add-on functionality to existing applications to feed data into existing Web applications. There are lots of simple scenarios where I do just this:

• Information popups (hover popups) that show additional data

• Data Updates a selection or button a form causes some
  formatting to be done of the server and return the result
  
  
• Validation of data entry with validations that require data lookups
  
  
• Page refreshes of HTML fragments (Counters, Statistics)

All of these tend to be very small operations that update a small portion of a page and don't require any rocket science code – it's easy enough to do in JavaScript with a few lines of code.

But according to the pundits and big vendors, AJAX will change everything. Uh huh. The first thought I have here is that for this to be true there would have to a fundamental problem with non-AJAX POSTBACK Web applications in the first place.

Yes there are some problems, but most of these issues are esoteric. The most common examples cited are user interface flashing, loosing browser scroll position. Pathetic but those would be the most common reasons stated… Everybody is too worried about building flashy UIs that drag windows around the screen and popping up windows everywhere with data from the server – a lot of times in obnoxious ways <g>

Seriously though. Bandwidth is becoming less of a problem these days. Broadband use is wide spread now and downlink speeds are blazing fast. I have a 6 megabit downlink here on Maui which is standard Cable service. We're to the point where dial up is not something you have to worry about much anymore.  There's boat loads of bandwidth to run applications and many well designed POSTback style applications don't have much of UI flash at all as data comes down and loads in the browser quickly. I say well-designed – there seem to be an awful lot of badly designed applications too, using excessive viewstate etc.

In this light, also consider that some of the AJAX framework like ATLAS in particular aren't exactly light in the amount of data they ship over the wire for callbacks, so the data savings aren't all that great to start with. They also assume that boatloads of bandwidth will be available.

So given that the UI issues are a big concern I got to thinking (oh boy):

If this is really what the problem is then why isn't somebody at the browser companies thinking of a way to have the browser figure diff'ing the HTML that in the page and what's coming down from the server and optionally – via a flag on the body tag maybe – update just what's changed.Doing diff's is not rocket science.

If you're posting back to the same page the browser could potentially store its internal settings and – via some sort of flag – restore that base environment. It wouldn't be much – scroll position, active control – that's almost all that's needed. The browser could automatically diff the HTML that's coming in from what's already on the client and based on that update just that portion of the page. There no flash, no scrolling… Sure sounds a heck of a lot easier than a server framework like ATLAS trying to figure out what's changed on the client on the Server side without having the actual HTML available.

Imagine what this would mean. Maybe by setting a flag on the body tag you could specify that it's an updateable page and the server could continue to post back the page but only update what's changed.

Sounds far fetched? Well, consider that ATLAS is to some degree doing this anyway – it's trying figure out what's on the client and send only updated data. But because it's doing this on the server it has to also deal with ViewState updating and managing a different event sequence for the ATLAS framework.

Taking this thought a little bit further if UI problems is what we are really concerned with why in the world are we still using HTML at all? There are better solutions. There's Flash, bad as it is, but it provides rich UI plus the infrastructure to support remote access to data as well as a really rich UI framework.  There are always rich client applications. You can build rich WinForms application that run through downloadable modules that update when changed bringin you much of the browser model but with a real user interface and real connectivity features (but the Windows and .NET requirements).

Then there's WPF/XAML coming down the line. Like WinForms it will be Windows hosted, but with the added advantage that Xaml can run right in the browser and get to take advantage of the rich user interface framework and .NET. Chrome, XUL all are new interfaces that promise better functionality than HTML but still here we are looking at the same 10 or so crappy controls that Html provides.

But I don't see any of those going anywhere anytime soon. Anything coming from Microsoft will never gain critical momentum in the Web world at large. But then AJAX solutions are often targeted at internal projects and would it make way more sense with those types of apps to run them with a rich client?

Nah, we rather stick with hobbled HTML and controls that are stone age and haven't changed since the Web's inception in the mid nineties. Now there's progress for you!

But there are those that foresee every application running like GMail with everything loaded through AJAX callbacks. If you realistically look at this scenario though how well does that fit into a general Web application world? GMail is an awesome app for sure and it works in that specific scenario because the data it deals with mostly private data.  But given the complexity of building an application that way and the fact that it doesn't blend with the current Web infrastructure (different browser behavior, not searchable/indexable) is that really the direction we all want to go? And is the 'slick UI' really providing that much more value especially given that it's difficult to build a slick UI like that even if you have high level tools helping you?

If we really want this rich kind of interface then the first thing that should happen is browsers should start improving by providing better controls. Why for example, isn't there a decent built-in List control like a ListView and a TreeView? Browser innovation has been at a standstill with HTML standards for 10 years, but if we were serious about this we'd all make some noise about this.

But no, instead we're asking tool vendors to spend their time to build HTML hacks that emulate a proper user interface. Here's another Html Editor control implemented in stoneage HTML. Another Calendar Control and another Grid control or ListView or TreeView etc. And so we go re-inventing the wheel over and over and over again.

Apparently we're not really serious. If we were we would actually consider writing WPF/XAML applications or even Flash Applications for that matter. Our industry is a funny one. We put up with a lot of inferiority and maybe we've just become too complacent to raise a ruckus about it anymore. We're all assuming it is what it is and nothing will change it…

Back to AJAX and callbacks.  UI Issues aside, AJAX also address bandwidth issues when used wisely and not sending bloated content over and over again. Updating page CONTENT not page layout. I think that's really where the value of AJAX lies. The problem I have with frameworks like ATLAS is that they don't treat AJAX as data mechanism but they treat AJAX as a UI mechanism. So the idea with ATLAS is to do your work on the server and the server decides what's changed and shuttles back only what's changed and needs updating. The problem here is that you're shuttling a lot of crap back and forth to make that happen, especially with ASP.NET.

ATLAS makes a typical Microsoft assumption: Hardware and network resources are limitless. If so much data is shuttled over the wire you're not significantly enhancing through put of an application because you are essentially sending back large pages anyway. Requests still hit the full page pipeline in ASP.NET, even encoding up ViewState and shipping it back and forth.

Somehow that strikes me as the wrong approach.

Even if we are assuming for a minute that we're sending only small chunks of data back and for the between the client and the server you have to also consider the load AJAX is incurring on the Web Server. I see a lot of samples (including my own) that show off the fact that I can make one small call to the server to retrieve a really small value and update my page with it. But remember that that small 20 byte result string probably cost you a couple k bytes of network bandwidth counting the HTTP headers from client and server, plus the CPU hit on the server. Something is to be said for many small requests vs one big request being not as efficient. If you have 1 request returning a huge 200k page or you have 20 requests returning 10k chunks to update the page, which do you think will be faster on the client and which do you think is going to load server more heavily. In both cases you'll find that the single page request probably wins hands down both in terms of performance and server load.

Then again if that 200k needs to be refreshed to update a listbox selection, then that single file becomes a burden quickly, but this is exactly where a useful AJAX scenario comes in by updating that small piece of data inline without causing the full page to post back. It can help enhance an existing application without turning the whole application on its head.

At this time I find ATLAS pretty intimidating. Everytime something goes wrong (and it does a lot) I get that sinking feeling that I'm not going to be able to work around the issue.

It's funny as I've gone down the AJAX path here, I'm actually coming around to appreciate the fact that writing the script code myself gives you something you will never have with a framework like ATLAS: Full control. I'm no fan of JavaScript, but since starting with this my Jscript skills have improved quite a bit and I am much more productive with it than I used to be now. I can actually write more than a few lines of code now without looking at my Visibone charts <s>.

Most of the AJAX vendors though have moved away from the minimalist approach. I used to really like MyAjax.NET (now Anthem) when it was a simple data providing AJAX library. Now this framework too has gone to a control based approach and in fact has removed some of the original data service functionality it originally had. It's different than ATLAS in that it uses custom controls, but in a lot of ways much easier to use. Still it too is very heavy in what it shuttles across the wire.

I'm not sold. I think the simplicity of pulling data off the server especially in JSON format and then being able to utilize that data on the client is very powerful and relatively easy and most importantly it's what AJAX is really about: Mean and lean. Let's not forget that part of it!!!