4 ms·
We only used .innerHTML when creating new subtrees, which requires a reflow anyway when they're inserted. There are reasons that document.createElement is faste
by spicyj 11y ago
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.
- 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).