Welcome!

AJAX & REA Authors: Yakov Fain, Andreas Grabner, Lori MacVittie, Kevin Hoffman, John Gannon

Related Topics: AJAX & REA

AJAX & REA: Article

AJAX and RIA 2009: More Choices, Tough Decisions

Where we are now and what’s coming in 2009

There are two major schools of thought about the best interface to use when tying AJAX to HTML pages. One school says to tough it out and use JavaScript directly, since the performance for end users is what matters. The other school says to avoid JavaScript and use XML tags instead, despite the performance hit, since they are more likely to render the same way on all browsers, and less likely to throw runtime errors.

On another front, we are also seeing large Web components get internal AJAX support. A good example of this is data grid controls. In the ASP.NET space alone, there are several data grids available that have data binding and AJAX updating baked into the grid control.

What's Coming for 2009?
One interesting piece of news comes from an unlikely pair. Microsoft is partnering with jQuery to supplement ASP.NET AJAX, and Microsoft is beefing up support for jQuery in Visual Studio 2008. As announced by Scott Guthrie, a Corporate Vice President in the Microsoft Developer Division:

"Microsoft will be shipping jQuery with Visual Studio going forward. We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch. The files will continue to use and ship under the existing jQuery MIT license.

"We will also distribute intellisense-annotated versions that provide great Visual Studio intellisense and help-integration at design-time."

Why did they do that? Microsoft ASP.NET AJAX basically allows ASP.NET components to use AJAX instead of heavyweight post-backs for screen and database updates. According to Guthrie, jQuery adds some capabilities that complement what's in ASP.NET AJAX:

"A big part of the appeal of jQuery is that it allows you to elegantly (and efficiently) find and manipulate HTML elements with minimum lines of code. jQuery supports this via a nice ‘selector' API that allows developers to query for HTML elements, and then apply ‘commands' to them. One of the characteristics of jQuery commands is that they can be ‘chained' together so that the result of one command can feed into another. jQuery also includes a built-in set of animation APIs that can be used as commands. The combination allows you to do some really cool things with only a few keystrokes."

Nexaweb
What else is coming? We spoke with Jeremy Chone, CTO of Nexaweb, who has the additional perspective of having been responsible for Adobe Flex and having been Adobe's representative to the OpenAjax Alliance.

According to Chone, in the long term developing AJAX applications will become easier and easier, and AJAX applications will become more robust, largely because of progress in the JavaScript and CSS standards and in browser implementations. Chone cited Internet Explorer (IE) 6 and 7 as two of the least compliant current browsers as far as JavaScript and CSS standards, and said that IE 8 is a considerable improvement, although not as good as FireFox 3 or Google Chrome in that department. (We have heard other AJAX toolkit developers express the desire that Microsoft retire or deprecate IE 6 as soon as possible.)

Chone said that for right now, the "big three" AJAX toolkits, which he listed as dojo, jQuery, and Ext, do a fairly good job of keeping AJAX robust and isolating developers from browser dependencies. Meanwhile, Nexaweb is using an enhanced version of dojo, dojo.E, as part of its offerings.

Nexaweb actually offers two client-side interfaces, an AJAX interface based on dojo.E, and a heavier-weight but "more consistent" interface that uses a Java applet. Nexaweb developed dojo.E to provide XML tags for dojo, and contributed the implementation back to the dojo Foundation last June. Dojo.E's XML tag support makes it easier for corporate developers, who may not be comfortable with JavaScript, to contribute to AJAX applications. Despite this, Chone thinks that all AJAX developers will have to learn JavaScript eventually.

Why the alternate Java-based client interface? "We're in the business of modernizing applications, not pushing specific technologies," said Chone. "Our Java applet dynamically displays a user interface that is defined by XML, and can modify the XML. Our AJAX interface does essentially the same thing."

Chone described this architecture as "distributed MVC" and claimed that is better suited to complex applications than more traditional RIAs, such as Flex. "If you have to build every one of your forms into a Flex library, what are you going to do when you have to write an application against SAP?" he asked. "SAP has about 4,000 tables, and there's no way you're going to be able to hand-craft a form for every query you'll make against it."

Isomorphic
Charles Kendrick, Founder and CTO of Isomorphic Software, agreed with Chone on the general question of AJAX browser dependency, but disagreed on specifics. "I think the single biggest thing that an AJAX platform can do to simplify development is to eliminate the need to troubleshoot why an application is behaving differently on different browsers. Not only does this save time, it also avoids the need for a developer to deeply understand the browser DOM, CSS layout, and cross-browser quirks. Essentially all frameworks claim to work cross-browser, but it's a question of completeness."

According to Kendrick, there's a spectrum from low-level libraries like jQuery, which are "completely DOM- and CSS-oriented," to platforms like his product SmartClient, "where even custom components, skinning and branding are done in an object-oriented way familiar to Java or C# developers." Kendrick said: "My prediction for 2009 is that it will become more widely understood that server-driven AJAX frameworks, such as JSF and ZKoss, do not actually provide insulation from cross-browser issues throughout the entire application lifecycle (non-trivial customizations, skinning and branding still require deep browser expertise). Since server-driven AJAX also loses the lion share of possible benefits of AJAX, this will cause a shift to client-oriented AJAX platforms, where much closer scrutiny will be applied to how frameworks provide cross-browser safe functionality."

Meanwhile, Isomorphic is planning several new offerings for 2009: SmartGWT, a Google Web Toolkit wrapper for SmartClient; Visual Builder, a "drag and drop application building environment suitable even for semi-technical users like product managers and business analysts, but backed by the full scope and flexibility of the SmartClient platform"; and enhancements to its Aptana/Eclipse plugin that will tie into Visual Builder.

More Stories By Martin Heller

Martin Heller is a software developer and consultant who often writes and blogs about development.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
becca77 11/08/08 02:07:55 PM EST

An interesting insight. I honestly think that things are looking pretty good for Ajax as far as jobs go. If you look at these stats http://www.odesk.com/trends/ajax, it looks as though we're remaining steady during the otherwise tumoltuous economic trends.

ckendrick99 11/07/08 07:18:19 PM EST

Excellent article Martin, you picked mostly real companies instead of the ever present crop of VC-funded noisemakers. Few people are aware of Alpha and their technology makes good sense, but I would say that wouldn't I? .. those same features (QBE, inline edit, optional direct SQL connection) are also in SmartClient.

Jouk Pleiter of Backbase unfortunately made some factually incorrect claims.

1) GWT does not use XML tags and does not "render tags" on the server. GWT allows you to write Java code that is translated at compile time to JavaScript and runs purely in the browser. GWT does not require any particular server technology to be used, for example, GWT applications can run on PHP servers.

The point of GWT is to enable Java programmers to leverage existing skills - using GWT feels very similar to using Java Swing. This is in contrast to an XML tag library approach, which provides declarative access to some features but still exposes you to JavaScript for deep customization. GWT allows you to build custom components in ordinary Java. That's why we've created SmartGWT, which gives you SmartClient's extremely sophisticated Ajax visual components in a familiar Java environment.

2) There is likewise confusion about the distinction between how various frameworks handle XML tags. With the exception of Backbase, all of the frameworks mentioned have the ability to "compile" XML tags to JavaScript or to proprietary formats (Flex, Silverlight). This includes SmartClient, which has an XML language that can be either compiled or used dynamically. None of the frameworks mentioned have the disadvantage of requiring server-side rendering of XML tags, as implied by Jouk's contrast with Backbase.

Instead, the actual distinction is that Backbase alone interprets it's XML tags inside the browser. This is less efficient (extra steps taken at runtime) and so far as I know, they do not provide a way around this inefficiency, which is not a problem with any of the other technologies listed.

At your service Martin - again great article.

Cheers,
Charles