Taming huge collections of DOM nodes
Hajime Yamasaki Vukelic has come to the conclusion that, if you’re dealing with a really big number of DOM nodes that need to be updated in real time, frameworks are usually incredibly slow on top of the already-slow DOM operations you have to do. The solution they settled on is to avoid frameworks altogether for these scenarios and use vanilla JavaScript. Also of note are that repaints and reflows are going to be big bottlenecks regardless of what you use.
- If you are looking for performance, don’t use frameworks. Period.
- At the end of the day, DOM is slow.
- Repaints and reflows are even slower.
- Whatever performance you get out of your app, repaints and reflows are still going to be the last remaining bottleneck.
- Keep the number of DOM nodes down.
- Cache created DOM nodes, and use them as a pool of pre-assembled elements you can put back in the page as needed.
- Logging the timings in IE/Edge console is unreliable because the developer tools have a noticeable performance hit.
- Measure! Always measure performance first, then only fix the issues you’ve reliably identified.