5 ms·
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 h
by nevir 11y ago
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)
- spicyj 11y agoI'm not sure how this is ironic? We were using one DOM API (.innerHTML) before; now we're using a different one.
- akst 11y agoI 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-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
- BinaryIdiot 11y agoI 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 :)
- spicyj 11y agoWe 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.
- BinaryIdiot 11y agoEven 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 :)
- spicyj 11y agoYeah, 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.
- esailija 11y agoThe 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.
- spicyj 11y agoInteresting, 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.
- BinaryIdiot 11y agoMight 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.
- spicyj 11y agoIE 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).
- amelius 11y agoUhm, perhaps a stupid question, but how exactly would one build DOM elements without access to the DOM?
- rabelrabel 11y agodocument.createDocumentFragment() https://developer.mozilla.org/en/docs/Web/API/Document/createDocumentFragment https://developer.mozilla.org/en/docs/Web/API/Document/creat...
- amelius 11y agoThe 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)?
- rabelrabel 11y agoOnly one reflow calc at fragment hookup as opposed to a reflow for every child node added to the main DOM.