本文作者：Robin Wieruch；编译：Cointime Freya

虽然，在我个人看来，Web开发的前景已经放缓了几年（2016年- 2021年），但就在去年它开始获得大量的吸引力。 在本篇文章中，我想聊聊我所看到的新的Web开发趋势，我期望这些趋势能够继续激发Web开发人员的兴趣，而且我对明年的趋势感到兴奋的地方。现在，让我们一起进入这个话题。

（META）框架

单页面应用程序（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领域已经是一个成熟的竞争者，并将许多前端开发人员自然地转变为全栈开发人员，但其他框架也应该在你的关注列表中：SvelteKit（基于 Svelte.js 构建）及其最新的1.0版本，由Vercel 和 SolidStart（基于Solid.js 构建）提供支持，与React.js相比改进了DX。

应用程序和渲染模式

虽然过去十年（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）竞争了很长一段时间，以获得完美的性能（参见Next.js 与Gatsby.js），尽管这两种模式服务的目的完全不同。后者用于静态内容（例如博客之类的网站），而前者用于动态内容（例如Web应用程序）。如果SEO是相关的，那么SSR和SSG就都有意义的。但是，由于需要高度动态的内容或以用户为中心的内容并进行身份验证，开发人员不能选择SSG（在部署之前进行一次构建，因此是静态的），而必须在SSR（根据服务器上的单个数据请求按需构建）或CSR（在客户端上按需获取个人数据）之间做出决定。

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

另一方面，流式SSR优化了服务器端渲染的单线程瓶颈。普通的SSR需要在服务器上等待数据，以便立即将渲染的内容发送到客户端，而流式SSR允许开发者将应用分成块，可以从服务器上逐步并行发送至客户端。

在过去几年中，在SPA/MPA中使用SSG和SSR的渲染模式非常简单。然而，如今更微妙的版本正在成为趋势。 但不仅是ISR和SSR流变得更相关，部分水化（例如 React 服务器组件）允许仅在客户端上水化某些组件，渐进式水化可以对水化顺序进行更细粒度的控制，岛屿架构（例如 Astro）用于MPA中孤立的应用程序或组件，以及使用可恢复性代替水（例如 Qwik）正在成为目前有效的方法。

边缘SERVERLESS

SSR和SSG等渲染技术与边缘无服务器的趋势高度相关，因为两者都是由性能驱动的，目的是在浏览器中提供无缝的用户体验。从本质上讲，为用户提供更快的网站和Web应用程序的冲动激发了对边缘无服务器的兴趣。

无服务器，也称为无服务器函数、无服务器计算（例如AWS Lambda）或云函数（例如 谷歌/Firebase云函数）已经成为云计算的一个大趋势。虽然无服务器仍然意味着拥有一个正在运行的（远程）服务器，但开发人员不必管理服务器及其相关任务（例如基础设施按需扩展）。 相反，必须将单个功能部署为无服务器功能，由云提供商负责。

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

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

但是，不仅性能很重要，即使它是主要的驱动因素，降低成本等其他好处也会伴随边缘计算而来。例如，通常不是所有在客户端和服务器（这里是edge函数）之间发送的数据都需要由主数据中心计算。在物联网中，有大量不相关的数据（例如每帧没有变化的视频记录）发送到主数据中心，这些数据中心可以简单地在边缘进行过滤。毕竟，边缘函数只是一个开始……

数据库复兴

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

无服务器数据库领域的热门竞争者是PlanetScale（MySql）、Neon（PostgreSQL）和Xata（PostgreSQL），它们具有许多功能，如数据库分支、模式差异和强大的搜索/分析/洞察力。当涉及到世界各地的无服务器时，他们提供边缘缓存或分布式只读数据库，以将你的数据移动到更靠近用户的地方，从而实现最小的延迟

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

JavaScript 运行系统

这一切都始于Ryan Dahl在2009年的一次会议上宣布Node.js。最初的尝试是将JavaScript从浏览器中分离出来，并使其在服务器上可用，后来这成为JavaScript在过去十年中成功故事的最大驱动力之一。从本质上说，Ryan Dahl使用名为V8的JavaScript引擎（由Chrome实现）用于Node.js而不使用浏览器本身。因此Chrome浏览器和Node.js都使用相同的JavaScript引擎，但有自己的JavaScript运行系统（例如浏览器api vs节点api）与之交互。

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

在边缘功能的竞争领域，许多云供应商实现了自己的JavaScript运行系统（例如Cloudflare Workers），它针对自己的基础设施（例如Cloudflare）进行了优化。因此，Deno的商业模式也是通过Deno Deploy和他们的即时边缘渲染SSR框架（最初是概念验证）成为云供应商，称为Deno Fresh。像Bun这样独立于云供应商的解决方案（（运行在JavaScriptCore引擎上，在Zig中实现），最近成为了最快JavaScript运行系统竞争中的另一个热门话题。

头脑敏锐的人会再一次发现，由于运行系统的不同，JavaScript环境中出现了大量的碎片化。如果事情搞砸了，我们就会陷入多年来在浏览器中获得碎片化的JavaScript支持的相同情况，但这次是在服务器上，当部署在不同的云供应商上时，并不是所有的JavaScript在运行时都能得到同等的支持。因此，所有利益相关者（如Deno、Vercel、Cloudflare）都加入了WinterCG，在他们的JavaScript运行时之间的API互操作性方面进行合作。

MONOREPOS

过去，monorepos 主要用于大型应用程序，其中一个项目在一个版本控制的存储库中包含较小的项目。这些较小的项目可以是任何东西，从单独的应用程序（如SPA、MPA）到可重用包（如功能、组件、服务）。组合项目的实践可以追溯到2000年初，当时它被称为共享代码库。

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

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

Turborepo（被Vercel收购）再次在JavaScript/TypeScript中大肆宣传monorepo、Turborepo允许团队在一个monorepo中为他们所有的应用程序和包创建构建管道。最吸引人的地方是：在本地机器上或跨团队的云中的管道内缓存构建内容。Turborepo与其他重要的monorepo工具配对，如npm/yarn/pnpm工作区（依赖管理）和变更集（版本控制），使这个工具链成为今年值得关注的领域。

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

UTILITY-FIRST CSS

开发者们对它又爱又恨。Tailwind CSS是utility-first CSS的典型代表。一一方面，开发人员讨厌它在UI代码中显得冗长，另一方面，开发人员喜欢它出色的DX。作为开发人员，你只需在你的项目中配置一次，就可以立即在HTML中使用其预定义的CSS。

不过，随着服务器端渲染 (SSR) 的兴起，这种关于utility-first 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模块，或被称为零运行时/编译时的CSS-in- js（如香vanilla-extract、linaria、astroturf、compiled）。

使用 TYPESCRIPT 的E2E类型安全

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

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

然而，对于类型安全的API来说，有一个新的后起之秀，叫做tRPC，它可以作为REST/GraphQL的替代品。如果你在前端和后端共享代码的TypeScriptmonorepo中工作，tRPC能够从后端导出所有类型到前端应用程序，而无需在中间生成类型化模式。随后，前端可以通过使用类型化函数来调用后端API，而这些函数是由HTTP在后台连接的，以实现实际的客户端-服务器通信。整体趋势无疑是朝着为全栈应用程序使用更多的类型安全解决方案的方向发展，如tRPC、Zod、Prisma和TanStack Router，它们都在应用程序的边缘提供类型安全。

构建工具

在React领域，Create-react-app（CRA）主导了几年的局面。这在当时是一场小小的革命，因为初学者可以得到一个随时可用的React入门项目，而不必再配置一个带有React设置的自定义Webpack。然而，在过去的一年里，Webpack很快就过时了。

Vite是单页应用程序 (SPA) 方面的新手，因为它可以与所有流行的框架（如React.js）一起创建入门项目。 由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最终会取代开发人员的工作吗？这个问题目前还没有答案，不过，AI驱动的开发在2022年已经成为了现实。随着GitHub Copilot的发布，开发人员能够在他们最喜欢的IDE中与AI程序员配对。就像写代码一样简单（或写一个注释，说明你想写什么代码），GitHub Copilot会根据其最佳理解自动完成执行细节。

但它还不止于此：OpenAI的ChatGPT是一个更通用的语言模型，它也可以负责处理编程任务。虽然你可以向ChatGPT提出自由形式的问题，但它也能够执行编码任务。许多开发人员已经发现自己正在使用ChatGPT来替代StackOverflow。在许多情况下，ChatGPT作为搜索引擎的替代品时提供了有用的答案（尽管并不总是完美无缺）。因为后者必须处理大量的SEO垃圾邮件（不仅仅是与开发相关的内容），ChatGPT目前被视为一个可行的替代方案。

不过，“此刻”是这里的重要术语。 从全局角度来看，AI创建的内容也可能会危害万维网。 以前手动创建的 SEO 内容已经是一个问题，没有人阻止人们使用 ChatGPT 自动生成更多SEO内容。ChatGPT 最终会对自己生成的内容进行培训吗？

有几个值得一提的地方，即它们并没有成为列出的趋势。

Tauri是Electron的替代品，用于由JavaScript/CSS/HTML实现的桌面应用程序；Playwright是Cypress的替代品，用于E2E测试；Warp和Fig是下一代终端；CSS Container Queries是CSS Media Queries的替代方案，用于响应式设计；最后，同样重要的是htmx作为丰富的HTML，用于在没有 JavaScript 的情况下创建交互式用户界面。由于我在这里只做了一个小的总结，所以我鼓励你自己去看看这些东西