SSR 无处不在！2023 年 8 大 Web 开发趋势预测

（元）框架

单页应用 (SPA) 及相关框架（例如 React.js、Vue.js、Svelte.js）都已经存在了很多年。然而，随着这些解决方案之上的元框架的兴起，可以看到应用从客户端渲染（CSR）转向服务端渲染（SSR）的明显趋势。如今，在使用 JavaScript 框架时，SSR 无处不在。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

流行的 Next.js 的元框架建立在 React 之上。React 核心开发人员 Andrew Clark 将其称为 2022 年的“真正的 React 18 版本”，因为它附带了 React 团队作为较低级别的基本构建块提供的所有功能（例如 Suspense、流式 SSR）。Vercel（Next.js 背后的公司）和 React 核心团队正在密切合作，提供出色的开发者体验。Remix（最近被 Shopify 收购）是 Next.js 替代品，它采用不同的方法将 React 转变为元框架（例如，使用 Web 标准作为一等公民）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

尽管 Next.js 已经是现代 SSR 领域的有力竞争，但其他框架也值得关注：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

• SveltKit：基于 Svelte.js 构建，其最新的 1.0 版本由 Vercel 支持；
• SolidStart：基于 Solid.js 构建，其 DX 与 React 相比有所改进。

渲染模式

虽然过去 10 年（2010 年至 2020 年）一直由单页应用 (SPA) 和客户端渲染 (CSR) 主导，从 Knockout.js 和 Ember.js 到 Angular.js、React.js 和 Vue.js，过去几年，人们对使用元框架的服务端渲染 (SSR) 越来越感兴趣。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

从外部看来，这个周期似乎又要结束了，因为在多页应用 (MPA) 中使用 SSR 和 JavaScript（例如 jQuery、MooTools、Dojo.js）已经很长时间了（2005 年至 2010 年）。虽然过去 Java（例如 JSP）或后来的 Ruby on Rails 已经用于 SSR，但这次不同，因为我们依赖 JavaScript。近年来，Next.js 一直是这一趋势背后的推动力，但其他元框架（如 SvelteKit）也正在迎头赶上。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

SSR 已经与静态站点生成 (SSG) 竞争了很长一段时间，以获得完美的性能（参见 Next.js 与 Gatsby.js），尽管这两种模式的用途完全不同。后一种模式用于静态内容（例如博客等网站），而前者用于动态内容（例如 Web 应用）。由于需要高度动态的内容或以用户为中心的内容并进行身份验证，开发人员不能选择 SSG（在部署前构建一次，因此是静态的），而必须在 SSR（根据服务器上的单个数据请求按需构建）或 CSR（在客户端上按需获取个人数据）之间做出选择。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

CSR、SSR、SSG 并不是渲染技术的最新趋势。虽然 SSR 和 SSG 在几年前开启了性能优化趋势，但增量静态再生 (ISR) 和流式 SSR 等更细分的渲染技术开始活跃起来。前者推进了 SSG，因为它允许在每个页面的基础上静态重新构建网站（例如，每 60 秒重新构建页面 X）而不是重新构建整个网站。按需 ISR，也称为按需重新验证，可用于通过应用公开的 API 触发重新构建（例如，当 CMS 数据更新时）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

另一方面，Streaming SSR 优化了服务端渲染的单线程瓶颈。普通 SSR 必须在服务器上等待数据将渲染的内容立即发送到客户端，而流式 SSR 允许开发人员将应用分成块，这些块可以逐步从服务器并行发送到客户端。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

在过去几年中，SPA/MPA 中的 SSG 和 SSR 渲染模式非常简单。然而，如今更细分的版本正在流行，除了 ISR 和流式 SSR，部分水合（例如 React 服务端组件）允许仅在客户端上水合某些组件，渐进式水合可以对水合顺序进行更细粒度的控制，Island 用于 MPA 中的隔离应用或组件的架构（例如 Astro ）以及使用可恢复性而不是水合作用（例如 Qwik）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

JavaScript运行时

2009 年，Ryan Dahl 在一次会议上宣布了 Node.js。最初 Node.js 只是一项将 JavaScript 与浏览器分离并使其在服务器上可用的实验，后来成为 JavaScript 在过去十年中取得成功的最大推动力之一。Ryan Dahl 在没有浏览器的情况下为 Node.js 使用了称为 V8 的 JavaScript 引擎（由 Chrome 实现）。因此，Chrome 浏览器和 Node.js 使用相同的 JavaScript 引擎，但有自己的 JavaScript 运行时（例如浏览器 API 与 Node.js API）来与之交互。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

十年后，Ryan Dahl 宣布 Deno 成为 Node 的继任者，并承诺为开发人员提供一个更安全、更快速的环境，其中包括类似浏览器 API、TypeScript 和开箱即用的标准库。 Deno 也运行在 V8 上，不过如今它只是众多 JavaScript 运行时中的一种。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

在边缘计算的竞争领域，许多云提供商实现了自己的 JavaScript 运行时（例如 Cloudflare Workers），它针对自己的基础设施（例如 Cloudflare）进行了优化。 因此，Deno 的业务模型也正在成为一个云提供商，拥有 Deno Deploy 和它们的即时边缘渲染 SSR 框架（最初作为概念验证），称为 Deno Fresh。 像 Bun 这样的独立于云提供商的解决方案最近成为最快 JavaScript 运行时竞争中的另一个热门话题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

Monorepos

在过去，monorepos 主要用于大型应用，一个项目在一个版本控制的存储库中包含较小的项目。这些较小的项目中的每一个都可以是从单个应用程序（例如 SPA、MPA）到可重用包（例如函数、组件、服务）的任何东西。合并项目的做法可以追溯到 2000 年初，当时它被称为共享代码库。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

如今，monorepos 不再是大型应用的专属，很多小型公司和开源项目也可以从中受益。例如，一家公司可以在 monorepos 中拥有各种包，包括共享 UI 组件、共享设计系统（例如可重用协作设计）以及各自领域的常用实用函数。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

这些包可以在各种应用程序中导入：使用所有这些共享包的实际应用（例如 app.mywebsite.com 客户端渲染），考虑 SEO 的主页/产品/登陆页面（例如 mywebsite.com 使用服务端渲染或静态网站生成）仅使用共享设计系统包，以及使用共享 UI 组件和共享设计系统包的技术文档页面（例如 docs.mywebsite.com）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

Turborepo（被 Vercel 收购）再次在 JavaScript/TypeScript 中宣传 monorepo。 Turborepo 允许团队在 monorepo 中为他们所有的应用和包创建构建管道。引人注目的是：在本地机器或跨团队的云中的管道内缓存构建。Turborepo 与 npm/yarn/pnpm 工作区（依赖管理）和变更集（版本控制）等其他重要的 monorepo 工具相结合，使该工具链成为今年值得关注的领域。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

实用优先的 CSS

Tailwind CSS 是实用优先 CSS 的典型代表。一方面开发人员讨厌它在 UI 代码中显得冗长，另一方面又喜欢它出色的 DX。作为开发人员，只需在项目中对其进行一次配置，即可立即在 HTML 中使用其预定义的 CSS。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

不过，随着最近服务端渲染 (SSR) 的兴起，这种关于实用优先 CSS 的爱与恨的分歧可能会结束。近年来，像 Styled Components (SC) 和 Emotion 这样的 CSS-in-JS 解决方案一直是现代基于组件的 Web 应用样式的主导力量。然而，如果使用 SSR 的主要目标是高性能，那么 CSS-in-JS 就会带来负面影响：增加包大小（SC 为 12.7kB，Emotion 为 7.9kB），更重要的是，在将其插入 DOM 之前，由于 CSS 序列化，运行时开销增加。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

因此，我们可能会看到开发人员转向对 SSR 更友好的解决方案，例如将实用优先的 CSS（例如 Tailwind CSS、UnoCSS）与预定义的 UI 组件（例如 DaisyUI）搭配使用。或者使用其他同样流行的替代方案，例如 CSS Module，或称为零运行时/编译时的 CSS-in-JS（例如 vanilla-extract、linaria、astroturf）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

端到端类型安全

从 JavaScript 到 TypeScript 的演变是不可阻挡的。在这场 Web 开发的大迁移中，全栈应用的端到端类型安全无疑是一个重要的趋势。这个概念的实现与通信层 (API) 相辅相成，通信层是将类型化实体（例如：type User、type BlogPost）从服务端桥接到客户端应用所需的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

在用于客户端-服务端通信的 Web 开发中，通常会使用 REST 和 GraphQL。两者都可以与 OpenAPI for REST 和 GraphQL Code Generator for GraphQL 一起使用，为前端应用生成类型化的模式文件。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

有一个名为 tRPC 的类型安全 API 成为后起之秀，它可以作为 REST/GraphQL 的替代品。如果使用在前端和后端共享代码的 TypeScript monorepo，tRPC 可以将所有类型从后端导出到前端应用，而无需任何类型化模式的中间生成。之后，前端只需使用在后台通过 HTTP 连接的类型化函数即可调用后端的 API，以实现客户端-服务端通信。总体趋势肯定会朝着使用更多此类类型安全解决方案的方向发展，用于全栈应用，例如 tRPC、Zod、Prisma 和 TanStack Router，它们都在应用中提供类型安全。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

构建工具

在 React 中，create-react-app (CRA) 主导了几年。这在当时是一场革命，因为初学者获得了一个随时可用的 React 入门项目，而无需再使用 React 设置配置自定义 Webpack。 然而，在过去的一年里，Webpack 很快就过时了。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

Vite 是构建单页应用 (SPA) 的新秀，它适用于所有流行的框架（例如 React、Vue）来创建入门项目。由 Vue.js 的创建者尤雨溪实现，将 Vite 定位为下一代前端工具。在 Vite 内部，它从 esbuild 获得了强大的功能，与其他 JavaScript 构建工具相比，它是用 Go 编写的，因此打包依赖项的速度比其竞争对手（例如 Webpack）快 10-100 倍。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

Vite 的生态系统随着 Vitest（Jest 的替代品）等新增功能而蓬勃发展。但最近出现了新的竞争对手，如 Vercel 推出的 Turbopack。Turbopack 被称为 Webpack的继任者，因为它是由 Webpack 的创始人 Tobias Koppers 主导推出的。Next.js 目前仍然在使用 Webpack，它和 Turbopack 是由同一家公司开发的，所以预计 Next.js 和 Turbopack 可能会在未来成为完美搭配。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

AI 驱动的开发

AI 最终会接管开发者的工作吗？这个问题目前还没有答案，但是，AI 驱动的开发在 2022 年成为了现实。随着 GitHub Copilot 的发布，开发人员能够在喜欢的 IDE 中使用 AI 程序。只需编写代码（或写一条注释说明想编写什么代码），GitHub Copilot 就会自动完成实现细节。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

但 AI 驱动开发并不止于此：OpenAI 的 ChatGPT 是一种更通用的语言模型，它也可以完成编程任务。许多开发人员已经使用 ChatGPT 作为了 StackOverflow 的替代品。在许多情况下，当用作搜索引擎替代品时，ChatGPT 会提供有用的答案（尽管并不总是完美的）。 因为搜索引擎必须处理大量的 SEO SPAM（不仅与开发相关的内容），ChatGPT 目前被视为可行的替代方案。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

其他

除了上面提到的趋势，还有很多值得一提的地方：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/gcs/31039.html

• Tauri 成为 Electron 的替代方案用于由 JavaScript/CSS/HTML 实现的桌面应用程序；
• Playwright 成为 Cypress 的 E2E （端到端测试）替代方案；
• Warp 和 Fig 成为下一代终端；
• CSS 容器查询成为响应式设计的 CSS 媒体查询替代方案；
• htmx 作为一种丰富的 HTML，用于创建没有 JavaScript 的交互式用户界面。