[jerf]

I'd be interested in some people expanding on what they think is so "wrong" with the DOM, especially from the point of view of performance, and (emphasis on this!) what would be so much better. It's not that different than any other widget toolkit anymore, which have all largely converged on the same sort of model for the same reasons.

I can't think of very many things that affect performance in big ways. An explicit "I'm going to do a lot of things to the DOM here, please hold the reflows until I'm done, I understand that some of the properties may go out of date in the meantime" might be nice. (Perhaps it's a death-of-a-thousand-cuts.)

The API itself is a bit klunky, but the rough edges are easy to paper over with any number of libraries, and is hardly the world's first klunky-but-functional API to be so papered over by libraries that add no significant slowdown. (Note I'm not talking about "react" here, but just things that make the DOM API a bit less klunky. Thin little wrappers that mostly get JIT'd out.) Native XPath-like integration into JS would be nice, but honestly, that's going to be a net slowdown because people will do lots of slow, easy things rather than write the more tedious, but faster, DOM manipulation.

But just being klunky doesn't actually make it slow.

[lhorie]

It's not so much there being something "wrong" with it, it's more that there are trade-offs. Look, for example, at https://tc39.es/ecma262 (the JS spec) and try to jump around the page: you'll notice that it takes quite a bit of time for some things to render simply because the document is absolutely humongous. BUT, once it does load completely, you can insta-search it with ctrl+f, it reflows/wraps correctly in a mobile browser and and if you throw your iphone's accessibility feature at it, it'll read the document for you. Being able to google the thing in the first place is also due to ability to programmatically crawl the document and analyze its contents. These are important features that are usually forgotten by the people proposing that everything should be a thin bitmap buffer on top of raw hardware.