Now that jQuery is popular, developers are taking an interest in speed
I became aware of Javascript libraries in 2005. For a long time I used prototype for everything. I was dazzled by the profusion of libraries: mootools, YUI, ext, and more, but I never had time to experiment with all of them. They all basically did the same things, though they represented different philosophies about how to do things. Then last year it seemed like the community of developers that I followed had suddenly agreed that jQuery was the best library. I’ve been using jQuery for less than a year, but I like it. I think it is strange how, with these libraries, people who never cared about the speed of their Javascript now worry about the speed of their, say for instance, jQuery script. Down in the comments, under this article about the fastest method for turning a string into DOM elements and adding them to the page, I thought this remark had some truth in it:
I find it curious that developers were drawn to tools like jQuery because they abstracted away this sort of thing, yet now that adoption is high people that never did it pure js are looking for speed and moving back in the direction of string concats and straight js.
Just for speed comparison sake have you tried this test using innerHTML and createElement instead of anything jQuery? I don’t think I would want to return to those days, but it would be interesting to know the cost of using jQuery at all. As a side effect of doing that test it would also show the speed diff between those two old rivals, the “correct” DOM approach vs the “hack” string injection. In browsers a few years back the hack always beat the DOM, don’t know if that is still the case today.
September 16th, 2009 at 1:45 pm
Thanks for the link :)
I’ve tried both of those methods, it is highly browser dependent which method is quickest. In the latest generation of browsers, the difference is insignificant and both methods are VERY fast. In IE6 though the current generation, string generation is faster. In versions previous to IE6, DOM insertion is faster, so there has been this tug of war from browser version to browser version.
While jQuery does try and optimize for speed, writing in javascript will always net you faster results, because at the very least you save a function call. The benefits jQuery gives you here, however, more then make up for any lack of speed unless you need raw speed over many, many elements, in which case you may need to revert back. That isn’t the case 95% of the time, however.
I became interested in speed after jQuery because I had a lot of development time freed up by not having to worry about cross-browser issues, and other complexities that jQuery abstracts away.
September 19th, 2009 at 4:02 pm
Josh, thanks for the info. I do think the general trend is toward more and more abstraction, for the sake of greater programmer productivity. But, no doubt, the more abstraction we add to our code, the more speed becomes a concern.