先說(shuō)說(shuō)nuxt.js的優(yōu)勢(shì)

1）就是我們無(wú)需為了路由劃分而煩惱，你只需要按照對(duì)應(yīng)的文件夾層級(jí)創(chuàng)建 .vue 文件就行；

2）無(wú)需考慮數(shù)據(jù)傳輸問(wèn)題，nuxt 會(huì)在模板輸出之前異步請(qǐng)求數(shù)據(jù)（需要引入 axios 庫(kù)），而且對(duì) vuex 有進(jìn)一步的封裝；；

3）內(nèi)置了 webpack，省去了配置 webpack 的步驟，nuxt 會(huì)根據(jù)配置打包對(duì)應(yīng)的文件；

4）對(duì)seo比較友好，對(duì)于普通的vue項(xiàng)目，不會(huì)將html的dom暴露在頁(yè)面中。nuxt就解決這一問(wèn)題。

不要用Nuxt！ 不要用Nuxt！ 不要用Nuxt！

重要的事說(shuō)三遍。

Nuxt是我用過(guò)最后悔的框架，設(shè)計(jì)理念高度Template化，有太多太多的黑盒。不出問(wèn)題則以，出問(wèn)題非常非常難以debug，哪怕是非常非常小的錯(cuò)誤（除了前端page還算能debug以外） ，你甚至無(wú)法追蹤錯(cuò)誤在哪里發(fā)生。一切都是配置，包括你寫(xiě)的server端代碼都是包在盒子里的，拋出異常？ 不存在的，nuxt把異常直接吞了。對(duì)docker的支持非常非常糟糕，因?yàn)橛刑嗟呐渲胮ath，resolved path ...，導(dǎo)致你本地測(cè)試沒(méi)問(wèn)題，放進(jìn)docker里就各種問(wèn)題，往往要手動(dòng)去改。

所以，使用nuxt帶來(lái)的那一點(diǎn)點(diǎn)便利，與后期維護(hù)的巨大成本完全不成比例。nuxt 的整個(gè)design pattern有巨大問(wèn)題, 耦合性太高。

補(bǔ)充:

實(shí)際production中，我這兩年用到MVC越來(lái)越少了,  思考了一下，從 jQuery 到 express+view engine，然后是 MVC(react/vue/angular) + virtual DOM + packet tools，之后出現(xiàn)了SSR，是不是已經(jīng)有點(diǎn)開(kāi)始變味？

最新svelte的崛起，complier的回歸，只能說(shuō)印證了歷史呈螺旋上升狀的事實(shí)。

react hooks的引入，其實(shí)早已經(jīng)不再是單純MVC了，而基本上進(jìn)入Reactive Programming范疇。

其實(shí)說(shuō)白了只有一個(gè)問(wèn)題無(wú)法回避， 就是performance，virtual DOM、tree shaking、ssr 繞來(lái)繞去都是為了改善那幾秒鐘的loading, 然而只要是打包, 臃腫根本上就是難以避免，框架套框架的加法并不能解決問(wèn)題本身。所以我不看好vue，當(dāng)然更不看好nuxt，nuxt可以說(shuō)本身的設(shè)計(jì)理念就有巨大問(wèn)題。

一個(gè)高度耦合高度template化的community framework？

現(xiàn)實(shí)就是, 版本一迭代, 連官方列表里的module都跑不起來(lái)...