因为视图就是是数据，而你可以对数据做任何操作。

2、JSX / VDOM 缺点

目前，VDOM 本身成本真的很高。

想一想，当我们刚出来的时候，很多人都认为，这不是很慢吗？答案是 Yes，我们很慢，但速度却足够快！

但是，仍然从纯粹的技术角度来看，你做了很多多余的工作。想想这个简单的模板，它只需要更新其中单个消息绑定就可以完成大量的工作。

我们必须遍历整个 VDOM 节点并且做 Diff，在这个过程中，一直以递归的方式向下传递，直到你以某种方式更新它。

因此，标准 VDOM 不同的代价是相对于视图的总大小，而不是可能改变的节点数量。

即使你只有一个节点，也可能会触发 这个VDOM 的 Diff 算法。

正是由于渲染函数的动态特性使得它难以优化。

关于动态性，我的意思是你可以写这样的代码。

你可以使用一个 for 循环来构建一个 children 数组，然后将它交给你的父节点，以及接下来进行你想要做的其他事情，也就是说你可以先创建一个父节点，然后通过往它的 children 中添加元素来进行改变。

你在使用 JavaScript 的时候，编译器不可能hold住所有可能发生的事情，因为 JavaScript 太过于动态化。

在这块我们已经做了很多尝试，但从本质上来说，我们很难通过这种方式对其提供安全的优化。

因为它不是你简简单单做足够多的条件预断就可以的，你对用户意图做的预判越多，代码越容易优化，这对于Javascript来讲实在太难了。

最后，React 对于这块的解决方案就是不把重心放在加快 VDOM 本身的速度，而是如何提高感知性能。

因此，React 引入了运行时调度并发时间切片的概念，但是这种运行时调度方案，整个 fiber，几乎和我们管理自己的堆栈一样，比如进入和退出渲染，所有的东西都需要很长的运行时间。

这意味着无论你何时加载 React，都必须去加载那些用于处理复杂的运行时调度工作的所有必需代码。

这就像加载几个20、30KB 大小的 JavaScript 一样。

反过来，这也会让你的初始化加载受到一点影响。

3、模板编译优点

另一方面，如果你是在模板中编译的渲染代码，通常它可以生成一个更加直接的渲染指令，并且具有更好的原生性能。原因就是：根据定义，模板是一种非常有约束的语言，你只能以某种方式去编写模板。

例如，当你写出这样的代码的时候，我们可以立刻告诉你，这些 p 标签的顺序是不会变的，这个 id 是不会变的，这些 class 也不会变的，唯一会变的就是这个。

静态（编译）和非常严格的限制实际上是允许编译器对你的意图做更多的预判，从而给它更多的空间去做执行优化。

我们来看看 SVELTE 编译代码时会做什么。

其他所有内容都是静态的，只有 name 可能会发生改变，这个 p 是一个 update 函数，它唯一做的事情就是当 name 发生变更的时候对它（name）进行更新。

将 SVELTE 与 VDOM Diff 算法所做的事情相比较的话，它只有到达一定量级才会更快。

所以说，根据策略的不同，模板编译或者基于通用编译的方法也可以使 runtime baseline 更轻量，因为它不需要所有的复杂运行时调度来尝试让事情看起来更快，因为它本身已经很快了。

所以 SVELTE 可以产出一个非常轻量的输出，而不需要一个很重的 baseline runtime 来适应所有可能的 runtime 行为。

4、模板编译缺点

现在来看看模板编译的缺点。很显然，你会受限于模板语法，从而失去 JavaScript 的表达能力。

所以，当你想去构建一个真正复杂的组件的时候，你会想我要可以在模板里这样做多好，然而编译器对此并不支持。

很不走运，如果你选择完整的编译路线，那就没有退路，因为级别越低的编译输出，实际上你越难将你的自定义操作与它进行挂钩。

就好比 opa 编译器，你是无法深入到汇编去看看为什么会这样，就好比你无法使用 C 语言去调试你的汇编代码。

更轻量的 runtime、更轻量的 baseline runtime，也可能是以每个模板更详细的输出作为代价。因为当你试图去生成尽可能高效的代码时，有时你必须直接在输出的时候编码更多信息。

例如，SVELTE 生成的代码其实是以命令式的形式通过逐行插入创建了所有元素，并且它们有一个单独的函数进行更新操作。

相比之下，基于 VDOM，结果是你只需要一行，而这（一行）只是一个返回 VDOM 结构的表达式。

如果在运行时编译，则会产生运行时编译成本。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!