Vue使うなら最初からNuxt.js使えよ、という条件反射みたいな風潮にちょっと反論してみる。
※2020/7/6 追記
NuxtJSが必要な状況になって使ったときの感想などはこちら
uyamazak.hatenablog.com
※2018/9/4 追記
1にviewsフォルダ等について追記
またこの記事はNuxtにしようかなと思っていたところでVue CLI3を使って感動し、今も使っていないのでその持論でもあります。
Vue-CLI3に関するVue開発者Evan Youの記事の和訳がきました
jp.vuejs.org
1. Vue CLI3でよく使う公式ライブラリはインストールできるようになった
最近アップデートされたVue CLI3では、プロジェクト作成時にVue Router、Vuex、テスト、lint関連、TypeScriptサポートなどが選べ、選んだ機能に最低限必要な設定ファイルや初期テンプレートが生成されるようになりました。
viewsというディレクトリもができ、routerで使用するページ用vueファイルはそこ、そのほかはcomponentsに入れるというゆるいルールが感じられます。初期状態ではviewsにHome.vue、componentsにHelloWorld.vueが入っている。
でもviewsに入れたからといってNuxtのように自動でルーティングされるわけではなくrouter.jsでの設定が必要。
ホットリロードの開発サーバーも付いているのでほとんどの場合これで十分ではないだろうか。
SSRはついてないので自分でやるかNuxtを使った方がよさそう。
Vue.js Server-Side Rendering Guide | Vue SSR Guide
2. 「The Progressive JavaScript Framework」に反している
融通が効く ライブラリと完全な機能を備えたフレームワークの間で拡張できる徐々に採用可能なエコシステム
だからこそNuxtが生まれた理由でもあると思うけど。
Vueは必要に応じてパーツを追加、拡張していこう、みたいな考えを貫いており、コア機能をシンプルに保っています。
その哲学は機能追加の議論などでも貫かれており、かっけーとよく思ってます。
例として最近みたVueにconst的なデータを持たせたいみたいな議論
Constant component data · Issue #6004 · vuejs/vue · GitHub
Vueを始めるときも、最初はCDNからの読み込みで触って、大きくなってきたらシングルファイルコンポーネントで書きたくなってvue-cli使って、みたいに大きくなっていったので、非常にいい思想だと思っています。
その過程でああ、だからVuexがいるんだ、router使うとこんな便利なんだ、みたいな途中の学習や納得が積み重なりVueへの理解が深まります。
一方Nuxt.jsはRailsみたいにいきなりどかっとサーバー環境まるごと全部入り環境な感じなので、Nuxtで一通り用意されてる構造や規約を理解して、それに従って作っていく感じになります。
3. Vue公式ではない
NuxtはVueを使ってるけど別プロジェクトです。
それだけのことですが、NuxtはVueの変更に対し後追いになってしまったり継続が大変そうだなぁと思う。
直接関係ないけど面白いのがGitHubでコントリビューター一覧上位を見ると、全然空気が違う。
Vueは中国系とアニメアイコンが目立つのに対し
Contributors to vuejs/vue · GitHub
Nuxtはヨーロッパ系な感じ。
Contributors to nuxt/nuxt.js · GitHub
それでもNuxtを採用する理由
で、現時点の私はコードに関わる開発はデザイナーと私で2人で、企画、設計、ユーザーテスト等その他運営もろもろを2人やっている小さな新規サービス（yagish履歴書）であり、Serach Consoleも問題なくてSSRの必要性もないため、Vue-CLI3で十分、Nuxt.jsいらないとなっています。
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発
- 作者:花谷 拓磨
- 発売日: 2018/10/17
- メディア: 単行本（ソフトカバー）
