State of AJAX

In State of Ajax: Progress, Challenges, and Implications for SOAs, Dion Hinchcliffe gives his take on just where all the hype and sensation surrounding AJAX is headed. I also editorialized on this subject somewhat in the Tech Times #120.

Despite some claims that AJAX will supercede desktop application development, I believe that certain types of applications are–at least for the forseeable future–inextricably bound to the desktop. That said, thanks to AJAX and its kin, the Web really has grown significantly in the type of user experience it can deliver for the kinds of applications it is suited for.

In his post, Hinchcliffe makes some observations about how the rise of AJAX-style development on the client side will affect some of the trends at the leading edge of server-side development. In particular, he points out that a lot of the new standards being developed for Web Services are not architected such that they will be useful in an AJAX-driven world. Whereas AJAX thrives on many rapid, lightweight, bite-sized communications with a single server, much of the current work on Web Services is towards the exhange and processing of large documents between multiple service providers in a secure and intricately choreographed way.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Etnu

    That last paragraph is patently false. Apache’s new keepalive system is designed explicitly for delivering small bits of data in rapid-fire succession. And that’s just one piece of technology. SOAP and XML-RPC get more and more efficient every year, and are ideal for this sort of thing. The biggest limitation that AJAX has right now is browsers, namely:

    1.) IE still implementing the system using ActiveX, a system that most security experts tell people to disable.

    2.) The amount of work necessary to create a large number of elements on a page in a cross-browser fashion, i.e. document.createElement(). Sometimes you can get away with things like innerHTML (if you’re strictly catering to an audiance that uses the browsers that support it), but there are additional limitations there.

    3.) The relative limitations of animation. This could be solved with something like flash, but unfortunately flash wants to be delivered as an application instead of as a piece of media (e.g. an image type).

  • http://www.rideontwo.com z0s0

    Etnu, on what do you base your comment that SOAP and XML-RPC are getting more efficient? The feeling I get when using these technologies is that they instead get more bloated and cumbersome each year.

    Re: point 2, a good architect does this “work” once, and once only. The gains from being able to unit test this stuff – in stark contrast to innerHTML voodoo – far outweigh the cost of slightly more verbose code.

  • paulbb

    In reply to point 3) of Etnu’s list.

    It will be interesting to see what Microsofts ensuing “attack” on Macromedia, in the form of Sparkle will lead to.

    We should get a better idea of this at the upcomming “Professional Developers Conference” in september, Microsoft will apparently reveal some details of their upcomming plattform.

  • http://www.igeek.info asp_funda

    Sometimes you can get away with things like innerHTML (if you’re strictly catering to an audiance that uses the browsers that support it)

    Etnu, the innerHTML is buggy in IE Mac otherwise it works in all browsers!! :)
    see here http://www.quirksmode.org/dom/w3c_html.html#all