[acdha]

None of what you’re saying is globally true. It might have been true of the apps you personally worked on but it’s not the case that everyone did HTML string replacement or that using the DOM directly forced you to forget basic software engineering concepts.

[throwaway11460]

It's what was commonly done across more than 10 companies in Europe over a decade I worked in the field. Looking back at the source code of projects back then, it was the normal method.

[acdha]

So say that rather than pretending to speak for the entire web.

[throwaway11460]

I said that. It's faster than the browser DOM operations. Replacing a block of DOM is a DOM operation too.

[acdha]

It was faster in the early 2000s. It hasn’t been for the last decade and a half - try it now and be reminded just how bad IE6 was:

https://www.quirksmode.org/dom/innerhtml.html

https://segdeha.com/experiments/innerhtml/

The thing which was slow is changing more than you need to change. When the React marketing push included performance, that’s almost always what they were comparing it to - someone would have slow code making the same updates multiple times or triggering reflows by forcing the browser to do a partial update to measure something, and then updating again.

There’s an argument that the guaranteed overhead of using React is better because it helps the average developer who doesn’t measure performance much do a better job than they might have otherwise, and that can be true for many people but it also tended to get oversimplified to “React is fast” despite widespread evidence to the contrary.

[throwaway11460]

We measured performance, but we also measured things like how hard it is to implement a feature or how many bugs we have to fix, and how quickly we can do so. When we jumped on React in 2013, it improved all of these metrics.