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.
- I’m building a full
desktopweb application – I want to use as complete as possible selector engine.
- I’m building a version of the site specifically for the iPhone – I only want to use
querySelectorAllbecause I know it’s supported.
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:
- Whether we can write plugins (or hacks if you like) that allow new engines to be shoehorned into the library (jQuery, Prototype, Mootools, etc).
- 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.
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?