Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • JavaScript • Angular
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

Some more random AJAX thoughts

On this page:


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!!!

The Voices of Reason


Bertrand Le Roy
March 07, 2006

# re: Some more random AJAX thoughts

I think you're confusing Atlas with UpdatePanel. We treat Ajax very much as a data mechanism in the client framework and you'll have difficulty finding another framework that treats data on the client that seriously. We do not at all assume infinite resources. Nothing could be farther from the truth. If you look at the stuff we're doing in datasource, batching requests, and some of the new features that come with the March release you'll realize that. I realize that documentation has been sparse to say the least and our intentions may not be very clear because of that, but the documentation is coming too. Please have some patience and take the time to look into more details. I can answer your questions, too, you know my e-mail and Messenger addresses...

Kevin Wright
March 07, 2006

# re: Some more random AJAX thoughts

> I used to really like MyAjax.NET (now Anthem

So which of the frameworks do you now think is best for the simple data retreival operations that you describe?


Carl Olson
March 08, 2006

# re: Some more random AJAX thoughts

re: "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."


And to add to the fray here's an interesting comparison of AJAX frameworks:


March 08, 2006

# re: Some more random AJAX thoughts

For anyone wondering the same thing Rick brought up in the very beginning ("what is AJAX good for").. excellent post here:


Rick: I look forward to your pre-conference in Orlando.. all signed up and ready to go

March 08, 2006

# re: Some more random AJAX thoughts

AJAX at its best is just a way to reduce time to first render on a web-page, for both the first hit and subsequent hits. I don't think anyone makes the explicit claim that low network bytes is the goal (although clearly that contributes to low render time.) Amount transferred during AJAX should just be less than a full page would take, or it doesn't make sense to bypass the standard process.

There are lots of other ways to make an app fast. Gmail for instance uses many of them along with AJAX: fast servers, hidden iframes (no data transfer, so not ajax), client-side DHTML, etc combined with AJAX calls make it the most responsive webmail app.

You definitely should read the link that Carl posted, just to answer some of your techy questions. I'm sure you've looked around a lot, but if ATLAS is your primary model for understanding AJAX then you're not getting the full picture. (esp since the documentation is so poor.)

ATLAS is a framework which does a lot more than AJAX and accordingly comes with a heavy weight. It's sort of the "SOAP" of AJAX - there's a very powerful framework for XML data exchange which is not necessary for the simplest cases.

PS the two left-most columns in the article are the "correct" choices ;) Take a look at the componentart demos for some really good examples of how AJAX can speed up your app. (He messed up a few small details about ComponentArt because he didn't know some of the settings you can change.)

March 08, 2006

# re: Some more random AJAX thoughts

BTW imagining your 200k page vs. 20x10 page - as a user I'd likely prefer the latter, even at the cost to the server of multiple requests. That's because if you're really making 20 requests I'm assuming you've got 19 unique data elements on the page. The first 10k request would get enough HTML to render the entire page frame, rather than forcing me to wait while all the components perform their data access. At that point I could see each panel fill in as its data is retrieved. Since at least half are likely to be below the fold, I've effectively seen a "full page render" before half of the data has been transmitted - a net savings over the 200k version. Of course, no one would make something with 20 unique calls anyway. Typical AJAX usage is probably at *most* 2-4 calls per page, or less when averaged across the whole app, even in a heavy AJAX app.

BTW my "ajaxish" (not in the true sense) home page saves me a *lot* of bytes in each request! That's because I steal them from delicious. ;)

Bertrand Le Roy
March 08, 2006

# re: Some more random AJAX thoughts

"re: "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."


Nooooo! If one thing is wrong in this post, that's it.
Let me say it again:
UpdatePanel != Atlas

The Atlas client framework very much treats Ajax as a data mechanism. Look at DataSource, DataView, ListView, ItemView, bindings etc.
So if you're using updatapanel, sure, the rendering happens on the server and the client never sees the data, of course: you're using the plain old server controls, but you can also build a live data client application using the Atlas client framework and if you do so I don't think any other framework comes even close.

Peter Bromberg
March 09, 2006

# re: Some more random AJAX thoughts

I am an Atlas believer, because I have great faith in Leroy et al and their sense of purpose. However, until it's production ready I'm not even spending any time with it.

Everything I've done in the last six months that has seemed "appropriate" for a Remote Scripting ("AJAX") approach has been with Jason Diamond's library (now Anthem.Net) or, I simply create my own which is even more lightweight. It is very easy to "AJAX" yourself into oblivion as a developer; I need to write quality code that's suitable for production and I don't have the luxury of time to mess around.

Guy Peled
March 10, 2006

# Right there with you...

I too had the same thoughts you have raised here... I extended those thoughts and said... way do I have to brake my balls every time I want a treeview... lets say that you take a ready DHTML control... you still have to do all the plumbing of an xml rendering file that will produce this data... and here you get a security hole... you have to secure this page... to see that only the right people see the right data... is that the way to go... a couple of years ago I set down on a database oriented idea... interfaces represented by tables... started to write stored procedures... had a very nice system running in query analyzer... but now I had to spend twice the time writing the UI cause I wanted a web UI... that is what people want... cant argue with that... and that how I invented WebGui....

See my webcast

See my site

See the light... Guy Pelled

Jeff Barnes - MCSD
March 16, 2006

# Blog Highlights

Some cool white papers about the architecture of Microsoft.com
More Blog Skins for CS 2.0
SQL Express/MSDE...

Jeff W. Barnes
April 23, 2006

# Blog Highlights

Some cool white papers about the architecture of Microsoft.com
More Blog Skins for CS 2.0
SQL Express/MSDE...

Chris Loosley
August 22, 2006

# re: Some more random AJAX thoughts

Steve writes:

<em>That's because if you're really making 20 requests I'm assuming you've got 19 unique data elements on the page. The first 10k request would get enough HTML to render the entire page frame, rather than forcing me to wait while all the components perform their data access. At that point I could see each panel fill in as its data is retrieved.<em>

But I don't think the issue is the client forcing the user to wait. It is programmers creating AJAX logic (which may even be running in the background, while the user is reading the previous server response) that ALWAYS fetches the information to populate a display one object at a time, when they could be smarter and (when appropriate) fetch the same data in bigger chunks.

It's easy to write simple one-object-at-a-time logic, and it always works. And its performance is just fine for users who need to work with only a few objects (files, projects, contracts, accounts, or whatever data the application handles). But when a user has 100, 500, 1000 objects, that simple logic produces very unhappy users.

And the trouble is that (usually) a user who needs to view the details of 1000 objects, and whose response time is impossibly slow because of a chatty communication algorithms that fetch one object at a time, is actually 1000 times more important to your business than the user who has just one or two objects. That is a big problem.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2021