Hacker News Reader

Comment by spicyj | Hacker News Reader

We only used .innerHTML when creating new subtrees, which requires a reflow anyway when they're inserted. There are reasons that document.createElement is faster for us, but that's not one of them.

View on HN

Even inserting new subtrees should be significantly faster via appendChild() versus innerHTML. The browser has to do a whole heck of a lot more when you don't build the nodes first.

I'm curious though. I'll have to check out the source to see how it works in React now. You know, when I find some free time :)

Yeah, you'd think that it would be a lot faster to avoid serializing and parsing everything, but it turns out to be not much difference. Not sure why.

The native API calls such as createElement are pretty expensive (in V8 it's like 10 function calls to finally reach the target C++ function) and you are making a lot more such calls when not using innerHTML.

Interesting, thanks. I had heard that calls from JS to C++ were cheap but calls from C++ to JS (such as if Array.prototype.map was implemented natively) were expensive.

Might depend on how you build the nodes. If you build all the nodes and then append it should be a lot faster. Maybe browsers have optimized for this use case better but I ran benchmarks on this a couple of years ago and createElement / appendChild was always a lot faster.

IE and Edge are much faster when appending nodes first (thus always appending empty nodes) but Chrome, Firefox, and Safari are similar speed regardless of the order. We do the former in IE and Edge only and the latter in all other browsers because it's more convenient (and makes more logical sense to me).

Reply on news.ycombinator.com