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文件，或者首屏的請求接口非常的多在服務端完成，就會導致拉長整個接口時間。
在本身現代瀏覽器如此之快的背景下，去加快水合時間，而拖慢請求完成的時間，確實讓我非常的不理解。
💥 矛盾暴擊現場
i18n地獄 🌐
- 服務端渲染多語言版本 → HTML體積×N倍
- 爬蟲抓取時：“這頁面怎麼比新華字典還厚？📚”
接口瀑布流 🌊
- 服務端串行請求10個API → 鏈式延遲堪比春運搶票
- 用户內心OS：“我等得都能泡碗麪了🍜”
水合加速 vs 服務端減速 🐢⚡
現代瀏覽器渲染飛快，但服務端被重邏輯拖累 → 前端省下的時間，全賠給後端了！
安全問題
你敢相信嗎，這麼大一個框架，在一定情況下，會把NUXT_PUBLIC公開的環境變量直接掛在html裏（如果用到了環境變量），人都要暈了。
可以參考這個issue：https://github.com/nuxt/nuxt/issues/2033
這個問題從2017年已經到2024年了。
生態問題
不可否認的是，整個生態是欣欣向榮的，但在一些更商業和大型庫生態在我看來Nuxt是不夠深入的（就是Nuxt有非常多高級的語法糖和渲染方式和寫法、社區在遇到更具體問題的時候解法很少），反之整個生態的方向都導向了工具、組件庫、提效、性能類似的方向，讓我感覺很迷茫有時候，就是大家都不做應用是把。
誇一下
毫無疑問，Nuxt框架在不考慮上述這些因素的情況下，在純前端層面上的性能、語法便捷度、用户體驗（框架基礎）上絕對都是大於Next的，它也是可以用的。
歡迎加入羣聊，我們一起討論一些更有趣的技術、商業、閒聊。
