As I mentioned in an earlier post, the whole Ajax/Web 2.0 thing that’s happened this last year reminds me vividly of the mid-1990’s. Back then, the web was brand new, it was exciting, everyone was learning how to build web applications, developers were totally turned on and creative, everybody was pointing out cool new apps and sites, and the potential of this new computing platform seemed unlimited. Leading the charge was a young company that built software for every operating system under the sun, and they clearly had a solid vision of where they were headed. During 1994-96, Netscape introduced one astonishing new client-side technology after another to what a web browser could do–tables, animated graphics, client-side imagemaps, frames, cookies (yes, these really were a vital improvement to the web client), and something they called Javascript.

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.

Sensing the danger–in fact, being taunted with it by this upstart Netscape Communications Corp.–Microsoft dipped into its deep pockets and threw all its resources at thwarting that utopian vision. Microsoft knew it couldn’t stop the web from happening. This Unix-born technology was simply too potent a force. However, it could certainly make sure that when its customers reached for a web browser, that browser would be Internet Explorer rather than Netscape (or any other). Whole books have been written about that epic saga, and I could certainly sit here and write a dozen pages about it without even taking a bathroom break. But of all the things that Microsoft did, the most damaging to Netscape in the long run, and the act that virtually forced users into migrating to IE, was to introduce an incompatible document object model (DOM) and some incompatible Javascript extensions in IE 4.0.

I clearly recall attending a Microsoft briefing in 1997, when the company was starting to show off its own version of “dynamic HTML.” Netscape had a slight head start on DHTML, having introduced its 4.0 browser in the summer of 1997, several months ahead of Microsoft. (Of course, being the vaporware Microsoft it still is today, Microsoft behaved as if IE 4.0 and its version of DHTML had already been released by the time Netscape Communicator came out.) Netscape 4.0 was another leap in browser capabilities, continuing the innovative approach Netscape had wowed us with in prior years. Most significant was Javascript 1.2, with its layer tag, Javascript-accessible Cascading Style Sheets, and a continued strengthening of the Netscape DOM. The eye candy Microsoft was showing off in IE 4.0 looked great, too. However, unlike before, when Microsoft had played “follow the leader” with Javascript, the company now made a conscious decision to split Javascript into two incompatible halves. After IE 4.0, developers who wanted to build web applications that had a chance of competing against PC desktop apps would have 6 choices:

1. They could continue to ignore Javascript and stick to vanilla HTML with little client-side interactivity other than rollover images, doing their best to utilize graphics and great page design to wow customers,
2. They could try to develop rich DHTML applications that would work in both Netscape and IE,
3. They could ignore Javascript and introduce rich controls using Active/X (which would effectively bench Netscape from the game),
4. They could ignore IE 4.0 and write rich DHTML apps for Netscape Communicator,
5. They could ignore Netscape and write rich DHTML apps for IE, or
6. They could ignore Javascript and turn to a new client-side technology called Flash which, inexplicably, had ended up being equally supported by both leading browsers. (Of course, in 1998, Flash technology was pretty primitive compared with its 2006 abilities.)

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 layer tag had the ability to put bits of asynchronously loading content anywhere on the page, and it was incredibly easy to use. With layers, you could suddenly put layers on top of each other, and by combining Javascript, layers, and CSS you could perform amazing tricks such as drag-and-drop, or you could dynamically rewrite the page and the style of its elements.

Alas, we had only just begun to fantasize about the possibilities when Microsoft foisted the great Javascript/DOM Split on the world. By forcing a choice between Netscape and IE, and then illegally using its Windows monopoly to make sure customers didn’t choose Netscape, Microsoft ensured that its desktop monopoly would be extended to the browser market as well. You want the browser to be the OS? Sure… no problem… as long as you’re running IE on Windows, that is.

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.

A few brave souls tried to work at #2 by building cross-browser DHTML libraries and writing tutorials on the subject. But those of us who actually tried to satisfy both browsers–while also degrading gracefully to more primitive ones–found it was simply too hard to become a standard practice. A few DHTML widgets–mainly navigation menus of the cascading and tree variety–eventually became stable enough to work well in both browsers. Though these struggled along through the dark years between 1998 and 2005, most of the public web had to turn its back on Javascript, CSS, and the DOM.

Inside Intranets, a tiny percentage of companies like the one I worked for (Citibank) decided to ignore IE and build to Netscape’s DHTML model. A much larger percentage of developers took advantage of Microsoft’s dev tools to build apps that would work only in IE. Even larger still was the percentage that said “To heck with Javascript!” Just use VBscript and build Active/X controls! To my utter amazement, this latter impulse ended up overrunning company firewalls and making its way broadly into public websites.

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:

1. 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.)
2. 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.

So, with all this as prelude (and, like I said, I could continue preluding for quite some time on this subject…!), 2005 started with the amazing and improbable reentrance of Javascript as a respectable tool for web application development. At its side was a new kid called Ajax, which was a fancy name for a greatly enhanced version of the layer tag’s 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.

Despite Microsoft’s dominance of the web through Windows and IE, a significant portion of the developer community still cares very much about open standards, such as HTML, XML, CSS, and Javascript, and they actually have quite a few positive, platform-neutral trends on their side:

• 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:

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.

You simply can’t claim that your Ajax/DHTML library is cross-browser if it denies a user the right to select the best browser for her operating system. It’s for this reason that Opera is included here, because a number of studies have clearly shown that Opera bests Firefox at rendering Javascript, CSS, and other content types on a Windows PC. Likewise, if you want to be called “cross-browser” or “standards compliant”, you need to include Safari in your testing. Each browser has its own quirks, and Safari has its share. But not nearly so many today as does IE 6.0. If using your library forces developers to build web applications that overcome the quirks of Browsers A and B while ignoring the quirks of minority, but standards-compliant, Browsers C and D, then you can’t claim to have provided a Grade A cross-browser solution.

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:

1. 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).
2. DHTML-only libraries (these are toolkits that provide only the rich UI tools one needs).
3. Ajax-only libraries (ditto for the Ajax part of the equation).
4. 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 didn’t grade the Ajax-only libraries, because it’s not Ajax per se that causes browser incompatibilities. Rather, it’s differences in Javascript, CSS, and DOM implementations, and these are the components that together comprise what are known as Dynamic HTML (DHTML).

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.

Let me close this introduction by briefly summarizing the scores. First, despite my fears, and despite a few prominent Ajax/DHTML libraries that have a very narrow degree of browser support, I was delighted and surprised to find so many that made Grade A. Clearly, if you want to build astonishing Web 2.0 applications in 2006, you’ve got a lot of fine Javascript libraries to choose from! And nearly all of the Grade A libraries are open-source, so you can build without shelling out a license fee for the privilege.

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.

   

     

   

  

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-Only Libraries

Other Related Projects