I live in the sometimes sunny Brighton (it's in the south of the UK, for those across the pond). The south coast is definitely my favourite place to be, but I spent some time on the outskirts of London whilst at University. I'm starting to focus on my own company Left Logic. It's a web development company with strong focus in usability, accessibility, clean design and powerful bespoke applications. Remy is a DZone MVB and is not an employee of DZone and has posted 53 posts at DZone. You can read more from them at their website. View Full User Profile

The Future of JavaScript Libraries

  • submit to reddit

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 the Prototype and Mootools, etc architectures well enough to know whether the engines can be replaced programatically - but it's worth a try, right?

Published at DZone with permission of Remy Sharp, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)