HTML is Dead, Long Live HTML: A Rant on the State of the DOM and Web APIs
Hello everyone. Today, we’re going to take a scalpel to the festering wound that is the modern web’s Document Object Model (DOM) and its associated APIs. If you thought the web was a shining example of technological progress, prepare to have your illusions shattered. We’re about to dissect why the DOM is a bloated, archaic mess, why CSS is a Frankenstein’s monster of layout hacks, and why the so-called solutions being proposed are little more than band-aids on a gangrenous limb. So, scrub in, because this is going to get messy.
The DOM: A Relic of the Past
Let’s start with the DOM itself. In Chrome, document.body now has over 350 properties. That’s not a typo. Three hundred and fifty. And that’s not even counting the 660 CSS properties lurking in document.body.style. It’s like opening a patient’s chart and finding out they’ve got every disease in the medical textbook. The DOM is a Frankenstein’s monster, stitched together from decades of legacy features, half-baked ideas, and redundant APIs.
The boundary between properties and methods is about as clear as a chest X-ray in a sandstorm. Some properties are just facades with invisible setters behind them. Some getters can trigger a just-in-time re-layout, which is a fancy way of saying “good luck debugging that performance issue.” And then there’s the ancient legacy stuff, like all the onevent properties that nobody uses anymore but are still hanging around like a bad case of athlete’s foot.
Most developers have wisely chosen to avoid working with the DOM directly. Instead, they use JavaScript frameworks that treat the DOM as a necessary evil, something to be manipulated as little as possible. Web Components were supposed to be the web-native answer to these frameworks, but they arrived too late and are about as popular as a rectal exam. The API is clunky, the Shadow DOM introduces new layers of complexity, and proponents sound like they’re trying to convince themselves as much as anyone else.
HTML: Stagnant and Outdated
As for HTML itself, nothing significant has changed in over a decade. The only notable development is the focus on accessibility, which is ironic because that’s what Semantic HTML was supposed to address and failed miserably. There are still no <thread> or <comment> tags, despite those being well-established patterns. Instead, you’re supposed to nest <article> tags inside each other and pretend that’s semantically meaningful. It’s like treating a broken leg with a bandage and hoping nobody notices the bone sticking out.
HTML has always had a weird obsession with mimicking paper documents, never fully embracing its hypertext nature. The result is a mishmash of elements and attributes that don’t quite fit together, like a jigsaw puzzle with pieces from three different sets. Stewardship of HTML has passed to the browser vendors, who seem content to add minor features at the margins rather than address the core issues.
CSS: The Inside-Out Nightmare
Now, let’s talk about CSS. If the DOM is a bloated corpse, CSS is the autopsy report written in crayon. Most people approach CSS with the wrong mental model, thinking of it as a constraint solver. In reality, it’s a two-pass system: first, it goes outside-in, then inside-out. This makes sense for documents, but it’s a nightmare for applications.
For example, setting height: 50% on two child divs inside a parent doesn’t divide the parent in half unless the parent’s height is explicitly set. Otherwise, the heights are ignored, and the parent just shrink-wraps its contents. It’s like prescribing medication without checking the patient’s allergies—you’re just asking for trouble.
Flexbox and CSS Grid were supposed to make layout easier, and to some extent, they do. But they also introduce new complexities, like speculative layout passes and recursive dependencies. Vertical alignment is still a pain, and you often have to use containment hacks or set arbitrary sizes to get things to behave. It’s a system that works despite itself, not because of any inherent elegance.
The Kitbashing of the Web
Most modern web applications are built by kitbashing HTML, CSS, and SVG into something that vaguely resembles a user interface. This comes with immense overhead and is the opposite of a decent UI toolkit. Lists and tables have to be virtualized by hand, scrollbars are a constant headache, and making anything interactive requires a mountain of JavaScript. It’s like performing surgery with a butter knife and a prayer.
Even basic features like text-ellipsis are broken. You can’t use it to truncate entire paragraphs, only unwrapped text. Measuring text is a nightmare, and everyone ends up counting characters instead. Positioning elements with position: sticky is subtly broken, and layering with z-index turns into a war of arbitrary numbers. These are not the signs of a healthy system.
SVG: Powerful but Isolated
SVG is natively integrated and useful for generating shapes and icons, but it’s neither a subset nor a superset of CSS. There are subtle differences, like how transforms work, and it has its own quirks, like serializing coordinates as strings. CSS has gained some SVG-like features, but they’re limited and inconsistent. Whether you use HTML/CSS or SVG for a particular element depends on a series of trade-offs, none of which are particularly satisfying.
The Futility of “HTML in Canvas”
One recent proposal is to allow drawing HTML content into a <canvas> element, giving developers full control over the visual output. On the surface, this sounds promising. In reality, it’s a kludge. Elements have to be descendants of <canvas> to participate in layout and styling, and you have to take over all interaction responsibilities just to customize how something looks. It’s like giving a patient a full-body cast because they sprained their ankle.
The real reason to do complex UIs on canvas is to escape the limitations of the DOM, to virtualize content, implement custom gestures, and so on. But this proposal drags all the DOM’s baggage along for the ride, making it more of a hindrance than a help. It’s an all-or-nothing approach when what we need is something in the middle.
A Glimmer of Hope: Rethinking the Box Model
There are some promising ideas out there, like the Use.GPU project, which implements a full X/Y flex model with a fraction of the complexity. Vertical centering is easy, positioning makes sense, and you don’t need a million accessors for every property. It’s a bare-bones system, but it’s already nicer than the DOM in many ways.
The classic data model here is a view tree and a render tree. The question is, what should the view tree look like, and what can it be lowered into? The current DOM is a tangled mess, but alternative browser projects like Servo and Ladybird are in a position to make good proposals. They have fresh implementations and are targeting essential features first. The big browser vendors could do it too, but taste matters, and good big systems grow from good small ones, not bad big ones.
Conclusion: Time for Radical Surgery
In summary, the DOM is a bloated, outdated mess that’s holding back the web. CSS is a convoluted system that’s only partially effective, and the proposed solutions are little more than superficial treatments. What we need is a radical rethinking of the web’s core APIs, stripping away decades of cruft and starting fresh with modern principles in mind.
Step one should be a data model that doesn’t have 350+ properties per node. It’s not an impossible task, but it requires vision, discipline, and a willingness to break with the past. Until then, we’re stuck performing surgery with blunt instruments, hoping the patient doesn’t bleed out on the table.
And that, ladies and gentlemen, is entirely my opinion.
Source: Rethinking DOM from first principles, https://acko.net/blog/html-is-dead-long-live-html/
