我曾见过很多很多人盲目地使用（前端）框架，如 React，Angular 或 Vue等等。这些框架提供了许多有意思的东西，然而通常人们（自以为）使用框架是因为：

         1.它们支持组件化；
         2.它们有强大的社区支持；
         3.它们有很多（基于框架的）第三方库来解决问题；
         4.它们有很多（很好的）第三方组件;
         5.它们有浏览器扩展工具来帮助调试；
         6.它们适合做单页应用。

但这些都不是使用框架的根本原因。

最最本质的原因是：

         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 （界面与逻辑）尽可能简单了！！

响应式 UI 拯救一切

           框架是如何工作的呢?
           基于两个基本的策略：

         重新渲染整个组件，如React。当组件中的状态发生改变时，在内存中计算出（新的）DOM 结构后与已有的 DOM 结构进行对比。实际上，这是非常昂贵的。因而采取（将真实 DOM）映射为虚拟 DOM ，通过对比状态变化前后虚拟 DOM 的不同，计算出变化后再改变真实 DOM 结构。这个过程称为调和（reconciliation）。通过（添加）观察者监测变化，如 Angular 和 Vue.js。应用中状态的属性会被监测，当它们发生变化时，只有依赖了（发生变化）属性的 DOM 元素会被重新渲染。

结论

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

此内容DOC下载　此内容PDF下载

版权声明:

1、陕西弈聪网站内容中凡注明“来源：XXX（非陕西弈聪网站）”的作品，转载自其它媒体，转载目的在于传递更多信息，其中涉及的网站建设，网站优化，百度关键词优化，西安软件开发等技术细节并不代表本站赞同支持其观点，并不对其真实性负责。对于署名“陕西弈聪”的作品系本站版权所有，任何人转载请署名来源，否则陕西弈聪将追究其相关法律责任。

2、本站内容中未声明为“原创”的内容可能源自其它网站，但并不代表本站支持其观点，对此带来的法律纠纷及其它责任与我方无关。如果此内容侵犯了您的权益，请联系我方进行删除。