[译文] 现代 js 框架存在的根本缘由

原文连接：The deepest reason why modern JavaScript frameworks exist

众成翻译地址：现代 js 框架存在的根本缘由(翻译同样是我翻译的，但它缺了几张图，所以掘金从新发了~)

精读《现代 js 框架存在的根本缘由》 by 黄子毅（感谢大神的精读，也是根据他的建议看了原文，也顺便为你们带来翻译）

我曾见过不少不少人盲目地使用（前端）框架，如 React，Angular 或 Vue等等。这些框架提供了许多有意思的东西，然而一般人们（自觉得）使用框架是由于：

• 它们支持组件化；
• 它们有强大的社区支持；
• 它们有不少（基于框架的）第三方库来解决问题；
• 它们有不少（很好的）第三方组件;
• 它们有浏览器扩展工具来帮助调试；
• 它们适合作单页应用。

但这些都不是使用框架的根本缘由。

最最本质的缘由是：

（UI 与状态同步很是困难）

是的，就是这缘由，让咱们来看看为何

假设你正在设计这样一个 Web 应用：用户能够经过群发电子邮件来邀请其余人（参加某活动）。UX/UI 设计师设计以下：（在用户填写任何邮箱地址以前，）有一个空白状态，并为此添加一些帮助信息；（当用户填写邮箱以后，）展现邮箱的地址，每一个地址的右侧均有一个按钮用于删除对应的地址。

这个表单的状态，能够被设计为一个数组，里面包含若干对象，对象由邮箱地址和惟一标识组成。开始的时候，数组为空。当（用户）输入邮箱地址并按下回车键以后，往数组中添加一项并更新 UI。当用户点击删除按钮时，删除（数组中对应的）邮箱地址并更新 UI。你感受到了吗？每当你改变状态时，你都须要更新 UI。

（你可能会说：）那又怎样？好吧，让咱们看看如何在不用框架的状况下实现它：

用原生（JS）实现相对复杂的 UI

如下代码很好地说明了使用原生 JavaScript 实现一个相对复杂的 UI 所需的工做量，使用像 jQuery 这样经典的库也须要差很少的工做量。

在这个例子中，HTML 负责建立静态页面，JavaScript 经过 document.createElement 动态改变（DOM 结构）。这引来了第一个问题：构建 UI 相关的 JavaScript 代码并不直观易读，咱们将 UI 构建分为了两部分（译者注：应该是指 HTML与 JavaScript 两部分）。尽管咱们使用了 innerHTML，可读性是加强了，但下降了（页面的）性能，同时可能存在 CSRF 漏洞。咱们也可使用模板引擎，但若是是大面积地修改 DOM，会面临两个问题：效率不高与须要从新绑定事件处理器。

但这也不是（不使用框架的）最大问题。最大的问题是每当状态发生改变时都要（手动）更新 UI。每次状态更新时，都须要不少代码来改变 UI。当添加电子邮件地址时，只须要两行代码来更新状态，但要十三行代码更新 UI。（此例中）咱们已经让 UI（界面与逻辑）尽量简单了！！

代码既难写又难理解，更麻烦的是它很是脆弱。假设咱们须要（添加）同步服务器数据到邮件地址列表的功能，咱们须要对比服务器返回结果与数组中数据的差别。这涉及对比全部数据的标识与内容，（当用户修改后，）可能须要在内存中保留一份标识相同但内容不一样的数据。

为了高效地改变 DOM，咱们须要编写大量点对点（译者注：指状态到 UI）的代码。但只要你犯下了很小的错误，UI 与状态将再也不保持同步：（可能会出现）丢失或呈现错误的信息、再也不响应用户的操做，更糟糕的是触发了错误的动做（如点了删除按钮后删除了非对应的一项）。

所以，保持 UI 与状态同步，须要编写大量乏味且很是脆弱的代码。

响应式 UI 拯救一切

因此，（之因此使用框架，）不是由于社区，不是由于工具，不是由于生态，不是由于第三方库......

目前为止，框架最大的改进是（为咱们）提供了应用内部状态与 UI 同步的可靠保证。

只要你清楚特定框架的某些（特定）规则（如不可变状态），就差很少（能够正常使用）了。

咱们只须要定义一次 UI 界面，再也不须要为每一个操做编写特定的 UI 代码，同时，每一个相同的状态均有相同的输出（译者注：指 UI 一致）：当状态改变后，框架自动更新（对应的）视图。

框架是如何工做的呢?

基于两个基本的策略：

• 从新渲染整个组件，如React。当组件中的状态发生改变时，在内存中计算出（新的）DOM 结构后与已有的 DOM 结构进行对比。实际上，这是很是昂贵的。于是采起（将真实 DOM）映射为虚拟 DOM ，经过对比状态变化先后虚拟 DOM 的不一样，计算出变化后再改变真实 DOM 结构。这个过程称为调和（reconciliation）。

• 经过（添加）观察者监测变化，如 Angular 和 Vue.js。应用中状态的属性会被监测，当它们发生变化时，只有依赖了（发生变化）属性的 DOM 元素会被从新渲染。

那 Web components 呢?

不少时候，人们会把 React、 Angular 和 Vue.js （等框架）与 Web components 进行对比。这显然体现了人们并不理解这些框架所提供的最大好处：保持 UI 与状态同步。Web components 并不提供这种同步机制。它仅仅提供了一个<template>标签，但它不提供任何（状态与 UI 之间的）协调机制。若是你在应用中使用 Web components 时，想保持 UI 与内部状态同步，则须要（开发者）手工完成，或者使用如 Stencil.js (内部和 React同样，使用虚拟 DOM)之类的库。

让咱们明确一点：框架表现出的巨大潜力并不体如今组件化上，保持 UI 与状态同步才是具体的体现。Web components 并未提供相关的功能，你必须手工或使用第三方库去解决（同步的）问题。使用原生 JavaScript 去编写复杂、高效且易于维护的 UI 界面基本上是不可能的。这就是你须要使用现代 JavaScript 框架的根本缘由。

本身动手，丰衣足食

若是热衷于了解底层原理，想知道虚拟 DOM 的具体实现。那，为什么不试着在不使用框架的状况下，仅使用虚拟 DOM 来重写原生 UI呢？

这里是框架的核心，全部组件的基础类。

这里是重写后的 AddressList 组件（借助 babel 来支持 JSX 的转换）。

如今 UI 是声明式的，咱们并未使用任何框架。咱们能任意添加新逻辑来改变状态的同时，不须要编写额外的代码来保持 UI 同步。问题解决了！

如今，除了事件处理以外，这看起来就像个 React 应用对吧？咱们有haverender()、componentDidMount()、setState()等等。一旦解决了保持应用内 UI 与状态的同步问题，全部东西就会很天然地叠加起来（造成组件）。

能够在这个 Github 仓库中找到完整的源代码。

结论

• 现代 js 框架解决的主要问题是保持 UI 与状态同步。
• 使用原生 JavaScript 编写复杂、高效而又易于维护的 UI 界面几乎是不可能的。
• Web components 并未提供解决同步问题的方案。
• 使用现有的虚拟 DOM 库去搭建本身的框架并不困难。但并不建议这么作！