什么是框架?
这应该不是我第一次谈‘框架‘了。React 是一个框架吗？ Vue 是一个框架吗？ 严格来说不是，它们只是一个视图解决方案，这里面算得上是框架的估计只有 Angular。
如果说后端框架围绕着数据存储建立起来，那么前端框架的基础就是视图库，毕竟前端的本质工作就是视图。这是为什么前端生态圈一般是围绕着视图库展开的。所以说，前端框架的基础是‘视图’库。
如果跟后端框架比起来，成熟的前端框架其实不多。
什么是框架？
看个例子。打开 UmiJS, 它对自己的描述是:
可插拔的企业级 react 应用框架
关键字是企业级。什么是企业级，我自己也说不清楚。我只知道 React 没有说自己是企业级，Koa、Express 也没有，然而 Eggjs 和 Umijs 都说它们是企业级框架；Angular 通常也常常跟企业级这个概念联系在一起；语言层面有 Java。
对比一下他们就知道了，我觉得企业级表示它是 面向企业生产，目的是提高企业的生产力。总结一下有以下特点：
- 是高效 成熟方案的整合
- 关注生产的整个链路，而不是某个环节
- 有更强的约束和限制
- 更严苛的要求。性能、可扩展性(以应对不同的需求)、健壮性、稳定性、可用性、安全性
- 标准化
- 经过生产环境验证, 有较多用例保证
归根到底还是成本问题，框架最本质的目的就是要减低各类成本。让更少的人可以做更多的事情、且能保证质量、降低维护成本，且能保证不断优化和演进。
给个定义吧。
前端框架体系的建立离不开前端工程化成熟和‘最佳实践‘的沉淀’。你可以认为框架就是一个整合的方案，提供一个前端‘最佳‘的组合配置。开发者需要做的就是在这个框架约束下填充自己业务代码。
好处：
- 效率提升。让开发者关注业务开发
- 学习成本降低。框架封装了很多底层复杂性
- 更强的约束。所有动作必须按照框架规定的执行, 避免干坏事、蠢事。更强的约束也意味着框架集成度更高、框架内部可以做更多事情，但灵活性也更低。
- 产品质量。框架内部会自动处理很多事情，例如性能优化、安全性处理
- 可维护性。所有项目都按照一致的、标准化的规范开发，升级迭代方便。这一点对团队项目的可维护性很重要。
坏处:
- 灵活性。不能满足所有人的需求，最佳实践这种东西有点武断
- 滞后性。具体方案可能会滞后。
- 大而全。对于某些项目可能过重。
前端‘框架’的发展历程
前端框架启蒙阶段
在 React、Vue 流行之前已经有许多‘前端框架‘，例如 Angular、Ember、Backbone…
它们大部分都受到后端框架的启发，因为当年也正是后端框架最火的时候，例如 Rails。所以在它们身上会看到很多后端框架的影子。
但是很多后端的开发模式，在前端有点吃不开。更本质的原因是前端工程化还不成熟，基础相对薄弱，难以支撑上层建筑的发展。
野蛮生长期
随着 NodeJS 的普及、JavaScript 语言日益强大，前端工程化逐步深化。 React 这类视图库出来后，很多东西被打碎重构, 正所谓百花齐放，欣欣向荣。
围绕着三大视图库各种各样的库百花齐放，前端也拓展到了浏览器以外的领域。人们都乐于造轮子，使用最新的技术。
由于发展得太快，所谓的框架/最佳实践很难被广泛接受，或者很容易就过时了，每个人每个团队更热衷于创造自己的组合方案，往往也只限于团队内部。
前端框架整合期
几乎每个团队都会重复走这样的路子：稳定技术栈、工程化建设、基础库/组件库建设、沉淀自己的最佳实践。
团队没有一定的工程能力和资源其实是很难将这些零散的实践体系化、有机地粘合起来, 长期有效的维护更新更是一件难事, 半途而废的居多。
现在前端发展开始进入平稳阶段。所以大一统的前端‘框架’再一次进入人们的视野。就像 Umi 的作者 云谦 说的: 现在是工业化时代, 框架像是一个魔法球，把各种技术栈吸到一起，加工后吐给用户，以此来支撑业务。
框架就是将各种技术栈方案、基础设施整合起来, 暴露标准的、一致性的接口, 让开发者专注业务开发。
现有的框架都有什么？
一个前端开发框架应该涵盖前端开发链路的各个环节。为约束和简化业务开发、提供有用的指导。
看看现有‘前端框架‘吧，现在社区上比较流行的‘框架’有 Angular、Next.js、Nuxt、Umi。我们横向对比一下它们的一些特性，发现基本上包含这些东西：
跟衣服的标准码一样。社区开源的都是通用类型框架，可以预知的是它们没有办法满足所有团队的要求。我们往往需要根据自己业务情况量身定制框架。
为了应对这些需求，不同的框架也有不同的应对策略:
- 更开放。框架只提供核心功能，附加几乎什么事情都能干的插件机制。插件可以干预框架的整个生命周期，不满足的需求可以自己定制自己的插件
- 更决断。我给你提供的就是最好的，能满足你的尽量满足你，其他的你不要管太多，也没有必要管, 专注你的业务。
我们也有自己的选择策略:
- 自己搞。例如大厂团队，有资源、有丰富的实践经验。他们有能力将自己的‘最佳实践’体系化。他们会选择创建自己的框架。同时他们也乐于将经验分享出来，也可以利用社区完善自己的作品。个人，基于学习和折腾的目的, 也可以搞一套。
- 基于开源框架扩展。可以将开源框架作为基础，根据自己团队情况进行扩展开发。
- 完全使用开源框架。开源框架可以满足许多通用的需求, 适合简单的应用场景。我们选择一个框架主要有两个原因：① 我们要提高工作效率；② 我们需要一个标准。 为了标准，其实可妥协一些事情。更重要的是这些框架是在不断发展和演进的, 从而我们团队的技术也可以免费地跟随他们演进和发展。将开源框架的默认最佳实践开发视为标准。
我一直坚信专业的人做专业的事。要善于将事情外包出去，腾空自己去做重要的事情。大厂有专门的团队在做工具、建设基础设施，社区上开源的框架也由一大帮牛人在维护，而且通常开发迭代很活跃。所以说社区已经有的方案，可以直接拿来用，不要自己去造轮子，因为你一般没那么多精力。
谈谈前端团队框架体系的建设
前端开发的时间都花在了哪里?
上图来源于<蚂蚁前端研发最佳实践> PPT
对于前端团队来说，开源前端框架只是一个基础，只是涉及前端开发的某个很小的部分，它就像一艘船。你要航线穿越大西洋，还有做很多工作、需要紧密高效的协作、可靠的后勤保障、目标和方向、坚定的领导… 路还很长。
现在来聊聊‘广义的‘框架体系，它集成自身业务，涉及前端开发完整链路，关注点从前端应用上升到了前端团队研发体系。
九层之台，起于累土。 前端团队框架体系的建设是一个渐进式的过程，首先从基础设施开始、接着就是应用开发技术栈组合，再到组件体系，后面是上层的业务开发方案… 上层以下层为基础，共同构建出完整的框架体系。
我觉得前端团队可以按照这样的分层结构，分阶段来完成这些建设任务。
第一阶段: 前端工程化 / 基础设施
最基础的阶段，关注前端的基础设施建设。这个阶段已经比较成熟，社区上有很多开箱即用的方案，例如 Umi、Next.js、Vue-CLI、Create-React-App 等等。主要内容有:
第二阶段: 应用开发方案整合
在完善基础设施的同时，团队的应用开发技术栈组合方案也应该稳定下来，成为框架的一部分。这些组合也非常重要，它会影响上层的组件建设和业务开发。主要内容有:
第三阶段: 组件体系
组件化现在是前端主流开发模式，这里还有很多工作可以做，还有很大的提效空间。
整个组件体系也是一个分层式的结构：
- 基础组件。越底层，就说明可复用的程度越高、越通用。Ant-Design、Element-UI、iView、Material-UI 这些就属于基础组件库，有能力的团队也可以开发一套符合自己设计风格的组件库。
- 业务组件。在基础组件之上封装的、耦合自己业务的组件。它们一般从重复的业务场景中抽象出来。
- 区块。再往上，就很难用模块化的组件去组织了。于是有人(阿里前端)提出了‘区块’的概念，你可以认为‘区块’是：代码片段、代码示例、代码模板… 这么看来，这并不是一种新的概念? 还没完! 区块还要配套‘区块市场’才能展现它的用处。区块市场是一个代码片段分享平台，维护着大量的区块，试图覆盖大部分常见的使用场景。对于开发者来说就是找到尽量匹配自己场景的区块，拷贝过来，稍微改改就行了。这是一种 ‘Ctrl C，Ctrl V’ 编程哲学的完美实践啊。
- 页面。和区块差不多，快速生成页面和路由。约定式的路由可以给页面自动化创建带来一些便利。
- 布局。例如后台的整体布局。
- 项目。项目的整体结构。可以通过‘脚手架‘ 来快速生成项目模板。
像区块、页面生成这些操作需要一些工具辅助。例如：
- 生成器。生成不同级别的元件
- 项目(项目模板)。 俗称脚手架, 支持不同的项目类型：应用、组件库、程序库、 插件
- 页面/路由
- 区块
- 组件
- 数据模型
- 可视化工具。可视化的项目编排工具, 如飞冰。
第四阶段：打通上下游
前端只是研发流程的一环，只是前端自嗨，上下游没有资源支持，是很难走远的。
对于前端来说，通常上游指的是 UI、下游指的是后端。
对于 UI。上面说的组件体系，其实是建立在稳定的、一致的、统一的 UI 设计语言之上的。否则一切都是空谈。所以我们要求 UI 设计团队要有良好的设计规范、能和前端组件体系绑定并良性迭代。
对于 后端。可以促进建立更标准的接口范式、封装通用的服务(有利于业务组件复用)、更深的有业务中台、BFF…
上下游的打通，对前端生产力的解放也有非常大的促进作用。
