> The reality is that web is fast enough
This. So much this.
Yes, there are contrived examples where DOM rendering speed makes a difference, and also a fair amount of real-world crapware (much of it written by companies that should know better) where shitty code continues to hit the DOM unnecessarily hundreds or thousands of times even after the page is allegedly "loaded", but that is not the fault of the DOM.
> hit the DOM unnecessarily hundreds or thousands of times even after the page is allegedly "loaded", but that is not the fault of the DOM.
If DOM was actually performant, this wouldn't be a problem.
If people could actually write code, it also wouldn't be a problem.
I think the misunderstanding is how to hit the DOM. If using static methods the performance cost is a memory cycle, so there can be many wasted steps and it’s still negligible. If access is via query selector then there is a string parse operation which is a few orders of magnitude slower. That does not mean the DOM is slow. Even Lamborghinis are incredibly slow if you never move out of first gear.
String parsing is negligible compared to the speed of the DOM which is glacially slow: https://news.ycombinator.com/item?id=38835920
Come on, people, make an effort to learn how insanely fast computers are, and how insanely inefficient our software is.
String parsing can be done at gigabytes per second: https://github.com/simdjson/simdjson If you think that string parsing of selectors is the slowest operation in the browser, please find some resources that talk about what is actually happening in the browser?
That is not at all correct. That is why we measure things.
https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
For those of us who understand how these things work the incredibly slow performance of query selections is not surprising. What is interesting, though, is comparing the numbers between difference browsers.