Ongoing JavaScript library discussion

2007-01-21 06:29:00

PPK over at QuirksBlog has a nice entry on the latest round of discussions about JavaScript libraries in the JS/DOM/CSS blogging world.

The JS library thing continues to provide rich fodder for discussion because it involves so many different layers -- what type of app you want to use the library for, your level of skill with native JS/DOM/CSS, the coding style you're comfortable with, your tolerance for sloppy/undocumented code, your tolerance for download size, your tolerance for corporate overlords, how well your goals align with the goals of the toolkit developers, and so on.

PPK starts off by referencing a post I read last week or so from Stuart Langridge (author of DHTML Utopia, and the tech reviewer for my book), where Stuart seems to moderate a lot of the serious anti-library leanings he used to have. Ultimately however, I don't really buy PPK's final point -- he believes that the current lack of doco means that the only people who can use the toolkits are the experts who don't need them. He writes:

Right now it doesn't seem that Stuart's nine-to-fivers will actually benefit from libraries, unless they're pretty decent scripters to begin with, which makes their using a library less necessary (hence less likely).

First of all, I think there are plenty of nine-to-fiver developers out there plugging in one toolkit or the other, squinting at the scant online docs, and hammering at it until they get it to do what they want. For most of those guys it still beats trying to write a CSS fadeout transition from scratch. And second, it's pretty obvious even to a diehard do-it-yourself-er like me that even experts can get a lot of benefit from leveraging the work of a larger group of experts like themselves.

Similarly to Stuart, my opinion of the use of libraries or toolkits has evolved, as the kinds of things I want to do with JavaScript has changed, and as the quality of the available libraries has improved. Relying on a set of tools used by a larger group of developers gives you significantly more power with a lot less effort than if you were to try to do all that stuff yourself.

But you do give up some degree of freedom. In the words of Wooderson, "Oh, yes you do."

First of all, you have to do some stuff the toolkit's way whether you like it or not. I've used both Dojo and Prototype now enough to know that both of them do things in ways that seem less than optimal to me. Dojo's packaging and namespacing stuff feels kind of Byzantine and overengineered to me, for example. Prototype's Event.observe is pretty underwhelming, and I find the bindAsEventListener thing seriously awkward. Not to dump on those two libraries -- in return I get a bunch of well-tested functionality for free.

More importantly, you become dependent on the developers of the library to implement the features and fixes you need. If you've got that library code rooted deep in your app, it becomes a genuine concern to you that the library developers not do things that will totally break your shit. In theory, you do always have the freedom of not upgrading your main JavaScript library. Ever. But how appealing is that in a serious Ajax app that's under heavy development?

We use Dojo in the Cosmo app, and the news that Dojo is jumping from 0.4 to 0.9, with no backward-compatibility code in the new version, doesn't give me a warm, fuzzy feeling inside. Libraries are supposed to make your life easier, and the words "comprehensive porting guide" sound suspiciously like "a bunch of extra work" to my jaded ears. I'll withhold judgement until I see how extensive the changes are.

I feel like now I have a pretty even-handed view of the positives versus the perils of using a third-party toolkit in your Web app. The peril part is one of the reasons I keep working on the Fleegix.js library for use in my personal projects. Okay, that, and the fact that I just genuinely enjoy playing with this stuff.


mde (2007-01-26)
Good comments. Sure, throwing out backward compat makes the framework developers happy, because you don't have to wrangle ugly, icky old APIs. Developers hate working on old code. And it doesn't bother people like independent consultants much who work on projects one after the other, and don't touch them again. My angst comes from wanting to manage a codebase over the long-term -- and now upgrading this third-party code is highly likely to break stuff. I understand the motivation for doing it, and it may be better to do it now than later. I guess we'll have to wait and see how Dojo 0.9 turns out.

Mikeal (2007-01-21)
Dojo seems like it was rushed out into the public before it was really as ready as it should have been. If it were up to me I'd probably ditch backwards compatibility in every version until 1.0 to make developing the framework easier until it was really ready. Yeah, it would keep people from adopting it but it would provide a better playground for developing the framework. As a side note, I started checking out MochiKit a bit more -- the new video makes this a fairly lazy task. Not too shabby. "That's why I love these high school girls man. I get older. Theystay the same age. Yes they do" -- Wooderson (quote has nothing to do with comments whatsoever)

Chris Barber (2007-01-21)
I too use Dojo in my projects, but I couldn't be happier that Dojo is ditching backward-compatibility. Javascript isn't pre-compiled, so those extra bytes of deprecated code just bloats the toolkit. The bigger the Javascript files, the longer the transfer time and the longer it takes to parse the file.


This is the blog for Matthew Eernisse. I currently work at Yammer as a developer, working mostly with JavaScript. All opinions expressed here are my own, not my employer's.


Previous posts

All previous posts ยป

This blog is a GeddyJS application.