Why Ajax?

With the emergence of the Web 2.0 trend, alternatives to Ajax technology seem to be popping up on an almost daily basis. Technologies such as Microsoft's Silverlight™, Adobe's Flex™ and Sun's JavaFX™ claim a nearly identical set of benefits in exchange for moving off of the internationally standardized web platform.

It's a bad bet. Here's why. Reach & Simplicity In the early web, when the idea of a "web application" was new, web applications delivered primitive functionality that paled in comparison to installable applications. This was considered a reasonable tradeoff because of the audience that could be reached, the simplicity of not having to install anything or maintain software on end user's machines. Reach and simplicity mattered more than anything.

Reach and simplicity are just as important today.

Usability tests have shown that an alarmingly high number of users are either confused or lose interest when an application requires installation. Meanwhile users burned by "malware" have been trained to answer "No" to any dialog requesting software installation.

In this environment, it should be considered a core requirement that when a user arrives, the application simply works.

As the SmartClient examples clearly show, compelling, responsive, high data volume business applications can be delivered without plugins. Where you must use plugins, for features like video, an Ajax-based application even has the flexibility to use the plugin each individual user has installed, providing far more reach than any single plugin technology can ever match. Risk The emerging plugin-based technologies are marketed with a virtually indistinguishable message of amazing richness and simplified development - just like any new platform.

When behemoths like Microsoft, Adobe and Sun go head to head, there's no telling who will come out on top. If you decide to use one of these platforms as the foundation of your application, you could easily pick the wrong one.

But if you choose Ajax, you can leverage them all.

Flex, Silverlight and Java can all be embedded within an Ajax application, but no plugin-based technology can be embedded in any other plugin. By using Ajax as the foundation of your application, you get the best of both worlds: a standards-based, truly zero-install approach for your core application and the ability to leverage plugins for niche uses until standards-based approaches are available. Integration The lingua franca of the internet consists of the international standards behind HTML, CSS and Ajax. When a product, application or website offers features that allow you to integrate it into your application or site, there will be an Ajax-based integration approach every single time.

Will there be an integration approach for the plugin you bet on? Not if they were busy working on supporting other plugins.

Interoperability is no longer optional. No benefit a plugin could possibly bring to the table is worth cutting yourself off from 3/4 of your potential partners, customers or affiliates. Security & Partnering Enterprise IT departments know: everything you add to a browser is another security risk.

In many large enterprises, especially those in the financial, insurance or defense sectors, security breaches would be catastrophic. The last thing that's appropriate in a security-conscious environment is a series of plugins from vendors in a desperate race to leapfrog each other.

For this reason, many of the world's largest enterprises set policies to remove, disable, version-lock or otherwise limit plugins. Common as they may be on consumer desktops, these plugins are frequently missing from business machines.

In today's connected world, these conservative security policies directly affect enterprises who would otherwise adopt unproven new technology. Enterprise IT is now expected to deploy applications for the use of customers and partners. Scaring off valueable customers and partners through the use of plugins is unnacceptable. It is just as unnacceptable to be forced into building and maintaining a parallel technology stack that avoids plugins: it means extra staff, extra servers, extra licenses.

Which leads to a simple mantra: if it's inappropriate on the extranet, it's inappropriate on the intranet. In this evolving Web 2.0 world, the infrastructure you assumed was internal may be repurposed at any time. It pays to stick with a technology that works in any scenario, and that technology is Ajax. Fallback options Plugin vendors tout that their technology is open source or an open source alternative is available. The implied benefit is that if you are desperate you might be able to fix problems yourself.

If a plugin vendor is not interested in prioritizing the fixes or features you desperately need, does having the source code to a plugin really give you options?

If you have the source code to the plugin, you can:

• patch the plugin, on all platforms
• negotiate deals with Microsoft, the Mozilla Foundation and Apple to bundle your modified plugin with their browsers
• wait 3 years for sufficient adoption

Don't be fooled by claims of openness. Source code access to an Ajax technology gives you real fallback options in a bad situation, but with plugins, the ability to get a plugin distributed worldwide is the true source of lock-in, and nothing else matters.