Nuxt.js と Vue 使用レポート

使用レポートシリーズ、ついに Nuxt.js と Vue に到達したぞ。ちょっと使い心地と Next.js と React との比較について話してみる。

Vue

Vue はコード部分を <template> と <script> に分ける。React の JSX/TSX のように、すべてを JavaScript/TypeScript ファイルの中に直接書く形とは違う。この書き方を実現するために、Vue は .vue という独自のファイル形式を作った。

まず <template> の利点から話そう。 Nuxt UI のようなコンポーネントライブラリを使うとき、<template header> のようなスロット記法は、ページレイアウトにとても便利だ。対して React では、似たようなレイアウトを実現するのに CSS を組み合わせる必要がある。でも CSS ってやつは…… 正直、僕にはなかなか読み解けない。

あと Edge と Chrome の開発者ツールにはちょっと言いたいことがある。CSS の問題を調べるとき、正直かなり弱い。ある要素のスタイルがなぜ効かないのか、ただグレー表示にするだけで、理由までは教えてくれない。Firefox の開発者ツールの方が良いらしいけど、僕はまだ使ったことがない。

<script> 部分は React にかなり近い。JavaScript/TypeScript のコードだし、状態管理もだいたい同じだ。最近のフロントエンドフレームワークの多くは、関数コンポーネントや Hooks のような書き方に寄っていて、Vue も例外ではない。ただ、組み合わせ方によっては、再描画の繰り返しや無限ループみたいな問題が出ることもある。最近同じ会社の二つのプロジェクトに関わったけど、Ctrl + S で保存したあと、ホットリロードされたページの状態が消え、バックエンドに HTTP リクエストを送れなくなる問題が起きた。僕のざっくりした推測では、ある状態をどこかのコンポーネント内に持っていて、ホットリロード時にそのコンポーネントの状態がリセットされ、結果としてページ全体の状態まで消えてしまったのだと思う。

<style> 部分もあるけれど、これは良い書き方だとは思わない。やっぱりスタイルはコンポーネントの近くにあればあるほどいい。つまり、Tailwind CSS のように <template> の中で直接スタイルを書く形の方が好きだ。

ここからは文句だ。

まず、コンポーネントの props は通常 <script> 内の defineProps で定義される。IDE がヒントを出してくれるとはいえ、ソースをただ読むだけなら、そのコンポーネントがどんな props を持つのかを知るために、まず defineProps の位置を探さなければならない。特にコンポーネントのコードが長いと、何度も上下にスクロールする羽目になる。

それに、Vue 自体も実際にはコンポーネントの import が必要だ。ただし多くのプロジェクトは、Nuxt.js や各種のコンポーネント自動登録プラグインのような自動 import 方式を使っている。そうすると、テンプレートでは手動で import しなくてもコンポーネント名をそのまま書ける。でもその代償として、コンポーネント名がファイル名やディレクトリ構造にかなり強く結びつく。コンポーネント名を変えると、たいていファイル名も合わせて変える必要があるし、名前の衝突が起きたときも、ファイル名やディレクトリ構成を変えて解決することが多い。これに対して React は明示的な import / export を好むので、コンポーネント名とファイル名の結びつきがそこまで強くなく、リファクタリング時の柔軟性は高い。

Nuxt.js

なんて良いフレームワークなんだろう。かなり好きだ。Next.js とかなり似ているから、いつもの良さについてはあえて細かくは言わない。

ただ、モジュールシステムについてはもっと話したい。Nuxt.js のモジュールシステムは本当に強力で、認証、国際化、PWA 対応などを簡単に組み込める公式・サードパーティ製モジュールがたくさんある。こういうエコシステムは、Next.js にはない。

その Nuxt Content モジュールこそ、僕にとって一番刺さった部分だ。Next.js で似たことをやろうとすると、Contentlayer のようなサードパーティ製ライブラリを組み合わせる必要がある。もちろん公式には SSG もあるけれど、Markdown ファイルなどのコンテンツ資源を扱う専用のコンテンツ管理システムは用意されていない。

note-of-me.top のブログは今は VitePress で動いているけれど、もし将来 Next.js 時代のブログを意識したものを作りたくなったら、Nuxt Content は間違いなく次の候補になるだろう。もちろん、複雑さはかなり増すけどね（（。

まとめ

意外と悪くない。というか、予想をはるかに超えてきた。

というわけで、Nuxt.js は Next.js に次ぐ、あるいは同率一位の僕のお気に入りフロントエンドフレームワークになった。