Rethinking DOM from first principles

While the web has grown complex in line with increasingly complex applications, the platform is also undeniably bloated, precisely because every new feature (like HTML in Canvas proposal) has to be shoehorned into an already very fragmented puzzle. Backwards compatibility has become an idealistic badge of honor rather than a technical feat. I believe the article does a good job at getting into the technical parts that are in fact not so remarkably robust, despite the web's organic growth. Even a bonsai tree needs to be pruned every once in a while. And while there will never be One Correct Way the way we engineer interfaces have converged a lot since the days of Flash meaning we can at least move the conversation forward in the Mostly Agreed Upon Way.

> I struggle to imagine how it could realistically be not complex.

Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days.

Java and Flash (although very problematic from a security point of view) were probably better bases on which to build "Web for applications" than HTML5+/CSS3+/JS/WASM will ever be, but it was intolerable for Google/Microsoft/Mozilla to hand the keys to Oracle/Adobe for that. It's all politics, and it's all worse and more complicated and more inefficient as a result.

As for the vertical centering, trying this 20 years ago, it was a pain in the ass. These and layouting in general got massively simplified in the past 20 years. Remember that back then, everything was cramped into tables? I do. So if someone tells me, "DOM, HTML and CSS is becoming more and more difficult" just tells me to ignore their amateurish and unfounded opinion... Hah!

> Yes, some applications tend to have a large amount of markup for what seems like simple features (the Slack’s input box example). However, the alternative is that browser vendors bake it all in, and then every app is stuck with the opinionated way they think is right. Perhaps some amount of chaos is healthy.

Or, you know, provide a set of usable controls that provide useful functionality out of the box and provide a set of useful APIs so that people can either extend those controls or create their own.

Web Platform provides neither. Compare that to literally every other UI toolkit under the sun. Turbo Vision from 1990s was a better toolkit than anything the web has to offer.

I closed my web dev business just three years ago. I found that many people who work with the web don't want to do the work to understand how it all works. They think there must be a library somewhere to do "that" while doing "that" is simple enough using standard components and features.

Another issue is people basing their fears of things in the past. Yes, the web was more difficult to do fancy things but often they're trying to push the web to do things it just couldn't do back then. Now you can using basic, built-in functionality and it's often easier that way.

The reason WASM does not have dom access is that many recent DOM APIs return and expect javascript objects and classes like iterators, so you would still need some thin js glue wrapper between the dom and wasm. Security has nothing to do with it as (performace aside) wasm+minimal js glue can already do anything js can do

> For WASM to become a replacement it would have to gain full DOM access to the containing page.

To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around.

Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance.

> Browser makers have refused to do that for clear security reasons.

Actually, they’re a long way down the path of doing it. They’ve just been taking their time to make sure it’s done right—they’ve headed in at least three different directions so far. But it’s been clear from just about the start that it was an eventual goal.

The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another.

The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you.

It's not irrational; quite the contrary.

> I have no idea why, but tree models scare the shit out of college educated developers.

Very few people are "scared" of tree models.

The problem of working with the DOM is that it's:

- 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things

- Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you need out of existing building blocks

- An API that is completely non-composable

- A rendering system that is actively getting in the way of doing things, and where you have to be acutely aware of all the hundreds of pitfalls and corner cases when you so much as change an element border (which may trigger a full re-layout of the entire page)

- A rendering system which is extremely non-performant for anything more complex than a static web page (and it barely manages to do even that). Any "amazing feats of performance" that people may demonstrate are either very carefully coded, use the exact same techniques as other toolkits (e.g. canvas or webgl), or are absolute table stakes for anything else under the sun. I mean, an frontpage article last week was how it needed 60% CPU and 25% GPU to animate three rectangles: https://www.granola.ai/blog/dont-animate-height

> So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions

The abstractions of the past 15 or so years have been trying to hide from the DOM only because the DOM is both extremely non-performant and has an API even a mother wouldn't love.

> Browser makers have refused to do that for clear security reasons.

Because only javascript should be allowed to screw up that badly.

I'd vote for something along the lines of QML or Slint for defining UIs; business logic should be purely done in WASM.

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

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 smell second system syndrome.

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.

Yes, I am generally weary of rewrites.

> I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications?

In all seriousness, isnt this what Java is for? Why would you need to treat a web browser like a virtual machine?

No, they really don't.