DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs.
Mark my words.
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.
Please correct me (you know a lot, and I'm betting some of my assumptions are wrong).
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.
I'm looking into building an extension to build Quantum Display Lists from a WASM vdom.
Last time I checked C/C++ based UI libraries even text selection was a problem. If there were a cross platform way to build UI-s as good and feature rich as a modern browser is now, then it will slowly die.
That's the reason we have so many Electron based apps, because it makes UI building really simple.
- abstracts lots of file handling
- js is much easier than most languages to pick up and learn
- js has a large dev base because of the web
- people are well versed in coding for the web, and adding a “native” layer on top of that is actually quite easy
- cross platform c/c++ in general is not so simple even without the GUI
What I think of GUI toolkits, I think of lots of imperative code to build out an interface, e.g., "Create a window. Add a vertical box layout. Create button1. Change button1.font to xxx. Change button1.style to bold. Set the minimum height of button1 to 20px. Add button1 to the box. Create button2. Add button2 to the box. Tell the box to grow button2 when it is resized. Create button 3..."
The declarative style of HTML/CSS seems so much better. The grouping of elements becomes apparent just by looking at how they are nested, with no need to keep track of what gets added to what. And CSS gives you a really rich ability to select groups of elements, style them, try out new styles, reuse styles across pages, and so on.
CSS has definitely gotten really complicated. But then, I could never build anything in a GUI toolkit without constantly referencing the API docs to figure out how to do this or that, either...
Qt always had a nice UI designer, with layout managers for responsive UIs, no need for imperative code to build out an interface.
Since version 5 they have QML, a JavaScript like declarative language, quite similar to J3 the first version of JavaFX.
Usually imperative UI code tends to be a thing only among developers that dislike RAD tooling, or game devs using immediate mode UIs.
Actually I think that most game UIs (the menus, settings, inventories - not the actual game) are done quite well - maybe immediate mode GUIs have a place outside of gamedev?
I'm not a frontend whiz by any means, but I've always found the widget-centric (GUI) approach fit my mental model better than the HTML centric one.
SPA architectures help, but I find most HTML designers tend to prefer raw HTML to any composed/widget approaches.
CSS (as a concept) is actually quite great, which is why you've seen the older GUI approaches adopt it. Qt itself is also leading more towards a reactive approach where you interact with an abstract data model, and the UI reflects the updates.
If you’re talking about rendering everything on a canvas, well, there’s been the occasional discussion about making it a11y-friendly, exposing content in it to screen readers and so forth, but nothing has really happened with it.
Your WebAssembly GUI toolkit is going to be completely invisible to screen readers.