3 ms·
>> "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.
by axod 18y 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 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 18y agoI 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 18y agoMibbit feels pretty durned fast to me, for a rich web-app.
- axod 18y agoIt'd have to be a lot slower for me to stand things like this in the code: e.innerHTML = "Hello & world, here's some HTML <span>Some html</span>"; 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+"!";
- willwagner 18y agoI'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.
- axod 18y agoMy 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.
- willwagner 18y agoI see your point; I misread it first time around. From a security point of view for user content, nodeValue is a much better approach.
- davidw 18y agoAre there any actual... benchmarks out there? That might be a good way of looking at the issue in a more objective way.
- axod 18y agohttp://www.quirksmode.org/dom/innerhtml.html http://www.quirksmode.org/dom/innerhtml.html As I posted :/ just click on the buttons and it'll test in your browser.
- mr_justin 18y 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.
- axod 18y agoNo, 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.
- mr_justin 18y ago> 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.
- axod 18y agoMy 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.
- mr_justin 18y agoSo where do you work? Is it: A) A fantasy land B) A college computer lab C) Develop intranet apps for a small company