I was writing up some notes for my next guest spot on the Lab with Leo next week (which will appropriately be about comparing and contrasting AJAX frameworks) when I realized that I probably shouldn’t let all this research and paraphrasing work that I’ve put together go to waste. Most of it won’t make it on air, I’m sure, but it seems useful to make it available here in case anyone is curious. This also just happens to be relevant to (and also completely unrelated to) Brian LeRoux’s Vancouver AJAX & Beer meetup which is happening tonight over at the Irish Heather (and which I will be most enthusiastically attending as soon as I post this article.)

What my (non-scientific) research ended up becoming is basically a modified SWOT analysis. I did quite a bit of digging on the pros and cons of various AJAX frameworks that I didn’t have much experience with (most of my work has been with the YUI and script.aculo.us), such as MooTools, ext.js and Dojo. Not to mention the more highly-coupled frameworks out there like ASP.NET AJAX and the Google Web Tookit. During said digging, I failed to come across much in terms of recent comparisons between frameworks, so it seemed like a good idea to post up the rather high-level view of the different popular frameworks available that I’ve put together. Doesn’t hurt to let people comment if I’ve mucked something up or missed anything important, too.

Acknowledgements: Thanks to Steve Calvert (or nu-steve, as we like to refer to him here) at OpenRoad for his insight into working with MooTools, which I had very little knowledge of.

This is all pretty much point form, but it may still be useful to you as it’s pretty concise. I won’t go into any kind of detail into what exactly comprises an AJAX framework, since I assume that you wouldn’t be reading this post without already being somewhat familiar with AJAX. 

I’ve covered five of the most popular frameworks here; there are many others, but these are the ones I’ve worked with or heard a lot about, so I’ll stick to what I’m familiar with. It’s highly likely I may have excluded your favourite framework, so try not to take offense. :)

Yahoo User Interface Library (YUI) (http://developer.yahoo.com/yui/)

Strengths:

• Very flexible; wide variety of controls and effects available
• Extremely well-documented; PDF cheat sheets and lots of examples available
• Large user base, including many large sites
• Updated frequently, well-supported
• YAHOO is very involved with the YUI user community; huge developer community
• Very component-ized, easy to only use what you need
• Includes Rich Text Editor component (currently in beta, but works nicely)
• Controls are relatively easily skinnable

Weaknesses:

• Code-heavy (large JS & CSS files even after being minified, lots of includes = code bloat)
• Namespace structure can make for overly verbose code, but are a necessary evil of  using the YUI
• Lack of native JavaScript extensions (mostly due to the namespace system, but still noticeable when switching from a framework that has them)

script.aculo.us & Prototype (http://script.aculo.us/)

Strengths:

• Lightweight, tight code
• Lots of native JavaScript object extensions
• Better support for the traditional object-oriented programming model (OOP)
• Excellent Ruby on Rails integration (ships with it)
• Logical method naming, avoids namespace confusion

Weaknesses:

• Serious lack of proper documentation and examples
• Small set of core effects and controls

Ext.js (http://extjs.com/)

Strengths:

• Well-documented & well-supported
• Fantastic, flashy UI for user controls; works nicely cross-browser
• Very well-suited to an administration interface
• Large user base, including some heavy-hitters (CNN, Adobe, Sony, Canon)

Weaknesses:

• Often criticized as “just a widget library with a catchy UI”; lacking in other AJAX functionality
• Relatively new framework
• Commercial license required in for-profit use; open-source license for non-profit use

MooTools (http://moofx.mad4milk.net/)

Strengths:

• Lightweight code & well documented
• Excellent, rich animation framework (reverse engineered from Adobe Flash)
• Intuitive JavaScript object extensions (major plus for development)
• Handles DOM manipulation and element selection very well

Weaknesses:

• Doesn’t always play well with other JavaScript frameworks
• Smaller set of controls
• Developers don’t listen to community feedback

Dojo Toolkit (http://dojotoolkit.org/)

Strengths:

• Rich API including an elaborate graphics package
• Excellent infrastructure: includes Java-like package system and optional build tools
• Provides two data storage mechanisms
• Local client-side storage via XPCOM (Firefox) or ActiveX (IE)
• Server-side via various mechanisms
• Built-in internationalization support
• Dojo Foundation has support from IBM and Sun

Weaknesses:

• Very poorly documentated
• Serious lack of demos / examples available
• Badly designed UI
• Heavy page load time
• Difficult to implement custom controls

Other Options

In addition to the open-source frameworks I’ve listed above, there are some other, large vendor-backed, slightly less open implementations out there too. Most of the vendor-backed implementations are very well-documented and well-implemented. However, I won’t go into any detail on these (maybe I’ll save them for another post), as I haven’t really worked with any of them except Atlas, and that was before it was formerly released as “ASP.NET AJAX.”

• Microsoft ASP.NET AJAX (formerly “Atlas”)
• Adobe SPRY Framework for AJAX (HTML/CSS/JS centric, designer-oriented)
• Google Web Toolkit (GWT)

Choosing a Framework

There are two main types of AJAX frameworks available currently: what I like to call loosely-coupled and highly-coupled (or tightly-coupled) frameworks, specifically in how they pertain to integration with back-end technologies. Highly-coupled frameworks may work for you in very specific cases and integrate very well with your server architecture, but by default will tie you to a specific platform. Loosely coupled frameworks may require more front-end JavaScript but allow for portability of code and less dependence on server-side technology.

Examples of this breakdown:

• YUI / script.aculo.us are loosely-coupled and don’t depend on any back-end technology
• ASP.NET AJAX and GWT are both highly-coupled and depend on ASP.NET and Java

Common Pitfalls

The grass is greener syndrome 

Companies need to try and avoid writing reams of code on a project, then switch frameworks because the other one has a better widget. I think a lot of people have been guilty of this one, including myself. A lot of that may have to do with the fact that AJAX is a maturing technology and new framework implementations are released on a regular basis, so sometimes the “grass is greener” approach is actually mandated by an improved framework. Just keep in mind that you are always going to spend a serious amount of time switching a large application over from one framework to another. It shouldn’t be a decision that’s made lightly.

Avoid the temptation to mix and match AJAX frameworks

It may be very tempting to look at one framework, then another, and say “well, I’d love to use the YUI Rich Text Editor, but I also want the Dojo charting engine.” It may seem as simple as dropping in the required JavaScript files for both libraries, and away we go. However, this leads to several nasty side effects, including:

• Code bloat: loading multiple libraries make for huge page load time for your readers
• Conflicting functions or object prototype methods (many libraries provide similar, if not identical core functions)
• Applications become much harder to maintain, especially in a team environment

Conclusion

While it’s hard to recommend a single AJAX framework, I think the choice (or hell, roll your own) is pretty subjective, and really depends on what you’re trying to accomplish in your application or site. There are definitely some guidelines to stick to when choosing a framework.

Try and make sure you address the 80-20 rule and be sure that your site is getting the most out of the framework you select. Take into account not only the controls and functionality you get out of the framework, but also the support available from the framework’s developer, the community surrounding the framework, and what kind of future the framework has. Things like whether it’s being developed by a single developer on his spare time versus a multi-billion dollar company will start to come into play if you’re looking at choosing a framework for your organization, and not your own blog.

Hopefully this has been of some use to you — I’d love to hear feedback on anything important that I may have left out, or comments about my conclusions.

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

Posted in Code, General, Web 2.0 |

Tags: ajax, frameworks, comparison, swot, analysis, javascript