[rektide]

fwiw there's almost nothing on the dom in this article.

I'm quite tired of the hot air pointless uneducated uninformed web bashing. I don't know why the web attracts such angry angry people but for all the complaining the grandparent post is about as real of a counter-idea to the dom as I have ever seen.

what we do with the web is often bad. fully agreed there are terrible experiences everywhere. but starting fresh, starting with different source materials, different rendering data structures: I don't think that targets at all what is wrong. so I just see such complaining as misdirected, complaints against a pop culture that instead focus on the tech that allows that pop culture. and I see it as sabotaging the best tech humanity has going, the freest most expressive most versatile data we've got that we often yes use quite poorly. but that we do get better at. that we continue to evolve our architectures of use around. and I see such grumbles as undermining this great thing, while supporting something limited & domineering & utterly in corporate control, something apart from the greater connected cyberspace: native (awful) apps.

[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.