2023 年前端十大 Web 提高趋向

作者 | Robin Wiruch

译者 | 核子可乐

操持 | 丁晓昀

固然就一局部看法，我以为 Web 开发的出息以前好几年没什么历程（2016 年至 2021 年），但在刚刚已往的 2022 年中的确又猛窜了一波。在本文中，我想跟各位聊聊本人看到的最新 Web 开发趋向。信赖这波海潮会持续引发 Web 开发者的眷注，也让我对万象更新的 2023 年更具渴望。闲言少叙，我们立刻进入正题。

（元）框架

单页使用步骤（SPA）及各种干系框架（包含 React.js、Vue.js、Svelte.js 等）或多或少都履历过一定的炒作周期，也用多年阅历证实白本身强壮的生命力。但随着以这些处理方案为基本的元框架的快速崛起，可以看到使用步骤正在分明从客户端渲染（CSR）转向办事器端渲染（SSR）。如今，无论你使用哪一种 JavaScript 框架，总能看到 SSR 的影子。

此中最具人气的 Next.js 元框架就以 React.js 为基本。React 中心开发者 Andrew Clark 将 2022 年公布的新版本称为“真正的 React 18”，由于此中包含 React 团队为底层库基本构建块构建的一切 battery（比如 Suspense、流式 SSR 等）。Vercel（Next.js 眼前的公司）也与 React.js 中心团队严密互助，协同打造出色的开发者体验。

固然不少开发者都对 Next.js 和 React.js 之间过于“亲密”的干系颇有微词，但 React.js 并非不成交换。迩来刚刚被 Shopify 收买的 Remix，就接纳不同办法将 React.js 转化为元框架（比如将 Web 标准设为优先）。并且在竞争之外，两套框架之间也有一定水平的功效交融（比如嵌套路由）。

除了古代 SSR 范畴最上心的到场者、协助浩繁前端开发者顺遂成型为全栈开发者的 Next.js，其他一些紧张框架相反值得各位眷注：SvelteKit（基于 svelte.js 构建）及其最新 1.0 版本是由 Vercel 和 SolidStart（基于 Solid.js 构建）提供支持，较 React.js 拥有更好的开发者体验。

使用步骤与渲染形式

固然已往的十年（2010 年至 2020 年），Web 天下不休由单页使用步骤（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 等其他元框架也正在到场战团、协同促进这一汗青性变化。

只管两种形式的基本用处并不相反，但依靠恒久以来与静态站点天生（SSG）的竞争，SSR 如今以前拥有近乎完善的功能体现（参考 Next.js 和 Gatsby.js）。在使用场景下，SSG 寻常用于静态内容（比如博客等网站），而 SSR 则用于动态内容（比如 Web 使用步骤）。假如必要思索 SEO（搜刮引擎优化），则 SSR 和 SSG 均实用。但假如必要提供高度动态的内容，大概是交付以用户为中央的内容并触及身份验证，则 SSG 实用性较差（在摆设前一次性构建，即静态）；这时分最好是在 SSR（能依据办事器上的单个数据哀求按需构建）大概是迩来热度飙升的 CSR（在客户端上按需获取一局部数据）间做选择。

但这里要重申，CSR、SSR 和 SSG 都不属于新兴的渲染武艺。固然 SSR 和 SSG 在前几年迎来了一波功能优化趋向，但实践提高的只是增量静态再天生（ISR）和流式 SSR 等更具体的渲染武艺。前者改良了 SSG 功能，允许在每页基本之上静态重修整个网站。更进一步的办法另有按需 ISR，也称按需重新验证，可经过使用步骤公开的 API 触发重修（比如在 CMS 数据更新时触发）。

另一方面，流式 SSR 则优化了办事器端渲染的单线程瓶颈。平凡 SSR 必要在办事器上等候数据停当，之后再将渲染完成的内容发送至客户端。比拟之下，流式 SSR 允许开发者将使用步骤拆分红多个块，让各个块渐渐由办事器并行发送至客户端。

已往几年间，SPA/MPA 中的 SSG 和 SSR 渲染形式由极简便，渐渐提高成如今愈发奇妙的外形。并且不但是 ISR 和 SSR 流有所接洽，局部水合（Partial Hydration，比如 React 办事器组件）允许仅在客户端抬升合某些组件、渐进式水合可对水合排序举行细粒度控制、Island 架构（比如 Astro）面向 MPA 中的断绝使用或组件，乃至显现了以可规复性代表水合（比如 Qwik）的另一种好效办法。

边沿无办事器

SSR 和 SSG 等渲染武艺与边沿无办事器的普及态势高度干系，缘故是这些趋向均遭到功能驱动，目标是在欣赏器中提供无缝的用户体验。从实质上讲，正是为了向用户提供更快的网站和 Web 使用步骤呼应速率，才终极催生出边沿无办事器这一武艺分支。

这里我们照旧重新开头徐徐捋顺：无办事器，又称无办事器函数、无办事器盘算（比如 AWS Lambda）或云函数（比如 Google.Firebase Cloud Functions），多年来不休在云盘算范畴占据一席之地。固然无办事器并不是真正的不必要（长程）底层办事器，但开发者以前不必办理办事器及其干系职责（比如基本办法按需扩展）。相反，用户只必要将单一功效摆设为无办事器函数，其他一切运维事情均由云办事商承当。

无办事器函数的显现带来了一大上风：由于不必要将使用步骤办事器摆设到特定一处或几处数据中央，我们初次完成了功效在天下各地的广泛掩盖。因此在来由情况下，无办事器函数可以尽约莫贴近与用户间的距离，即最大水平低落客户端 - 办事器间的往复延长，由此改良用户体验。也正是这种尽约莫接近用户摆设无办事器函数的思绪，创造出了边沿盘算和边沿函数两个术语。

浩繁云办事商（包含 Cloudflare 和 Cloudflare Workers、Vercel 及其 Edge Network、Deno 及其 Deno Deploy 等）以前在这个范畴掀开竞争，各自积极为终极用户提供最佳交互时间（TTI）体验。边沿函数不仅能增速 SSG/SSR 内容的交付速率（由于毗连终极用户的线路更短），并且能将后果缓存到离用户更近的地点。

但除了功能之外，边沿盘算还在本钱等其他紧张要素上具有上风。比如，关于边沿函数，客户端与办事器之间往来的数据中有相当一局部并不必要交由主数据中央处理。在物联网场景中，有多量非干系数据（比如内容无任何厘革的视频纪录帧）但是没有任何意义，直接在边沿地点挑选即可。这就大大浪费了数据传输与会合办法处理带来的平常开支。

数据库规复

随着无办事器（边沿地点）的显现，数据库也迎来一波规复。使用无办事器函数，开发者很快就会碰到数据库毗连开启过多的成绩，这是由于新的边沿办法外形招致每台办事器不再安稳坚持一条开启毗连，而是每个无办事器函数都与数据库逐一连接。固然毗连池可以很好处理成绩，但用户要么必要自建，要么由第三方办事商提供。

无办事器数据库范畴的抢手竞争者包含 PlanetScale（MySQL）、Neon（PostgreSQL）和 Xata（PostgreSQL），它们具多数据库分支、schema diffing 和强壮的搜刮 / 分析 / 洞察功效。遍及举世各地的无办事器办法只必要提供边沿缓存或分布式只读数据库，确保让数据尽约莫接近用户地点、最大水平低落延长。

假如第三方办事不仅必要分发数据库，还必要分发使用步骤，Fly.io 可以将一切内容打包至单一平台中间。这类使用就跨越了常规数据库，进而推进新的武艺厘革。人们常将 Railway 视为 Heroku 的继任者，它为平台即办事（PaaS）带来了摆设武艺堆栈所必要的统统。假如各位渴望将办事链上移至后端即办事（BaaS），则可经过 Supabase 使用 Firebase 的开源交换方案，取得使用步骤 / 数据库托管、身份验证和边沿函数等功效。

JavaScript 运转时

统统都始于 Ryan Dahl 在 2009 年一场聚会会议上公布的 Node.js。最初，Node.js 的目标只是将 JavaScript 和欣赏器拆分开来，实验将其运转在办事器端。但厥后，JavaScript 成为已往十年间最告捷的 Web 开发驱动力。实质上，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 引擎上，却依托于 Zig 完成而出名）如此的独立处理方案，也在这场以速率为比拼要素的 JavaScript 运转时比赛中取得了一定眷注。

面临这么多运转时选项，信赖敏锐的读者伙伴一定感遭到了武艺碎片化的倾向。假如和谐不妥，那我们又会像当年种种千般的欣赏器那样疲于为 JavaScript 提供支持。但幸而这次竞争的核心在于办事器端，并且不同云办事商关于种种 JavaScript 运转时的眷注度也大有区别。为了坚持江湖位置，Deno、Vercel、Cloudflare 等优点干系方纷繁到场 WinterCG，表现乐意就 JavaScript 运转时间的 API 互利用性展开互助。

Monorepo

已往，Monorepo 战略主要用于大型使用步骤，此中各项目在单一版本控制货仓中仅包含较小体量。这些较小的项目单位约莫是独立使用步骤（比如 SPA、MPA），也约莫是可复用包（比如函数、组件、办事等）。这种项目拆分再兼并的作法可以追溯到 2000 年初，当时分的称呼叫共享代码库。

但如今的 Monorepos 不仅面向大型使用步骤，同时也开头办事于小型企业和开源项目。比如，一家公司可以在 Monorepos 中包含种种包，比如共享 UI 组件、共享计划体系（比如可复用的协作计划）以及不同范畴的平常实用东西函数。

这些包可以在种种使用步骤中直接导入：使用一切共享包的实践使用步骤（比如 app.mywebsite.com 客户端渲染）、仅使用共享计划体系包且思索 SEO 需求的主页 / 产物 / 登岸页面（比如由办事器端渲染或静态站点天生的 mywebsite.com），以及使用共享 UI 组件和共享计划体系包的武艺文档页面（比如 docs.mywebsite.com）。

现已被 Vercel 收买的 Turborepo，现在就努力于在 JavaScript/TypeScript 中放纵宣传 Monorepo 办法。Turborepo 协助开发团队在 Monorepo 中为一切使用步骤和包创建构建管线。其最大亮点，就是能在当地机器或云端完成跨团队的管线内 build 缓存。

Turborepo 与 npm/yarn/pnpm 事情区（依托项办理）和变动集（版本控制）等其他紧张 Monorepo 东西相团结，协同为这局部开产生态吸引到了举世 Web 社区的目光。

Turborepo 的竞争对手包含 Nx、Rush 和 Lerna（一段时间中止维护，后被 Nx 开发商 Nrwl 所收买）。

实用东西优先的 CSS

对这波趋向，喜好的超喜好、厌恶的特厌恶。Tailwind CSS 是实用东西优先 CSS 的典范代表。一方面，开发职员厌恶它的存在令 UI 代码显得冗长；但另一方面，开发者又喜好它出色的开发体验。作为直承受众，开发职员只必要在项目中举行一次设置，即可立刻在 HTML 中使用其预界说的 CSS。

但随着近期办事器端渲染（SSR）的崛起，这种关于实用东西优先 CSS 的爱恨分裂可能彻底完毕。几年来，像 Styled Components（SC）和 Emotion 如此的 CSS-in-JS 处理方案，不休是古代基于组件的 Web 使用步骤样式的主导力气。但是，假如说 SSR 天下一直以功能为至高目标，那 CSS-in-JS 的存在本身就是反功能的：它会让包愈加痴肥（SC 为 12.7 kB，Emotion 为 7.9 kB），并且在插进 DOM 前的 CSS 序列化也会带来分外的运转时开支。

因此，我们约莫会看到开发职员转向对 SSR 更友好的处理方案，比如将实用东西优先 CSS（比如 Tailwind CSS、UnoCSS）与预界说的 UI 组件（比如 DaisyUI）配对，使用 CSS 模块等其他相反盛行的交换方案，大概选择零运转时 / 编译时 CSS-in-JS 类方案（比如 vanilla-extract、linaria、astroturf、complied 等）。

共同 TypeScript 完成端到端典范宁静

从 JavaScript 到 TypeScript 的演化以前势不成挡。在这场席卷整个 Web 开发天下的大迁徙中，全栈使用的端到端典范宁静无疑是一大中心驱力。这个看法的完成与通讯层（API）亲密干系，由于通讯层必要将典范化的实体（比如 type User、type BlogPost 等）从办事器桥接至客户端使用步骤。

在触及客户端 -0 办事器通讯的 Web 开发中，稀有的选项是 REST 和 GraphQL。二者能与 OpenAPI for REST 和 GraphQL Code Generator for GraphQL 共同使用，为前端使用步骤天生典范化的 schema 文件。

除此之外，还出名为 tRPC 的典范宁静 API 后起之秀，它以前证实本人完全有才能成为 REST/GraphQL 的交换方案。假如您以前使用了前端和后端共享代码的 TypeScript Monorepo，tRPC 允许各位将一切典范从后端导出至前端使用步骤，历程中无需天生任何典范化 schema。之后，前端只须使用在背景经过 HTTP 毗连的典范化函数即可调用后端 API，完成客户端 - 办事器间通讯。将来，全栈使用步骤的总体趋向一定会转向这品种型宁静处理方案。作为此中的典范代表，tRPC、Zod、PrismatTanStack Router 都能在使用步骤边沿提供典范宁静保证。

构建东西

在 React-land 中，create-react-app（CRA）曾多年占据主导。这在事先掀起了一场小小的反动，由于初学者取得了一个随时可用的 React 入门项目，不再必要使用 React 设置自界说 Webpack。但已往短短一年之间，Webpack 却敏捷过时。

Vite 固然是单页使用步骤（SPA）范畴的新秀，但却能跟一切盛行框架（比如 React.js）共同构建入门项目。作为 Vue.js 创造者尤雨溪的又一力作，Vite 的定位是下一代前端东西。在引擎盖之下，它从 esbuild 处承继了强壮的功效；并且跟其他 JavaScript 打包器比拟，它是用 GO 编写的，因此打包依托项的速率能到达竞争对手（比如 Webpack）的 10 到 100 倍。

Vite 的生态体系是伴随着 Vitest（Jest 的测试交换方案）等新增功效而发达提高，同时 Vercel 的 Turbopack 同等类竞争方案近期也开头涌现。Turbopack 被称为 Webpack 的继任者，由于它是由 Webpack 的创造者 Tobias Koppers 牵头开发完成。由于 Next.js 既是 Webpack 的现用户，一边又是 Turbopack 的开发商，以是估计 Next.js 和 Turbopack 在后续将成为严密关联的一对 Web 组合。

AI 驱动开发

AI 终极会扫除开发者的事情岗亭吗？这个成绩还贿答案，但 AI 驱动开发确真实 2022 年内成为了实际。随着 GitHub Copilot 的公布，开发者们可以在本人喜好的种种 IDE 中与 AI 助手结对。其使用历程与常规编码大概正文编写没什么区别，GitHub Copilot 会主动补全细节以尽力提升代码质量。

还不止于此：OpenAI 的 ChatGPT 是一套高度通用的言语模子，并且在编程范畴也有不俗体现。没错，ChatGPT 既能回复情势多样的自在发问，也能天生颇为靠谱的开发后果。不少开发者不知不觉变小了对 Stack Overflow 的拜候，转而跟 ChatGPT 讨论武艺成绩。在大多情况下，ChatGPT 都能以搜刮引擎交换品的姿势提供十分有效的答案（固然还称不上完善）。相较于存在多量 SEO 渣滓、乃至跟开发绝不关联的倾销内容，ChatGPT 的使用以为相较于传统搜刮引擎提升了一大截。

但请注意，这种短期收益约莫会带来深远的危害。大局来讲，AI 创建的内容约莫、乃至可以说一定会危害整个互联网。以往手动创建的 SEO 宣传内容以前是个大困难，将来没人拦得住 ChatGPT 以人类无法比力的听从主动天生更多 SEO 渣滓。假如 ChatGPT 本人在练习中也持续使用这些渣滓内容，后果将不堪假想。

另有一些我以为很紧张，但未被列入十大的紧张趋向。起首，Tauri 作为 Electron 的交换品开头进入 JavaScript/CSS/HTML 完成的桌面使用步骤；Playwright 正成为 Cypress 的 E2E 测试交换品；Warp 与 Fig 可能成为下一代终端；CSS 容器查询则作为 CSS 媒体查询的呼应式计划交换方案；最初，htmx 作为富 HTML 格式，可以不借助 JavaScript 创建出交互式用户界面。总之，以上只是我的一局部整理，感兴致的伙伴无碍自行探求更多细节。

渴望这次的文章能帮各位更好地域解 Web 开产生态体系的提高现状。Web 开发无界，江湖有缘再见！