2023 年 10 大 Web 开发趋势

17611538698

webmaster@21cto.com

登录注册

2023 年 10 大 Web 开发趋势

万能的大雄

前端 0 1209 2023-02-03 09:44:37

虽然在我个人看来，Web 开发的前景曾放缓了几年（2016 年 - 2021 年），它在去年又开始重获足够的吸引力（请参阅State of JS(https://2022.stateofjs.com/)，本文的图片均来源于此网站）。

在这篇文章中，我想介绍我所看到的新 Web 开发趋势，这些趋势一定会继续激发各位 Web 开发人员的兴趣，它也让我对今年感到特别兴奋。

来让我们直接进入正题。

（元）框架

单页应用程序 (SPA) 及其各种框架（例如 React.js、Vue.js、Svelte.js）或多或少经历了炒作周期，并且它们已经存在很多年。

然而，随着元框架在这些解决方案之上的兴起，我们可以看到应用程序从客户端 (CSR) 转向服务器端呈现 (SSR) 的明显趋势。

如今，在使用 JavaScript 框架时，SSR 已经无处不在。

最流行的名为Next.js的元框架位于 React.js 之上。React 核心开发人员 Andrew Clark 到目前为止将其称为2022 年的“真正的 React 18 版本”，因为它附带了 React 团队作为较低级别的基本构建块提供的所有“内置电池”（例如 Suspense、流式 SSR）库。Vercel（Next.js 背后的公司）和 React.js 核心团队紧密合作，提供出色的开发人员体验。

虽然许多开发人员以担忧的态度关注 Next.js 和 React.js 之间的密切关系，但 React.js 有替代品，如Remix（最近被 Shopify 收购）。Remix 采用不同的方法将 React.js 转变为元框架（例如，使用 Web 标准作为一等公民），但由于竞争，两个框架之间也有融合的功能（例如嵌套路由）。

尽管 Next.js 已经是现代 SSR 领域的既定竞争者，并让许多前端开发人员自然地转变为全栈开发人员，但其它框架也应该在关注列表中：

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

应用程序渲染模式

虽然过去十年（2010 年至 2020 年）一直由单页应用 (SPA) 和客户端渲染 (CSR) 主导。从 Knockout.js 和 Ember.js 到 Angular.js、React.js 和 Vue.js，过去几年中开发者们对使用元框架的服务器端渲染 (SSR) 越发感兴趣。

从外部看来，这个周期即将结束。因为我们在多页面应用程序 (MPA) 中使用 SSR 和 JavaScript（例如 jQuery、MooTools、Dojo.js）已经很长时间了（2005 - 2010 年）。

然而，虽然过去 Java（例如 JSP）或后来的 Ruby on Rails 已用于 SSR，但这次不同，因为我们依赖 JavaScript。

几年来，Next.js 一直是这一趋势背后的推动力，但是，其它元框架（如 SvelteKit）正在迎头赶上来。

SSR 已经与静态站点生成 (SSG) 竞争了很长一段时间，以便获得完美的性能。尽管这两种模式用于完全不同的目的，后一种模式用于静态内容（例如博客之类的网站），前者用于动态内容（例如 Web 应用程序）。

如果SEO是相关的，那么 SSR 和 SSG 都具有现实意义。但是，由于需要高度动态的内容或以用户为中心的内容并进行身份验证，开发人员不能选择 SSG（在部署之前构建一次，因此是静态的），而必须在 SSR（根据服务器上的单个数据请求按需构建）之间做出选择或最近的 CSR（在客户端上按需获取个人数据）。

CSR、SSR、SSG 并非渲染技术的最新趋势。

虽然 SSR 和 SSG 在几年前开启了性能优化趋势，但增量静态再生 (ISR) 和流式 SSR 等更细分的渲染技术开始活跃起来。前者推进了 SSG，因为它允许在每个页面的基础上静态重建网站（例如，每 60 秒重建页面 X）而不是重建整个网站。更进一步，按需 ISR，也称为按需重新验证，可用于通过应用程序公开的 API 触发重建（例如当 CMS 数据更新时）。

另一方面，Streaming（流式） SSR 优化了服务器端渲染的单线程瓶颈。普通 SSR 必须在服务器上等待数据将呈现的内容，然后发送到客户端，而 Streaming SSR 允许开发人员将应用程序分成块，这些块可以逐步从服务器并行发送到客户端。

在过去几年中，SPA/MPA 中的 SSG 和 SSR 渲染模式非常简单。

如今更细分的版本正在流行，不仅 ISR 和 SSR 流变得更相关，而且部分水合（例如 React 服务器组件）允许仅水合客户端上的某些组件，渐进式水合可以对水合顺序进行更细颗粒度的控制，Island用于 MPA 中的隔离应用程序或组件的架构（例如Astro ）以及使用可恢复性而不是水合作用（例如Qwik）。

边缘计算与无服务器

SSR 和 SSG 等渲染技术与边缘无服务器的趋势也高度关联，它们均为性能驱动，其目的是在浏览器中提供无缝的用户体验。

从本质上讲，为用户提供更快的网站和 Web 应用程序服务的冲动，激发了大量开发者对边缘无服务器的兴趣。

让我们从头开始梳理：无服务器，也称为无服务器功能、无服务器计算（例如 AWS Lambda）或云功能（例如 Google/Firebase Cloud Functions）多年来一直是云计算的大趋势。虽然无服务器仍然意味着拥有一个正在运行的（远程）服务器，但开发人员不必管理服务器及其相关任务（例如基础设施按需扩展）。相反，必须将单个功能部署为无服务器功能，它是由云提供商负责的。

无服务器功能解锁了另一个优势，因为不是将应用程序服务器部署到一个（或几个）数据中心，而是在世界各地可能有数十个。因此，在一个完美的世界中，无服务器功能将尽可能离用户最近运行，这意味着最短的客户端-服务器往返，从而改善用户体验。尽可能靠近用户部署无服务器功能创造了边缘计算和边缘功能这两个术语。

许多的云提供商（例如 Cloudflare 和 Cloudflare Workers、Vercel 及其边缘计算网络、Deno 和 Deno Deploy）都在这个领域竞争，每个人都在为他们的最终用户优化最佳交互时间 (TTI) 体验。边缘计算功能不仅可以更快地提供 SSG/SSR 内容（因为连接到最终用户的线路更短），而且还可以将其结果缓存到离用户更近的地方。

不仅性能很重要，即便它是主要驱动因素，边缘计算还有其他优势（如降低成本）。例如，通常并非客户端和服务器之间发送的所有数据（此处为边缘功能）都需要由主数据中心计算。在物联网中，有许多不相关的数据（例如，每帧没有变化的视频记录）发送到主数据中心，而这些数据中心可以简单地在边缘进行过滤。毕竟，边缘计算功能只是一个开始......

数据库的复兴

随着无服务器（在边缘侧）的出现，数据库也经历了复兴。使用无服务器功能，开发者很快会遇到打开数据库连接过多的问题，因为没有一台服务器保持连接一直打开，而是许多无服务器功能与数据库 1:1 连接。连接池一直是这个问题的解决方案，但要么自己解决，要么让第三方服务处理。

无服务器数据库领域的热门竞争者是PlanetScale (MySql)、Neon (PostgreSQL) 和Xata (PostgreSQL)，它们具有许多功能，如数据库分布、模式差异和强大的搜索/分析/洞察力。当谈到世界各地的无服务器时，他们提供边缘缓存或分布式只读数据库，以将用户的数据移动到更靠近用户的位置，以最大限度地减少延迟。

想要第三方服务不仅要分发数据库，还要分发应用程序，Fly.io 将所有内容打包到一个平台中。这让开发者们超越了数据库，而且数据库也发生了很多变化。Railway被视为 Heroku 的继任者，它为平台即服务 (PaaS) 带来了一切以部署自己的技术堆栈。如果你想将服务链向上移动到后端即服务 (BaaS)，可以使用Supabase获得 Firebase 的开源替代方案，它具有应用程序/数据库托管、身份验证和边缘功能。

JavaScript 运行时

这一切都始于 Ryan Dahl在 2009 年的一次会议上宣布Node.js。

最初他是一项将 JavaScript 与浏览器分离并使其在服务器上可用的实验，后来Node.js 成为 JavaScript 在过去十年中取得成功的最大推动力之一。本质上，Ryan Dahl 在没有浏览器本身的情况下为 Node.js 使用了称为 V8 的 JavaScript 引擎（由 Chrome 实现）。因此，Chrome 浏览器和 Node.js 使用相同的 JavaScript 引擎，但有自己的 JavaScript 运行时（例如浏览器 API 与节点 API）来与之交互。

十年后，Ryan Dahl宣布Deno 成为 Node 的继任者，并承诺为开发人员提供一个更安全、更快速的环境，其中包括类似浏览器 API、TypeScript 和开箱即用的标准库。Deno也运行在 V8 上，不过现在只是众多 JavaScript 运行时中的一种。

在边缘功能的竞争领域，许多云提供商都实现了自己的 JavaScript 运行时。例如 Cloudflare Workers，它针对自己的基础设施（例如 Cloudflare）进行了优化。因此，Deno 的商业模式也是目标成为一个云提供商，拥有Deno Deploy和他们的即时边缘渲染 SSR 框架（最初作为概念验证），称为Deno Fresh。像Bun （在 JavaScriptCore Engine 上运行并在 Zig 中臭名昭著地实现）这样独立于云提供商的解决方案，如今成为最快 JavaScript 运行时竞赛中的另一个热门话题。

由于不同的运行时，敏锐的头脑会（再一次）看到 JavaScript 领域中的大量碎片。如果事情搞砸了，我们最终会遇到多年来在浏览器中支持零散的 JavaScript 的情况，但这次是在服务器上，当部署在不同的云提供商上时，并不是所有的 JavaScript 都在运行时得到同样的支持。

所以，所有利益相关者（例如 Deno、Vercel、Cloudflare）都加入了WinterCG，以就其 JavaScript 运行时之间的 API 互操作性进行协作。

Monorepos

在过去的时间里，monorepos （单体仓库）主要用于大型应用程序，其中一个项目在同一个版本控制的存储库中，里面也包含较小的项目。这些较小的项目中的每一个都可以是从单个应用程序（例如 SPA、MPA）到可重用包（例如功能、组件、服务）的任何东西。

合并项目的做法，可以追溯到 2000 年初，当时它还被人们称为共享代码库。

如今的 monorepos 不仅专用于大型应用程序，而且很多小型公司和开源项目也是如此。比如，一家公司可以在单一存储库中拥有各种包，包括共享 UI 组件、共享设计系统（例如可重用协作设计）以及各自领域的常用实用程序功能。

这些包可以在各种应用程序中导入：使用所有这些共享包的实际应用程序（例如 app.mywebsite.com 客户端呈现），首页/产品/登陆页面（例如 mywebsite.com 与服务器端呈现或静态站点生成）考虑到 SEO 仅使用共享设计系统包，以及使用共享 UI 组件和共享设计系统包的技术文档页面（例如 docs.mywebsite.com）。

Turborepo（现已被 Vercel 收购）在 JavaScript/TypeScript 中花了大量力量宣传 monorepo 。Turborepo 允许技术团队在 monorepo 中为自己所有的应用程序和包创建构建管道。值得注意的是：在本地机器或跨团队的云中的管道内缓存构建。Turborepo 与 npm/yarn/pnpm 工作区（依赖管理）和变更集（版本控制）等其他重要的 monorepo 工具相结合，这使该工具链成为本年度很值得关注的领域。

Turborepo 的竞争对手是Nx、Rush和Lerna（有一段时间没有维护，后来被 Nx 的公司 Nrwl 收购）。

实用优先的 CSS

说到CSS，有的开发人员喜欢它，有的开发者却讨厌它。

Tailwind CSS是实用优先 CSS 的典型代表，一方面开发人员讨厌它在 UI 代码中显得冗长，另一方面开发人员喜欢它出色的 DX。

作为开发人员，只需在项目中对其进行一次配置，即可立即在 HTML 中使用其预定义的 CSS。

不过，随着最近服务器端渲染 (SSR) 的兴起，这种关于实用程序优先 CSS 的爱恨分歧现象可能会结束。

近几年来，像Styled Components (SC) 和Emotion这样的 CSS-in-JS 解决方案一直是现代基于组件的 Web 应用程序样式的主导力量。然而，如果 SSR 世界中的性能是主要目标之一，那么 CSS-in-JS 会带来负面影响：增加包大小（SC 为 12.7kB，Emotion 为 7.9kB），更重要的是由于之前的 CSS 序列化导致的运行时开销将其插入到 DOM 中。

所以，人们可能会看到开发人员转向对 SSR 更友好的解决方案，例如 utility-first-CSS（例如 Tailwind CSS、UnoCSS）与预定义的 UI 组件（例如DaisyUI ）配对，其他同样流行的替代方案（例如CSS Modules），或称为零运行时的失败者/compile-time CSS-in-JS（例如vanilla-extract，linaria，astroturf，compiled）。

端到端的类型安全

从 JavaScript 到 TypeScript 的演变将势不可挡。

在这场 Web 开发的大迁移中，全栈应用的端到端类型安全无疑是一个重要的趋势。此概念的实现与通信层 (API) 相关，通信层需要将类型化实体（例如type User，type BlogPost）从服务器桥接到客户端应用程序。

在用于客户端-服务器通信的 Web 开发中，通常是REST和GraphQL。两者都可以与OpenAPI for REST 和GraphQL Code Generator for GraphQL 一起使用，为前端应用程序生成类型化的模式文件。

然而，有一个名为tRPC的类型安全 API 的后起之秀，它可以用作 REST/GraphQL 的替代品。

如果你在前端和后端共享代码的 TypeScript monorepo 中工作，tRPC 使开发者能够将所有类型从后端导出到前端应用程序，无需任何类型化模式的中间生成。随后，前端只需使用在后台通过 HTTP 连接的类型化函数即可调用后端的 API，以启用实际的客户端-服务器通信。总体趋势肯定会朝着使用更多此类类型安全解决方案的方向发展，用于全堆栈应用程序，如 tRPC、Zod、Prisma和TanStack Router，它们都在应用程序的边缘提供类型的安全。

构建工具

在 React-land 中，create-react-app (CRA) 主导了几年。这在当时是一场小小小的革新，因为初学者获得了一个随时可用的 React 入门项目，而无需再使用 React 设置，或配置自定义 Webpack。但是，在过去的一年里，Webpack 很快就过时了。

Vite是单页应用程序 (SPA) 方面的新生力量，它可以与所有流行的框架（例如 React.js）配合使用来创建项目。

Vite由 Vue.js 的创建者 Evan You 实现，它将自己定位为下一代前端工具。在引擎之下，它还从esbuild获得了强大的功能，与其它 JavaScript 打包器相比，首先它是用 Go 编写的，因此打包依赖项的速度比其竞争对手（例如 Webpack）快 10-100 倍。

Vite 的生态系统随着Vitest（Jest 的测试替代品）等新增功能而蓬勃发展，但 Vercel 的Turbopack等其它竞争对手最近才出现。Turbopack 被称为 Webpack 的继承者，它是由 Webpack 的创建者 Tobias Koppers 带头开发的。由于 Next.js 仍在使用 Webpack，而 Turbopack 是由同一家公司开发，因此可以预期 Next.js 和 Turbopack 在未来可能是绝配。

人工智能驱动开发

AI最终会取代开发人员的工作吗？这个问题没有确切答案。

但是，AI 驱动的开发在 2022 年已经成为了现实。随着GitHub Copilot的发布，开发人员能够在他们最喜欢的 IDE 中与 AI 程序员结对编程。它就像编写代码一样简单（或编写说明编码内容的评论），GitHub Copilot 将自动完成实现细节，以达到最佳代码可读。

但这些能力并不止于此：OpenAI的 ChatGPT 是一种更通用的语言模型，它也能够负责编程任务。

你可以向 ChatGPT 提出自由形式的问题，它也能够执行编码任务。许多开发人员已经正在使用 ChatGPT 作为 StackOverflow 的替代品。在许多情况下，当用作搜索引擎替代品时，ChatGPT 会提供有用的答案（尽管并不总是完美无缺）。因为后者必须处理大量的 SEO 垃圾邮件（不仅用于开发相关内容），ChatGPT 目前被视为可行的替代方案之一。

不过，“此刻”是这里的重要术语。从更广泛的角度来看，人工智能创建的内容也正在危害互联网。以前由人手动创建的 SEO 垃圾内容已经是一个问题，现在没有人阻止有人使用 ChatGPT 生成更多自动生成的 SEO 文本。

ChatGPT 最终会训练自己生成的内容吗？

小结

还有一些我不想忘记，但又值得注意的内容。它们并没有进入上面的趋势中：