Over a million developers have joined DZone.

The Future of JavaScript Libraries

DZone's Guide to

The Future of JavaScript Libraries

· Web Dev Zone
Free Resource

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

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?

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.


Published at DZone with permission of Remy Sharp, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}