v3.x のドキュメントを見たい場合はこちら

ガイド

v2.x 以前のドキュメントです。 v3.x のドキュメントを見たい場合はこちら

他のフレームワークとの比較

最終更新日: 2020年11月7日

これは確かにガイドの中では最も書くことが難しいページですが、私たちはこれが重要だと感じています。きっと、あなたは解決したい問題を抱えていて、その問題を解決するために他のライブラリを使ったことがあるでしょう。あなたがこのページを読んでいるのは Vue があなた特有の問題をよりよく解決することができるかどうかを知りたいからでしょう。それは私たちがあなたに答えを示したいことです。

また、私たちは偏見を避けるために多くの努力を費やしています。Vue のコアチームですので、私たちは明らかに Vue がとても好きです。私たちはいくつかの問題については Vue が世の中に存在する他のものよりもより良く解決すると考えています。もし私達がそれを信じることができなかったら、Vue のために作業をすることはなかったでしょう。しかし、私たちは公平で間違いのないようにしたいと考えています。React の代替レンダラの巨大なエコシステムや Knockout の IE6 からのブラウザサポートのように、他のライブラリが著しく優れていると示される部分に関して、私たちはそれらをできる限り載せるようにしています。

さらに、私たちはあなたがこのドキュメントを最新の情報に保っていただけることを望みます。なぜなら、JavaScript の世界は速く動いているからです！もし、あなたが正確ではない部分や、あまり正しくないように見える部分に気がついたら、Issue を開いて教えてください。

React

React と Vue には多くの類似点があります。それらは両方とも：

スコープがとてもよく似ているため、この比較の改善に他よりも多くの時間をかけています。私たちは技術的な正確さだけでなく、バランスも保証したいと考えています。例えば、React のエコシステムの豊かさや、カスタムレンダラの豊富さのように、私たちは React が Vue よりも優れている点を示します。

とはいえ、多くの調査項目はある程度主観によってしまうため、React ユーザーにとってはどうしても Vue をひいきしているように見えてしまうかもしれません。様々な技術的な嗜好があることは認識したうえで、その嗜好が私たちのものと運良く一致している場合に、Vue がおそらくより適切となる理由について概説することがこの比較の第一のねらいです。

続くセクションのいくつかでは React バージョン 16 以上に対して行われた更新により若干古くなった内容を含む可能性が有り、私たちは React コミュニティと共に作業を進めてこのセクションを近い将来刷新する予定です。

実行時性能

React と Vue の両方は、どちらも非常に早いので、速度はどちらを選ぶかの決定要因になりそうにありません。ですが、具体的なメトリクスについては、このサードパーティのベンチマークを確認してください。これは、シンプルなコンポーネントツリーでの生のレンダリング / 更新のパフォーマンスに重点をおいています。

最適化の取り組み

React では、コンポーネントの状態が変化するとき、そのコンポーネントをルートとして、コンポーネントのサブツリー全体を再描画します。不要な子コンポーネントの再レンダリングを避けるには、できるだけいつでも PureComponent を使うか、shouldComponentUpdate を実装する必要があります。また、不変 (immutable) なデータ構造を使用して、状態の変更をより最適化しやすくする必要があるかもしれません。しかしながら、PureComponent / shouldComponentUpdate は、サブツリーの描画出力全体が現在のコンポーネントのプロパティによって決定されると仮定しているため、そのような最適化に頼ることができない場合もあります。そうでない場合、そのような最適化は DOM の状態が不一致になる可能性があります。

Vue では、コンポーネントの依存関係が描画中に自動的に追跡されるため、システムは状態が変化したときに実際にどのコンポーネントを再描画する必要があるか正確に認識します。各コンポーネントは、自動的に shouldComponentUpdate が実装されていると見なすことができ、ネストされたコンポーネントに注意する必要はありません。

概して、これによって開発者は性能最適化全般を行う必要がなくなり、スケールアップに際していっそうアプリケーションの構築そのものに注力できるようになります。

HTML & CSS

React では、すべてのものは単なる JavaScript です。HTML 構造が JSX で表現されているだけでなく、最近の傾向は CSS 管理も JavaScript 内に置く傾向があります。このアプローチには利点もありますが、必ずしもすべての開発者にとって価値があるわけではないさまざまなトレードオフもあります。

Vue は古典的な Web 技術を取り入れ、その上に成り立っています。その意味を示すために、いくつかの例を取り上げます。

JSX vs Templates

React では、すべてのコンポーネントは JSX を用いた 描画関数 (render) の中でそれらの UI を表現します。JSX とは JavaScript の中で用いることのできる、宣言的で XML のような構文です。

JSX を伴う 描画関数にはいくつかの優位な点があります：

Vue は、描画関数と、さらに JSX のサポートを備えています、なぜなら、あなたは時折その力を必要とするためです。しかしながら、デフォルトのエクスペリエンスとして、より単純な代替手段としてテンプレートを提供しています。すべての有効な HTML は有効な Vue テンプレートでもあり、このこと自体がいくつかの利点をもたらします。

テンプレートを書くために別途 DSL (Domain-Specific Language) を覚えなければならないと主張する人もいますが、私たちはこの違いはせいぜい皮相的なものに過ぎないと信じています。第一に、JSX はユーザーが何も覚える必要が無いということを意味しません。JSX はプレーンな JavaScript に基づく拡張構文なので、JavaScript に慣れている人なら簡単に覚えられるかもしれませんが、基本的に学習コストがかからないと言うと語弊があります。同じように、テンプレートはまさにプレーンな HTML に基づく拡張構文なので、すでに HTML に慣れている人なら学習コストは非常に軽いです。DSL は、より少ないコード(例: v-on 修飾子) でより多くのことを成し遂げることもできます。プレーンな JSX や描画関数では、同じタスクのためにより多くのコードが必要になるかもしれません。

より高いレベルでは、コンポーネントをプレゼンテーション用と論理用の 2 つのカテゴリに分けることができます。私たちは、プレゼンテーション用のコンポーネントにはテンプレートを使用し、論理用のものには描画関数 / JSX を使用することをお勧めします。これらのコンポーネントの割合は、作成しているアプリケーションのタイプによって異なりますが、一般的にプレゼンテーション用のものの方がはるかに多く見られます。

コンポーネントスコープ CSS（Scoped CSS）

あなたがコンポーネントを複数のファイルに分けない限り（例えば、CSS モジュールを使うなど）、React で CSS のスコープを限定するときには CSS-in-JS ソリューション (例えば styled-components 、 emotion) 経由でしばしば行われます。これは通常の CSS 作成プロセスとは異なる新しいコンポーネント志向のスタイルパラダイムを導入します。加えて、これらにはビルド時に単一のスタイルシートに CSS を抽出するためのサポートがありますが、スタイルが正しく機能するためにはランタイムをバンドルに含める必要があることがいまだ一般的です。スタイルを構成する際に Javascript のダイナミズムにアクセスできる一方で、トレードオフは多くの場合バンドルサイズとランタイムのコストが増加することです。

もしあなたが CSS-in-JS のファンなら、著名な CSS-in-JS ライブラリの多くは Vue をサポートしています (例えば styled-components-vue や vue-emotion)。ここでの React と Vue の主な違いは、 Vue でのスタイリングのデフォルトの方法は 単一ファイルコンポーネント でのより身近な style タグによるものだということです。

単一ファイルコンポーネント では、 その他のコンポーネントコードと同じファイル内で CSS にフルアクセスできます。

<style scoped>
  @media (min-width: 250px) {
    .list-container:hover {
      background: orange;
    }
  }
</style>

任意に付与できる scoped 属性は、要素に一意な属性（data-v-21e5b78 のようなもの）を付与し、.list-container:hover を .list-container[data-v-21e5b78]:hover のようなものにコンパイルすることで、この CSS のスコープをあなたのコンポーネントに限定します。

最後に、 Vue の単一ファイルコンポーネントのスタイリングは非常に柔軟です。 vue-loader 経由で、どのようなプリプロセッサ、ポストプロセッサ、そして CSS Modules との深い統合でさえも使うことができます – すべてが <style> 要素内で。

規模

スケールアップ

大きなアプリケーションのために、Vue も React も強力なルーティングの解法を提供しています。React コミュニティは状態管理という観点でとても革新的な解法を持っています（例えば、Flux/Redux）。これらの状態管理のパターンと、さらに Redux 自体は簡単に Vue のアプリケーションと統合することができます。実際に、Vue はこのモデルをさらに一歩進めた Vuex という、Vue と深く統合されている Elm に触発された状態管理の解法をもっており、私たちはそれがより優れた開発体験をもたらすと考えています。

これらの間にあるもう 1 つの重要な違いは、Vue における状態管理やルーティング（やその他の関心事）のための関連ライブラリはすべて公式にサポートされていて、コアのライブラリとともに更新され続けているということです。React はそのような関心事はコミュニティにまかせており、より断片的なエコシステムを作り上げています。それはより大衆的ではありますが、React のエコシステムは Vue のそれを大きく上回って豊かです。

最後に、Vue は CLI によるプロジェクト生成ツールを提供しており、対話形式のプロジェクト構築ウィザードによって新しいプロジェクトを簡単に始めることができます。コンポーネントの高速なプロトタイピングにも使うことができます。React にも create-react-app があり、この分野で進歩を遂げていますが現状でいくつかの制限があります。

しかしながら、これらの制限は create-react-app のチームによって意図された設計上の決定で、それによる優位性も確かにあります。例えば、あなたのプロジェクトの要件がとても単純で、ビルドプロセスをカスタマイズするために”取り出し”する必要がまったく無いのなら、あなたはそれを 1 つの依存性として更新することができるでしょう。あなたはこの哲学の違いをここでより詳しく読むことができます。

スケールダウン

React はその急な学習曲線で有名です。あなたが本当に始めることができるようになるまでに、JSX とおそらく ES2015+ について知る必要があります。なぜなら多くのコード例が React の class 構文を使っているからです。あなたはさらにビルドシステムについて学ぶ必要があります。なぜなら、技術的には Babel Standalone を使ってコードをブラウザでその場でコンパイルすることは可能ですが、プロダクション環境では絶対に適していません。

React と同じように Vue は規模を大きくできますし、一方で、jQuery のように規模を小さくすることもできます。そうです - 使い始めるにあたって、あなたはページの中に 1 つの script タグを放り込むだけで良いのです：

<script src="https://cdn.jsdelivr.net/npm/vue@2"></script>

これであなたは Vue のコードを書き始めることができますし、後ろめたい思いをしたり性能問題について心配したりすることなく、ミニファイ（minify）版をプロダクション環境へ設置することもできます。

あなたは Vue を始めるにあたって JSX、ES2015 やビルドシステムについて知る必要はないので、複雑なアプリケーションをビルドするための十分な学習をするためにガイドを読むのにはたいてい一日もかからないでしょう。

ネイティブレンダリング

React Native によって同じ React コンポーネントモデルを使って iOS や Android のためのネイティブ描画を行うアプリケーションを書くことができます。これは開発者にとっては素晴らしいことで、あなたは 1 つのフレームワークの知識を複数のプラットフォームをまたいで適用することができます。この点において Vue は、Weex と公式に協業しています。Weex はアリババグループによって作られたクロスプラットフォームな UI フレームワークで、Apache ソフトウェア財団(ASF)によって支援されています。Weex はブラウザの描画だけではなく、iOS や Android のネイティブ描画を行うことのできるコンポーネントを書くために同じ Vue コンポーネントの構文を使うことを可能にします！

今の段階では、Weex はまだ活発に開発が続いており、React Native ほど熟しておらず、実際に使われているわけではありませんが、その開発は世界で最も大きな e コマースの製品要件に基づいており、そして Vue のチームは Vue の開発者のための円滑な体験を保証するために Weex のチームと活発に協業するつもりです。

もう 1 つの選択肢は、NativeScript-Vue です。これは、Vue.js を用いて完全なネイティブアプリケーションを構築するための NativeScript プラグインです。

MobX と用いた場合

MobX は React コミュニティ内でとても人気になってきており、実はそれは Vue のリアクティブシステムとほぼ同じものを使っています。限られた範囲内では、React + MobX の流れはより冗長な Vue として考えることができるので、もしあなたがその組み合わせを使って、それを楽しんでいるのならば、Vue を使ってみるのは、おそらく次のステップとして理にかなっているでしょう。

Preact とその他の React 系ライブラリ

React 系のライブラリはたいてい、API とエコシステムの多くをなるべく React と共有しようとします。そのため、上に挙げた比較の大部分はそれらのライブラリにも当てはまります。主な違いは、まず React と比べてエコシステムの規模が（しばしばかなり）小さいことです。これらのライブラリが React のエコシステムのすべてと 100 パーセントの互換性を持つことは無いはずですから、いくつかのツールや関連ライブラリは使用できないかもしれません。あるいは、うまく動いているように見えたとしても、その React 系ライブラリが React と同等に公式にサポートされていない限りは、いつ壊れないとも限りません。

AngularJS (Angular 1)

いくつかの Vue の構文は AngularJS と非常に良く似ているように見えることでしょう（例えば、v-if と ng-if）。これは AngularJS が解決した多くのものがあるのと、最初期の Vue の開発の際にインスピレーションを受けているためです。しかしながら、AngularJS から導入された多くの痛みもあり、それらは Vue が大きな改善を提供しようと試みた点でもあります。

複雑性

API と設計の両方の観点から、Vue は AngularJS と比較してとても単純です。複雑なアプリケーションを構築するために十分学ぶのには大抵 1 日もかからないでしょう。これは AngularJS には当てはまらない点です。

柔軟性とモジュール性

AngularJS にはあなたのアプリケーションがどのような構成になるべきかという点について強い思想が反映されていますが、対して Vue はより柔軟で、モジュール組み立て式な解決を図っています。このことが Vue を広い種類のプロジェクトにより適合可能にしている一方で、私たちは、時にはただコーディングを始められるように決めごとを作ることも有用だということも認識しています。

私たちが高速な Vue.js の開発に必要な完全なシステムを提供するのはこのためです。Vue CLI は、Vue エコシステムのための標準ツールのベースラインとなることを目的にしています。これにより、様々なビルドツールはよく選ばれたデフォルト値でスムーズに動作し、設定に何時間も費やす代わりに、自分のアプリケーションを書くことに注力できるようになっています。それと同時に、特定の用途に合わせて各ツールの設定を微調整できる柔軟性も残しています。

データバインディング

AngularJS がスコープ間による双方向バインディングを使用している一方で、Vue はコンポーネント間では一方向のデータフローを行うようになっています。これは小さくないアプリケーションにおいてデータの流れを推測することをより簡単にします。

ディレクティブ vs コンポーネント

Vue はディレクティブとコンポーネントの間に明確な線引きをしています。ディレクティブは DOM の操作のみをカプセル化するように意図されている一方で、コンポーネントは自身のビューとデータロジックを持つ独立した構成単位です。AngularJS では、ディレクティブは全てを行い、コンポーネントはただの特定の種類のディレクティブに過ぎません。

実行時性能

Vue は Dirty Checking を使用していないため、より良い性能を発揮し、さらに、もっともっと簡単に最適化できます。AngularJS はスコープ内の何かが変更されると、毎回すべてのウォッチャがもう一度再評価される必要があるため、たくさんのウォッチャが存在する時は遅くなってしまいます。さらに、ダイジェストサイクルは、もしいくつかのウォッチャが追加の更新をトリガしたら、”安定”のために複数回の実行が必要となる場合もあります。Angular のユーザーはダイジェストサイクルを回避するために難解なテクニックによく頼る必要がありますし、いくつかの状況では、多くのウォッチャが存在する状況でスコープを最適化する単純な方法がない場合もあります。

Vue では、非同期キューイングを用いた透過的な依存追跡監視システムを使用しているため、このことで苦しむことはまったくありません。すべての変更は明示的な依存関係を持たない限り独立してトリガされます。

興味深いことに、これらの AngularJS の問題点に Angular と Vue がどのように対処しているかという点について、いくつかとてもよく似ている点があります。

Angular (以前は Angular 2 として知られる)

Angular は本当に AngularJS から完全に異なるフレームワークなので、私たちは新しい Angular のために分割した節を設けています。例えば、それは第一級のコンポーネントシステムを特徴として持っており、多くの詳細な実装は完全に書き換えられており、そして、API もまた抜本的に変更されています。

TypeScript

ほとんどすべてのドキュメントと学習リソースが TypeScript ベースのため、Angular は本質的に TypeScript を使用する必要があります。TypeScript には明らかなメリットがあります。静的型チェックは大規模アプリケーションには非常に便利で、Java や C# を使用している開発者にとっては生産性を大幅に向上させることができます。

しかし、誰もが TypeScript を使いたいとは限りません。多くの小規模なユースケースでは、型システムを導入すると生産性の向上よりもオーバーヘッドが発生する可能性があります。そのような場合は、Vue を使うよりも、TypeScript を使わないで Angular を使うのが難しいかもしれないので、あなたは Vue を使うほうが良いでしょう。

最後に、Vue は Angular のように TypeScript と深くは統合されていませんが、Vue で TypeScript を使用したいと望む人に対して、Vue も公式の typingsと公式 decorator を提供します。また、私たちは Vue + TS ユーザーの TS / IDE エクスペリエンスを改善するために、Microsoft の TypeScript および VSCode チームと積極的に協力しています。

実行時性能

両方のフレームワークは非常に高速で、ベンチマークでも似たようなメトリクスがあります。より詳細な比較のために、具体的なメトリクスを参照することもできますが、速度は決定要因にはなりそうにありません。

サイズ

Angular の最近のバージョンは、AOT コンパイルと tree-shaking によって、サイズを大幅に縮小することができました。しかしながら、Vuex + Vue Router (gzip 済みで 〜 30 KB) を含むフル機能の Vue 2 プロジェクトは、初期状態のangular-cli製の AOT コンパイル済みアプリケーション (gzip 済みで 〜 65 KB) よりもかなり軽量です。

柔軟性

Vue は Angular よりもずっとあなたのやり方には口出しすることはありません（less opinionated）、様々なビルドシステムのための公式サポートを提供していますし、あなたがあなたのアプリケーションをどのように構成するかについては制限していません。どんなアプリケーションを作るのにもたった 1 つの正しいやり方を持つことを好む開発者がいる一方で、多くの開発者はこの自由を楽しんでいます。

学習曲線

Vue を始めるために、あなたは HTML と ES5 JavaScript（つまり、プレーンな JavaScript）をよく知るだけで良いです。これらの基本的なスキルがあれば、ガイドを読むのに一日もかからずに複雑なアプリケーションの構築を始めることができます。

Angular の学習曲線はもっと急です。フレームワークの API は巨大で、ユーザーは生産性を獲得する前により多くの概念に慣れておく必要があります。明らかに、Angular の複雑さは、大規模で複雑なアプリケーションのみを対象とするという設計目標に大きく起因していますが、そのことが経験の浅い開発者がこのフレームワークを選び取ることをはるかに難しくしています。

Ember

Ember はフル機能のフレームワークでとても強い思想（highly opinionated）の下で設計されています。それはすでに用意されたたくさんのやり方を提供しており、あなたがそれらを十分使いこなせれば、高い生産性を発揮できることでしょう。しかしながら、それは学習曲線が高く、柔軟性に乏しいことも意味しています。強い思想を持つフレームワークと、ゆるやかに結びついて協働するツール群を用いるライブラリのどちらを選ぶかはトレードオフです。後者はあなたにより多くの自由を与えますが、あなたはアーキテクチャ上の決定をより多くする必要もあります。

ですので、Vue のコアと Ember のテンプレートとオブジェクトモデルレイヤーを比較することは比較をより良いものにすることでしょう：

Knockout

Knockout は MVVM と依存追跡の分野における先駆者で、そのリアクティブシステムは Vue のものととてもよく似ています。ブラウザサポートもその対応のすべてを思うと非常にすばらしく、IE6 までサポートしています！Vue は一方で、IE9 以上のみをサポートしています。

しかしながら、時間とともに Knockout の開発は遅くなっており、少々古さを見せ始めています。例えば、そのコンポーネントシステムはライフサイクルフックの一式が欠けており、とてもよくあるユースケースにもかかわらず、コンポーネントへ子要素を渡すためのインタフェースは Vue のものと比較して少々ぎこちないものに感じられます。

さらに、API デザインにも哲学的な違いがあるようにも思えます。興味があれば、それぞれが単純な TODO リストの作成をどのように扱うのかを見ればわかるかもしれません。これは確かに少々主観的ですが、多くの人は Vue の API はより複雑でなく、よく構造化されていると考えています。

Polymer

Polymer は Google がスポンサーをしているもう 1 つのプロジェクトで、その上実は Vue がインスピレーションを受けていたものでした。Vue のコンポーネントは Polymer の Custom Elements と緩く比較することができ、さらに両方ともとてもよく似た開発スタイルを提供しています。最も大きな違いは Polymer が最新の Web Component の機能を基に構築されており、ネイティブでこれらの機能をサポートしていないブラウザ上で（より劣った性能で）動かすためには小さくない Polyfill を必要とする点です。それと比較して、Vue は IE9 まで依存や Polyfill 無しで動きます。

Polymer では、その開発チームは性能を補うためにデータバインディングシステムもかなり制限しました。例えば、Polymer のテンプレートは真偽値の反転と単一のメソッド呼び出しの構文のみしかサポートされていません。その算出プロパティの実装についてもあまり柔軟ではありません。

Riot

Riot 3.0 はよく似たコンポーネントベースの開発モデル（”タグ”と Riot では呼ばれています）を提供しており、必要最小限の美しく設計された API を持っています。Riot と Vue はおそらくその設計哲学の多くが共通しているのでしょう。しかしながら、Riot よりも少し重いにも関わらず、Vue はいくつか著しく優れた点を持っています：

← Vuex 0.6.x から 1.0 への移行 Vue.js コミュニティへ参加しましょう! →
間違いを見つけた、またはドキュメントに貢献したいですか？ GitHub で編集しましょう！ このサイトは Netlify でホストされています。