The Future of JavaScript Libraries

Libraries have been a huge contributor to the surge in popularity of JavaScript in the last few years. JavaScript developers have had the cumbersome tasks lifted and have been able to get back to business in developing interesting solutions to interesting problems.

I’ve been thinking about the next steps for JavaScript libraries, and I really would like to see the separation of the engine from the API. My gut tells me we’re close.

Selector Engine Portability

There’s a lot of discussion about the speed of a library’s selector engine, but the bottom line how you use your selector engine. Which is why I want to customise this choice to my application.

So what do I mean by selector engine portability?

I mean I want to be able to chop and change the selector engine depending on the project I’m working on.

For example:

  1. I’m building a full desktop web application – I want to use as complete as possible selector engine.
  2. I’m building a version of the site specifically for the iPhone – I only want to use querySelectorAll because I know it’s supported.
  3. I’m building a lite/fat free version that will be accessed by mobile devices, so I’ll limit my JavaScript to just targeting elements by id to keep the work as tight as possible.

There’s so much work going in to selector engines right now (has been for a few years now, but the bar keeps on getting raised). So there’s more and more choice of raw selector engines especially if you’ve got a good idea how you want to optimise your application.

John’s sizzle library has already been alluded to being portable (or certainly that’s how I’m reading into it) – and what I’d really love to see is:

  1. Whether we can write plugins (or hacks if you like) that allow new engines to be shoehorned into the library (jQuery, Prototype, Mootools, etc).
  2. Will future versions of popular libraries will support a pluggable query engine.

My feeling is that the developer should be able to select the selector engine based on the application’s specific needs.

API of Choice

Once you’ve separated out the engine, the library selected is really a matter of preference. Which ever grammar suits you best.

In addition, the separation would allow more companies to create their own libraries based on existing engines or APIs. For example, I remember reading (somewhere…) that one of reasons the BBC created Glow, their own JavaScript library, was because (the latest) jQuery didn’t support Safari 1. However, if they only had to write their own engine, they could have reused the API and the plugin architecture.


I would love to see plugins for all the major libraries that allow us to plug a new selector engine in to the library. So that’s the challenge.

Is it possible? I’m not sure. I don’t know the Prototype and Mootools, etc architectures well enough to know whether the engines can be replaced programatically – but it’s worth a try, right?

8 Responses to “The Future of JavaScript Libraries”

  1. I like examples 2 and 3. I can’t think of a bunch of selectors I’d use in a full desktop app. Any examples for that?

  2. Hmmm, thats an interesting thought and I agree that it would be a good idea, but I dont agree we are close to getting there. Take for instance jQuery, the selector engine is not isolated from the rest of the jQuery code, the engine is relied upon and used within other parts of the library itself, it is the equivalent of the jQuery programmers deciding the selector engine they want to use and basing the rest of there library features around interesting built in uses of the selector engine they chose.

    I think it would be a lot of work to remove the jQuery selector engine and plonk another one in and then expect the rest of the jQuery library to be able to understand how to use the new selector engine. Is that even ideal anyway? if the library programmers had no idea what engine would end up being used how could they optimise any parts of the library to use the selectors in the best way, it seems to make optimisation impossible in the pursuite of choice.

  3. @Jörn – sorry, that should have been web app rather than desktop app – so I meant that a full web app would probably benefit from a fuller selector engine.

    I always remember reading John Resig’s post on which selector people actually use, and kept thinking why don’t we cut away the cruft required to support everything else (i.e. the selectors we don’t us)? Obviously there’s always the need for a complete selector engine, but I keep feeling like there’s room for application optimised selectors too. It’s just whether we can get them in the game.

  4. @Tom – I think in part you’re right, that the engine is not entirely isolated. However, I’ve put together a quick and dirty hack with jQuery and I’ve managed to patch in a new selector engine. The new engine runs entirely on the native implementation of .getElementsByClassName – but on initial testing it does work.

    Have a look: (edit link)

    Open Firebug and give it a try, you’ll see the selector still works. I know there’s still some shortcuts inside of jQuery (like the getElementById shortcut right at the top of the code), but this quick test is promising enough to make me think I could get a short selection of engines running for jQuery.

  5. Am I missing something, or was this not the whole premise behind Sizzle, a standalone selector engine that can be buillt upon by other libraries, or by devs themselves, probably using john’s upcoming book to do so :-). I’m sure I saw an allusion to Prototype and Mootools, or was it Mochikit, intending to adopt it for their own frameworks in one of the slideshow presentations. At a guess, it looks about 10kb minified/4kb zipped, which is pretty small, and I wouldn’t have thought it worth the while forking it for different use cases.
    I agree with your central idea with regards to the library. I’m working on quite a few apps that I hope to be releasing soon, that make heavy use of JQuery, but I’m using less than half the functions available from the lib, so there’d definitely be mileage in subsetting parts of that. .each, .attr, .css, .offset,.val, .html, the events and just .ajax, would cover most needs, with the full library for more esoteric uses. Just my .02

  6. If its not actually that entrenched into the library itself then it would be possible i suppose. The problem that I see is when a programmer working on jQuery will write a little bit of functionality which makes use of a jQuery selector feature, if you completely remove the jQuery selector engine and add a new one in it may not have the feature the programmer is using and hence the jQuery library would stop functioning correctly. Every time an update to the library is released you would have to retest the entire library using the unit tests with each and every selector engine you use in order to make sure that jQuery still works with all of the selector engines you have got working with it previously. If a new feature added in a release makes use of a jQuery specific selector then its definately not going to work and a large amount of re writing of this new feature (or dropping it out completely) would be required to get it working with the selector engine you want again.

    Thats the way I see the problem, or am i missing something?

  7. I can see the benefits of being able to do this, but really, its only use is when you need to scale *down* a project. The only reason you’d want to change the selector engine is because of speed (which is becoming less of an issue), even so, if you’re only using IDs to select various elements it’s likely that somewhere along the line you’ll be sacrificing semantics. That’s what I love about jQuery, when I use it I really feel like I’m adding that unobtrusive “third layer” – I rarely have to adjust the HTML accordingly – it’s truly unobtrusive!

    Plus I’d imagine this challenge being all the more difficult with libraries like Prototype which change/add-to native browser methods/objects…

    How many different selector engines do you really see being available? Other than speed, how will they differ?

  8. @Paul – re: your comment about Mochikit et al picking up Sizzle – then that’s great news and if that’s the case, then it definitely sounds like plug and play selector engines are on their way.

    @James – I agree with you in the most common cases. However, if you’ve built an iPhone specific version of your site (i.e., then wouldn’t you want to entirely rely on querySelectorAll rather than a bespoke query engine? This could be easily achieved by plugging in the new selector engine for iPhone specific site, and off you go.

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight