文章探讨了当前浏览器环境中DOM（文档对象模型）的复杂性和过时性，尽管WebAssembly已成功应用于服务器端，但客户端体验仍与十年前相似。作者指出，虽然通过WebAssembly访问原生Web API已不是问题，但DOM的复杂性和冗余性使其成为开发中的负担。文章呼吁重新思考DOM的设计，并提出了一些改进建议，以简化开发流程并提升性能。

HTML已死，HTML长存

2025年8月6日

重新思考DOM的基础

浏览器目前处于一个非常奇怪的状态。尽管WebAssembly已经取得了成功，甚至在服务器端也得到了广泛应用，但客户端的感觉与10年前几乎没有什么变化。

虽然通过WASM访问原生Web API已经是一个被解决的问题，但很少有人问为什么我们还需要访问DOM。DOM只是目前唯一的选择。因此，本文旨在解释为什么现在是时候将DOM及其相关API彻底淘汰，并提出一些替代方案。

DOM的现状

很少有人真正了解DOM的糟糕程度。在Chrome中，document.body现在有350多个键值，大致分为以下几类：

这还不包括document.body.style中的CSS属性，数量高达660个。

DOM的属性和方法之间的界限非常模糊。许多属性只是带有隐藏setter的“门面”，某些getter可能会触发即时重新布局。DOM中还存在大量过时的遗留内容，比如那些不再使用的onevent属性。

DOM并不精简，反而越来越臃肿。你是否注意到这一点，很大程度上取决于你是在制作网页还是Web应用。

大多数开发者现在都避免直接操作DOM，尽管偶尔会有一些纯粹主义者称赞纯DOM优于各种JS组件/模板框架。DOM的声明式功能（如innerHTML）与现代UI模式完全不匹配。DOM有太多方式来做同一件事，但没有一种方式是优雅的。

Web Components的困境

Web Components值得一提，它是Web原生的JS组件库等价物。但它们出现得太晚，且不受欢迎。API显得笨拙，Shadow DOM引入了新的嵌套和作用域层。支持者的言论听起来像是在为它辩护。

DOM的致命弱点在于其SGML/XML遗产，使得所有内容都是字符串类型。React类框架没有这个问题，它们的语法只是看起来像XML。开发者已经学会不在文档中保存状态，因为DOM并不适合这样做。

HTML的停滞

对于HTML本身，没有什么可批评的，因为它在过去10到15年里几乎没有变化。只有ARIA（可访问性）值得一提，而这正是语义HTML本应实现但未能实现的功能。

语义HTML从未真正达到其目标。尽管它自2011年左右就已存在，但例如没有<thread>或<comment>标签，而这些是早已确立的惯用标签。相反，文章中的文章可能是评论。这些指南显得非常奇怪。

HTML似乎一直对纸张有某种羡慕，未能完全拥抱或定义其超文本本质，也不信任用户会遵循明确的规则。

HTML的管理权已经牢牢掌握在WHATWG手中，实际上是浏览器厂商，他们未能定义更具体的愿景，只是在边缘添加了一些额外的功能。

CSS的困境

CSS也没有很好的声誉，但很少有人能明确指出原因。

大多数人犯的错误是从错误的心智模型开始，将其视为约束求解器。例如：

```

```

```

```

第一个例子看起来合理：将父元素垂直分为两半。但第二个例子呢？

从约束的角度来看，这是矛盾的，因为父元素的高度是其自身高度的两倍。实际上，在这两种情况下，height都会被忽略。父元素的高度未知，CSS不会回溯或迭代，它只是将内容收缩包裹。

如果你在父元素上设置height: 300px，那么它会起作用，但后一种情况仍然会溢出。

CSS的布局模式

CSS的布局模式应该被视为两种约束的传递：首先从外向内，然后从内向外。

当你制作应用框架时，这是从外向内：可用空间被划分，内部内容不会影响面板的大小。

当段落堆叠在页面上时，这是从内向外：文本拉伸其包含的父元素。这是HTML自然想要做的。

通过这种结构，CSS布局在计算上非常简单。你可以将父元素的约束传递给子元素，然后在另一个方向上收集子元素的大小。这使得网页在元素和文本内容方面能够很好地扩展。

Flex Box的优缺点

Flex Box（display: flex）提供了对空间划分的显式控制，但它的使用也模糊了简单的CSS模型。为了自动伸缩，布局算法必须测量每个子元素的“自然大小”。这意味着需要两次布局：第一次是推测性的，就像漂浮在以太中，然后在增长或缩小以适应后再次布局。

这听起来合理，但可能会带来隐藏的意外，因为它是递归的。对父元素进行推测性布局通常需要对未确定大小的子元素进行完整布局。例如，要知道文本如何换行。如果你正确地嵌套它，理论上可能会导致指数级爆炸，尽管我从未听说过这是一个问题。

CSS的继承问题

文本和字体样式在超文本中实际上是异类。像字体大小这样的属性从父元素继承到子元素，以便像<b>这样的格式化标签可以工作。但大多数CSS属性并不这样做。在元素上设置边框不会递归地将相同的边框应用于所有子元素，那样会很愚蠢。

这表明CSS至少是两种不同事物的混合：一种基于继承的富文本样式系统，以及一种用于块和内联元素的布局系统，它们嵌套递归但没有继承，只有包含。它们使用相同的语法和API，但并没有以相同的方式级联。将它们结合在一个样式伞下是一个错误。

SVG的集成

SVG也原生集成到DOM中。将SVG放在DOM中而不仅仅是<img>标签中，对于动态生成形状和调整图标样式非常有用。

但尽管SVG功能强大，它既不是CSS的子集也不是超集。即使它们有重叠，也存在细微的差异，比如仿射transform。它也有自己的问题，比如将所有坐标序列化为字符串。

Canvas的局限性

最近有一个HTML in Canvas的提案，旨在将HTML内容绘制到<canvas>中，并完全控制视觉输出。但它并不理想。

虽然它可能看起来有用，但API之所以具有这种形状，只是因为它被硬塞进了DOM：元素必须是<canvas>的后代才能完全参与布局和样式，并使可访问性工作。使用它进行离屏渲染也存在“技术问题”。

未来的方向

“HTML in Canvas”的目标确实引起了共鸣，使用HTML块作为自由浮动的片段，这个概念一直存在于底层。它是一种可以处理的复合值类型。但它不应该拖拽20年的无用包袱，同时不启用任何真正新颖的功能。

Web的拼凑也导致了巨大的停滞和一般UI精细度的丧失。当UI行为必须从div中挖掘出来时，它限制了你甚至可以考虑的解决方案类型。在DOM/HTML内部修复这个问题似乎不明智，因为里面有太多的混乱。相反，应该在它之外开辟新的表面。

WebGPU的潜力

我的观点是，Use.GPU的HTML-like渲染器在复杂性和代码量上远远优于现有的DOM/CSS/SVG。它没有语义HTML或CSS级联，只有一流的布局。你不需要61种不同的border*访问器。你可以直接将着色器附加到div。这就是人们想要的，对吧？

结论

DOM很糟糕，CSS只有个位数的百分比是好的，SVG丑陋但必要……而且没有人有能力修复它？

不，诊断是中间层不再适合任何人。仅仅是一个最终删除内容的HTML6可能是一个好的开始。

但大多数需要做的是解放已经存在的功能。这可以通过好或坏的方式完成。理想情况下，你设计你的系统，使自定义使用的“逃生舱口”是你构建用户空间内容的相同API。这就是狗食测试，也是你获得好内核的方式。

第一步

第一步应该是一个数据模型，每个节点没有350多个属性。

不要误以为这是完全无法修复的。

评论内容总结：

1. 对CSS和HTML的正面评价：

   • 评论1认为文章对CSS基础的解释非常出色。
   • 评论14认为HTML设计良好，保持向后兼容性是一个巨大成就。

2. 对当前Web技术的批评与反思：

   • 评论2和评论16认为HTML应回归标记语言的本质，减少对JavaScript的依赖。
   • 评论3和评论10指出CSS和DOM API的复杂性不断增加，可能导致技术臃肿，建议重新设计浏览器标准。
   • 评论15认为CSS将样式和布局系统结合是一个错误。

3. 对Web组件和未来技术的讨论：

   • 评论8和评论9提到Web组件逐渐被接受，认为应探索新的Web应用开发方式。
   • 评论3和评论9提到Use.GPU和WebGPU，认为这些技术可能带来新的解决方案。

4. 对DOM和开发者的心理分析：

   • 评论7指出开发者对DOM的恐惧和不必要的抽象层，认为WASM不能完全替代JS和DOM。
   • 评论17认为将状态保留在文档中可以简化开发，批评JS框架对状态的处理方式。

5. 对向后兼容性和Web平台成功的思考：

   • 评论11和评论13强调向后兼容性的重要性，认为Web平台的成功部分归功于其灵活性和兼容性。
   • 评论18批评文章未提及向后兼容性的价值。

6. 对具体技术细节的讨论：

   • 评论4和评论12讨论了CSS的will-change和clip-path属性。
   • 评论19提到DOM在移动设备响应性和隐私保护方面的优势，并举例说明Google的Flutter和Canvas应用。

总结：评论中对CSS和HTML的评价褒贬不一，既有对其设计良好和向后兼容性的肯定，也有对技术复杂性和臃肿的批评。开发者对DOM的恐惧和不必要的抽象层被多次提及，同时也有对Web组件和未来技术（如Use.GPU和WebGPU）的期待。向后兼容性被认为是Web平台成功的关键因素之一，而具体技术细节（如CSS属性和Canvas应用）也引发了讨论。