摘要：官方规范估计很难出现现代框架的设计了，因为官方设计中前端三剑客是相互分离的方案，为了解决现阶段前端框架的问题，必须由完全接管，这几乎就是，或者支持语法的，可这与最初网页设计思路是违背的。现代前端框架正在告诉我们新的三剑客虚拟虚拟。
1 引言
深入思考为何前端需要框架，以及 web components 是否可以代替前端框架？
原文地址，建议先阅读原文，或者阅读概述。
2 概述现在前端框架非常多了，如果让我们回答 “为什么要用前端框架” 这个问题，你觉得是下面这些原因吗？
组件化。
拥有强大的开源社区。
拥有大量第三方库解决大部分问题。
拥有大量现成的第三方组件。
拥有浏览器拓展/工具帮助快速 debug。
友好的支持单页应用。
不，这些都不是根本原因，最多算前端框架的营销手段。作者给出的最根本原因是：
解决 UI 与状态同步的难题。
作者假设了一个没有前端框架的项目，就像 Jquery 时代，我们需要手动同步状态与 UI。就像下面的代码：
addAddress(address) {
// state logic
const id = String(Dat.now())
this.state = this.state.concat({ address, id })
// UI logic
this.updateHelp()
const li = document.createElement("li")
const span = document.createElement("span")
const del = document.createElement("a")
span.innerText = address
del.innerText = "delete"
del.setAttribute("data-delete-id", id)
this.ul.appendChild(li)
li.appendChild(del)
li.appendChild(span)
this.items[id] = li
}
首先更新效率是个问题，最大问题还是同步问题。试想多次与服务器交互，在同步过程中漏执行了一步，会导致之后的 UI 与状态逐渐脱节。
因为我们只能一步步同步状态与 UI，却无法保证每个瞬间 UI 与状态是完全同步的，任何一个疏忽都会导致 UI 与状态脱节，而我们除了不断检查 UI 与数据是否对应，毫无办法。
所以现代框架最重要的帮助是保持 UI 与状态的同步。
如何做到有两种思路：
组件级重渲染：比如 React，当状态改版后，映射出改变后的虚拟 DOM，最终改变当前组件映射的真实 DOM，这个过程被称为 reconciliation。
监听修改：比如 Angluar 和 Vue.js，状态改变直接触发对应 DOM 节点中 value 值的变化。
这里稍微说明下，React 虽然是整体渲染，但在虚拟 DOM 作用下，效率不比 observable 低。observable 在值不能完整映射 UI 时，也需要做更大范围的 rerender。另外，Vue.js 与 Angluar 也早已采用了虚拟 DOM。
这三个框架已经融会贯通，作者提到的两种思路现在已经是一种混合技术了。
那 web components 呢？大家经常会拿 React, Angluar, Vue.js 与 web components 做比较，可 web components 最大的问题就是，没有解决 UI 与状态同步。
web components 只提供了模版语法，自定义标签解决 html 的问题，并没有给出一套状态与 UI 同步的方法。
所以就算使用 web components，我们可能还需要一个框架做 UI 同步，比如 Vue.js 或者 stenciljs。
作者还提供了一段简短的 UI 状态同步实例，这里略过。
最后给出了四点总结：
现代 js 框架主要在解决 UI 与状态同步的问题。
仅使用原生 js 难以写出复杂、高效、又容易维护的 UI 代码。
Web components 没有解决这个主要问题。
虽然使用虚拟 DOM 库很容易造一个解决问题的框架，但不建议你真的这么做！
3 精读作者的核心观点是，现代前端框架主要解决 UI 与状态同步的问题，这是毫无疑问的，也提到了包括 web components 也依然没有解决这个问题。
这可能是 web 开发最核心的问题了。
最初开发者的精力都在前端标准化上，诞生了一系列解决标准化问题的库，最有知名度的是 jquery。当前端进入 react 时代后，可以看到精力从解决标准化到解决 web 规范与实践的冲突，这个冲突正是作者说的问题。
前端三剑客问题就出现在 html、js、css 三者分离上。
html、css、js 各是一套独立的体系，但 js 又能同时控制 html 与 css，那为了解决同步问题，最好将控制权全部交给 js。
这样 web components 的问题也就好理解了，web components 解决的是 html 问题，注定与 js 无关。
html 官方规范估计很难出现现代框架的设计了，因为官方设计中前端三剑客是相互分离的方案，为了解决现阶段前端框架的问题，html 必须由 js 完全接管，这几乎就是 jsx，或者支持 template 语法的 html，可这与最初网页设计思路是违背的。
html 是独立的，甚至可以不依赖 js 运行，这天然导致了 UI 与状态同步这个难题。
为什么一定要用 jshtml 不依赖 js 的设计可能已经跟不上前端发展步伐了，也许 jsx 或者 template 才是真正的未来。
诚然，html 现在的设计可以在不支持 js 的浏览器执行，但就在最近，所有现代浏览器都支持了 service worker，它是凌驾于 html 执行时机之上的 js 脚本，甚至可以拦截 html 请求。一个不支持 js 的浏览器，可能也无法支持 service worker，禁用 js 的坚持可能只剩下安全性保护。
而实际上现代 web 页面都使用了 js 完全主导网页渲染，所以这已经从技术问题上升到了社会问题，如今禁用 js 的浏览器还有多少网页可以正常访问？除了某些超大型网站对禁用 js 状态做了特殊优化以外，现在几乎没有前端项目会考虑禁用 js 的情况了，因为我们不会假设 React、Angluar、Vue.js 框架代码无法运行。
所以为什么不融合 html 与 js 呢？既然事实上 UI 已经与 js 绑定了，那 w3c 为何不将 jsx 或者 template 列为标准呢？也许为了向前兼容，规范永远也迈不出这一步吧。
幸运的是，这并不妨碍现代前端框架的大量普及，而且势不可挡。
4 总结也许 UI 与状态同步的问题是前端发展的最大阻力，虽然现代化框架已经解决了这个问题，但 w3c 标准却一直无法往这个方向发力，导致 web 的下一个发展方向难以依靠标准规范来推动。前端日新月异的发展，很大一部分是规范的发展带来的，而现在我们进入了一个由工业化领导的时代，规范很可能永远也跟不上来，随之而来的是工业化社区也难以做进一步突破。
前端不仅是 web，或者也许下一个突破并不在 web，而是 ar/vr 或者下一个人机交互场景。同样，web 也不仅是前端三剑客，如果认为 React、Angluar、Vue.js 带来的工业化规范就是新的规范，前端才有动力向后发展，比如基于虚拟 DOM 的新框架、新语言。
所以笔者推导出现代前端开发的本质，是将 js、html 的平行关系变成了 js 包含 html 的关系，正如上面所说，这可能背离了 w3c 的初衷，但这就是现在的潮流。
最后总结一下观点：
也是原作者的，现代 js 框架主要在解决 UI 与状态同步的问题。
传统的前端三剑客正面临着进一步发展乏力的危机。
现代前端框架正在告诉我们新的三剑客：js（虚拟 dom、虚拟 css）。
5 更多讨论讨论地址是：精读《现代 js 框架存在的根本原因》 · Issue #84 · dt-fe/weekly
如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/95127.html
摘要：我是这一期的主持人黄子毅本期精读的文章是。模块化需要保证全局变量尽量干净，目前为止的模块化方案都没有很好的做到这一点。精读本次提出独到观点的同学有流形，黄子毅，苏里约，，杨森，淡苍，留影，精读由此归纳。 这次是前端精读期刊与大家第一次正式碰面，我们每周会精读并分析若干篇精品好文，试图讨论出结论性观点。没错，我们试图通过观点的碰撞，争做无主观精品好文的意见领袖。 我是这一期的主持人 ——...
摘要：拿到的都是而不是原始值，且这个值会动态变化。精读对于的与，笔者做一些对比。因此采取了作为优化方案只有当第二个依赖参数变化时才返回新引用。不需要使用等进行性能优化，所有性能优化都是自动的。前端精读帮你筛选靠谱的内容。 1. 引言 Vue 3.0 的发布引起了轩然大波，让我们解读下它的 function api RFC 详细了解一下 Vue 团队是怎么想的吧！ 首先官方回答了几个最受关注的...
摘要：目前我们的业务项目采用的来进行优化和首屏性能提升。可变性需要让开发人员降低开发时的基准线，来保证每一个用户的体验。对于路由的切分以及库的引入来说，这一个原则至关重要。快速生成一份站点的性能审查报告。 The Cost Of JavaScript 2018 关于原文 原文是在Medium上面看到的，Chrome工程师Addy Osmani发布的一篇文章，这位的Medium上面的自我介绍里...
摘要：由于具备一定的使用场景，而且支持方式零成本改写为即可，所以就支持它吧不支持的特性下面三个特性不支持，原因是没什么使用场景安全的安全的上面两者的结合首先看一个对象，如果出来的结果是，那这个返回值使用起来也没有意义。 1. 引言 备受开发者喜爱的特性 Optional chaining 在 2019.6.5 进入了 stage2，让我们详细读一下草案，了解一下这个特性的用法以及讨论要点。 ...
阅读 2687·2021-11-22 13:52
阅读 1167·2021-10-14 09:43
阅读 3617·2019-08-30 15:56
阅读 2927·2019-08-30 13:22
阅读 3245·2019-08-30 13:10
阅读 1537·2019-08-26 13:45
阅读 1084·2019-08-26 11:47
阅读 2746·2019-08-23 18:13
