as days pass by, by Stuart Langridge

It’s pretty foggy at the moment, here in the Midlands in the UK. It’s been like it for two days. Stepping out of work the other day, after dark, with each street light at the centre of a glowing aura, made the street I work on — in the centre of Birmingham — look like something Victorian. Like a woodcut from a Sherlock Holmes book. I wouldn’t have been at all surprised to see a hansom cab pull up and a man with a sword-stick get out.

Of course, I wouldn’t have been surprised to see Jack the Ripper hiding in a doorway either.

It made it feel like it was nearly Christmas, which it is. It was really rather difficult to remember that it’s still the same old modern street underneath.

So now I’m going to talk about JavaScript libraries. You’ll see how the fog is relevant in a bit.

There’s been quite a bit of discussion of libraries recently. Jeremy Keith writes:

There’s a lot of talk about JavaScript libraries, including a lot of hype and cheerleading, but I think that maybe the discussion is disproportionate to the amount of people actually using libraries. Personally, I’m somewhat mistrustful of using other people’s code (I’m a bit of a control freak) and I thought I was in the minority, but having spoken to people like Stuart and PPK who share my feelings, now I’m not so sure.

PPK himself says:

a quick and non-scientific poll @media showed that only a minority of JavaScript developers use a library; the others just code by hand. But JavaScript libraries are cool nowadays and will remain so until the Ajax hype blows over.

Chris Heilmann complains mightily about libraries in general, although about specific details rather than about the concept of using libraries as a whole.

And Roger lays into people who use them, too:

Overuse of JavaScript frameworks/libraries. Back to the 90’s, baby, except they were called DHTML libraries that time around. What is it with people learning a JavaScript library instead of learning to write JavaScript? It’s like learning Frontpage instead of HTML. Yes, script libraries can be great. But not when people use them because they can instead of because they should.

Lots of people are getting into the whole idea of using a JS library. Among the cognoscenti, though, there’s starting to be a bit of a backlash. “Putting guns in the hands of children” is how the discussion was phrased during our JS panel at @media 2006. The idea behind this discussion is that libraries give developers access to lots of cool powerful stuff — hiding and showing areas of the page, Ajax requests, animation — without them having to really demonstrate that they know what they’re doing. It’s an argument with a certain amount of truth in it; it’s used a lot by gun-control advocates as well, because if you have to go through five years of training to become a karate black belt then you’re much less likely to kill someone after leaving the pub, and much less likely to accidentally kill a member of your family, than someone who’s bought a Saturday night special and hasn’t had any training.

On the other hand, it’s a pretty elitist viewpoint. Apparently, you shouldn’t be allowed to use JavaScript unless you’re an expert. New developers, people just looking to get their job done, someone who wants to apply a cool effect: these people are not wanted in our glorious new revolution. Dammit, programming ought to be hard: it keeps out the idiots. This attitude comes up a lot, a lot, in the Linux world, and it’s one of the reasons why Linux is perceived as being harder to use than, say, a Mac: I’m surprised that there are Mac people out there who are highly happy* with the ease of use of their computers and don’t have to understand one iota about how they work under the covers, but still believe that JavaScript developers should be held to a higher standard.

What drives adoption of technology is real ordinary people, people who come in at 9am and clock off at 5pm and don’t think about work outside those hours, being able to use those technologies. JavaScript libraries bridge that gap. I’ve changed my opinions on this quite a bit; I used to hand-code all my JavaScript myself, and now, for quite a few of my projects, I use jQuery. I just got sick and tired of thinking: how do I hook up events in IE5.5? Is it different to 6.0? Where’s that cut-and-pasted code for creating and using an XMLHttpRequest object in every browser? I’d ended up building a tiny library for myself of bits of code I cut-and-pasted into every project, and my library was inferior to others because I don’t do as much testing in every browser. So, why not use a library? I couldn’t think of a reason. Now cross-browser testing is John Resig’s problem, which is handy.

The fog hid the nastiness of Birmingham. Libraries hide the nastiness of cross-browser scripting. While it’s easy to say that you should have to know about the nastiness, this is the season of goodwill. It’s nice to step out of your office into a foggy lit street that looks like a scene from It’s A Wonderful Life. Let’s not take that away from people.

This doesn’t answer Chris Heilmann’s objections, though, and that’s because they’re a damned good set of objections. The libraries we have are in general not well documented; a list of functions that the API provides does not help if you know what you want to do but not how to do it, because you have to guess at what the library might have named this function. Making the documentation available only online doesn’t help either, although this is something that really could be fixed by someone other than the main library developers — most documentation issues, including a proper decent set of examples of how your library can progressively enhance a page, with a case study or two, can be fixed by people outside the core team. So if you really hate this issue, jump in and get involved by building some docs for the library you like the most.

None of these problems are insoluble, though. Part of the issue is that JavaScript developers divide into:

1. People who aren’t hugely experienced with JS; these are at least some of the target market for a lot of libraries
2. People who are experienced and are writing a library
3. People who are experienced and think that you shouldn’t use libraries unless you have the experience to not use them
4. People who are experienced and willing to help

Of those, category 1 people aren’t going to help write documentation very much, or case studies, or browser support matrices, because they’re consumers of that information rather than creators. (Those of you who think “yes! we’ll have a huge army of people contributing!”, take a tip from the Linux world, where we’ve been using that model for code since the beginning; it happens, but not all that often.) Category 2 people are too busy writing a library to build supporting stuff around it. Too many of the remaining: people who could be helping to make the libraries we have better, and better documented, and more appropriate, and less stuffed to the gills with flashy but bad effects, are too busy repudiating the entire concept of libraries. They’re in category 3. If we can collectively, as a community, move from category 3 to category 4, and make the libraries we have great, then there won’t need to be any kind of objection to them. Let’s try and help.

This entry was posted on Sunday, December 24th, 2006 at 1:02 am and is filed under JavaScript and the DOM, Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.