「結局どれを使えばいいんですか」と聞かれがちな分野です。React、Vue、Next.js、Nuxt、Astro……名前はよく見かけるのに、何がどう違うのか、非エンジニアにはつかみにくくなっています。
先に結論を書きます。どれか1つが優れているわけではありません。 作ろうとしているものが、常に画面が動き続けるアプリなのか、それとも文章を読ませるサイトなのかで、向いている道具が変わります。この記事では、その見分け方を実例2つとともに整理します。
3つの層に分けて見る
名前が並んでいると混乱しますが、大きく3つの層に整理すると見通しが良くなります。
| 層 | 代表 | 何をしてくれるか |
|---|---|---|
| 素のライブラリ | React・Vue | 画面のUI部品を組み立てる仕事だけを引き受ける。ルーティング（URLごとに、どの画面を表示するか決める仕組み）やデータの取得方法は自分で選んで組み合わせる |
| メタフレームワーク | Next.js（React用）・Nuxt（Vue用） | 素のライブラリの上に、ルーティング・データ取得・サーバー側レンダリング（SSR、ページをサーバー側で組み立ててから送る仕組み）などをセットで載せ、決めることを減らしてくれる |
| コンテンツ特化型 | Astro | ページの大半が文章であることを前提に、初期状態で配るJavaScriptをほぼ0にする |
下に行くほど「決めてくれること」が増え、代わりに「その道具の流儀に従うこと」が増えます。どこに乗るかは、次に書く「何を作るか」で決まります。
素のライブラリの良さと課題
React・Vueのような素のライブラリは、画面部品の組み立てだけを引き受けます。良さは自由度です。 ルーティングも状態管理（ログイン状態やカートの中身のように、複数の画面部品にまたがって共有する情報をまとめて管理する仕組み）もビルドツール（書いたコードを、ブラウザが読める形に変換する道具）も、必要なものだけ選んで足せます。余計な仕組みを抱え込まずに済みます。
課題は、決めることが多いことです。 ルーティングは何を使うか、状態管理はどうするか、サーバーとのやり取りはどう書くか——選択肢が多いぶん、組み立てる側が毎回選定する必要があります。この「決めることの多さ」を肩代わりするために生まれたのが、メタフレームワークです。
メタフレームワークの良さと課題
Next.jsやNuxtのようなメタフレームワークは、ルーティングやサーバー側レンダリング（SSR、ページをサーバー側で組み立ててから送る仕組み）をセットで用意してくれます。良さは、決められた型に乗ればすぐ動くことです。 検索エンジン対策（SEO）や、最初の一画面を速く届ける用途にも強く、Vercelのようなホスティングとの相性も良好です。
課題は、仕組みが増えるぶん重くなる場面があることです。 サーバー側レンダリングに加えて、ルーティングのような周辺機能もまとめて抱え込む作りになっている分、その画面の表示には直接関係のない部分まで、読み込みコストとして乗ってきます。 文章を1回表示するだけならこれで十分ですが、同じ画面の中で何度も再計算・再描画が起きるようなアプリでは、この重さが響きやすくなります。
実例1：このサイトがAstroである理由
Dance with Agentsは、Astroで作られています。理由は単純で、このサイトの中身のほとんどが、静的なMarkdown記事だからです。読者が操作する場面は検索やタグの絞り込み程度で、ページのほとんどは一度書いたら変わらない文章です。こういうサイトでは、JavaScriptをほぼ配らずに済むAstroの設計思想がそのまま強みになります。詳しくはAstroとはにまとめました。
実例2（体験談）：Jyotish-ONEでNext/Nuxtを試して、遅くなった話
管理人が開発に関わっているJyotish-ONEは、インド占星術の計算・鑑定プラットフォームです。Vue 3・Vuex・Viteで組んだSPA（Single Page Application、画面全体を1つのアプリとしてブラウザ側で動かす構成）で、SVGベースのチャート（ラグナチャート、ナヴァムシャチャートなど）を、日付や惑星を切り替えるたびに再計算・再描画します。文章を読ませるサイトとは正反対の、常に画面が動き続けるタイプのツールです。
過去に、このアプリをNext・Nuxtへ移行しようと試したことがありますが、動きが遅くなりました。あらためて中身を見ると、原因はサーバー側レンダリング（SSR）そのものというより、ルーティングをはじめ、占星術のチャート描画には関わりのない周辺機能まで一緒に読み込まれるオーバーヘッドのほうが大きいと見ています。チャート描画は、日付や惑星を1つ変えるだけで数十〜数百ミリ秒の体感速度が問われる世界なので、この種の「本題と関係のない読み込み」がそのまま体感の遅さに直結します。2026年に次期バージョンの設計を検討したときも、あらためて「Next/Nuxt不採用は正解」という結論に至っています。
誤解のないように補足すると、これは「Next.js・Nuxtが遅い」という一般論ではありません。 どちらもクライアント側だけで完結する書き方を選ぶことはできます。ただ、メタフレームワークは既定でルーティングやSSRといった周辺機能をまとめて抱え込む作りになっている分、その画面の描画には直接関係のない部分まで、読み込みコストとして乗ってきます。 数十〜数百ミリ秒を削り合うような画面では、この余分な重みが響きやすい、というのが実際に試して得られた教訓です。
選ぶときの軸
2つの実例に共通する軸は1つです。「ページの大半が読みものか、それとも常に画面が動き続けるアプリか」。
- 読みもの寄りなら、Astroのようなコンテンツ特化型か、メタフレームワークを静的生成（SSG）寄りに使う構成が向きます
- 操作し続けるアプリ寄りなら、素のライブラリによるSPA、もしくはメタフレームワークをクライアント側レンダリング寄りに設定した構成が向きます
「流行っているから」ではなく「このアプリでは画面に何が起きているか」で選ぶと、遠回りが減ります。
この先の記事
各道具の中身は、それぞれの記事にまとめました。