Monday, December 24th, 2007
WebKit gets native getElementsByClassName
Category: Browsers
, Safari, Performance
getElementsByClassName has always been a pain in the arse for us developers. Why it wasn’t implemented natively across the board is something that browser folk can chat about. Not having it available has caused hacks, workarounds, and bugs.
Firefox and Opera support the beast, and now Webkit has joined them:
The advantages of a native implementation are clear:
- No additional JavaScript library files required
- Clearly specified and consistent behavior
- Blindingly fast
How fast? Let’s have a look at WebKit’s shiny new implementation. For testing purposes I wrote a simple benchmark allowing comparison between three different methods for getting elements by their class names. The first is the new native getElementsByClassName, and the last two are both from prototype.js; one uses XPath, and the other is a straight JavaScript/DOM implementation.
“Blindingly fast”
When we’re using hyperbole about technology, I think we should just start saying stuff like “so fast it makes you compulsively masturbate.
While I think this is fantastic news, I also believe its about time browsers consider adding a native getElementsBySelector method. If you look at most of the popular libraries they allow you to use CSS or XPath selectors to match elements in the DOM. When something becomes such a common abstraction, it makes sense that browsers natively support it..
It’s definitely gone to plaid.
Now we just gotta wait for IE to catch on. Ha.
@dkubb - You’re right that CSS/XPath selectors for the DOM are a key abstraction in many libraries. I tend to write fairly complex selectors in jQuery, though, ones which make use of some unique features of that library.
So assuming that native browser support would lag behind the syntax which, for example, jQuery allows, it makes me wonder whether I would switch to a native implementation if one existed?
Maybe browsers should just support more low-level DOM methods (a la getElementsByClassName) and allow frameworks to tie them together into selector implementations?
Wow! So now another 0.001% of the browsers will have native functionality that has already been surpassed by all the frameworks. I guess we can just junk those frameworks now. Oh, but it’s faster. I’ll keep that in mind the next time I need to run 10,000 iterations in the real world.
@K9: I assume that jQuery would do what most other frameworks do now: parse the selector, hand off what it can to the built-in methods, and then use normal JS logic to winnow down the results. If there’s a getElementsBySelector method, perhaps less of the logic will need to be done in JS, and more by the built-in methods, which is a win for every framework.
Anytime an abstraction is found that is in such common use, I think its reasonable to consider pushing it down a layer in the stack.