Two techniques for massively faster JavaScript | Hacker News Reader

Two techniques for massively faster JavaScript

asserttrue.blogspot.com

44 pointstechdog23 comments

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

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.

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

It'd have to be a lot slower for me to stand things like this in the code:

  e.innerHTML = "Hello &amp; world, here's some HTML &lt;span&gt;Some html&lt;/span&gt;";

over

  e.nodeValue = "Hello & world, here's some HTML <span>Some html</span>";

Also you better be 100% sure you're data is 'safe' if you use innerHTML. eg

e.innerHTML = "Hello "+some_user_provided_data+"!";

I'm confused by this comment. I don't think you can shove arbitrary html into a nodeValue, although you can do it with innerHTML. Using your example, this works fine:

e.innerHTML = "Hello & world, here's some HTML <span>Some html</span>";

I believe the intent of the original author was to point out that basic DOM manipulation methods like appendChild, removeChild, etc are slower than innerHTML, which in almost all cases, is true. Whether it's worth doing so is another matter.

If you have a fairly complex document, inserting multiple children can slow things down quite a bit as the browser has to reflow the document between each insert/append. Bulking them up in an array of strings, joining them, and inserting them into an innerHTML makes the reflow happen only once. The document fragment approach can help a lot over multiple appends/inserts, but it has some tradeoffs too as far as performance.

Duly noted about user provided data though being a security risk.

My point was that having to escape things like open close tags, ampersands etc looks horrible and ugly. HTML entities inside HTML code inside strings isn't something I enjoy looking at.

(My example code shows some HTML code as plain text, which needs htmlEntities when using innerHTML).

You can't put anything in nodeValue apart from a string value. But the good thing is, it's just a string. No security issues, no entity encoding, no html tag issues.

I see your point; I misread it first time around. From a security point of view for user content, nodeValue is a much better approach.

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

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

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

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

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.

> Making IE users experience worse also pushes people toward other browsers

That is simply false. The average internet user should not have to make that leap of faith. They simply will think your website/app is crap and they will stop using it, because there's probably another product out there that does the same thing but actually works for them.

If you want to gain users and keep them, you do not make their experience intentionally bad.

My experience is the opposite of yours. IE usage is the minority, so I don't feel bad if their experience is slightly worse than users using a better browser.

When they come and ask why X is slow, we send them over to firefox/safari/chrome, and they thank us.

So where do you work? Is it:

A) A fantasy land B) A college computer lab C) Develop intranet apps for a small company

I wrote http://www.mibbit.com - so none of the above. I get to decide what I do, and so far it's worked:

http://tinyurl.com/d8nqu7 (Traffic growth)

If you work in the corporate world, then totally. You probably have to bend to IE's every whim.

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.

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)

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.

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.

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.

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

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)

Try DocumentFragment instead:

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

Reply on news.ycombinator.com