if 我是前端Leader，谈谈前端框架体系建设

这期来聊一聊前端框架。

“if 我是前端 Leader” 是我的一个文章系列，说说我人在其位，欲谋其职的一些点点滴滴感悟。跟前端 Leader 只有那么一丢丢关系，干货不多，但老少皆宜，不要被标题给唬住了。

文章大纲

什么是框架?

这应该不是我第一次谈‘框架‘了。React 是一个框架吗？ Vue 是一个框架吗？ 严格来说不是，它们只是一个视图解决方案，这里面算得上是框架的估计只有 Angular。

如果说后端框架围绕着‘数据存储’建立起来，那么前端框架的基础就是视图库，毕竟前端的本质工作就是视图。这是为什么前端生态圈一般是围绕着视图库展开的。所以说，前端框架的基础是‘视图’库。

如果跟后端框架(Rails, Django, Laravel...)比起来，成熟的前端框架其实不多。

什么是框架？

看个例子。打开 UmiJS, 它对自己的描述是:

可插拔的企业级 react 应用框架

关键字是企业级。什么是企业级，我自己也说不清楚。我只知道 React 没有说自己是企业级，Koa、Express 也没有，然而 Eggjs 和 Umijs 都说它们是企业级框架；Angular 通常也常常跟企业级这个概念联系在一起；语言层面有 Java。

对比一下他们就知道了，我觉得企业级表示它是 面向企业生产，目的是提高企业的生产力。总结一下有以下特点：

归根到底还是成本问题，框架最本质的目的就是要减低各类成本。让更少的人可以做更多的事情、且能保证质量、降低维护成本，且能保证不断优化和演进。

给个定义吧。

前端框架体系的建立离不开前端工程化成熟和‘最佳实践‘的沉淀’。你可以认为框架就是一个整合的方案，提供一个前端‘最佳‘的组合配置。开发者需要做的就是在这个框架约束下填充自己业务代码。

好处：

坏处:

前端‘框架’的发展历程前端框架启蒙阶段

在 React、Vue 流行之前已经有许多‘前端框架‘，例如 Angular、Ember、Backbone...

它们大部分都受到后端框架的启发，因为当年也正是后端框架最火的时候，例如 Rails。所以在它们身上会看到很多后端框架的影子。

但是很多后端的开发模式，在前端有点吃不开。更本质的原因是前端工程化还不成熟，基础相对薄弱，难以支撑上层建筑的发展。

野蛮生长期

随着 NodeJS 的普及、JavaScript 语言日益强大，前端工程化逐步深化。 React 这类视图库出来后，很多东西被打碎重构, 正所谓百花齐放，欣欣向荣。

围绕着三大视图库各种各样的库百花齐放，前端也拓展到了浏览器以外的领域。人们都乐于造轮子，使用最新的技术。

由于发展得太快，所谓的框架/最佳实践很难被广泛接受，或者很容易就过时了，每个人每个团队更热衷于创造自己的组合方案，往往也只限于团队内部。

前端框架整合期

几乎每个团队都会重复走这样的路子：稳定技术栈、工程化建设、基础库/组件库建设、沉淀自己的最佳实践。

团队没有一定的工程能力和资源其实是很难将这些零散的实践体系化、有机地粘合起来, 长期有效的维护更新更是一件难事, 半途而废的居多。

现在前端发展开始进入平稳阶段。所以大一统的前端‘框架’再一次进入人们的视野。就像 Umi 的作者 云谦 说的: 现在是工业化时代, 框架像是一个魔法球，把各种技术栈吸到一起，加工后吐给用户，以此来支撑业务。

上图来源于 PPT

框架就是将各种技术栈方案、基础设施整合起来, 暴露标准的、一致性的接口, 让开发者专注业务开发。

现有的框架都有什么？

一个前端开发框架应该涵盖前端开发链路的各个环节。为约束和简化业务开发、提供有用的指导。

看看现有‘前端框架‘吧，现在社区上比较流行的‘框架’有 Angular、Next.js、Nuxt、Umi。我们横向对比一下它们的一些特性，发现基本上包含这些东西：

跟衣服的标准码一样。社区开源的都是通用类型框架，可以预知的是它们没有办法满足所有团队的要求。我们往往需要根据自己业务情况量身定制框架。

为了应对这些需求，不同的框架也有不同的应对策略:

我们也有自己的选择策略:

我一直坚信专业的人做专业的事。要善于将事情外包出去，腾空自己去做重要的事情。大厂有专门的团队在做工具、建设基础设施，社区上开源的框架也由一大帮牛人在维护，而且通常开发迭代很活跃。所以说社区已经有的方案，可以直接拿来用，不要自己去造轮子，因为你一般没那么多精力。

谈谈前端团队框架体系的建设

前端开发的时间都花在了哪里?

上图来源于 PPT

对于前端团队来说，开源前端框架只是一个基础，只是涉及前端开发的某个很小的部分，它就像一艘船。你要航线穿越大西洋，还有做很多工作、需要紧密高效的协作、可靠的后勤保障、目标和方向、坚定的领导... 路还很长。

现在来聊聊‘广义的‘框架体系，它集成自身业务，涉及前端开发完整链路，关注点从前端应用上升到了前端团队研发体系。

九层之台，起于累土。 前端团队框架体系的建设是一个渐进式的过程，首先从基础设施开始、接着就是应用开发技术栈组合，再到组件体系，后面是上层的业务开发方案... 上层以下层为基础，共同构建出完整的框架体系。

我觉得前端团队可以按照这样的分层结构，分阶段来完成这些建设任务。

第一阶段: 前端工程化 / 基础设施

最基础的阶段，关注前端的基础设施建设。这个阶段已经比较成熟，社区上有很多开箱即用的方案，例如 Umi、Next.js、Vue-CLI、Create-React-App 等等。主要内容有:

第二阶段: 应用开发方案整合

在完善基础设施的同时，团队的应用开发技术栈组合方案也应该稳定下来，成为框架的一部分。这些组合也非常重要，它会影响上层的组件建设和业务开发。主要内容有:

第三阶段: 组件体系

组件化现在是前端主流开发模式，这里还有很多工作可以做，还有很大的提效空间。

整个组件体系也是一个分层式的结构：

飞冰

像区块、页面生成这些操作需要一些工具辅助。例如：

可视化工具。可视化的项目编排工具, 如飞冰。

第四阶段：打通上下游

前端只是研发流程的一环，只是前端自嗨，上下游没有资源支持，是很难走远的。

对于前端来说，通常上游指的是 UI、下游指的是后端。

对于 UI。上面说的组件体系，其实是建立在稳定的、一致的、统一的 UI 设计语言之上的。否则一切都是空谈。所以我们要求 UI 设计团队要有良好的设计规范、能和前端组件体系绑定并良性迭代。

对于 后端。可以促进建立更标准的接口范式、封装通用的服务(有利于业务组件复用)、更深的有业务中台、BFF...

上下游的打通，对前端生产力的解放也有非常大的促进作用。

未来: AI?

AI 自动生成前端代码？ 太高大上了，还是把话筒交给它吧： 《双 11 模块 79.34% 的代码是怎样智能生成的？》， 溜了

扩展资料