Two techniques for massively faster JavaScript

http://asserttrue.blogspot.com/2009/04/two-techniques-for-faster-javascript.html

by techdog • 17 years ago

44 23 17 years ago

asserttrue.blogspot.com

axod7• 17 years ago

>> "How? Use innerHTML wherever possible. "

Terrible advice IMHO. True, innerHTML is faster in IE, so if you care about IE being slow (I don't), use innerHTML. However, innerHTML is buggy, has a bunch of caveats, and just looks incredibly ugly.

http://www.quirksmode.org/dom/innerhtml.html

On non-IE browsers, the difference in speed is negligible, and the code is far nicer using dom methods. (My browser SF/OSX reports 20ms for innerHTML, 25ms for DOM).

You also have useful references to nodes you might need later which makes code nicer and more optimum. For example, you could do innerHTML=foo, then use getElementByID later to update one of the nodes in foo. But using the dom methods, you can just save the ref to the node when you create it yourself. You can also attach any event handlers easily as you go, rather than trying to cram them in the HTML (Even more eugh) or set them up afterwards.

pieter• 17 years ago

I used to do DOM editing in my app that uses webkit. I changed it to use innerHTML, because the DOM was just too slow.

I agree that manipulating the DOM looks nicer. But if it saves 1 second of stalling, I'll use the innerHTML method any time.

khafra• 17 years ago

Mibbit feels pretty durned fast to me, for a rich web-app.

davidw• 17 years ago

Are there any actual... benchmarks out there? That might be a good way of looking at the issue in a more objective way.

mr_justin3• 17 years ago

> On non-IE browsers, the difference in speed is negligible

Are you suggesting that people develop two versions of their JS? One for IE and one for everyone else? Just to appease the pedantics of JS DOM manipulation?

For small bits of HTML, DOM creation/insertion is fine for reasons you have cited (attaching events, etc), but for a bunch of markup, sticking to your guns on this policy is going to cost you your job.

axod7• 17 years ago

No, I'm saying that if you don't mind making IE users experience worse than other peoples, use the DOM methods.

Making IE users experience worse also pushes people toward other browsers, which is a very good thing.

themanual• 17 years ago

Also for a faster Javascript you need to avoid script blocking downloading content. See http://www.webdigi.co.uk/blog/2009/avoid-javascript-blocking...

smwhreyebelong• 17 years ago

x.innerHTML is a DOM operation too. I would think you want to differentiate between doing an "innerHTML" operation and "other DOM operations"

That said, constructing HTML as a string and using one innerHTML call is much faster than doing createNode/appendChild multiple times. DOM operations are definitely the bottleneck when it comes to performance : The less of them you do, the better off you are. (I learnt my lesson the hard way)

briansmith• 17 years ago

Try DocumentFragment instead:

http://ejohn.org/blog/dom-documentfragments/ http://slayeroffice.com/articles/innerHTML_alternatives/#5c

bsaunder2• 17 years ago

The fact that most js frameworks willfully ignore #2 has been one of the reasons I've avoided them. Doing a lot of DOM manipulations in code feels about as efficient as making tons of system calls to an OS. Much better to do a few larger writes than many small ones.

I've become a big fan of JST: http://code.google.com/p/trimpath/wiki/JavaScriptTemplates . Send over template snippets as strings and use JST to put them together. With far fewer innerHTML replacements along the way.

edw519• 17 years ago

I feel the same way but never knew how to say it.

If I need a complex algorithm that will run once a month and someone has already written an open source solution, then sure.

But if I need something that must be efficient and runs thousands of times per day, then maybe I should roll my own.

I guess the formula could be:

WriteYouOwn if DevTimeSaved < (TxnTimeSaved * TxnsPerDay)

sachmanb• 17 years ago

The newer browsers (Chrome, Firefox 3.5 and such) use JIT JavaScript VMs. For that reason, I think it's not worth investing the effort of avoiding jQuery and going through all this effort for performance gains. It is highly likely that the browsers will optimize these kinds of things at compile time, and these kinds of problems will go away much like contemporary compilers reduced the need to make every string a constant and such (they are made into constants at compile time for you). There's plenty of other performance things to think about, though, but it doesn't seem to be worth it to me to chase this one.

richcollins• 17 years ago

It is if you care about the 70% of people online that use IE. I doubt IEs DOM will be speeding up any time soon.

bsaunder2• 17 years ago

You're probably right now. I started down this road in 2006 when the JavaScript VMs weren't there yet with performance. At the time, it was a night and day difference (from don't blink to good-golly-what-are-you-doing). Also, I tend to like the declarative style of templates vs. the imperative style of code for my presentation layer.

Two techniques for massively faster JavaScript

Related Stories