Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

为 DOM 伸冤

  我们经常说 Web 慢是因为坑在 DOM 上,把 Web 慢的责任全推给 DOM。仔细想想其实 DOM 也挺冤枉的。最初的 DOM 应该不至于这么慢,只是在 Web 的发展过程中 DOM 被扩展了太多本不该在上面实现的东西,这才导致了现在这个「慢」的局面。
  如果现在回头看看 DOM Level 1,其实并不比 Virtual DOM 多多少东西。React 被吹得神乎其神的其中一点就是可以在服务器端渲染 DOM,但 DOM 本身就不是浏览器的专利。在我接触 Web 前就在 Windows 上用过了微软的 Microsoft.XMLDOM 组件来处理 DOM。5 年前我还搞过一个基于 ASP 的后端框架「JASP」,直接从服务器端使用 DOM 渲染页面的 。
  DOM 在浏览器上之所以慢是因为浏览器上的 DOM 同时实现了 CSSOM 导致的。单纯的 DOM 其实就是纯 Model,怎么可能慢得那么离谱呢?而且如果我们的需求仅仅是 DOM 模板那么简单,那么 DOM Level 1 就足以满足了。现在看浏览器上的 DOM,里面大绝大部分东西都是没用的。比如文档中的元素首先是继承于 HTML*Element 然后继承 HTMLElement。如果我们不用某个元素的特性,甚至都不考虑它是否是一个 HTML 自带标签的话,这两个级别的继承根本就不需要。再深入纠结下去是继承自 Element,对于 DOM 模板而已,这一层应该就已经可以满足所有需求了。但是 CSSOM 也染指了这一层,所以浏览器上的 Element 是很慢的。
  但如果无视浏览器,考虑服务器端的 DOM 模板渲染呢?其实最终生成的是静态的 DOM,所以 EventTarget 也可以从继承链上干掉,而且服务器上不用考虑 UI 部分,也不会被 CSSOM 坑性能。所以如果我们在服务器端实现一个干净的 DOM Level 1,或许有时候(我是说或许!)可以比 JavaScript 内置的 Object 操作起来还快(一个是链表存储,一个是 hash 存储)。
  纠结了以上一堆,我的目的只是给 DOM 洗白。DOM 本身在理论上并不慢,慢的是浏览器的实现。要是哪天浏览器自己提供了一个 DOM Level 1 的额外实现,并且性能完全不输给 JavaScript 原生对象(这真的是可以做到的),那么手动实现 Virtual DOM 之类的无聊事情就自然会变得很奇怪。
网名:
34.203.213.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^