React vs Vue [日本語] – VISASQ Dev Blog

Introduction

私は長年にわたりReactおよびNext.jsを用いた開発に従事してきましたが、最近、フロントエンド開発の大部分がVueで行われているVisasqに入社しました。
入社後、まずVue 2からVue 3への移行プロジェクトに携わり、現在はVue 3とNuxt 3（最近Nuxt 4へアップグレード）を用いたチームに所属しています。この一連の移行経験は、実際のプロジェクトを通じて両フレームワークを比較するよい機会となりました。

Reactの柔軟かつ自由度の高いエコシステムから、Vueのより構造化された環境へと移行したことで、開発体験における多くの発見がありました。また、この転換をきっかけとして、両ツールにおけるウェブの動作原理をより深く理解し、それぞれの根本的な設計思想や技術的差異を探究することができました。

本稿は「どちらが優れているか」を論じるものではなく、React／Next.jsからVue／Nuxtへの移行を通じて得られた実務的かつ技術的な差異を整理・考察するものです。

相違点：更新処理におけるレンダリングの仕組み

• React: Pull型（引き取り型）レンダリングモデル
• Vue: Push型（通知型）リアクティビティモデル

ReactとVueはいずれも仮想DOM（Virtual DOM）を用いていますが、DOMの更新手法においては明確な違いが存在します。
Reactは「Fiberアーキテクチャ」を採用しており、変更点を再調整（reconciliation）することで、影響を受けたサブツリーのみを再レンダリングします。不要な再レンダリングを抑制するために、useMemo、useCallback、およびReact.memoといったメモ化機構が利用され、これにより性能最適化が図られています。

一方でVueは、テンプレートを効率的なレンダリング関数（render function）にコンパイルし、リアクティブデータに依存する部分のみを選択的に更新します。つまり、Vueはコンポーネントツリー全体を比較することなく、変更の影響範囲を自動的に特定して局所的な再描画を行うということです。この仕組みにより、特に複雑なビュー構造や大量のデータを扱う場合でも再レンダリング回数が少なく、描画性能が高いという特長があります。

実際の運用においても、Vue 3で構築された大規模なデータグリッドやフォームを含むページは、同等のReact実装と比較してより滑らかで応答性の高い動作を示す傾向が見られました。

// React:
const [items, setItems] = useState([1,2,3]);
setItems([...items, 4]); // Must create an array

// Vue3 direct mutation:
const items = ref([1,2,3]);
items.value.push(4);

Reactにおいては、親コンポーネントの状態（state）の変更が子コンポーネントの再レンダリングを誘発することが多く、これを防ぐためにはReact.memoやuseMemo、useCallbackといったメモ化による明示的な最適化が不可欠です。言い換えれば、開発者が手動でレンダリングの境界を管理しなければ、不要な再描画が発生しやすい構造となっています。

一方、Vueではこの問題がフレームワーク内部のリアクティブシステムによって自然に処理される。依存関係の追跡と更新伝播が自動化されているため、特別な最適化を施さずとも、変更の影響を受ける箇所のみが効率的に再レンダリングされます。

特に、Vue 2からVue 3へのバージョンアップによるこのリアクティビティ機構の進化は顕著でした。Vue 2ではObject.definePropertyを用いたリアクティブ実装が採用されており、プロパティの追加や削除といった動的な変更を検知できないという制約が存在しました。

Composition APIとReact Hooksの比較

Vue 3におけるComposition APIは、ReactのHooksと概念的に類似していますが、その設計思想と挙動には明確な違いが存在します。本節では、両者の動作原理を本稿で扱った観点に基づいて比較し、その特徴を整理します。

ReactとVueは、コンポーネントの設計思想においても明確な対照を示しています。
Reactは、JSX（JavaScript XML）を全面的に採用しており、コンポーネントの構築・制御・描画をすべてJavaScriptの文脈の中で完結させます。このアプローチにより、開発者はJavaScriptの言語的柔軟性を最大限に活用することが可能となり、複雑な条件分岐やロジックを直接テンプレート内に統合できるようになっています。

// React:
return(
    

        {status === "loading" ? :
        status === "error" ? :
        items.length === 0 ? :
        }
    
)

// Vue - more verbose:

一方で、Vueのコンパイラは静的コンテンツをレンダリング関数の外部に移動し、イベントハンドラを自動的にキャッシュするなどの最適化を行うことができます。これにより、テンプレートベースでありながらも、高度に効率化された描画処理が実現されています。
しかし、JSXではこのような最適化は困難です。なぜなら、コンパイラは任意のJavaScriptコードに対して安全な仮定を置くことができず、静的・動的な要素を明確に区別できないためです。

それでも筆者個人としては、複雑な条件分岐を伴うレンダリングにおいてはJSXの方を好む傾向があります。入れ子構造の三項演算子や多段階の状態分岐などを扱う際、v-if や v-else-if を連鎖させるよりも、JavaScriptの自然な制御構文をそのまま利用できるJSXの方が記述が明快であると感じられるためです。

State管理

Reactにおける従来の状態管理の手法はReduxですが、筆者は現在Zustandを使用しています。その理由は、Reduxの冗長なアクション構文に比べて、Zustandの方がシンプルでボイラープレートが最小限であるためです。
Zustandは、プロバイダーを必要とせず、TypeScriptとの高い互換性を持ち、Reactコンポーネントの外でも動作し、優れた開発ツール統合を提供しています。
このような特性から、Zustandは筆者にとってデフォルトの選択肢となっています。

Vueにも同様の歩みが見られます。Vuexは初期のReduxのように、冗長なミューテーションやアクションを伴う構造でした。
一方、Vue 3で推奨される状態管理ライブラリであるPiniaは、よりシンプルな設計となっています。

クライアントとサーバーの状態を分離するために、筆者はTanStack Queryを使用しており、これによってデータフェッチに対する考え方が大きく変化しました。
筆者は、APIデータをZustandやRedux内で管理すべきではないと考えています。TanStack Queryはサーバー状態を管理し、Zustandはモーダル、フィルター、ユーザー設定などのUI状態を管理します。
TanStack QueryはVueでも動作し、同様の状態管理上の利点を提供するが、現時点ではプロジェクト内で導入はされていません。

TanStack Queryは複雑なサーバー状態の管理に優れているものの、現在のVue/Nuxtアーキテクチャでは、すでにクライアント状態とサーバー状態の間に明確で型安全かつ保守しやすい分離が実現されています。

• Pinia がアプリケーションおよびUIの状態を管理
• Nuxt がデータフェッチとSSRリアクティビティを担当
• VueUse がUIの振る舞いを補強

現行のスケールとアーキテクチャにおいては、この組み合わせがシンプルさ、柔軟性、制御性の最適なバランスを提供しており、追加のデータフェッチライブラリを導入する必要をなくしています。

Styleのアプローチ

両フレームワークは複数のスタイリング手法をサポートしているが、その設計と得意分野には明確な違いがあります。
Reactの開発者は一般的に、標準的なCSSを扱うCSS Modules、ランタイムコストを伴う動的スタイリングを可能にするCSS-in-JSライブラリ、ユーティリティクラスベースのTailwind CSS、あるいはTypeScript対応のゼロランタイムスタイルであるVanilla Extractなどから選択します。

一方、VueのSingle File Components（SFC）にはスコープ付きスタイル機能が組み込まれており、style ブロック内に通常のCSSを記述するだけで、そのスタイルが自動的にコンポーネント単位でスコープされます。
動的な値を扱う場合、Vue 3ではスタイル内でのv-bind()構文が導入され、リアクティブなJavaScriptの値をCSSカスタムプロパティ（変数）として直接バインドできるようになりました。これにより、ランタイムでスタイルを生成する必要がなく、CSS-in-JSのコストを伴わない高いパフォーマンスを実現しています。
この仕組みは、スタイルを実行時に生成するStyled Componentsよりも効率的であり、CSS変数としてコンパイルされる点においてより優れた実行性能を発揮する。

副作用とライフサイクル

Reactでは、useEffectがあらゆる用途に多用されています。
データフェッチ、イベントリスナーの登録、ドキュメントタイトルの更新、サブスクリプション管理など、多様な副作用処理がすべてuseEffectに集約されています。

function UserProfile({userId}) {
    const [user, setUser] = useState(null);

    // Data fetching
    useEffect(() => {
        const handler = () => console.log('resize');
        window.addEventListener('resize', handler);
        return () => window.removeEventListener('resize', handler);
    },[])

    // Document title
    useEffect(() => {
        document.title = user?.name || 'Loading...';
    }, [user]);

    return 
{user?.name}
}

この設計は、依存配列やクリーンアップ関数、そして副作用が実行されるタイミングの理解において課題を生じます。
依存配列はバグの温床となりやすく、依存関係の記載漏れは古いクロージャ（stale closure）を引き起こし、逆にオブジェクトや関数を依存関係に含めると無限ループを発生させる原因となります。
そのため、筆者が新たにNext.jsプロジェクトを構築する際には、useEffectの代替としてTanStack Queryを標準的な選択肢として採用しています。

一方、Vue 3のComposition APIは、より明確な意図を示すための専用のライフサイクルフックを備えています。

主要な利点は、依存配列が不要であるという点にあります。
Vueのリアクティビティシステムは、使用されている値を自動的に追跡するため、Reactで頻発する古いクロージャや依存関係の記載漏れによるバグが発生しません。

また、実行タイミングにも違いがあります。VueのwatchEffectは、デフォルトでマウント時に同期的に実行されるのに対し、ReactのuseEffectは描画後（after paint）に実行されます。

Next.jsは、App Routerの導入によって大きく進化しました。
新たに導入されたServer Componentsにより、デフォルトの動作はサーバーサイドレンダリングとなり、非インタラクティブな部分にはJavaScriptが一切含まれない構成が可能となり、インタラクティブなコンポーネントを使用する場合には、’use client’を明示的に指定することで、Next.jsが自動的にコード分割と必要部分のみのハイドレーションを実行します。

Nuxt 3は、デフォルトでユニバーサルレンダリングを採用しており、同一のコードがサーバーとクライアントの双方で実行されます。
useFetchは、サーバーからクライアントへの状態転送を自動的に処理し、データフェッチにおける一貫性を保ちます。
さらに、Nuxtのルートルールを利用することで、ルートごとに異なるレンダリング戦略を柔軟に設定することが可能です。
また、両フレームワークはいずれもメタタグ管理を内包しており、SEO対策において高い水準を維持しています。

ビルドシステムとパフォーマンス

ビルドツールの環境は、現在では両フレームワークともViteを中心に統一されつつあります。
ReactはかつてCreate React Appとwebpackに依存してましたが、現在それらは非推奨となっています。Viteは、即時のサーバー起動、高速なホットモジュールリプレースメント（HMR）、迅速な本番ビルドを提供します。
一方、Next.jsは独自のビルドシステムを持ち、従来はwebpackを使用していたが、現在はより高速なビルドを実現するためにTurbopackへの移行が進められています。
Vueは公式にViteを採用しており、開発者に対して一貫した効率的な開発体験を提供しています。

バンドルサイズの観点では、VueはReactよりもはるかに小さく、特にコンテンツ量の多いサイトでは体感できる差が生じることがあります。しかし、大規模なアプリケーションにおいては、フレームワーク自体のサイズは全体のコード量に比べて相対的に小さい傾向にあります。

両エコシステムはツリーシェイキングおよびコードスプリッティングをサポートしており、ユーザーは現在表示しているページに必要なコードのみをダウンロードします。
また、Next.jsとNuxtはこれらの最適化を自動的に処理するため、パフォーマンスチューニングがフレームワークの設計段階から組み込まれています。

Next.js 15 と Nuxt 3 の比較

Next.jsは、Reactを基盤とした柔軟なフレームワークであり、SPA（シングルページアプリケーション）、静的サイト、およびサーバーサイドレンダリングアプリケーションの構築をすべてサポートしています。
App Routerは、ページ、レイアウト、ローディング状態を統合的に管理し、Server Componentsによってクライアント側のJavaScriptの量を削減します。

一方、NuxtはVueにおけるフルスタックフレームワークであり、「設定より規約（convention over configuration）」の原則に基づいて設計されています。
ユニバーサルレンダリング、自動インポート、および明確なフォルダ構造を備えており、最小限の設定で整理されたコードベースを維持できます。

両者とも、認証やリダイレクトを処理するためのミドルウェアをサポートしています。
Next.jsはサーバーコンポーネントとクライアントコンポーネントの間でデータフェッチを明確に分離しているのに対し、NuxtのuseFetchはサーバーとクライアントの双方でシームレスに動作します。

デプロイメントに関しては、NuxtのNitroエンジンが複数のプラットフォームを標準でサポートしているのに対し、Next.jsはVercel向けに最適化されつつも、他の環境への適応も可能です。

Vitestによるテスト

Vitestは、Viteを使用するReactおよびVueプロジェクトにおける標準的なテストランナーとして広く定着しています。
Jestとの互換性を保ちながらも、Viteの変換パイプラインを活用することで劇的に高速に動作する点が特徴です。

Reactにおいては、VitestをTesting Libraryと組み合わせて使用し、VueではVue Test Utilsが用いられます。

その性能差は顕著であり、たとえば、500件のテストを含むスイートでは、Jestでは15〜20秒を要するのに対し、Vitestではわずか3〜5秒で完了します。
さらにウォッチモードでは、影響を受けたテストのみを再実行し、1秒未満で反応するほぼ即時のフィードバックが得られます。

長所と短所

結論

Reactでの数年間の経験と、最近のVueでの集中的な開発を通じて、筆者は両フレームワークがそれぞれ異なる形で卓越した能力を持つ優れたツールであることを学びました。
リアクティビティと再レンダリングという根本的な違いは単なる技術的差異にとどまらず、更新の捉え方そのものに影響を与える概念的な転換です。

本調査で、筆者の視点は「Reactこそ唯一の方法だ」という考えから、両フレームワークの価値を相互に認める立場へと変わりました。
本質的に重要なのは、ReactかVueかという比較ではなく、ユーザーに優れた体験を提供することであり、両フレームワークはいずれも、適切に用いればその目的を十分に達成することができます。

ビザスクではエンジニアの仲間を募集しています！
少しでもビザスク開発組織にご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
recruit.visasq.co.jp