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地獄 🌐

   1. 服務端渲染多語言版本 → HTML體積×N倍

   2. 爬蟲抓取時：“這頁面怎么比新華字典還厚？📚”

2. 接口瀑布流 🌊

   1. 服務端串行請求10個API → 鏈式延遲堪比春運搶票

   2. 用戶內心OS：“我等得都能泡碗面了🍜”

3. 水合加速 vs 服務端減速 🐢?

   1. 現代瀏覽器渲染飛快，但服務端被重邏輯拖累 → 前端省下的時間，全賠給后端了！

安全問題

我靠，你敢相信嗎，這么大一個框架，在一定情況下，會把NUXT_PUBLIC公開的環境變量直接掛在html里（如果用到了環境變量），人都要暈了。

可以參考這個issue：https://github.com/nuxt/nuxt/issues/2033 這個問題從2017年已經到2024年了。

生態問題

不可否認的是，整個生態是欣欣向榮的，但在一些更商業和大型庫生態在我看來Nuxt是不夠深入的（就是Nuxt有非常多高級的語法糖和渲染方式和寫法、社區在遇到更具體問題的時候解法很少），反之整個生態的方向都導向了工具、組件庫、提效、性能類似的方向，讓我感覺很迷茫有時候，就是大家都不做應用是把。

夸一下

毫無疑問，Nuxt框架在不考慮上述這些因素的情況下，在純前端層面上的性能、語法便捷度、用戶體驗（框架基礎）上絕對都是大于Next的，它也是可以用的。

歡迎加入群聊，我們一起討論一些更有趣的技術、商業、閑聊。