- Reviewed and rated Spry, Jitsu, and Morfik toolkits.
- New article summarizing recent additions and changes
Each of these technologies offered dramatic new ways of presenting information in a web browser, and developers who loved new gadgets glommed on to every advance, racing each other to see who could do the coolest things with these first. A lot of mistakes were made–a lot of really ugly eggs were hatched–but excitement and optimism were the buzz feelings. With Netscape in charge, you felt like you do when working as a protege with a master hacker: Does this guy ever stop pulling amazing tricks out of his sleeve?
One of the promises of Netscape’s vision was that the web–and, in particular, the web browser–could make one’s choice of operating system irrelevant. The web could level the computing playing field, since applications built for the web were applications for all, regardless of what OS you happened to prefer. What worked for NeXT, OS/2, Irix, Solaris, and Windows would also work just fine on Linux, Mac OS, Be OS, HP-UX, and BSD. The web browser could be the OS, and the only limiting factor in what you could do would be your hardware and connection speed. Microsoft’s lock on the computer desktop could be broken, and new competitors in operating systems and computers could unleash the full potential of the personal computer to improve our lives–both at work and at leisure.
Only, it didn’t quite turn out that way.
- They could try to develop rich DHTML applications that would work in both Netscape and IE,
- They could ignore IE 4.0 and write rich DHTML apps for Netscape Communicator,
- They could ignore Netscape and write rich DHTML apps for IE, or
Prior to this, those of us who believed in the potential of a DHTML-driven Web couldn’t wait to begin writing interfaces that would take web applications to a new level. If people thought the web was cool in 1997, just wait a few years… this halting page-refresh after page-refresh model could now be broken. Netscape’s
So, what did web developers do when confronted with this choice back in 1997-98?
Those who wanted to keep the web open and standards-based typically went with #1, and that included the vast majority of e-Commerce firms like Amazon.com and eBay. Only a very small percentage opted for #6, reflecting an aversion to relying on browser plug-ins for core functionality that continues today, perhaps with implications for Laszlo and the other rich-interface frameworks that rely on Flash.
Why was I amazed at the spread of Active/X?
Well, it was just such a devastating lack of collective judgment in the web programmer community. Active/X did two very bad things to the web and to personal computing:
- It built a direct route for writers of viruses, worms, and other malware to infiltrate the Windows operating system. Not that Active/X was the only way in. But it sure was low-hanging fruit, particularly given how easy it was to write and deploy the controls. Microsoft’s irresponsible implementation of default browser options for Active/X in IE, together with its abysmal user interface for “Internet Options” in general, helped grease the skids that has ended up costing the U.S. and world economies untold amounts of money and time in a seemingly futile battle to stop these villains from taking over company and personal PC’s. Sure, we now have a vibrant and healthy information security industry. But claiming that’s a good or inevitable thing is like arguing that disease is something you can only address by building more hospitals and insurance companies. Yet, when was the last time the health care industry gave us a disease that put hundreds or thousands of people out of commission all at once? When was that, like 1919? Unlike the computer industry, where vast numbers of otherwise intelligent people act as if Windows were the only game in town, in health care they actually have competition and hordes of highly motivated people trying to solve health problems by developing new medicines and new techniques. Gee… sounds a little like the open source folks, doesn’t it? (Hint, hint.)
- Using Active/X turned web applications into Windows applications, effectively putting up a “Macintosh and Linux users not welcome” sign on website after website for several years. Ironically, one of the things that’s saved the web from turning into a big Windows desktop by now has been the persistent, relentless attacks on it by malware entering via Active/X.
src attribute from 1997. We have Google to thank for recognizing that the time was ripe, once again, to begin expanding the web application’s potential. With Google Maps and gMail, Google had the market power to showcase some truly amazing and Different apps that got a lot of geeks thinking “outside the box” again after many years.
In Google’s wake came a sudden stream of tiny companies with new and astounding applications like Backpack, JotSpot, Writely, Net Vibes, Rallypoint, and Basecamp. Also last year, Firefox started breaking down the IE wall and gaining noticeable market share. Apple’s Mac OS X was also gaining market share for the first time in years, evidenced by a doubling in Safari’s share of the web browser market.
And that’s when it hit me, some time last fall: The vision of a rich and OS-agnostic web was still possible, after all.
- In the years following the w3c’s blessing of its own DOM (which was different still from the 1997 Netscape and Microsoft models), both IE and the Mozilla open-source juggernaut had migrated toward common ground. Significant differences remain, but they no longer seemed insurmountable.
- Years of struggling with the browser incompatibilities had yielded a large number of stable hacks that could make things work roughly the same across the big IE/Mozilla divide.
- Years of neglect for IE had allowed both Mozilla/Firefox and the newly standards-based and open-sourced Safari to gain mindshare and momentum away from proprietary extensions and toward standards-based, open-source solutions.
- Years of wrestling with viruses and worms had begun to force Active/X out of the developer’s toolkit for web apps
- Personal computers themselves were vastly more powerful than in the 1990’s, and computer users had faster and bigger pipes connecting them to the net… making it easier to contemplate stuffing richer client loads into them.
And finally, the “modern” browsers–particularly Firefox and Safari–had by now implemented most of the advanced CSS elements and methods that we had drooled over in the late 1990’s. (It’s worth noting that the Netscape/IE battle brought the exciting CSS specification to a virtual halt in 1998, when CSS 2.0 became an official recommendation, only 2 years after finalizing CSS 1.0. After that, it took 4 years for CSS 2.1 to even reach the draft stage.)
So last fall, once it seemed likely that Ajax was going to stick around for a few years, I dove in and began checking out the large array of new toolkits that were available for Ajax and DHTML. It wasn’t long before I started worrying again. It turns out that some of these libraries actually supported only IE, or only IE and Firefox, or (in one case) only Safari. Most alarming was the large percentage of Ajax/DHTML libraries that failed to include Safari. Since Safari had just last fall distinguished itself by becoming the first browser to pass the Web Standards Project’s Acid2 test, this made me worry that IE’s hold on the web–and on the hearts, minds, and wallets (primarily wallets, truth be told) of developers–was still too strong to shake. If that was the case, would the trend toward Firefox and Safari continue once Microsoft actually updated its browser to version 7.0, which presumably would arrive with new bells and whistles appropriated from the pioneers, and hopefully in a sandbox a little safer than Windows XP?
Naturally, as a user of a “minority” operating system, I am a strong advocate of an OS-agnostic web. The standards set down by the w3c are amazingly powerful, and if computer users could have browsers that actually implement those standards in full, we could have not only the promise of truly rich, exciting, and time-saving web applications, but the freedom to choose our operating system without worrying so much about incompatibilities.
In other words, 2005 was starting to look a heckuva lot like the mid-1990’s to me. But this time, I’m hoping things can turn out differently. With Microsoft distracted by Apple’s surprise win in the music download game, and with IE still holding a very comfortable 85% share of the browser market, maybe they won’t try to ruin everything this time.
So, after googling around a bit, I decided to try to document the current state of things. I set about to compile a comprehensive list of all the Ajax/DHTML toolkits that web developers now have to choose from, and then to test those toolkits against a standard for cross-browser compatibility. In doing so, I made use of several existing lists:
- One from a fellow geek-oriented blogger, Ian Sheridan at Savage Vines
- One from the Ajaxian website,
- One from the Open Source Application Foundation (OSAF), and
- One in that great 2005 book on Ajax, Ajax in Action.
Even with these four large lists, I had found several on my own that didn’t exist in the other lists, and a few new ones emerged in just the last 2 months. Given how fast this Ajax steamroller is moving, I won’t be surprised if my own list is obsolete within a week or two. However, I am going to try to keep it current–both by adding and grading new libraries as they announce themselves and by updating grades as existing libraries update themselves. And with a Web this big, I’m certain there are Ajax/DHTML toolkits that I simply don’t know about yet, but hopefully these will get a nod in the days to come, from either their loving owners or adoring fans.
Now, everybody is going to define “cross-browser” slightly differently, so I wrote down a grading system to use in measuring each DHTML/Ajax library. The cross-browser ideal is a library that is tested and certified against all of the major browsers–defined as IE, Firefox, Safari, and Opera (including browsers that share “core” rendering engines with these)–and that theoretically supports any browser that claims to be compliant with the w3c DOM. The least desirable library is one that the developer will certify to run only in IE (or, let’s say, in only one of any of the major browsers). Here, then, moving from ideal to nadir, is the grading scale:
|A||IE 6 ↑
Firefox 1.0 ↑
Safari 1.2 ↑
|B||IE 6 ↑
Firefox 1.x ↑
Safari 2.x ↑
|C||IE 6 ↑
Firefox 1.x ↑
|D||IE 6 ↑
Firefox 1.5 ↑
|E||IE 6 ↑|
Now, many well-intentioned developers think they are providing a cross-browser library if they certify it against only IE and Firefox on a Windows workstation. But this is a completely Windows-centric perspective, whether such developers realize it or not. Safari is to the Macintosh what IE is to Windows–in a positive sense, though, not as an illegal monopoly strategy. It’s perfectly possible to remove Safari from a Mac OS X computer and never miss it, whereas Microsoft will presumably insist until the day it dies that removing IE from Windows would cripple the operating system.
Therefore, to deliberately exclude Safari from testing, and therefore from making the few minor tweaks that might be needed to raise one’s library to the cross-browser ideal, is to deliberately exclude Macintosh users from your worldview. Yes, Mac users can switch to Camino, Firefox, Netscape, or any number of other Gecko-based browsers, or they could use Opera or iCab or other completely different browsers. Camino is particularly popular with some Mac users–me included–who at a minimum insist on a Cocoa-based web browser that takes advantage of all the Cocoa framework has to offer. I switched completely to Camino some time during Panther, because it was so noticeably faster than Safari. But with Tiger, I switched back, since Safari 2.0 was once again head-and-shoulders above the Gecko crowd in a number of ways.
Some of these libraries have partial support for Firefox, or for Safari–that is, some functions work, and some don’t. This is also taken into account. During the testing, I made use of all the online demos that were provided (or tried to download and test in the few cases with no online demos), and I independently certified those libraries against both Firefox 1.5 and Safari 2.0 on Mac OS X 10.4 (Tiger). In a small number of cases, a developer claimed that their library worked in one of these browsers, but in fact it did not.
In the lists that follow, I’ve included a “Notes” section for each entry that records various observations about the libraries and their attributes–open source or commercial, well documented or not, freely downloadable or not, etc. However, the only attributes that count toward a given score in this “shootout” are those that affect a library’s level of commitment to a cross-browser standard.
It was relatively easy to divide the different libraries into four categories, only the first two of which were actually rated:
- Ajax/DHTML libraries (these are comprehensive toolkits that provide functions both for asynchronous user interactions and content management and for the user interface effects and GUI widgets that together define a Web 2.0 application).
- DHTML-only libraries (these are toolkits that provide only the rich UI tools one needs).
- Ajax-only libraries (ditto for the Ajax part of the equation).
- Other Related Projects (this is where items from the four starting lists ended up if they either seemed too insignificant to include, were too narrow in scope to fall into any of the other categories, weren’t libraries at all but rather related resources, or were unavailable due to server problems on multiple occasions when I visited for testing).
I’ll bet some of you are starting to wonder, “When is he going to shut up and let me see the scores?” If that’s you, rest assured… I’m almost done.
There are 18 A-graded Ajax/DHTML libraries out of 42, and 8 A-graded DHTML libraries out of 15, and at the bottom of the barrel are 3 Ajax/DHTML scoundrels I had to grade E, and 6 that get a D.
|Ajax/DHTML Libraries||DHTML-only Libraries|
|THE GOOD GUYS (Grade A Toolkits)|
|Dojo Toolkit||DHTML Kitchen|
|Echo 2||DynAPI 3.0|
|jQuery||Todd Ditchendorf’s DHTML Gallery|
|Yahoo! User Interface Library|
|Zapatec Ajax Suite|
|THE BAD GUYS (Grade D or E Toolkits)|
|EBA Ajax||Plex Toolkit|
|TIBCO General Interface|
As a final note, I have included Apple’s Dashboard Widgets framework in the Ajax/DHTML Libraries list, but refrained from grading it since it’s not offered as a toolkit for building websites. If it were, of course, it would be graded “E”, since it only supports one platform. For those of you who are wondering why Dashboard Widgets would be here at all, be sure to read the notes about it in the list below, and check out the resource links I’ve provided. Widgets are simply little Ajax/DHTML objects that live outside of the browser. AOL and Microsoft are both trying to copy the idea for their own platforms, and Yahoo, recognizing how cool they were, bought Konfabulator, which originally brought a version of widgets to the Mac OS X platform. Naturally, Yahoo is calling Konfabulator “Yahoo! Widgets” now.
Ajax/DHTML Libraries (42 Libraries)
DHTML-Only Libraries (15 Libraries)
Other Related Projects
- - Upgraded Backbase to C after confirming it works in Firefox 1.5
- Added AHAH and DWR to list of Ajax-only libraries
- - Added My-BIC (Easy Ajax for PHP) to list of Ajax-only libraries
- - Moved Behaviour from Ajax/DHTML list to “Other Related Projects” list, since it’s really an add-on to prototype.js rather than a standalone library.
- Added jQuery to list of DHTML/Ajax libraries with a grade of “A”. This new library gets better all the time and is well worth a try!
- - Added Alf Magne Kalleland’s DHTML Goodies website to the Ajax/DHTML list. The site opened up in September 2005.
- - Removed grade for Microsoft Atlas, pending an evaluation. When the scorecard was prepared a month ago, little of Atlas was available for testing, and what there was was for Windows IE only. The original grade–E–was consistent with the company’s traditional strategy of locking non-IE browsers out of web applications developed with Microsoft developer tools. I hope to have an evaluation completed within a week.
- - Added review and new grade for Microsoft’s Atlas DHTML/Ajax toolkit. See accompanying article, containing a full explanation and test results.
- - Updated information for Backbase. Backbase released a public preview of a future version of the product, which has partial support for Safari and Opera.
- - Added six new libraries that need to be reviewed and rated:
- Google Toolkit
- Echo 2
- LINB, and
In addition, I plan to revisit the scores for Atlas and Tibco General Interface, as a result of recent updates to those libraries. For now, this article has brief descriptions of and links to the new libraries, but no ratings yet.
- - Reviewed Echo 2 with an “A” rating.
- Reviewed Google Web Toolkit with an “A-” rating.
- Updated information for Dojo and AjaxFace.
- Removed AOL’s “I Am Alpha” entry, since it’s now clear that it is an Ajax-enabled application, not a library for building Ajax applications.
- - Reviewed Neuromancer with a “C+” rating.
- Reviewed jsLINB with an “A-” rating.
- Reviewed the latest build of MochiKit and raised its rating to “A”.
- Revisited the Rico library and lowered its rating to “B”.
- - Reviewed Zapatec Ajax Suite with an “A” rating.
- - Reviewed ZK, which gets a “D+” rating.
- Tibco General Interface revisited, rating of “E” sustained.Â
- - Added newly released Ajax/DHTML toolkit Jitsu for review.
- Revisited ICEfaces framework and raised grade from “B” to “B+”
- - Reviewed the latest version of Atlas, which has 4 new controls since April. Â Support for Safari and Opera both declined, despite Microsoft’s statement to the contrary for Safari. Â Grade remains a “D”.
- - Published followup article summarizing the Ajax toolkits added since March as well as those revisited. The summaries of each library presented there are also included in the main lists in this article.
- - Added two new libraries that need to be reviewed and rated:
- Spry Framework for Ajax, and
- Morfik WebOS AppBuilder
For now, this article has brief descriptions of and links to these four libraries, but no ratings yet. Also added XAP (Extensible Ajax Platform) and CFAjax to the Ajax-only list.
- - Reviewed Spry Framework for Ajax, with an A rating.
- Reviewed Jitsu, also with an A.
- Reviewed Morfik WebOS AppBuilder, which gets a C.
- Added UniAjax to the “Other” toolkits list.