JavaScript Libraries Suck

JavaScript libraries are awesome – they make it possible to develop cross browser coolness without going completely insane working around all the incompatibilities. The trouble is, we’re talking about JavaScript libraries. Instead of working around differences in browsers, now you work around differences and incompatibilities in JavaScript libraries.

While the simple response is to just pick one and stick with it, there are some problems with that:

If you’re developing a library, you will very likely have users who are already committed to a particular library.

If you’re using libraries, sooner or later one will require the other library. You know, the one you didn’t pick.

The new banner on the Ephox.com homepage is a good example1. The site was really simple so I went ahead and picked the JavaScript library I knew best – Scriptaculous and Prototype. I developed the script to get a nice cross fade between the two images and went to put it up on the live site. At that point, I discovered someone else at one point had decided to use a lightbox library. As Murphy would have it, it depended on JQuery.

Of course, since I’m rather keen to keep the JavaScript nice and generic so it can be reused in other places (like say our LiveWorks! site which does use Prototype), I was going to wind up having to support both JQuery and Scriptaculous at some point anyway, but I was hoping to put that off for another day.

In the end I nearly doubled my development time as I had to factor out all the bits of code that used one of the libraries and make them switch dynamically depending on what was available. So now the libraries are taking care of the tricky browser differences, but instead of making development easier, they’re actively making it much harder and slower again.

So what’s the answer? Well, one answer would be for these libraries to play nice with each other and in fact JQuery has an option that does exactly that, but there’s no guarantee that the libraries will actually work with it in that mode, and you give up a bunch of it’s shortcuts.

You can namespace everything (effectively what JQuery’s compatibility mode does) but again, that makes code more long winded again. I guess that’s the best available option beyond standardising some of the base level elements. So define what the $ and $$ functions are (or just ban their use and actually remove them from libraries so you know they aren’t being depended on). Then you have the various things like Prototype’s .parseJSON function it adds to strings and various other really handy functions which you could standardise but there will always be some functions that are currently in the innovation phase and wind up clashing.

So I don’t know what the answer is, but right now the JavaScript language is effectively forking in many different directions. You don’t code in JavaScript anymore, you code in Prototype, JQuery, Dojo or YUI. It’s a bit like picking Struts 1, Struts 2, Spring or whatever MVC library in the Java world but with more far reaching consequences.

It seems to be that all this innovation and reuse in JavaScript is really starting to inhibit innovation and reuse in JavaScript.

1 – you may need to watch for about 10 seconds to see the JavaScript kick in and cross fade the main banner. ↩