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