Hacker News Reader

Comment by willwagner | Hacker News Reader

Unfortunately, if you are adding a lot of elements, your performance can really suffer by creating DOM elements. It helps if you "createDocumentFragment" but as far as I know, shoving a big string into the non-standard innerHTML member is still the fasted way to add a lot of content.

View on HN

That's true for IE, but not for good browsers. For firefox/safari/chrome it's negligable difference if not sometimes slightly faster to use the DOM methods.

Also, using DOM methods allows you to easier attach listeners, save references to DOM elements for later updates/use etc. That means less getElementById()'s later.

Writing HTML inside js code is just horrible (IMHO). Horrible ugly code. And obviously easier to have security issues if you're including non-sanitized user data.

#6 is a horrible idea.

As far as your JS code is concerned, HTML is a (horrible, ugly) serialization of the DOM. Manipulate the DOM programatically. Don't use HTML.

Sadly, most of us have to code for IE, just as we have to code for the "good browsers".

If you're in the 'webapp' area, where IE is a minority (20% or so), I think it's justifiable to program in a clean way and live with IE users having a slower experience.

innerHTML is just the worst thing ever invented. Ugly ugly thing.

Where does that 20% stat come from?

That might be relevant if you want to continually add many elements to the DOM, but that's rarely the case in most web applications. The benefit of using strings to shave milliseconds is heavily outweighed by the unreadable, error-prone code created when one tries to shoehorn markup into a concatenated string.

Reply on news.ycombinator.com