Woohoo! This is beyond exciting, seriously. If you are familiar with DOM traverse with javascript (which i’m 99% sure you are, cus you are reading my blog), you should be excited as well.
Think about the limited ways that we have today about DOM traverse:
- getElementByID
- getElementsByTagName
- getElementsByName (limited to form elements under IE)
And for those of you who remember who Simon Willison was, he released one of the fastest traverse function “getElementsBySelector”, you know the pain. It has never been perfect, but only to make it as efficient as you can. Seriously, with all the crazy Ajax applications we are developing, “id” and “tag name” is simply not enough for us. jQuery, Prototype, and all the libraries try to support the well known XPath, but none can come close to native support.
getElementsByClassName is one of the more common functions requested by JavaScript programmers (and added by JavaScript libraries); it works along the same lines as getElementsByTagName and getElementById in looking up elements of a web page by their properties. In fact, it’s so common that in the new in-progress HTML5 specification it’s been added to the official DOM API. Last week WebKit joined upcoming versions of Firefox and Opera in supporting this new feature.
The advantages of a native implementation are clear:
No additional JavaScript library files required
Clearly specified and consistent behavior
Blindingly fast
The results speak for themselves. Web applications that do a lot of class lookups should see noticeable speed improvements when run with any of the native implementations, and existing JavaScript libraries can fill in for older or less advanced browsers. John Resig has run a different benchmark of the same functionality in Firefox 3 and observed a similar native vs. JavaScript/DOM speedup ratio.
I LOVE YOU WEBKIT!!!! KEEP THIS UP!!!
On the other side, it’s sad to see how slow other browsers are on the same race… sigh…
0 Responses to “WebKit gets Native getElementsByClassName”
Leave a Reply