E.g., I don't think any sane design of a UI toolkit would include the ability to read and modify the string representation of the UI code at runtime - yet it's a critical feature for the DOM.
Likewise, you wouldn't necessarily need the ability to access and mutate arbitrary nodes of the document tree at any time. (including mutations that might change which CSS selectors apply to a node) E.g., you could only expose higher-level widgets instead or only expose variables that feed into a template. That would allow optimisations which aren't possible with CSS and DOM.
Finally, a WASM toolkit would be shipped with a particular website anyway, so it wouldn't need to be general-purpose.
On the other hand, there is a great incentive for website operators to make their site into a single unparseable blob: Ad-blockers. If every site had it's own internal data representation and internal rendering engine, that would make it almost impossible for ad-blockers to modify certain parts of the site while leaving others intact.
Those can largely be avoided, and they typically don't cause global performance impacts.
> E.g., I don't think any sane design of a UI toolkit would include the ability to read and modify the string representation of the UI code at runtime - yet it's a critical feature for the DOM.
That isn't a problem. innerHTML is lazily computed from the tree structure: if you don't use it, you don't pay for it.
> Likewise, you wouldn't necessarily need the ability to access and mutate arbitrary nodes of the document tree at any time. (including mutations that might change which CSS selectors apply to a node) E.g., you could only expose higher-level widgets instead or only expose variables that feed into a template.
The main benefit of this would be to eliminate restyling, but cascading is really useful from a design point of view. That's why we've seen native frameworks such as Qt and GTK+ move to style sheets. And if you reinvent restyling, it'll be a ton of work to do better—remember that Servo and Firefox Quantum have a parallel work-stealing implementation of it. I've never seen any native toolkit that even comes close to that amount of performance effort.
I'm not paying for it, the DOM implementation is - with increased complexity. (E.g., HTML parsing suddenly becomes a time-critical operation because some wiseguy decided to implement animations for his website using setTimeout and innerHTML.)
And they can't drop it because a lot of sites rely on it - however, if you wrote a new, limited-purpose renderer on top of WASM, you could decide to drop it and simplify the implementation without losing much utility.
> And if you reinvent restyling, it'll be a ton of work to do better
But that's kind of my point - if you can control which parts of the tree are exposed and which mutations are valid, you might not need to implement restyling at all. (Or in reduced scope)
I'm not talking about cascading in general, but about how you can make arbitrary changes to the DOM after initial load, which the restyler has to fully support.
We're talking about performance here, not implementation complexity. Besides, it's not a win in terms of complexity if sites ship a limited subset of the Web stack to run on top of the full implementation of the Web stack that's already there.
> But that's kind of my point - if you can control which parts of the tree are exposed and which mutations are valid, you might not need to implement restyling at all. (Or in reduced scope)
Sure, you can improve performance by removing useful features. But I think it'll be a hard sell to front-end developers. Qt and GTK+ didn't add style sheets and restyling for no reason. They added those features because developers demanded them.
My point is that writing custom UI renderers using canvas and WASM might become a reasonable thing to do. For that you don't need to stick to the web stack at all, you can invent whatever language, API and data model fits your needs. Those can be a lot simpler than the DOM and therefore easier to implement with good performance.
Please correct me (you know a lot, and I'm betting some of my assumptions are wrong).
Everyone thinks that the rendering engines in browsers are easy to beat in terms of performance. I thought that too, until I implemented one. They are definitely beatable, but not easily, and certainly not with an architecture like that of Qt or GTK.