「汎用的にはAstro」は何を指しているのか

結論

• 「汎用的」には二つの軸がある。フレームワーク自体ができることの広さと、ある種類のサイトへの適合度である。
• できることの広さで比べれば、Nuxtの方が広い。サーバー、データベース、認証、APIまで一つのフレームワークで持てる。
• 静的なコンテンツサイトへの適合度で比べれば、Astroの方が合う。既定でJavaScriptを送らず、ビルド時にHTMLを出力するだけで完結する。
• 「静的サイトなら汎用的にはAstro」という助言は、後者の軸の話をしている。前者の軸では、Nuxtの方が汎用的だという直感はそのまま正しい。

「汎用的」が指しているものが二つある

WordPressから移行するeurekapuのアーカイブサイト（wordpress-migration）の技術選定を検討していたときに、次のような助言を受けた。

「静的サイトとしては、汎用的にはAstroが有力」

この助言に対して、次の疑問が浮かんだ。

「汎用的というなら、Nuxtの方が汎用的なのではないか」

この疑問は正しい。Nuxtはサーバーサイドの処理、データベースとの接続、ユーザー認証、外部APIの呼び出しまで一つのフレームワークで扱える。実際に、同じeurekapuブランドの商用プロダクトであるeurekapu-nuxt4は、Nuxt 4の上にCloudflare D1（データベース）、Cloudflare R2（画像や音声の配信）、認証機能を組み合わせて構築されている。将来的にはStripeによる決済も載せる計画がある。できることの広さという軸で見れば、Nuxtの方が明らかに汎用的である。

一方で、「静的サイトとしては汎用的にはAstroが有力」という助言が指しているのは、別の軸である。ブログ、ドキュメントサイト、アーカイブサイトのように大半が読み物で構成されるサイトという広いカテゴリに対して、どちらのフレームワークがより素直に当てはまるか、という軸である。この軸で見れば、Astroの方が汎用的である。

両者とも「汎用的」ではある。ただし、その言葉が指している軸が違う。

Nuxtができることの広さ

Nuxtは、Vue 3を土台にしたフルスタックのアプリケーションフレームワークである。ルーティング、データ取得、SEO用のメタタグ管理、画像最適化といった機能を規約として持ち、さらにserver/api/ディレクトリにサーバーサイドの処理を書ける。これによって、フロントエンドとバックエンドを同じプロジェクト内で完結させられる。

内部ではNitroというサーバーエンジンがこの仕組みを支えている。NitroはCloudflare Workers、Vercel、Node.jsサーバーなど複数のデプロイ先に対応したプリセットを持ち、どこにデプロイしても同じサーバー機能が動く。eurekapu-nuxt4がCloudflare Workers上でD1データベースと認証機能を動かせているのは、このNitroの機能による。

Nuxtはページ全体を、既定でクライアント側にハイドレートする。ハイドレートとは、サーバーから届いた静的なHTMLに対して、ブラウザ側でJavaScriptを実行し、クリックや入力に反応できる状態へ変えることを指す。ボタンを押して状態が変わる、フォームに入力した値がその場でバリデーションされる、複数のコンポーネント間でデータを共有する、といった挙動は、このハイドレートの上に成り立っている。

Nuxtにはnuxt generateという、サーバーを立てずに静的HTMLとして書き出すモードもある。ただしこのモードでも、書き出されたページはVueのアプリケーションとしてクライアント側で丸ごとハイドレートされる。静的に書き出しているのはあくまで初期表示のHTMLであり、実行モデルそのものは変わらない。

Astroが読み物サイトに合う理由

Astroは、Nuxtとは異なる前提で設計されている。Astroが既定で送るJavaScriptの量はゼロである。ページはビルド時にHTMLへ変換され、そのHTMLがそのままブラウザに届く。ボタンのクリックやフォームの入力といった動きが要らないページであれば、JavaScriptを一切読み込まずに表示が完結する。

動きが必要な部分だけ、個別に指定してハイドレートできる。この仕組みはアイランドアーキテクチャと呼ばれ、ページ全体を一つのアプリケーションとして扱うのではなく、必要な部分だけを独立した「島」として動かす。指定できるコンポーネントはVueに限らない。ReactやSvelteで書いた部品を同じページに混在させることもできる。

Astroはこの前提のもとで、MarkdownやMDXのファイルをコンテンツとして扱う仕組み（コンテンツコレクション）を標準で持つ。frontmatterのスキーマを定義しておけば、型のついたデータとして記事を扱える。ブログやドキュメントサイトのように、ページの大半が文章と画像で構成され、動く部分がごく一部にとどまるサイトでは、この設計がそのまま強みになる。

機能が使われないと、広さはコストになる

ここまでの説明だけでは、「Nuxtの方が何でもできるなら、Nuxtを選んでおけば損はないのでは」という疑問が残る。

この疑問には、コストの面から答える必要がある。Nuxtが持つ機能の広さは、無料ではない。ページ全体をクライアント側でハイドレートする以上、Vueの実行環境そのものをブラウザへ送る必要があり、その分だけ初期表示にかかるJavaScriptの量が増える。サーバー機能を使わない場合でも、Nitroというサーバーエンジンの層は構成として残り、依存関係の更新やビルド設定の対象になり続ける。

wordpress-migrationのアーカイブサイトが実際に必要としている機能を数えると、記事本文の表示、前後の記事への移動、矢印キーでのページ送り、目次のスクロール追従、ギャラリー画像の切り替えである。認証もデータベースも要らない。これらの機能は、素のJavaScriptだけで実装できる範囲にとどまっている。実際、現時点のプレビュー環境はNode.jsスクリプトとVanilla JavaScriptだけで、この機能一式をすでに動かしている。

Nuxtが持つ「認証、DB、API」という広さは、このサイトにとっては使われないまま残るコストになる。逆に、Astroが前提とする「大半は読み物、動く部分は一部だけ」という設計は、このサイトの実態にそのまま重なる。

それでもNuxtを選ぶ理由はあるか

適合度だけで判断すれば、wordpress-migrationのアーカイブサイトにはAstroが向いている。ただし、これとは別の理由でNuxtを選ぶ判断にも根拠はある。

一つは、eurekapu-nuxt4とVueコンポーネントを実際に共有する計画が具体化した場合である。両者が同じNuxtの上に乗っていれば、UIコンポーネントをパッケージとして共有できる。この場合の理由は「静的サイトとしての適合度」ではなく、「別プロジェクトとのコード共有」という、また別の軸に基づく判断になる。

もう一つは、Nuxtをすでに使い慣れているという事情である。eurekapu-nuxt4とmdx-playgroundはいずれもNuxt 4で構築されており、ファイルベースルーティングやデータ取得の作法にはすでに慣れている。新しいフレームワークを一つ増やす代わりに、慣れた道具で済ませるという判断も、実務上は十分に成立する。

いずれの理由も、「Nuxtの方がフレームワークとして汎用的だから」という理由とは別のところにある。

まとめ