Warning: Undefined array key "HTTPS" in /home/weston/www/weston.canncentral.org/writing/EmbObjs/Weblog/Weblog.class.php on line 40
Weston Cann - I Can't Believe It's Not Blogging

I Can't Believe It's Not Blogging

The Message is Medium Rare

Mantra for Crossing the jQuery Divide

Apr 7 2011

jQuery's been out for 5 years now, and I think there's still a large audience -- even among people who use it -- who don't understand what it actually is. You see a certain misconception show up in this April Fool's Joke, in StackOverflow questions, Metafilter comments, and all the time among developers who don't really have their JavaScript legs yet: the idea that jQuery supercedes JavaScript, that with jQuery, you abstract away having to deal with crappy features and gotchas of JavaScript and can focus on developing your applicaiton.

To some extent, I think it's an easy mistake to make. An examination of a number of the other JavaScript libraries out there seems to reveal salient features apparently motivated by a certain amount of distaste for the JavaScript language itself. Both Prototype and MooTools seem to believe it's important to offer developers an API for class hierarchies. Other libraries take this a bit further: not only do they eschew the prototype-focused nature of the JavaScript language, they seem to also reject the document-centric nature of web applications. Finally, though they aren't properly "JavaScript libraries", solutions like GWT and are the ultimate expressions of avoidance, relegating JavaScript and the browser to more or less just another target one compiles to.

There seems to be an awful lot of effort out there going towards avoiding having to learn or write JavaScript. And jQuery does indeed provide some great abstractions that make a number of formerly hard things so much easier that you end up writing much less JavaScript.

These two things are close enough that it's not hard to get them confused.

But jQuery doesn't replace JavaScript, of course; it replaces the DOM API instead. It turns out that was the painful part of most browser scripting to begin with. Not just the niggling little differences between the various browsers: most of the APIs themselves were clunky, class-heavy abstractions demanding repetition and verbosity. And that was when they worked as expected.

jQuery provided the rare abstraction layer over the DOM API that multiplies power in a developers's hands and delivers on its promise to let them write less and do more. And it didn't do so by superceding its host language or attempting to emulate common features of other languages. Rather, it's a very strong example of what can be done with the core power of JavaScript by embracing its functional and prototypical heritage. The pervasive use of fluent chained method calls and the first-class nature of functions weren't strictly groundbreaking when jQuery was introduced, but it may well have done more than any other piece of code to popularize both techniques, bringing them out of the realm of experimental, acadmeic, and niche application and into colloquial usage among the rank and file.

The only problem being, of course, the apparent and corresponding chronic low-grade misunderstanding among some of the aforementioned rank-and-file that these are jQuery idioms (rather than broadly applicable ones)... and that they're writing "jQuery Apps".

Rebecca Murphy calls this the jQuery Divide and suggests a number of key principles and tactics for educating developers. I think that while most of them are worthwhile considerations, they're also all things that need to follow the very first step: spreading the understanding that jQuery doesn't replace JavaScript, it replaces the DOM API.

With the absorption of this mantra comes at least a rough understanding that even with the power that jQuery can put in a journeyman's hands, there's still an entire field of knowledge and skills to be developed... and the confidence that comes from knowing they've already gotten a good start.

Leave a Reply