Monday, December 24th, 2007

WebKit gets native getElementsByClassName

Category: Browsers, Performance, WebKit

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.

Posted by Dion Almaer at 6:06 am

4.4 rating from 35 votes


Comments feed TrackBack URI

“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.

Comment by Trevor — December 24, 2007

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..

Comment by dkubb — December 24, 2007

It’s definitely gone to plaid.

Now we just gotta wait for IE to catch on. Ha.

Comment by jmoss — December 24, 2007

@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?

Comment by K9 — December 26, 2007

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.

Comment by McLars — December 26, 2007

@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.

Comment by dkubb — December 31, 2007

Leave a comment

You must be logged in to post a comment.