浅谈 「现代 Web 开发」 范式

「现代 Web 开发」代指现在全球技术社区和全行业里，越来越重要的一个「大趋势」（Megatrend）、一场正在进行中的「范式转移」。其中，重要的是如何将「现代 Web 开发」转化成具体的技术栈和研发工具体系。

传统Web开发

数量之多，场景之丰富打的各种产品、工具、软件应用的开发，很多是基于 Web 技术、前端技术，其中出现过很多的问题和瓶颈。

1. 前端脚手架

不管哪种形式的脚手架，本质都是复制粘贴一堆样板代码，组成新的项目。脚手架生成的前端项目，是混杂在一起的样板代码，虽然有文件结构，但可以随意修改，而且因为基建和示例代码混在一起，不仅是「可以改」，而且经常是「必须改」样板文件的内容和结构，才能完成真实项目的完整搭建。随着业务需求，也可能是因为技术沉淀和工程，以及脚手架本身的改进迭代，起初相同的项目之间差异不断增大。如果要做统一的改进，或者把一个项目的沉淀和改进，应用到另一个项目里，更或者引入脚手架本身的改进到每个项目，都会很困难。

脚手架是需要各种项目模板。从上图看，脚手架建设者需要提供多种模板，覆盖不同的需求，使用者也经常需要复制原有模板，修改成新的模板，比如产品的技术形态是 SPA 还是 MPA，都会产生不同的模板。升级维护模板、在模板之间同步技术沉淀，都有成本。很多模板会缺少更新，长期停滞，把成本留给搭建项目的人。多种维度的类型，导致模板进一步分裂和数量爆炸，每种模板的维护成本更高，应用场景更小，ROI 因此变低，更加倾向于停滞；要么会导致模板对很多维度中的需求，不做考虑，只覆盖小部分需求，对项目开发的支持，局限在比较低的水平。

2. Webpack 的「包装」

很多脚手架、工程化建设，对 Webpack 做包装，在最上层，提供围绕编译构建的两个命令 dev 和 build，搞出不同「规范」的配置文件和插件机制。问题是抽象程度很有限，深度依赖 Webpack、包含很多 Webpack 配置。

「JS 的第三纪元」，新范式的项目涌现，开始进入到日常业务的开发实践，很多场景下已经没有 Webpack。比如，esbuild 和 swc 这样的构建工具，把编译、构建、打包、压缩等在 Webpack 里属于不同环节的部分，合并在一起，加上非 JS 的系统编程语言的帮助，大幅提升构建速度。另一方面，也能支持 ESM 优先的、不需要打包的构建场景。Snowpack、Vite 这样的工具，在此基础上实现了开发者体验（DX）优先的、不打包（Unbundled）的开发调试模式。现代的 web 工程和前端工程，越来越多的包含「代码层面」之外的「平台层面」，不仅仅局限于跟编译构建有关的环节，已经超出了 Webpack 的能力范围。

3. React 技术栈

React 符合技术趋势，设计演进更快，使得在有基础建设团队支持的业务场景中，都具备很大的优势。React 在整个行业和技术社区的生态和基建，导致在业务支持和工程建设中，其领先地位无可替代。React 本身只解决视图层的问题，距离一个 Web 框架还缺很多东西，在框架层面上，React 是无偏见的，比如没有限制路由实现、组件类型、SSR 解决方案等，也没提供默认的配置和工具体系，跟一个真正框架的必备要素，是完全相反的。

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

4. Node.js 框架

业界主流的 Node.js 框架 NestJS 的作者，在文档首页的设计理念部分，就指出 React、Vue、各种开发工具，都没有解决「应用架构」的问题，而 NestJS 就是要提供开箱即用的应用架构。但是 Node.js 框架能提供的，只是「服务器端应用架构」，是以服务器端开发为中心的，这不适合关注哭护短部分的「客户端应用架构」。

完善的现代 Web 工程里，「服务器端应用架构」和「客户端应用架构」不会割裂，而应该是混为一体的，重点是要进行「分层」和「关注点分离」。在「前后端分离」之后从「后端项目」里独立出来的「前端项目」，使用 Node.js 框架之后，又混入了很重的后端业务逻辑和研发需求。而 Node.js 框架随着发展，本质上还是服务于专业服务器端开发的，降低不了前端开发者的服务器端开发门槛，这是一个最大的瓶颈。而包含服务器端部分的「前端项目」，并不是真正的「全栈」，只是包含了服务器端最上面的、很薄的一层，解决 Web （处理 HTML 请求）和 BFF（面向特定 UI 的 API 服务） 需求。用 Node.js 框架来开发，很多时候带来的问题比解决的问题更多。

5. IaaS 和 PaaS服务

前端项目跟后端项目一样，直接部署这  IaaS 和 PaaS层上。但是在这种 PaaS 上或直接在 IaaS 上做部署和运维，对前端开发者来说，不但复杂低效，而且在很多前端部署需求上，没有获得任何支持。而且 IaaS 和 PaaS 都源自后端开发场景，是后端研发技术的平台化沉淀，设计和演进都天然的受到局限，对前端研发场景不只缺乏理解，也无法在相同的基础设施里去兼顾前端部署方面的通用需求。

在真实业务中，为了避免直接跟 IaaS 和 PaaS 打交道，都会有意无意的做一些集中建设，填补这片空白。比如会统一的 SSR server 项目，在开发各种前端仓库的时候，需要本地有 SSR server 的仓库，才能运行和调试这些前端项目。

集中建设，不是把前端项目中的正常组成部分放到了前端开发者无法掌控的地方，就是反复重复的建设出被业务需求扭曲的部署方案，难以沉淀、演进和最大化的提效。因此，填补前端部署方面的通用需求，成为传统前端技术栈里的一个大问题。

现代 Web 开发范式

Ruby on Rails 是「传统 Web 开发」范式的一个典型代表， 本质上是以服务器端开发为中心的、MVC 架构的「服务器端 Web 框架」，就像图上右边这样，产出网页和 API。

12-Factor App本质上是一种工程标准，是进入云计算时代之后，服务器端应用和工程项目中形成的规范，这套标准可以保证应用能很好的运行在「后端 PaaS」或其他的传统云计算平台上。  

MERN / MEAN 技术栈，是前端代码和工程，从其他技术栈的服务器端框架中「分离」出来之后，又融合相同技术栈的服务器端框架，形成的「全栈」开发方案。

而在「现代 Web 开发」趋势下，在国外被称作「JAMstack」或 「SHAMstack」的技术栈，变得越来越清晰和主流。

展开来看，Serverless 模式和基建取代了 M 代表的传统后端基建；前端应用的构建产物 、 服务器端渲染、静态网站生成、前端程序中的 BFF、等等，取代了MERN 中E 代表的服务器端 Web 框架和服务器端代码。变成以客户端研发方式、客户端应用架构为中心，「全栈」的 Web 项目技术栈的项目。

同一个现代 Web 项目，可以同时符合 JAMstack 和 STAR，JAMstack 强调的是前后端架构和开发范式，STAR 强调的是专业的编程方式。特别要注意的是，STAR 其实体现了一个现代 Web 项目中的「前端工程化」，除了编译环节，也需要 Runtime 环节和代码编写环节的支持，除了视图层，也需要完整的应用架构和 Model 层的支持。

Meta-framework，取代了脚手架和构建工具。本质上是把 JAMstack 和 STAR 强调的部分加起来，用以客户端为中心的、包含更上层抽象的、通用的 Web 框架的形式，整体系统的满足这些需求，并抽象、简化这里面的各种模式。

 

综上，「传统 Web 开发」和「现代 Web 开发」两种范式的具有以下本质特征和组成要素： 

从框架和 UI 的角度来看，「传统 Web 开发」是以服务器端框架为中心来做全栈开发，客户端是围绕 HTML 和对象树的编程范式。「现代 Web 开发」是以新一代客户端框架为中心来做全栈开发，客户端同样围绕专业、通用的软件开发语言和编程范式。

从架构的角度来看，「传统 Web 开发」中存在两套比较独立和欠缺融合的程序，「前后端分离」改善了分工协作，但对于分离出来的「前端技术栈的 Web 项目」，在架构和开发范式上没有真正实现「分离」，前端开发者需要跟服务器代码打交道。「现代 Web 开发」实现了在同一套程序里一体化开发，在开发、调试、运行、部署等环节都能做到「无服务器化」，让前端技术栈的开发者更容易成为真正的「产品开发者」。

从抽象的角度来看，「传统 Web 开发」中前端部分的基础抽象是原始、初级的，比如脚手架、样板代码、基本的 Webpack 包装和 CLI 工具、React 和 JS 生态中的海量选择，这种「前端特色」，跟成熟的软件开发有显著差距。DX 是指开发者自身的效率，UX 是指开发出的应用的能力和质量，传统范式中的抽象太原始，导致 DX 和 UX 没法同时提升。「现代 Web 开发」中有了一体化的、更成熟的、框架级别的基础抽象，能同时追求和确保 DX 和 UX 的最大化。

从部署的角度来看，「传统 Web 开发」的项目，要么纯静态托管，要么作为服务器端应用来部署和运维。不同部署方式，会导致整个工程都不同，需要不同的脚手架模板。「现代 Web 开发」的项目有更多样强大的运行和部署方式，但在 Meta-framework 的支持下，项目模板的变化变少了，有机会完全融合、收敛成一个模板，成为「Universal App」。

从平台角度来看，「传统 Web 开发」基于后端的云基础设施，由于代码层面缺乏抽象，客户端代码的复杂性容易停留在很基础的程度，有些时候会干脆直接改成 JSON 之类的配置。「现代 Web 开发」基于新一代 Serverless 平台。在 Serverless 的支持下，能实现以前难以实用化的云研发。由于代码层面有统一的、上层的抽象，在开发中能引入更多低代码模式。

总结

「现代 Web 技术栈」可以展示为下图：

可以看到，「现代 Web 开发」中的平台化基建，占比超过纯代码层面的基建。没有割裂，中间的研发平台建立在「前端云」之上，工程框架基于研发平台支持研发全链路，右边的工程方案跨越上中下三层，是指可以通过工程方案，定制左边这三层的需求。

「Universal JS」是指同一份 JS 代码既支持在浏览器端运行，也支持在服务器端运行。而「Universal App」是进一步发展，让同一份 app 代码，可以用图上中间这一排的方框代表的任意方式来运行，也支持同时部署多个不同运行方式的版本。符合的应用架构应该是提供开箱即用的、符合现代 Web 开发范式、以客户端应用为中心、前后端一体化的。

比如一个静态网站切换成 SSR，或启用 SPR 的时候，不需要调研技术选型和考量成本收益，几乎什么都不用改。也可以随时退回原来的方式。比如为中后台项目同时提供 SaaS 版、桌面安装版和私有化部署版。比如让微前端子应用，既能在主应用里访问，也能独立访问。

从传统 Web 开发范式向现代 Web 开发范式的转换是能实现「三位一体」应用，在三种开发方式之间，可以无缝切换。比如可以从现代 Web 开发范式，切换成传统的 Node.js Web 应用。也可以把 MWA 项目中的 BFF 拆分成独立的纯 API 服务项目。一个纯 API 服务，也可以随时切换成包含 web 的 MWA 项目。