By Kevin Yank

State of AJAX

By Kevin Yank

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.

  • 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).

  • 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.

  • 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

Get the latest in JavaScript, once a week, for free.