AJAX Approaching for Takeoff

AJAX – Asynchronous JavaScript and XML is building up a huge bubble of interest.

The reason is simple – in n-tier processing managing the Presentation Layer is tough. There are a number of trade-offs between the centrally administered and generated interfaces versus local GUI on the client with better interface widgets and potential for better response time. But the biggest problem in Web-based GUI development to date has been network latency – the time it takes to do a screen refresh between operations in a browser. What AJAX does is threefold: 1)cut down on the number of refreshes required by caching critical data and routines locally and 2)cutdown on the wait for refreshes by asking for not complete screen refreshes but only parts of the data that need change and 3)it performs many operations asynchronously so client wait states in the browser are further reduced.

And users can quickly see that AJAX actually does work and very well by visiting flickr.com or using Google Mail. The response time for many operations on these websites is much faster than the screen refreshes required by HTML/ASP/JSP/PHP. However, despite attacking this important Presentation problem directly – AJAX does not get us out of the woods – there are other problems.

Here is a summary of the Presentation Layer Problems:
1)multiple device support – a central server is generating the interface for potentially many different targets- a PC, a PDA, a Mobile phone, an embedded processor with display display – each of varying display dimensions and processing capabilities;
2)multiple operating environs – the central server may be transmitting through to the same devices but different client environs with different connections, storage capacity, and operating system support and functionality;
3)broader range of GUI components – that match and go beyond what users expect in W3C Web forms;
4)offline operations – the client may want to work offline with the same functionality, including GUI look and feel, as they get in the online sessions;
5)network latency/roundtrip delay – the client will want to minimize the amount of delays and waits associated with refreshing screens and change of state processing – network traffic has to be minimized or made transparent;
6)same service level – system administrators want to be able to deliver the same security, reliability, availability and response time that users on the local LAN get;
7)ease of admin – system administrators want better management of the server software that delivers the n-tier applications. Admin and operations people the same ease of instant, on-demand centralized updates that prevents the problems of diverging local copies processing the same data differently.

AJAX still falls down on 1)multiple device support because DHTML also falls down on many emerging devices. For 2) and 3) AJAX delivers some pretty good solutions especially now with 3rd party DHTML components popping up all over the place and Mozilla plus Opera working through whatwg.org and W3C to expand the basic HTML form components and their programmability (to say nothing about slow implementation of XForms in browsers despite IBM and Novells help).

It is point 4)offline operations where AJAX surprisingly shows a great deal of promise. Because locally cached XML datastores can theoretically be used to greatly expand the offline capabilities of AJAX programs – users theoretically could get the best of both worlds. AJAX is giving a better Web experience by now reducing 5)network latency and roundtrip delays. The jury is still out if the new complexity of AJAX will effect points 6) and 7). My guess is that if obfuscation, compression and/or encryption does not take place – ugly security problems will rear their head around AJAX systems. But the biggest problem for AJAX may be standards and lack of development tool support from the IT industry.

The Standard Bad News

The bad news is that once again Microsoft gets to play Deus ex Machinations on the Web community. After closing down all fixes and updates on IE for 5 years, Microsoft, not reacting in anyway to the fact that they are losing market share to rival browsers, has decided to update IE. I have no idea what will be in IE7 due out this summer. Microsofts Dave Massy and Dean Hachmovitch are playing their cards pretty close to their vests. Will IE7 do more than add tabs, popup blockers, remove privileged OS state status to IE users, implement PNG and maybe skins and otherwise lock down the default security measures tight in IE7 ? What about these issues:
1)Meet long overdue commitments to W3C standards and support full CSS2, XHTML, SVG, XForms and/or JPEG2000 -(I vote for CSS2 and SVG above all else);
2)Rationalize the DOM interface so that JavaScript codearounds like if(typebrowser < = "IE5" || typebrowser == "IE55")... are unnecessary;
3)Implement ECMAScript 2.0 standards including the very powerful E4X extensions which greatly simplify XML processing in JavaScript;
4)If Microsoft insists on keeping its many proprietary DOM and JScript extensions (or HORRORS!! add more)than it should implement a stick to W3C and other standards switch like Adobe and Macromedia do in their web development products. This would mean in BizTalk, BIStudio, Visual Studio and other Microsoft development tools it should be dead simple to flick an option switch and know that the code produced by those systems will be strictly standards compliant. But lets face it, in the arena of JavaScript, Redmond is not the only sinner.

Adobe and Macromedia both use JavaScript extensively as a macro language and output product in a number of their tools. Sun in Java Studio Creator is doing some nifty thing with CSS and JavaScript. Ditto for Borland, IBM, and Oracle in their development tools. Now riddle me this – which of the above vendors:
1)provides a robust JavaScript IDE?
2)support ECMAScript 2.0 standard ?
3)supports the ECMA recommended E4X extension for simplified XML processing?
If you answered None of the Above to all three questions, the only party that might get to argue is Macromedia. They are pretty close to ECMAScript 2.0 in their ActionScript 2.0 superset of JavaScript used in Flash 7. Also some Macromedians may claim that Dreamweaver has a JavaScript IDE – but the median response from most Web developers would be that is stretching Dreamweavers JavaScript capabilities. The bottom line is that inspired (??) by browser stagnation, the IT community has largely let DHTML wither except curiously as a macro language until Google and Yahoo/Flickr almost singlehandedly revived it with AJAX.

Summary

So yes and for good reason AJAX is taking off because it is really attacking some of the most pernicious Presentation Layer Problems … and currently without a first class JavaScript IDE. But surely as the snows appear well into May across Canada, there will be a flood of new AJAX IDEs (theoretically Isomorphic is already providing one – but the jury is out on whether its a full IDE). However this party maintains its not the AJAX IDE that is critical but how the industry supports all the standards around AJAX and DHTML that will prove whether AJAX soars or essentially gets grounded into a specialized app niche. Uh oh … this is not good. Getting the major IT software firms to adopt, support and enforce IT standards ? This is not a prescription for a story with a happy ending.

(c)JBSurveyer 2005