介绍了，一个 react app 框架的最新版本。next.js 13 希望通过提供创新的特性开发出“动态无限制”的 app，其中许多特性仍处于 alpha 或 beta 阶段。新特性对编译器、路由和渲染基础设施进行了更新，并改进了组件工具包。
next.js 团队在了 next.js 最新版本背后的逻辑。
next.js 最初是用于构建动态服务器端渲染网站的 react 框架。在设计 next.js 时，我们没有针对单页应用进行优化，而是考虑帮助开发团队构建复杂的应用程序。但是，动态总是伴随着许多限制。
动态意味着要以高成本、始终在线的基础设施为代价，需要手动配置和大量的运维。
动态也意味着要同时处理两组运行时 api，在服务器端没有 js，而浏览器端有 web 标准 api。
想要动态，通常只在一个单一的区域，其伸缩性取决于遗留、静态和 cdn 缓存。
我们发布 next.js 13，让你们能够实现无限制的动态。
新版本对工具包进行了改进（改进的 link 组件、新的 image 组件和新的 @next/font 库）。alpha/beta 版特性提供了未来的服务器端渲染预览，正如 vercel 所设想的那样。
新的 image 组件旨在改善用户体验，采用本地延迟加载，减少客户端 javascript 交付，没有了布局漂移。在开发者体验方面，新组件力求简化设置样式和配置。
改进后的 link 组件不再需要锚标记（即
一样，turbopack 可以增量构建和捆绑源文件。next.js 团队宣称：
只打包开发所需的最小资产文件，因此启动速度非常快。一个包含 3000 个模块的应用程序，turbopack 启动只需要 1.8 秒，而 vite 耗时 11.4 秒，webpack 则需要 16.5 秒。
turbopack 对 server component、typescript、jsx、css 等都提供了开箱即用的支持。
vite 的作者最近对 vite 和 next/turbo 进行了。他发现，当使用执行基准测试时，二者的速度是相近的。截至本文发布，vercel 的，纠正了一些错误，但这仍然是一个存在。
虽然开发者体验的改善得到了许多积极评价，但一位开发者仍然指出了可能存在的：
因为庞大的 webpack 插件生态系统，这可能会使现有应用程序的迁移变得非常困难。vercel 可能需要依靠社区的贡献开发某种插件系统，这可能很困难，因为像我这样的 javascript 开发人员愚蠢又懒惰，不愿意学习 rust。
此外，对于大多数项目来说，带有的已经了，它提供了无与伦比的体验。
你还应该知道的是，vercel 有意希望通过在云端远程缓存构建来赚钱。
next.js 13 还对路由和渲染基础设施进行了重大更改，其中一些直接与 react 核心团队合作，以便更好地利用 react 的、。文档中提到：
新的路由器支持。
1. ：在路由之间轻松共享 ui，同时保留状态，避免昂贵的重新渲染。
2. ：将服务器优先作为大多数动态应用程序的默认设置。
3. ：渲染时在 ui 单元中显示即时加载状态和流。
4. ：async 的 server component 和扩展的 fetchapi 支持组件级抓取。
要了解更多细节，可以查看。
虽然有开发者对该版本做出了，但一位开发者：
如何使用 server component 相关的规则不直观，也很难理解。我认为这对 react 的负面名声也不会带来什么帮助。在同一个代码库中处理客户端 js 和 node 运行时就很麻烦了，而在旧范式中，至少两端之间只有一个交互点（getserversideprops/getstaticprops），但现在可以出现在每个组件边界上。
另一名开发者对一些新特性提出了警告：
next.js 涵盖了 react 团队正在研究的一些实验性的、还不稳定的 react 特性，比如服务器端组件，或者在这些服务器端组件中支持 async/await。
因此，next.js 也包含了 react 的一些未来的概念。但你需要知道这些是不稳定、尚未完成的 api，它们仍在研究和实现当中。
当你尝试在 beta 版的文档中搜索如何使用新的/app 文件夹和构建 next.js 应用程序的新方法时，你会发现许多相关特性仍然缺失、未完成、可能发生变更等警告和注释。
next.js 基于 mit 开源许可。欢迎开发者为做出贡献，并遵循 next.js和。
原文链接：
相关阅读：
评论