精读《寻找框架设计的平衡点》

1 引言

尤雨溪 在 2019 JSConf 的分享 Seeking the Balance in Framework Design 十分精彩，道出了如何进行合理的前端框架设计与框架选型。

正如所说，框架对比不能只停留在 Star 数量、Npm 下载量、Stackoverflow 问题量这些简单的数据对比，而要深刻到技术细节进行比较。比较框架有多种不一样维度，此次分享就从服务范围、渲染机制、状态机制这三个维度进行对比。

2 概述

此次分享的精彩之处在于不偏不倚的站在客观立场分析了框架各维度好的一面与坏的一面，从中咱们不只能学习到一些框架知识，还能培养思辨能力。

服务范围

服务范围是个比较难翻译的单词，在原 PPT 中用了 “Scope” 这个单词表示，能够理解为 “做用域、框架的承诺功能范围、服务配套齐全程度”。好比提供的是一个工具库仍是总体框架，插件管理是集中式仍是依赖生态。

React 是典型的小服务范围框架，核心包只实现了基本功能，而其余生态基本靠社区拓展；Angular 是典型大服务范围框架，官方对全部业务场景都作了最佳实践能力覆盖；Vue 处在中间区域，经过功能分层，既拥有小服务范围的能力，又能够搭配官方插件实现更多场景化能力。

小服务范围优点

概念少，易上手

小的服务范围表明了小的学习成本，由于暴露的基本能力较少，概念也会比较少，对新人上手比较友好。

生态繁荣，百花齐放

因为不少功能没有被官方实现，社区就有机会填补这些空白，所以会冒出许多第三方库，并且一旦作得好，就有机会成为 “事实标准”，所以开发者会更加积极参与到社区开发，本身作的框架 “上升空间” 也很是大。

同时，社区的力量会致使多元化，所以总体生态完整度与创新性都会很是亮眼，并且具备持续迭代的能力。

核心维护成本低

官方维护的核心代码较少，所以维护成本大大下降，并且官方能够将精力放在更多核心能力加强上，好比 Suspense 等，而不是将精力消耗在生态插件上。

小服务范围的劣势

复杂场景要引入新概念

复杂场景没法支持时，就要引入新的概念解决，这致使后续技术选型可能产生分歧，并带来持续的新概念理解成本。

非官方的开发模式逐渐产生

随着时间的流逝，会逐渐涌出一些新的设计模式，成为当下几乎是必不可少的方案，但却不会出如今官方文档中，形成选型时的疑惑。Redux 就是一个例子。

生态变化快，碎片化且持续流失

非官方的生态也意味着不稳定，并且缺少统一的管理，碎片化的模块之间可能常常出现不兼容的问题。

并且任何模块均可能被时代无情的淘汰，就像 Flux 到 Redux 再到 Hooks，带来额外的迁移成本和认知成本。谁也不但愿本身的项目架构 “变得过期”，或者随时面临被新架构取代的风险，但第三方社区几乎必定表明将来会出现一种模式取代现有模式，只是时间迟早而已。

大服务范围的优点

大部分业务场景都被内置解决

减小没必要要的技术方案调研与纷争，大服务范围的框架内置的方案就能解决几乎 100% 业务问题，团队不再会为通用架构问题烦恼了。

生态稳定、连贯

稳定是指，官方维护做为背书，几乎不会存在一些生态包忽然不维护、与已有版本不兼容、被植入恶意程序等等意外状况。

连贯是指，官方会统一考虑一个改动在全部生态插件形成的影响，并以一个最合理的思路作总体改造，生态包不管是接口仍是兼容性都不须要担忧，设计思路也会一脉相承。

大服务范围的劣势

前期上手成本高

全家桶的概念致使上手难度偏高，由于必须理解全部内置概念后才能开始项目。

若是内置模块没法知足业务，会以为有些死板

一旦发生内置功能没法知足业务的场景，就很难拓展了，由于 all in one 的思路本质上就是排斥自定义拓展的，这点从 angular-cli 就能看出来。

之因此以为死板，是由于这种状况没办法用优雅的方式解决，只能在现有约束的框架内经过某些 “Hack” 方式解决，天然会有种死板的感受。

中等服务范围的优点

分层设计，容许新特性渐进加入

Vue 经过分层设计作到了折中，即官方仍是会维护生态，只不过生态不是必须的，能够按需使用。这样作的好处是兼顾了一些优点。

低学习门槛

与小服务范围框架同样，对于核心包来讲学习成本都比较低。

依然有最佳实践解决全部业务问题

和大服务范围框架同样，拥有全套官方最佳实践，但不内置，不强求必定要使用，所以你能够按需使用。

中等服务范围的劣势

维护成本高

和大服务范围框架同样，虽然生态不强求，但毕竟官方仍是要持续维护的，所以维护成本高的问题依然存在。

生态多样性不高

虽然生态是按需的，但毕竟中等服务范围的框架官方会实现一套标准生态插件，这会极大影响社区生态的发展空间，致使 “非官方插件没人愿意作”，所以生态多样性会差一些。

渲染机制

渲染机制区别主要在 JSX vs Template 之间，不一样的表达方式之间仍是存在一些很本质的区别，然而正如一开始所说，没法一言蔽之，必须从多个角度拆解的看。

JSX 的优点

纯 JS 表达 UI

单这一点就很是重要了，知足了 All In Js 的幻想。毕竟 Html、Css 相比 Js 来讲，模块化能力和灵活性都很弱，将其都收敛到 Js 不只表达方式更统一，更重要的是都得到了与 Js 同样的模块化、灵活性、Typescript 支持等能力。

视图即数据

将视图看做一种数据，让针对视图的逻辑测试成为可能。

同时也将视图概念泛化了，由于数据是平台无关的，一份描述视图的 DSL 能够运行在任何平台。

JSX 的劣势

开销大

页面节点越多，Diff 开销就越大。

动态渲染很难性能优化

因为全部 DOM 节点都是动态生成，所以没法根据初始状态结构进行安全的优化。相比之下，Template 模式能够肯定哪部分属于变量，哪部分是固定的，对固定部分的 Diff 检测均可以跳过。

动态调度虽然改善了性能，但依赖更重的运行时

React ConcurrentMode 是一个调度优化器，但实现的逻辑也比较复杂，加剧了运行时负担。

Template 的优点

原生性能

因为 Template 对节点进行直接渲染，所以与原生性能一致。

Runtime 更小

因为不须要额外优化，运行时代码会小不少。

Template 的劣势

被 Template 语法约束，且没法拓展

对于 Template 不支持的，只能选择接受，由于除了框架本身，没有人能拓展 Template 的特性。当遇到一些很是动态场景，但 Template 不支持的状况，只能选择接受，并用比较 Hack 的方式绕过解决，除此以外别无他法。

模版冗长

JSX 能够利用循环语句或者变量赋值进行模版区块的复用，但 Template 模式每次新模版都要一行一行的打出来，这种冗长的开发体验不太友好。

运行时解析开销或者依赖编译期逻辑

要么经过编译器预先生成 AST，要么运行时动态将 Template 解析成 AST，不管哪一种方案都有额外的开销，一种是工程依赖的开销，一种是运行时动态解析的性能开销。

VDom + Template 的特点

Vue 在 Template 基础上支持了虚拟 DOM，所以兼具二者特点。

性能上，在编译时就进行 AST 解析，减小了运行时解析开销。

功能上，支持模版与 JSX 两种语法。

状态机制

状态机制 尤雨溪 在 JSConf 提到要单独拆出来说，由于内容较多，时间可能不够，本次精读也限于篇幅缘由略过：

• Mutable vs Immutable。
• 依赖追踪 vs 脏检测。
• 响应式 vs 模拟响应式。

显然，状态机制方案更是仁者见仁智者见智的事情，一样得从多个维度进行独立分析，并根据实际业务场景具体选择。

最后，意识到没有一个绝对均衡的框架设计方案，由于在工程领域，没有最好只有更好。

3 精读

咱们再延伸谈一谈为何框架设计要寻找平衡点。

框架设计没有银弹

与数学公式不一样，框架设计甚至整个工程技术设计都没有所谓的真理，所谓条条大路通罗马，实现同一个技术目标的众多方案之间也许就是平行关系，能够根据不一样维度列出一二三的对比，但没法得出一个总的结论，孰优孰劣。

使用场景不一样

不一样使用场景决定了对框架诉求的不一样。

好比开发很是定制、炫酷的可视化大屏，那么前端开发框架基本也用不上，由于关注点不会聚焦在项目路由、UI 描述、甚至是数据流，而是聚焦在性能、图形渲染等问题。解决这些领域的框架多是 虚幻 四、Unity 等游戏引擎，但普通的前端开发框架毫不会涉足这种领域，框架必定要肯定本身功能范围。

即使仅局限在 Web 领域，也须要考虑是否要支持非 Web 场景，那么将 HTML 抽象成一个通用 DSL 就多是一种选择，但非 Web 领域毕竟不是主打业务领域，在这种业务场景周边生态维护可能就比较少，这也是须要取舍的地方。

使用的人不一样

不一样团队对框架的要求也不一样。

刚起步的小团队可能更须要保姆式的框架，由于这样最节省人力成本。对于规模较大的团队，但愿对框架拥有较大定制能力时，小服务范围的框架可能更受青睐。固然框架做者能够像 Vue 同样作出渐进式官方能力加强方案，以此知足不一样需求的用户，但毕竟也不能将生态彻底交给社区，仍是要作取舍。

因此当遇到更新更酷的框架时，须要冷静思考的不仅是这个框架带来的收益与花费的迁移成本哪一个更高，以及团队可否接受这套框架的开发习惯，更须要思考的是这个框架自身作了哪些权衡，若是这些权衡与 React、Vue、Angular 相似，那么仅仅变化了语法或者语言的改动其实意义不大，此时须要慎重考虑。

4 总结

此次没有提到的状态机制对比，你能分别列举出优缺点吗？欢迎留言。

讨论地址是：精读《寻找框架设计的平衡点》 · Issue #223 · dt-fe/weekly

若是你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）