早上刷沸点，好多人都在抱怨前端已死，我特别想感慨一句：已死的永远不是技术本身，已死的是自己给自己设定的天花板。那么2023年了，在前端还有哪些开发趋势值得跟进呢？你是否还有可突破的天花板呢？这十大趋势来自于国外的一篇分享，里面有十分有趣的统计和分析。
首先，分享一张十分有趣的js生态发展图，其中可以很明显看到从去年开始前端的生态发展相较于之前几年开始放缓了许多。
1、（元）框架
本段关注点：Next.js、Svelte
单页应用（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构建），其DX与React.js相比有所改进。
2、应用与渲染模式
本段关注点：静态再生（ISR）和流式SSR
虽然过去十年（2010-2020年）一直以单页应用程序（SPA）及其客户端渲染（CSR）为主，从Knockout.js和Ember.js到Angular.js、React.js和Vue.js，但过去几年，人们对使用元框架的服务器端渲染（SSR）越来越感兴趣。从外部看，这一周期似乎再次结束，因为我们在多页应用程序（MPA）中通过JavaScript（例如jQuery、MooTools、Dojo.js）使用SSR已有很长一段时间了（2005-2010）。然而，鉴于过往的Java（例如JSP）或之后的Ruby on Rails被用于SSR的时期经验来看，这次不同了，因为我们依赖的是JavaScript。几年来，Next.js一直是这一趋势的驱动力，然而，SveltKit等其他元框架正在迎头赶上。
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流变得更加相关，而且部分hydrate（例如React Server组件）允许hydrate客户端上的组件一部分，渐进（Progressive Hydration）可以对hydrate顺序进行更精细的控制，孤岛架构（例如Astro）用于MPA中的隔离应用程序或组件，使用可恢复性代替hydrate作用（例如Qwik）正在成为当今有效的方法。
3、Serverless
本段关注点：Serverless商机下的发展形态，一些云提供商
SSR和SSG等渲染技术与serverless的趋势高度相关，因为两者都是由性能驱动的，目的是在浏览器中提供无缝的用户体验。本质上，为了更快地为用户提供网站和网络应用程序，人们开始对serverless感兴趣。
但让我们从头认识Serverless：无服务器（Serverless），也称为无服务器功能、无服务器计算（例如AWS Lambda）或云功能（例如Google/Firebase云功能）已成为云计算领域的一个大趋势。虽然无服务器仍然意味着有一个正在运行的（远程）服务器，但开发人员不必管理服务器及其相关任务（例如基础设施按需扩展）。相反，必须将单个功能部署为无服务器功能，由云提供商负责。
无服务器功能释放了另一个优势，因为不用将应用程序服务器部署到一个（或几个）数据中心，世界各地可能有几十个数据中心。因此，在一个完美的世界中，无服务器功能将尽可能靠近用户运行，因为这意味着最短的客户机-服务器往返，从而改善用户体验。尽可能靠近用户部署无服务器功能创造了边缘计算和边缘功能这两个术语。
许多云提供商（例如，Cloudflare与Cloudflare Workers、Vercel与其Edge Network、Deno与Deno Deploy）都在这一领域展开竞争，每个人都在为其最终用户优化最佳交互时间（TTI）体验。边缘功能不仅可以更快地提供SSG/SSR内容（因为与最终用户的连接更短），还可以将结果缓存到离用户更近的位置。
不仅与性能有关，即使它是主要驱动因素，其他好处，如降低成本，也来自边缘计算。例如，通常不是客户端和服务器之间发送的所有数据（这里是边缘函数）都需要由主数据中心计算。在物联网中，有很多不相关的数据（例如，每帧没有变化的视频记录）发送到主数据中心，而只需在边缘进行过滤即可。毕竟，边缘函数只是开始。。。
4、数据库的复兴
本段关注点：Fly.io & Railway
随着无服务器（处于边缘）的出现，数据库也经历了复兴。使用无服务器功能，开发人员很快就遇到了打开太多数据库连接的问题，因为没有一台服务器可以一直保持一个连接，但是许多无服务器功能与数据库要保持1:1的连接。连接池一直是解决这个问题的方法，但要么必须自己处理，要么由第三方服务处理。
无服务器数据库领域的热门竞争者是PlanetScale（MySql）、Neon（PostgreSQL）和Xata（PostgreQL），它们具有许多功能，如数据库分支、模式区分和强大的搜索/分析/洞察。当涉及到世界各地的无服务器时，他们提供边缘缓存或分布式只读数据库，以将您的数据移动到离用户更近的位置，从而将延迟降至最低。
如果第三方服务不仅要分发您的数据库，还要分发您的应用程序，Fly.io会将所有内容打包到一个平台中。这使我们不仅仅局限于数据库，同时伴随着很多功能的发生。Railway被视为Heroku的继任者，它为平台即服务（PaaS）提供了部署技术栈的一切。如果您想在服务链上向后端即服务（BaaS）迈进一步，您可以获得一个开源的替代方案，以取代带有Subasse的Firebase，后者提供应用程序/数据库托管、身份验证和边缘功能。
5、Js运行时
本段关注点：Deno，Bun
这一切始于2009年Ryan Dahl在一次会议上宣布Node.js。最初的实验是将JavaScript与浏览器分离并使其在服务器上可用，这成为过去十年中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及其名为Deno Fresh的即时边缘渲染SSR框架（最初是概念验证）的云提供商。Bun（运行在JavaScriptCore引擎上，并在Zig中实现）等独立于云提供商的解决方案最近成为最快JavaScript运行时竞赛中的又一热门。
聪明的人会再次看到由于不同的运行时，JavaScript环境中存在许多碎片。如果事情搞砸了，我们将陷入多年来浏览器中分散的JavaScript支持的情况，但这一次在服务器上，当部署在不同的云提供商上时，并非所有的JavaScript都可以在运行时得到同等支持。因此，所有利益相关者（如Deno、Vercel、Cloudflare）都加入了WinterCG，在其JavaScript运行时之间就API互操作性进行合作。
6、Monorepos
本段关注点：Turborepo
在过去，monorepos主要用于大型应用程序，这个程序在一个版本控制的仓库中包含一些较小的项目。这些小项目中的每一个都可以是从单个应用程序（例如SPA、MPA）到可重用包（例如功能、组件、服务）的任何东西。合并项目的实践可以追溯到2000年初，当时它被称为共享代码库。
然而，如今monoreos不仅是大型应用程序的专属，而且是小型公司和开源项目的专属，他们肯定会从中受益。例如，一家公司可以在monores中包含各种包，包括共享的UI组件、共享的设计系统（例如可重用的协作设计），以及各自领域中常用的实用功能。
这些包可以在各种应用程序中导入：使用所有这些共享包的实际应用程序（例如，带有客户端渲染的app.mywebsite.com）、考虑SEO的主页/产品/登录页（例如，具有服务器端渲染或静态站点生成的mywebsite.com）仅使用共享设计系统包，以及使用共享UI组件和共享设计系统包的技术文档页面（例如docs.mywebsite.com）。
Turborepo（被Vercel收购）再次在JavaScript/TypeScript中掀起了monorepo热潮。Turborepo允许团队在monorepo中为其所有应用程序和包创建构建通道。值得关注的是：在本地机器上或跨团队的云中缓存构建。Turborepo与npm/yarn/pnpm工作区（依赖关系管理）和变更集（版本控制）等其他重要的monorepo工具相结合，使该工具链成为今年值得关注的领域。
Turborepo的竞争对手是Nx、Rush和Lerna（一段时间没有维持，后来被Nx的公司Nwl收购）。
7、功能类优先Css
本段关注点：Tailwind Css
面对Tailwind CSS开发人员要么喜欢要么讨厌，它是功能类优先CSS的典范。一方开发者讨厌它在UI代码中显得冗长，另一方开发者则喜欢它出色的DX。作为开发人员，您可以在项目中配置它一次，然后立即在HTML中使用预定义的CSS。
然而，随着最近服务器端渲染（SSR）的兴起，这种关于功能类优先CSS的爱与恨的分歧可能会结束。几年来，CSS in JS解决方案（如Styled Components（SC）和Emotion）一直是现代基于组件的web应用程序样式的主流力量。然而，如果SSR世界中的性能是主要目标之一，那么CSS-in-JS会带来负面影响：捆绑包大小增加（SC为12.7kB，Emotion为7.9kB），更重要的是，在将其插入DOM之前，由于CSS序列化会增加运行时的开销。
因此，我们可能会看到开发人员向更友好的SSR解决方案迁移，如与预定义的UI组件（如DaisyUI）配对的功能类优先CSS（如Tailwind CSS、UnoCSS），其他同样流行的替代方案，如CSS Modules，或称为零运行时/编译时的CSS-in-JS（如vanilla extract、linaria、astropurf、compiled）。
8、使用TYPESCRIPT实现端到端类型安全
本段关注点：tRPC
从JavaScript到TypeScript的发展势不可挡。在web开发的大迁移中，E2E类型的全栈应用程序安全无疑是一个重要趋势。该概念的实现与通信层（API）一致，通信层是将类型化实体（例如，类型User、类型BlogPost）从服务器桥接到客户端应用程序所需的。
web开发中客户端-服务器通信的常见问题是REST和GraphQL。通过OpenAPI for REST和GraphQL Code Generator for GraphQL，二者都能生成前端应用程序的类型化模式文件。
然而，类型安全API有一个新的新星，称为tRPC，它可以用作REST/GraphQL的替代品。如果您在前端和后端共享代码的TypeScript monorepo中工作，tRPC允许您将所有类型从后端导出到前端应用程序，而无需任何类型模式的中间生成。随后，前端可以调用后端的API，只需使用类型化的函数，这些函数在后台通过HTTP连接，以实现实际的客户端-服务器通信。总的趋势当然是将更多的这些类型安全解决方案用于全栈应用程序，如tRPC、Zod、Prisma和TanStack Router，它们都在应用程序的边缘提供类型安全。
9、构建工具
本段关注点：Vite & Turbopack
在React领域，create React app（CRA）占据了几年的主导地位。这在当时是一场小小的革命，因为初学者可以获得一个准备就绪的React初学者项目，而无需再使用React设置项去配置自定义Webpack。然而，从去年Webpack很快就过时了。
Vite是单页应用程序（SPA）领域的新手，因为它可以与所有流行的框架（例如React.js）一起创建初学者项目。由Vue.js的创建者Evan You实现，它将自己定位为下一代前端工具。实际上，它从esbuild中获得了强大的功能，与其他JavaScript打包程序相比，esbuild是在Go中编写的，因此打包依赖项的速度比竞争对手（例如Webpack）快10-100倍。
虽然Vite的生态系统因添加Vitest（测试Jest的替代品）而蓬勃发展，但最近出现了其他竞争对手，如Vercel的Turbopack。Turbopack被称为Webpack的继任者，因为它是由Webpack创始人Tobias Koppers率先推出的。因为Next.js仍然在使用Webpack，而Turbopack是由同一家公司开发的，所以我们可以预计Next.js和Turbopack可能会在未来成为完美的匹配。
10、AI
本段关注点：ChatGPT
人工智能最终会接受开发者的工作吗？这个问题还没有答案，然而，人工智能驱动的发展在2022年成为了一件大事。随着GitHub Copilot的发布，开发人员可以在他们最喜欢的IDE中与AI程序员配对。只需编写代码（或写一条注释说明你想编写什么代码），GitHub Copilot就会自动完成实现细节，达到最佳理解。
但它并不止于此：OpenAI的ChatGPT是一个更通用的语言模型，它也能处理编程任务。虽然您可以向ChatGPT免费提问，但它也可以执行编码任务。许多开发人员已经发现自己使用ChatGPT作为StackOverflow的替代品。在许多情况下，ChatGPT在用作搜索引擎替代品时提供了有用的答案（但并不总是完美的）。因为后者必须处理大量的SEO垃圾邮件（不仅仅是与开发相关的内容），所以ChatGPT目前被视为一个可行的替代方案。
“目前”是个很重要的含义，从全局的角度来看，人工智能创造的内容也会（并将会）危害全球网络。在以前人工创建的SEO内容已经是一个问题的地方，没有什么能阻止人们通过ChatGPT产生更多自动生成的SEO内容。ChatGPT最终会对自己生成的内容进行训练吗？
还有几个趋势
还有几个值得注意的技术趋势，但它们并没有成为列出的趋势：Tauri作为Electron的替代品，用于JavaScript/CSS/HTML实现的桌面应用程序，Playwright作为Cypress的替代物，用于E2E测试，Warp和Fig作为下一代终端，CSS Container Queries作为CSS媒体查询的替代品用于响应式设计，最后但并非最不重要的是，htmx作为一种丰富的HTML，用于创建没有JavaScript的交互式用户界面。
