原文：迈入现代 Web 开发（GMTC 2021 演讲《字节跳动的现代 Web 开发实践》全文）
这次分享的内容可以分成三个部分。
第一部分，先整体回顾「传统 Web 开发」范式中的「前端开发」技术和工程体系，有哪些瓶颈问题。
第二部分，对于在这些问题的背后、在这些问题的驱动下，正在发生的转变，做一下归纳和比较。
第三部分，介绍字节跳动在落地和推动这种转变中，发展和建设出的技术体系。对于字节这个「App 工厂」来说，这种发展相当于一场「引擎升级」的过程。

看下评论总结的：

devops + webpack配置抽象成code less + webIDE + 线上编译，这是要革传统前端的命啊，让开发者专注react代码的编写，其他啥都不用会

服务(围绕)于代码开发：整合 editor/git/eslint(校验)/react(框架套件)/webpack打包套件/UI 组件相关/severless后台服务/部署流水线

我理解下来约等于Vercel+Next.js+Web IDE, 可以说确实是目前前端开发最前沿的基础设施

比 next.js 的抽象层级更靠上，next.js 承担不了这里说的 MWA 框架的角色这次分享以介绍框架为主，也是第一步要开源的东西，是「Modern Web Stack 系列项目」之一，其他方面来不及介绍不是画饼，先得清晰未来要做的事情，才能坚定不移地推进

备注一下，以旧概念来理解新概念的过程中，我连旧概念都不太清楚的：

severless后台服务、部署流水线、Vercel、Next.js MWA 框架 MWA = 可视化的操作界面 + 工程化相关的一系列内容 + DevOps ？

现状及其瓶颈

代表抽象层从底层到顶层。最右边三个方块，都从最下面延伸到了最上面，代表它们都是端到端的解决方案
蓝色的方块都是代码层面的，绿色的方块都是平台层面的。
这套技术栈正在同样自然的演变成历史遗留的「祖传技术栈」，其中每个部分都有比较大的瓶颈问题

脚手架问题

脚手架的问题：
1、脚手架随着业务的改进会变得臃肿，失去通用性，迁移便携性；
2、脚手架是一次性的，一用即抛，业务对脚手架带来的改造不易沉淀；

不管哪种形式的脚手架，本质都是复制粘贴一堆样板代码，组成新的项目。
跟建筑行业使用的脚手架一样，都是在搭建过程中使用，用完就放到一边，只留下搭完的项目

但建筑脚手架拆掉之后留下的建筑，有一套不能动的钢筋混凝土骨架，
而脚手架生成的前端项目，是混杂在一起的样板代码
基建和示例代码混在一起，所以不仅是「可以改」，而且经常是「必须改」样板文件的内容和结构

时间长了之后，同样由一个脚手架生成的三个项目之间会差别非常大，如果要做统一的改进，或者把一个项目的沉淀和改进，应用到另一个项目里，都会很困难

另一方面，脚手架本身也在迭代改进，因为脚手架是一次性的，一用即抛，这些改进不能对原先创建的项目带来好处
即改造脚手架的工作量不好沉淀下来，

项目模板

问题：
1、从技术选型角度设计的项目模板：升级维护模板，在模板之间同步的技术沉淀困难；
2、从项目场景应用角度设计的项目模板：不同场景之间的技术需求，重合度很高。
===> 总结出了多种设计维度，依据不同设计维度的考虑可以得到多种排列组合

解决问题的可能性方案：
way1、更多的模板来覆盖更多的场景
way2、得通用性，舍细节、局限；

图上每个方块，都代表一个真实存在的模板，可以看到这些模板中有大量重复、又不会完全相同的内容，
升级维护模板、在模板之间同步技术沉淀，都有成本。很多模板会缺少更新，长期停滞，把成本留给搭建项目的人。
上面的项目模板是从技术选型角度出发的

那假如是从项目场景角度出发设计和维护模板呢？

如果从项目场景的角度出发来设计和维护模板，也有相同的问题。图中的方块是一些最基础、最典型的场景，和场景中的技术需求，可以看到，不同场景之间的技术需求，重合度很高。

此外，一个项目还有很多的类型维度，图中的每个方块，代表一种维度，比如按照图上的第三种维度，不同项目之间仅仅因为「组件库」和「设计系统」不同，就要设计和建设不同的模板。

根据不同维度之间的多种排列组合，下一步的发展趋势：

要么:模板面面俱到，增加更多的模板来适应，模板维护成本增大
导致模板进一步分裂和数量爆炸，每种模板的维护成本更高，应用场景更小，ROI 因此变低，更加倾向于停滞

要么:模板保持通用性舍弃面面俱到，局限性也不得不增加
导致模板对很多维度中的需求，不做考虑，只覆盖小部分需求，对项目开发的支持，局限在比较低的水平

webpack包装->前端工程化问题

问题：
1、停留在编译构建打包层面，相当于翻译、整合的功能，在工程化链路层面看来是不够强大的；
2、不够开箱即用，业务还需要大量配置
问题解决思路：
现代前端工程化，不仅包含「代码层面」应还包含「平台层面」；

很多脚手架、工程化建设，都会对 Webpack 做图上这样的包装，在最上层，提供围绕编译构建的两个命令 dev 和 build，搞出不同「规范」的配置文件和插件机制。

问题1：业务项目仍然大量配置
问题2：编译工具演进
问题3：dev和build远远不够
对项目开发的工程支持只停留在比较低的水平，比如就像 dev 和 build 命令一样，局限于跟编译构建有关的环节。

传统的工程化建设，就像图中文字说的，只能实现「代码层面」的基础建设，在创建项目的时候，做的事情大部分都属于「代码初始化」。

现代的 web 工程和前端工程，越来越多的包含「代码层面」之外的「平台层面」。

绿色方块代表的，是靠「代码层面」来实现工程需求，
橙色方块代表的，是要靠「平台层面」才能更好实现的需求。

标注：
看看这张大图，突然觉得作者的野心真的很大；
比如编码的智能化，平时用的代码自动补全功能（vscode编辑器的插件可提供支持、工程化的prettier可提供支持），而从这张大图里看出作者期望能将这些分散的能力集成在一个平台里，实现复用、插拔式的应用

另外提到的编译工具演进问题：

业务项目深度依赖 Webpack、包含很多 Webpack 配置，还带来另一个问题：

JS 开发工具从去年开始又出现新一轮更新换代的征兆，有人把这种趋势称作「JS 的第三纪元」，新范式的项目涌现，开始进入到日常业务的开发实践，很多场景下已经没有 Webpack。

React问题

现状：
1、收敛技术栈，围绕react做技术基建
why react？技术演进每次领先；技术趋势也是明朗的 oop -> fp

react的问题：
1、作为一个单纯的mvvm框架，只是解决了视图层的问题，不够

期望：
像antd pro一样，更加集成一点，提供限制路由实现，组件类型，ssr解决方案等等；

react优点：符合技术趋势，设计演进更快

但在工程体系中只靠 React 自己是远远不够的，
React 本身只解决视图层的问题，距离一个 Web 框架还缺很多东西，
在框架层面上，React 是无偏见的，比如没有限制路由实现、组件类型、SSR 解决方案等，也没提供默认的配置和工具体系，跟一个真正框架的必备要素，是完全相反的。

nodejs框架问题

Webpack、React 都不解决全链路的问题，缺乏框架级别的解决方案，很多前端项目会把目光转向发展时间更长、已经形成框架级别基建的服务器端框架领域

传统的前端开发局限于视图层，跟完整的软件开发、产品开发相比，最缺的就是「应用架构」。
但是 Node.js 框架能提供的，只是「服务器端应用架构」，是以服务器端开发为中心的。

客户端部分比较厚，这种情况下需要的「客户端应用架构」，如果使用 Node.js 框架，蓝色部分仍然需要自己摸索和搭建。

不管什么软件架构，核心都是「分层」和「关注点分离」，
完善的现代 Web 工程里，「服务器端应用架构」和「客户端应用架构」不会割裂，而是混为一体的。

除了架构，Node.js 框架也解决不了前面说的其他问题，同时还引入了图中右边的新问题：
业务逻辑既分散割裂，同时又重复，导致项目变得「低内聚高耦合」。

Node.js 框架随着发展，本质也越来越清楚：还是服务于专业服务器端开发的，降低不了前端开发者的服务器端开发门槛，这是一个最大的瓶颈。

💡日常技术沉淀/项目相关

字节跳动的现代 Web 开发实践-阅读笔记