AJAX

 While the term AJAX was coined by Jesse James Garret in February of 2005 and is partly rooted in the asynchronous XmlHttpRequest implemented by Mozilla, lots of developers have used Microsoft's version of XMLHttpRequest and alternative techniques like IFrame since 1999. These techniques facilitate synchronous and asynchronous communications between the script in a page and server-side code. The main problem with AJAX is that despite its popularity it has no technical foundation. While the other solutions we mention here are based on rock-solid virtual machines, there's no standard VM for AJAX. Each browser implements AJAX building blocks differently. There's a chance that deployed AJAX application will require code changes with each new browser release. Wait, let's rephrase that: there's a chance that a deployed AJAX apps may run as is on a new browser release. Do you want to take chances with your business?
 That said, Internet giants like Google, Yahoo, and Amazon are building AJAX apps on top of their own abstraction layers such as Google Web Toolkit (GWT). Because of the immature level of the technology, these abstract layers need constant vendor attention as soon as changes appear.

AJAX Shortcomings

 An ability to create flicker-free Web apps without buying more software is AJAX's big appeal. You may have heard the chant "AJAX is free." Here's the simple translation: no commercial AJAX tool is worth paying for. There are hundreds of libraries, toolkits, and control sets that give you the impression that AJAX applications are cheap to develop and strategically safe since there's no vendor lock-in. Actually, there is vendor locking because you won't manually write JavaScript code and will have to pick an AJAX library of some vendor. Now think about it: starting from the ground up you need a communication layer, messaging and remoting mechanisms, an HTTP sniffer, a library of UI components with shared objects and event models, a visual IDE that understands these components in design time, and a debugger that accommodates all this stuff. On top of that, there's internationalization support, accessibility for the disabled, and support for automated testing tools.
 You really think you're safe with mix-and-match from different vendors? If the answer is yes, you must be working for a software company in the RIA business. Coming to reality, long development cycle, lack of free quality GUI components, and the shortcomings listed below make AJAX less appealing and, actually, the most expensive way of creating RIAs.
 These are some of AJAX's current drawbacks:

JavaScript development tools are limited due to the dynamic nature of the language, and debugging any DHTML/JavaScript mix is a pain. Yes, Google's GWT can spare you from writing JavaScript manually, but at the end of the day, it's still JavaScript that has to be deployed in production. When the system isn't working and time is limited, what are you going to use to debug it - the real page of Java mock-up?

Tons of JavaScript source code has to go over the wire to the client to be interpreted by the browser. We're talking about business applications, not some proof-of-concept demo.

Web browsers will happily display your application even if a piece of JavaScript didn't arrive at the client. You won't know of a problem exists until you execute the particular use case.

A simple right-click followed by the "View Source code" menu option would reveal your business application code. Better yet, all this code resides as plain text in the browser cache on disk. Because of this, you have to drop all the code comments and use obfuscators to protect your code from being stolen.

HTML rendering is slow: think of a data grid that contains 5,000 records. How long are you ready to wait for your sales report?

Any data manipulation by JavaScript is inherently slow because JavaScript is an interpreted, not a compiled language. We're talking thousand of times slow.

The code is more vulnerable to hacker attack, a fact that was proved recently by a worm that stole a bunch of mail addresses from Yahoo address books.

AJAX doesn't support server push. The server-side application can't publish the data directly to the client. AJAX applications have to poll the data from the server at specified time intervals without knowing if the data is there or not.
It's not easy to find good AJAX programmers.

To summarize, if you're developing a new enterprise business RIA from scratch, AJAX may not be the way to go. Choose a solid application development environment that offers a virtual machine at runtime like Flex/Flash, Java, or WPF. Any of these environments is more productive than AJAX. If you already have AJAX applications you can nicely integrate new Flex RIAs in existing AJAX applications using tools like FABridge from Adobe for communicating between AJAX and Flex.

During AJAX's first year of life, every article or book on the subject mentioned Google Maps and Gmail, and various type-ahead samples: you enter the first zip code digit in a text field, and it suggests your possible choices based on your input without a page refresh. Today, you can read about a number of AJAX applications, including ones that work with photo images loaded from the popular flickr.com Web site.

Lastly, I'd like to make it clear that popular comparisons of Flex versus AJAX are simply wrong, since Flex is a framework and complete development platform, while AJAX is a set of techniques. To compare apples to apples, you should compare products like Flex against GWT (Google) and the like.

Other RIA Solutions

OpenLaszlo

 OpenLaszlo  from Laszlo Systems is an open source product that lets you create applications that can be deployed as DHTML or Flash Player files.   The ability to generate DHTML code made it a good candidate for developing applications for mobile devices, and Sun Microsystems has recently partnered with Laszlo Systems to bring this technology to the Java mobile space. This is direct competition for Adobe Flash Lite.

GWT

GWT stands for Google Web Toolkit lets you write programs in Java and convert them to JavaScript so they can be delivered as AJAX Web applications.
 An interesting GWT feature is that it compiles Java into various versions of JavaScript to accommodate the specific needs of different Web browsers. GWT comes with a library of extensible components. The number of these components was limited, but that will probably change soon, because it's Google.

NexaWeb

NexaWeb  offers a Java-based thin client that doesn't require any additional installation on the user's desktop. The application's state is controlled by a small Java applet running on the client. This applet communicates with the NexaWeb Java EE application as needed. To avoid issues related to the version of the Java Runtime Environment installed with the Web browser, NexaWeb uses JRE 1.1 for its applet.