Hacker News Reader

Comment by nevir | Hacker News Reader

There's a bit of irony here, but in a good way: Switching back to DOM APIs (e.g. document.createElement) was a performance boost.

('cause the browser vendors have done a ton of awesome work speeding up DOM APIs in recent years)

View on HN

I'm not sure how this is ironic? We were using one DOM API (.innerHTML) before; now we're using a different one.

I think document.createElement could of been prone to memory leaks, as dom objects cannot be freed on the C++ side if it's still accessible from JS, which can be difficult to judge sometimes

https://blog.mozilla.org/research/2014/08/26/javascript-serv...

I had no idea react used .innerHTML. That provides a significant performance drawback compared to other DOM APIs due to it requiring the browser to re-flow / re-render so much more. Glad you guys updated :)

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.

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

Uhm, perhaps a stupid question, but how exactly would one build DOM elements without access to the DOM?

document.createDocumentFragment()

https://developer.mozilla.org/en/docs/Web/API/Document/creat...

The documentation says this is faster because the browser does not have to compute reflow during DOM construction. But is this also true if the DOM tree is built "bottom up" (i.e., first the leaves, then their parents, etc, and then finally hook everything into the document body)?

Only one reflow calc at fragment hookup as opposed to a reflow for every child node added to the main DOM.

Reply on news.ycombinator.com