Good article. It kind of makes me question how long we can go down this path though. Like surely we can't keep adding to css and the dom api's for 20 more years? How much bloat will we accumulate before we start over?
I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built with a flexbox-like API and let us bind shaders to elements. We don't need css if we have shaders. And I don't think adding more and more features to current api's is gonna solve problems long term.
I don't know exact what system you have in mind, but writing a performant shader is hard. Requiring that designers attach arbitrary shader code to HTML elements is an easy way to absolutely tank the performance of the web.
Flexbox also isn't great at all for many, many use cases - its performance absolutely tanks outside of the use case it was designed for, specifically a 1D flow of blocks along an axis. If you want a grid layout, choose the grid layout algorithm.
Any system here must accommodate extremely heterogeneous requirements, so it will inevitably become "bloat". One alternative future you could envision is based on WASM and WebGPU, where each site is essentially an app that pulls in whatever libraries and frameworks it needs to do its work, but that's also pretty far off, since there is not sufficient standardization of the protocols used by WASM UI frameworks.
I wouldn't expect devs to be writing their own shaders all the time - the browser could have standard shaders, and no doubt libraries would crop up that offer more.
Not only that, a new system will get completely coopted by the likes of Google for their own purposes. The result of what is built is in large parts a function of the culture that builds it. And I for one have zero interest in the current tech culture building a DOM 2.
> surely we can't keep adding to css and the dom api's for 20 more years?
We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.
> Why would you need to treat a web browser like a virtual machine?
There are many reasons. Performance, ability to bring concepts from other domains, ability to do things browser has no api for, ability to provide controlled experience and behaviour that goes beyond common browser usage.
I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built with a flexbox-like API and let us bind shaders to elements. We don't need css if we have shaders. And I don't think adding more and more features to current api's is gonna solve problems long term.