Nuxt3 还能用吗？

前一段时间，我完成了整个产品，从 Nuxt 到 Next 的迁移，因为面临了一些在框架层面就无法解决的问题。

payload json 化

在所有的的 Nuxt 中，我们都能看到有这样一个东西。

其实有这个东西也很正常，在 Next 中也会把服务端渲染的数据挂载 html 保持数据同步，这就是一个水合的必要步骤。在 Next 中是这样的。

可以看到在 Next 新一点的版本中是压缩过的字符串（老版本 Page Router,也是 JSON 格式），而在 Nuxt 中采用的是 JSON 格式.

为什么 Nuxt 要采用 JSON？有什么好处？会面临什么问题？

好处:

其实很好理解，就是为了性能和水合的加速，我的直觉因为是因为 V8 的性能加速对于 JSON 格式，V8参考资料。所以它不做压缩。

问题：违背 SSR 原则

这其实有点不符合 SSR 的设计原则，本身来说 SSR 是要在更快的时间看到页面和加载完成，这种设计会让整个 html document 的文件大小大量的增加。假设项目有 18n 文件，或者首屏的请求接口非常的多在服务端完成，就会导致拉长整个接口时间。

在本身现代浏览器如此之快的背景下，去加快水合时间，而拖慢请求完成的时间，确实让我非常的不理解。

💥 矛盾暴击现场

1. i18n 地狱 🌐

   服务端渲染多语言版本 → HTML 体积×N 倍

   爬虫抓取时：“这页面怎么比新华字典还厚？📚”

2. 接口瀑布流 🌊

   服务端串行请求 10 个 API → 链式延迟堪比春运抢票

   用户内心 OS：“我等得都能泡碗面了🍜”

3. 水合加速 vs 服务端减速 🐢⚡

   现代浏览器渲染飞快，但服务端被重逻辑拖累 → 前端省下的时间，全赔给后端了！

安全问题

你敢相信吗，这么大一个框架，在一定情况下，会把 NUXT_PUBLIC 公开的环境变量直接挂在 html 里（如果用到了环境变量），人都要晕了。

可以参考这个 issue：https://github.com/nuxt/nuxt/issues/2033这个问题从 2017 年已经到 2024 年了。

生态问题

不可否认的是，整个生态是欣欣向荣的，但在一些更商业和大型库生态在我看来 Nuxt 是不够深入的（就是 Nuxt 有非常多高级的语法糖和渲染方式和写法、社区在遇到更具体问题的时候解法很少），反之整个生态的方向都导向了工具、组件库、提效、性能类似的方向，让我感觉很迷茫有时候，就是大家都不做应用是把。

夸一下

毫无疑问，Nuxt 框架在不考虑上述这些因素的情况下，在纯前端层面上的性能、语法便捷度、用户体验（框架基础）上绝对都是大于 Next 的，它也是可以用的。

欢迎加入群聊，我们一起讨论一些更有趣的技术、商业、闲聊。