《Vue.js 设计与实现》—— 01 权衡的艺术

书籍链接：https://weread.qq.com/web/bookDetail/c5c32170813ab7177g0181ae

框架设计里到处都体现了权衡的艺术。

当我们设计一个框架时，框架本身的各个模块之间并不是相互独立的，而是相互关联、相互制约的。

作为框架设计者，一定要对框架的定位和方向拥有全局的把控，这样才能做好后续的模块设计和拆分。

作为学习者，在学习框架的时候，也应该从全局的角度对框架的设计拥有清晰的认知，否则很容易被细节困住，看不清全貌。

框架的范式有命令式和声明式，框架的设计有纯运行时、纯编译时和运行时 + 编译时，它们各有优缺，如何选择呢？这里面都体现了“权衡”的艺术。

1. 命令式和声明式

从范式上来看，视图层框架通常分为命令式和声明式，它们各有优缺点。

命令式框架的一大特点就是关注过程。曾一度盛行的 jQuery 就是典型的命令式框架。例如，我们把下面这段话翻译成对应的代码：

- 获取 id 为 app 的 div 标签
- 其文本内容为 hello world
- 为其绑定点击事件
- 当点击时弹出提示：ok

jQuery 对应的代码为：

$('#app') // 获取 div
  .text('hello world') // 设置文本内容
  .on('click', () => { alert('ok') }) // 绑定点击事件

原生 JavaScript 对应的代码为：

const div = document.querySelector('#app') // 获取 div
div.innerText = 'hello world' // 设置文本内容
div.addEventListener('click', () => { alert('ok') }) // 绑定点击事件

显然，原生 JavaScript 和 jQuery 都是命令式编程，自然语言描述能够与代码产生一一对应的关系，代码本身描述的是“做事的过程”，符合我们的逻辑直觉。

与命令式框架更加关注过程不同，声明式框架更加关注结果。结合 Vue.js，来看一下如何实现上面自然语言描述的功能：

<div @click="() => alert('ok')">hello world</div>

可以看到，我们提供的是一个“结果”，并不关心如何实现它，实现该“结果”的过程则是由 Vue.js 帮我们完成的。换句话说，Vue.js 帮我们封装了过程。

因此，能够猜到 Vue.js 的内部实现一定是命令式的，而暴露给用户的却更加声明式。

2. 性能与可维护性的权衡

命令式和声明式各有优缺点，在框架设计方面，则体现在性能与可维护性之间的权衡。这里先抛出一个结论：声明式代码的性能不优于命令式代码的性能。

以上面的例子来说，假设现在要将 div 标签的文本内容修改为 hello vue3，如何用命令式代码实现呢？很简单，直接调用相关命令操作即可：

div.textContent = 'hello vue3' // 直接修改

有没有比上面这句代码性能更好的方案呢？答案是“没有”。可以看到，理论上命令式代码可以做到极致的性能优化，因为我们明确知道哪些发生了变更，只做必要的修改就行了。但是声明式代码不一定能做到这一点，因为它描述的是结果：

<!-- 之前： -->
<div @click="() => alert('ok')">hello world</div>
<!-- 之后： -->
<div @click="() => alert('ok')">hello vue3</div>

对于框架来说，为了实现最优的更新性能，它需要找到前后的差异并只更新变化的地方，但是最终完成这次更新的代码仍然是：

div.textContent = 'hello vue3' // 直接修改

如果把直接修改的性能消耗定义为 A，把找出差异的性能消耗定义为 B，那么有：

命令式代码的更新性能消耗 = A
声明式代码的更新性能消耗 = B + A

可以看到，声明式会比命令式多出找出差异的性能消耗，最理想的情况是找出差异的消耗为 0 时，声明式代码与命令式代码的性能相同，但无法做到超越，毕竟框架本身就是封装了命令式代码才实现了面向用户的声明式。

但是，相比命令式，声明式代码的可维护性更强。从上例可以感知，采用命令式开发时，我们需要维护实现目标的整个过程，包括手动完成 DOM 元素的创建、更新、删除等工作。而声明式仅需要我们关注结果，过程不需要关心，心智负担较小，代码更可观。

在采用声明式提升可维护性的同时，性能就会有一定的损失，而框架设计者要做的就是：在保持可维护性的同时让性能损失最小化。

3. 虚拟 DOM 的性能

前文说到，声明式代码的更新性能消耗 = 找出差异的性能消耗+ 直接修改的性能消耗，因此，如果我们能够最小化找出差异的性能消耗，就可以让声明式代码的性能无限接近命令式代码的性能。而所谓的虚拟 DOM，就是为了实现这一最小化而出现的。

也就是说，采用虚拟 DOM 的更新技术的性能理论上不可能比原生 JavaScript 操作 DOM 更高。为什么要强调「理论上」这三个字，因为在大部分情况下，我们很难写出绝对优化的命令式代码，尤其在项目工程规模非常大的情况下。

虚拟 DOM 要解决的问题就是在书写可维护性更强的声明式代码时，尽可能的让应用程序的性能更好，甚至逼近命令式代码的性能。

值得一提的是，前文中所说的原生 JavaScript 实际上指的是像 document.createElement 之类的 DOM 操作方法，并不包含 innerHTML，因为它比较特殊，需要单独讨论。

在使用 jQuery 或者直接使用 JavaScript 编写页面的时候，使用 innerHTML 来操作页面非常常见。现在，我们也许要思考一下：

使用 innerHTML 操作页面和虚拟 DOM 相比性能如何？
innerHTML 和 document.createElement 等 DOM 操作方法有何差异？

先看第一个问题，为了比较 innerHTML 和虚拟 DOM 的性能，需要了解它们创建、更新页面的过程。

对于 innerHTML 来说，为了创建页面，需要构造一段 HTML 字符串：

const html = `<div><span>...</span></div>`

接着将该字符串赋值给 DOM 元素的 innerHTML 属性：

div.innerHTML = html

为了渲染出页面，首先要把字符串解析成 DOM 树，这是一个 DOM 层面的计算。我们知道，涉及 DOM 的运算要远比 JavaScript 层面的计算性能差，这有一个跑分结果可供参考，如下：

跑分结果显示，纯 JavaScript 层面的操作要比 DOM 操作快得多，它们不在一个数量级上。

我们可以用一个公式来表达通过 innerHTML 创建页面的性能：HTML 字符串拼接的计算量 + innerHTML 的 DOM 计算量。

接下来，讨论虚拟 DOM 在创建页面时的性能。虚拟 DOM 创建页面的过程分为两步：

创建 JavaScript 对象，这个对象可以理解为真实 DOM 的描述
递归地遍历虚拟 DOM 树并创建真实 DOM

我们同样可以用一个公式来表达：创建 JavaScript 对象的计算量 + 创建真实 DOM 的计算量。

可以看到，无论是纯 JavaScript 层面的计算，还是 DOM 层面的计算，其实两者差距不大。如果在同一个数量级，则认为没有差异。在创建页面的时候，都需要新建所有 DOM 元素。

给出第一个结论：在同一个数量级下，创建页面时，虚拟 DOM 和 innerHTML 的性能几乎没有区别。

下面看看它们在更新页面时的性能。

使用 innerHTML 更新页面的过程是重新构建 HTML 字符串，再重新设置 DOM 元素的 innerHTML 属性，也就是说，哪怕只更改了一个文字，也要重新设置 innerHTML 属性，这等价于销毁所有旧的 DOM 元素，再全量创建新的 DOM 元素。

虚拟 DOM 更新页面的，需要重新创建 JavaScript 对象（虚拟 DOM 树），然后比较新旧虚拟 DOM，找到变化的元素并更新它。

可以发现，在更新页面时，虚拟 DOM 在 JavaScript 层面的运算要比创建页面时多出一个 Diff 的性能消耗，但它也是 JavaScript 层面的运算，所以不会产生数量级的差异。再观察 DOM 层面的运算，可以发现虚拟 DOM 在更新页面时只会更新必要的元素，但 innerHTML 需要全量更新。这时虚拟 DOM 的优势就体现出来了。

另外，当更新页面时，影响虚拟 DOM 的性能因素与影响 innerHTML 的性能因素不同。对于虚拟 DOM 来说，无论页面多大，都只会更新变化的内容，而对于 innerHTML 来说，页面越大，就意味着更新时的性能消耗越大。如果加上性能因素，那么最终它们在更新页面时的性能如下图：

给出第二个结论：在同一个数量级下，更新页面时，虚拟 DOM 比 innerHTML 的性能要高。

基于此，可以粗略地总结一下 innerHTML、虚拟 DOM 以及原生 JavaScript（指 createElement 等方法）在更新页面时的性能：

事实上，innerHTML 已经有一点声明式编程的味道了，但它更像是一种没有经过优化的声明式代码，没有做好性能和可维护性两者之间的权衡。

4. 运行时和编译时

当设计一个框架的时候，有三种选择：纯运行时的、运行时 + 编译时的或纯编译时的。这需要你根据目标框架的特征，以及对框架的期望，做出合适的决策。

先看一下纯运行时的框架。假设我们设计了一个框架，它提供一个 Render 函数，用户可以为该函数提供一个树型结构的数据对象，然后 Render 函数会根据该对象递归地将数据渲染成 DOM 元素。规定树型结构的数据对象如下：

const obj = {
  tag: 'div',
  children: [
    { tag: 'span', children: 'hello world' }
  ]
}

每个对象都有两个属性：tag 代表标签名称，children 既可以是一个数组（代表子节点），也可以直接是一段文本（代表文本子节点）。接着，实现 Render 函数：

function Render(obj, root) {
  const el = document.createElement(obj.tag)
  if (typeof obj.children === 'string') {
    const text = document.createTextNode(obj.children)
    el.appendChild(text)
  } else if (obj.children) {
    // 数组，递归调用 Render，使用 el 作为 root 参数
    obj.children.forEach((child) => Render(child, el))
  }

  // 将元素添加到 root
  root.appendChild(el)
}

有了这个函数，用户就可以这样来使用它：

const obj = {
  tag: 'div',
  children: [
    { tag: 'span', children: 'hello world' }
  ]
}
// 渲染到 body 下
Render(obj, document.body)

用户在使用 Render 函数渲染内容时，直接为其提供了一个树型结构的数据对象。这里面不涉及任何额外的步骤，用户也不需要学习额外的知识。但是有一天，你的用户抱怨说：“手写树型结构的数据对象太麻烦了，而且不直观，能不能支持用类似于 HTML 标签的方式描述树型结构的数据对象呢？”你会发现，它并不支持。实际上，刚刚编写的框架就是一个纯运行时的框架。

为了满足用户的需求，你开始思考，能不能引入编译的手段，把 HTML 标签编译成树型结构的数据对象，这样不就可以继续使用 Render 函数了吗？思路如下：

为此，你编写了一个叫作 Compiler 的程序，它的作用就是把 HTML 字符串编译成树型结构的数据对象，于是交付给用户去用了。那么用户该怎么用呢？最简单的方式就是让用户分别调用 Compiler 函数和 Render 函数：

const html = `<div><span>hello world</span></div>`
// 调用 Compiler 编译得到树型结构的数据对象
const obj = Compiler(html)
// 再调用 Render 进行渲染
Render(obj, document.body)