大家好，这里是大家的林语冰。持续关注，坚持阅读，每天一次，进步一点。
免责声明
本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 10 Web Development Trends in 2023。
本期共享的是 ------ 年度十大 Web 开发趋势。
我的个人心证是，Web 开发前景在前几年差强人意，虽然但是，去年 Web 开发又双叒叕找到了"流量密码"。在本文中，我想共享本人亲眼见证的 Web 开发新趋势，我预言这些趋势会继续释放 Web 开发者的多巴胺，并且我对新年的发展感到鸡冻。
（元）框架
SPA（单页应用程序）及其各自的框架，比如 React/Vue/Svelte 等，已经经历了或多或少的炒作周期，且由来已久。虽然但是，随着构建于这些解决方案之上的元框架崛起，我们见证了 App 从 CSR（客户端渲染）转向 SSR（服务端渲染）大势所趋。今时今日，在使用 JS 框架时，SSR 无处不在。
人气爆棚的元框架 Next 构建于 React 之上。React 核心开发者 A.C. 称之为"React 18 的本体"，因为它配备了 React 团队提供的全家桶，比如 Suspense、流式 SSR 等，作为较低阶库的构建基建块。Vercel（Next 后台的公司）和 React 核心团队正在"梦幻联动"，提供出色的 DX（开发体验）。
尽管一大坨开发者杞人忧天 Next 和 React 之间的超友谊关系，但 React 还有其他备胎方案，比如最近被 Shopify 收购的 Remix。Remix 采用了一龙一猪的方案将 React 转变为元框架，比如使用 Web 标准作为一等公民，但由于它们平分秋色，两个框架之间也存在某些同款功能，比如嵌套路由等。
尽管 Next 已经是现代 SSR 领域的网红，并且将一大坨前端开发者无为转变为全栈开发者，但我们也应该暗中观察其他框架：SvelteKit 基于 Svelte 构建，其最近的 1.0 版本由 Vercel 和基于 Solid 构建的 SolidStart 支持，与 React 相比，其 DX 更进一步。
App 和渲染模式
虽然过去十年一直由 SPA 和 CSR 引领潮流，从 Knockout 和 Ember 到 VAR（Vue/Angular/React），过去几年大家对使用元框架的 SSR 越来越感冒。表面上看，此循环周期似乎又到头了，因为我们长此以往一直在 MPA（多页面应用程序）中使用附带 JS 的 SSR，比如 jQuery/MooTools/Dojo。虽然但是，虽然以前 Java 的 JSP，或后来的 Ruby on Rails 已用于 SSR，但这次有所不同，因为我们改为依赖 JS。近年来，Next 一直是这一趋势幕后的驱动力，虽然但是，SvelteKit 等其他元框架正在紧追不舍。
SSR 长期以来一直在与 SSG（静态站点生成）竞争完美性能，比如 Next vs Gatsby，尽管这两种模式服务于一龙一猪的目的。后者用于静态内容，比如博客等网站，而前者用于动态内容，比如 Web App。如果涉及 SEO，SSR 和 SSG 都有意义。虽然但是，由于需要高度动态的内容，或具有身份验证的以用户为中心的内容，开发者无法选择 SSG，SSG 部署前会构建一次，因此是静态的，而必须在使用根据服务器上的单个数据请求按需构建的 SSR，或使用按需请求客户端个人数据的 CSR 之间"零和博弈"。
不过，CSR/SSR/SSG 并非渲染技术的最新趋势。虽然 SSR 和 SSG 几年前就开启了性能优化的趋势，但 ISR（增量静态再生）和流式 SSR 等更细致的渲染技术开始焕发生机。前者推进了 SSG，因为它允许在每个页面的基础上静态重建网站，比如每 60 秒重建某页面，而不是重建整个网站。更进一步，按需 ISR，又名按需重新验证，可用于通过 App 公开的 API 触发重建，比如当 CMS 数据更新时。
另一方面，流式 SSR 优化了 SSR 的单线程瓶颈。普通 SSR 必须在服务器上等待数据，才能将渲染的内容立即发送到客户端，而流式 SSR 允许开发者将 App 大卸八块，这些组块可以从服务器渐进式并行发送到客户端。
过去几年，SPA/MPA 中的 SSG 和 SSR 渲染模式易如反掌。虽然但是，如今更微妙的版本正在流行。但不仅 ISR 和 SSR 流变得息息相关，而且局部水合（partial hydration），比如 RSC（React Server Components）允许只在客户端水合部分组件，渐进式水合（progressive hydration）可以对水合顺序微控，Island 架构，比如 Astro 用于 MPA 中的独立 App 或组件的架构，以及使用可恢复性而不是水合，比如带有 Qwik City 元框架的 Qwik，如今正在成为行之有效的方案。
Edge Serverless（边缘无服务器）
SSR 和 SSG 等渲染技术与边缘 serverless 趋势强相关，因为两者都由性能驱动，目的旨在浏览器中提供无缝的 UX（用户体验）。本质上，为用户提供更快的网站和 Web App 服务的欲望，释放了大家对边缘 serverless 的多巴胺。
serverless，又名无服务器函数（serverless function），或者无服务器计算，比如 AWS Lambda，又或者云函数（cloud function），比如 Google/Firebase Cloud Functions，多年来一直是云计算的大趋势。虽然 serverless 仍然意味着拥有正在运行的（远程）服务器，但开发者不必管理服务器及其相关任务，比如按需扩展基建。相反，我们必须将单个功能部署为云函数，由云提供商负责。
云函数解锁了另一个优势，因为我们不必将 App 服务器部署到一个（或几个）数据中心，而是可以在世界各地有数十个数据中心。因此，在完美世界中，云函数会尽量靠近用户运行，因为这意味着，最短的客户端-服务器往返行程，从而改善 UX。将云函数部署得尽量靠近用户，孵化了"边缘计算"（edge computing）和"边缘函数"（edge function）等术语。
一大坨云提供商，比如 Cloudflare 和 Cloudflare Workers、Vercel 和 Edge Network、Deno 和 Deno Deploy 等，都在此领域"神仙打架"，每个人都在优化终端用户的 TTI 体验（最佳交互时间）。边缘函数不仅可以更快地提供 SSG/SSR 内容，因为到终端用户的线路更短，而且还可以将其结果缓存到离用户更近的地方。
但不仅性能兹事体大，即使性能是主要驱动因素，边缘计算也会带来其他福利，比如降低成本。举个栗子，通常并非客户端和服务器（此处指边缘函数）之间发送的所有数据都需要由主数据中心计算。在物联网中，有一大坨不相关数据发送到主数据中心，比如每帧没有变化的视频记录，这些数据可以简单地在边缘过滤。总而言之，边缘函数刚刚崭露头角......
数据库复兴
随着边缘服务的出现，数据库也经历了复兴。使用云函数时，开发者很快就会遭遇打开过多数据库连接的问题，因为没有一台服务器保持一个连接打开，而是有一大坨云函数与数据库建立了一对一连接。连接池已成为此问题的解决方案，但要么必须自己处理，要么让第三方服务处理。
云数据库领域的网红是 PlanetScale（MySql）、Neon（PostgreSQL）和 Xata（PostgreSQL），它们具有一大坨功能，比如数据库分支、模式比较和给力的搜索/分析/见解。当谈到地球各地的 serverless 时，它们提供边缘缓存或分布式只读数据库，让我们的数据更接近用户，最小化延迟。
如果第三方服务不仅要分发我们的数据库，还要分发我们的 App，那么 Fly.io 会把所有内容打包到一个平台中。这让我们不受限于数据库，数据库也日新月异。Railway 被视为 Heroku 的继任，它提供了 PaaS（平台即服务）部署技术堆栈所需的一切。如果我们想在服务链上向 BaaS（后端即服务）更进一步，我们可以使用 Supabase 享受 Firebase 的开源备胎方案，它附带 App/数据库托管、身份验证和边缘函数。
JS 运行时
"万恶之源"始于"Node 之父"在 2009 年的一个大会上官宣 Node.js。这最初是一项将 JS 与浏览器解耦、并让 JS 在服务器上可用的实验，后来成为过去十年 JS 成功故事的最大动力之一。本质上，R.D. 在 Node 中使用了由 Chrome 实现的名为 V8 的 JS 引擎，而无需浏览器本身。因此，Chrome 浏览器和 Node 使用相同的 JS 引擎，但有自己的 JS 运行时与之交互，比如浏览器 API 与 Node API。
十年后，R.D. 官宣 Deno 作为 Node 的继任，承诺为开发者提供一个更安全、更快速的环境，其中包含类浏览器 API、TS 和开箱即用的标准库。Deno 也运行在 V8 上，但它只是目前众多 JS 运行时之一。
在边缘函数的竞争领域，一大坨云提供商实现了自己的 JS 运行时，比如 Cloudflare Workers，该运行时针对自己的基建进行了优化，比如 Cloudflare 等。因此，Deno 的业务模型也正在通过 Deno Deploy，及其名为 Deno Fresh 的边缘渲染 SSR 框架（最初作为概念验证）成为云提供商。像 Bun 这样的云提供商独立解决方案，一个在 JSC 引擎上运行、并在 Zig 中臭名昭著的实现，成为最近最快 JS 运行时竞赛中的另一个病毒式网红产品。
机智如你会（再次）看到由于运行时不同，导致 JS 领域乱成一锅粥。如果事情变得混乱，我们最终会遭遇与多年来浏览器碎片化的 JS 支持相同的情况，但这次发生在服务器上，当部署在不同的云提供商上时，并非所有 JS 都可以在运行时之间一视同仁。因此，所有利益相关者都加入了 WinterCG，比如 Deno、Vercel、Cloudflare 等，就其 JS 运行时之间的 API 互操作性进行协作。
Monorepo（多仓库）
过去，monorepo 主要用于大型 App，其中一个项目在一个版本控制存储库中包含较小的项目。这些较小的项目中的每一个都可以是从单个 App（比如 SPA/MPA）到可重用包（比如函数、组件、服务）的任何内容。组合项目的做法可以追溯到 2000 年初，当时称为共享代码库。
虽然但是，如今，monorepo 不仅适用于大型 App，而且也适用于小公司和开源项目，它们肯定会从中受益。举个栗子，公司可以在单一存储库中拥有各种包，包括共享 UI 组件、共享设计系统（比如可重用协作设计），以及各自领域的常用工具函数。
这些包可以导入到各种 App 中：使用所有这些共享包的实际 App，比如 CSR 的 app.mywebsite.com，主页/产品/登陆页面，比如 SSR/SSG 的 mywebsite.com，考虑到 SEO 仅使用共享设计系统包，以及使用共享 UI 组件和共享设计系统包的技术文档页面，比如 docs.mywebsite.com。
Turborepo（被 Vercel 收购）再次引发了 JS/TS 中的 monorepo 炒作。Turborepo 允许团队为 monorepo 中的所有 App 和包创建构建管道。引人注目的是：在本地计算机上的管道内或跨团队的云中缓存构建。Turborepo 与其他重要的 monorepo 工具相结合，比如 npm/yarn/pnpm workspaces（依赖管理）和变更集（版本控制），使该工具链成为今年令人瞩目的领域。
Turborepo 的竞争对手有 Nx、Rush 和 Lerna（有一段时间没有维护，后来被 Nx 的公司 Nrwl 收购了）。
实用至上的 CSS
开发者要么青睐它，要么嫌弃它：Tailwind CSS 是实用优先的 CSS 的典型代表。虽然一方面开发者嫌弃它在 UI 代码中又臭又长，但另一方面开发者却青睐它出色的 DX。作为开发者，我们可以在项目中一次配置，并立即在 HTML 中使用其预定义的 CSS。
不过，随着最近 SSR 的兴起，这种对实用优先 CSS 的爱憎分明可能会结束。几年来，CSS-in-JS 解决方案，比如 SC（Styled Components） 和 Emotion，已成为现代组件筑基的 Web App 样式设计的中流砥柱。虽然但是，如果 SSR 领域的性能是主要目标之一，那么 CSS-in-JS 会带来负面影响：包大小的增加 ------ SC 为 12.7kB，Emotion 为 7.9kB，更重要的是，由于 CSS 序列化之前将其插入到 DOM 中的运行时开销。
因此，我们可能会见证开发者迁移到 SSR 友好的解决方案，比如实用优先的 CSS（比如 Tailwind CSS、UnoCSS）与预定义的 UI 组件（比如 DaisyUI）梦幻联动，其他同样人气爆棚的备胎方案（比如 CSS 模块），或被称为零运行时/零编译时 CSS-in-JS 的 underdogs（比如 vanilla-extract/linaria/astroturf/compiled）。
使用 TS 实现端到端类型安全
从 JS 到 TS 的演变不可阻挡。在这次 Web 开发的大迁移中，全栈 App 的端到端类型安全无疑是一个重要趋势。此概念的实现取决于通信层（API），通信层需要将类型化实体（比如如 type User/type BlogPost）从服务器桥接到客户端 App。
在 Web 开发中，客户端-服务器通信的常见方式是 REST 和 GraphQL。两者都可以与 OpenAPI for REST 和 GraphQL Code Generator for GraphQL 一起使用，为前端 App 生成类型化架构文件。
虽然但是，类型安全 API 有一个新的后起之秀，称为 tRPC，它可以用作 REST/GraphQL 的备胎。如果您正在使用前端和后端共享代码的 TS monorepo，那么 tRPC 使您能够将所有类型从后端导出到前端 App，而无需中间生成类型化模式。随后，前端只需使用类型化函数即可调用后端的 API，这些函数通过 HTTP 在底层连接，实现实际的客户端-服务器通信。总体趋势肯定会倾向于在全栈 App 中使用更多类型安全的解决方案，比如 tRPC/Zod/Prisma/TanStack Router，它们都在 App 边缘提供类型安全。
构建工具
在 React 领域，CRA（create-react-app）主导了几年。这在当时是一场无声革命，因为初学者可以享受一个现成的 React 入门项目，而无需再使用 React 设置来配置自定义 Webpack。虽然但是，去年 Webpack 很快就 out 了。
当提及 SPA 时，Vite 横空出世，因为它可以与所有人气爆棚的框架（比如 Vue）梦幻联动来创建入门项目。它由"Vue 之父"尤雨溪（Evan You）实现，将其打造为下一代前端工具。在底层，它从 esbuild 获取了给力功能，与其他 JS 打包器相比，esbuild 用 Go 编写，因此打包依赖的速度比竞争对手（比如 Webpack）快 10-100 倍。
虽然 Vite 的生态系统因 Vitest（Jest 的测试替代品）等新增功能而蓬勃发展，但 Vercel 的 Turbopack 等其他竞品最近开始初露锋芒。Turbopack 被称为 Webpack 的继任，因为它是由 "Webpack 之父"领导开发。由于 Next 仍然使用 Webpack，且 Turbopack 也是同一家公司开发，因此我们可以预言 Next 和 Turbopack 在未来可能会成为完美搭档。
AI 驱动的开发
AI 最终会取代程序猿吗？此问题目前悬而未决，虽然但是，AI 驱动的开发会在新年找到"流量密码"。随着 GitHub Copilot 的发布，开发者能够在它们最喜欢的 IDE 中与 AI 程序员搭档。它就像编写代码（或编写说明您想要编码的内容的注释）一样易如反掌，GitHub Copilot 将自动完成实现细节，使其一目了然。
但它不止于此：OpenAI 的 ChatGPT 是一种更通用的语言模型，它也负责编程任务。虽然我们可以灵魂拷问 ChatGPT 形形色色的问题，但它也可以执行编码任务。一大坨开发者已经发现自己正在使用 ChatGPT 作为 StackOverflow 的竞品。在多数情况下，ChatGPT 在用作搜索引擎备胎时，提供了有用的答案，尽管并不总是完美无缺。由于后者必须处理一大坨 SEO 垃圾邮件而不仅仅是开发相关内容，ChatGPT 目前被视为可行的备胎方案。
不过，"此刻"是这里的重要术语。从鸟瞰角度来看，AIGC 的内容也可能（并且将会）损害万维网。以前手动创建的 SEO 内容已经是一个问题，但无法阻止大家使用 ChatGPT 生成更多自动生成的 SEO 内容。ChatGPT 最终会训练自己生成的内容吗？
其他补充
Tauri 作为由 JS/CSS/HTML 实现的桌面 App 的 Electron 的备胎，Playwright 作为端到端的 Cypress 的备胎测试，Warp 和 Fig 作为下一代终端，CSS 容器查询作为响应式设计的 CSS 媒体查询备胎方案，最后但并非最不重要的 htmx 作为丰富的 HTML，用于创建无需 JS 的交互式 UI。
如果您想科普其他关于 Web 开发的新年预言或脑洞，欢迎在本文下方群聊自由言论，文明共享。
《前端 9 点半》每日更新，持续关注，坚持阅读，每天一次，进步一点。
谢谢大家的点赞，那我滚了，掰掰~
