

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

======
axod
>> "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
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.

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

~~~
axod
<http://www.quirksmode.org/dom/innerhtml.html>

As I posted :/ just click on the buttons and it'll test in your browser.

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

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

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

------
themanual
Also for a faster Javascript you need to avoid script blocking downloading
content. See [http://www.webdigi.co.uk/blog/2009/avoid-javascript-
blocking...](http://www.webdigi.co.uk/blog/2009/avoid-javascript-blocking-
content-download-on-your-website-during-page-load/)

------
smwhreyebelong
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
Try DocumentFragment instead:

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

