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

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

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

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

React

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

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

ですので、調査対象の多くはある程度主観的なため、ある React ユーザーには、比較が Vue に偏っているようにみえるのはそれは必然です。私たちは様々な技術的な好みが存在することを認め、そしてあなたの好みが私たちのものと一致する場合は、Vue は潜在的によりフィットする可能性があるため、この比較は主に理由を概説することを目的としています。

React のコミュニティは、私たちがこのバランスを達成するのを手助けしてくださいました。React チームの Dan Abramov 氏には心から感謝いたします。彼にはとても寛容に時間を費やしていただき、私たちがお互いに最終結果に満足するまでこのドキュメントを改善するための数多くの助言をいただきました。

性能

React と Vue の両方は、最もよく見られるケースでは同等の性能を提供しますが、軽量の Virtual DOM 実装によって一般には 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 は、ユーザーが何も学ぶ必要がないという意味ではありません。単純な JavaScript の上に追加構文があるので、JavaScript に慣れている人にとっては簡単に学ぶことができますが、本質的に自由だと言っているのは誤解を招くものです。同様に、テンプレートはプレーンな HTML の上に追加された構文なので、すでに HTML を精通している人にとっては学習コストが非常に低くなります。DSL を使用することで、より少ないコード(例: v-on 修飾子) でより多くの作業を行うこともできます。プレーンな JSX や描画関数を使用する場合、同じタスクはもっと多くのコードを含めることができます。

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

コンポーネントスコープ CSS(Scoped CSS)

あなたがコンポーネントを複数のファイルに分けない限り(例えば、CSS モジュールを使うなど)、React で CSS のスコープを限定するときには CSS-in-JS ソリューション経由でしばし行われます。そこには競合するソリューションが多数あり、それぞれ独自に注意事項があります。

共通の問題は、hover 状態、メディアクエリや、疑似セレクタのようなより複雑な機能はすべて、CSS がすでに行っていることを再発明するために多くの依存を必要とするか、またはそれらは単にサポートされていません。 CSS-in-JS では慎重に最適化されていないと、実行時の性能にはほとんど影響を与えません。最も重要なのは、通常の CSS を作成した経験から逸脱していることです。

その一方で Vue は、単一ファイルコンポーネントの中で 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 のスコープをあなたのコンポーネントに限定します。

すでに CSS モジュールに精通している場合、Vue の単一ファイルコンポーネントにはファーストクラスのサポートもあります。

最後に、ちょうど HTML のように、あなたには任意の好きなプリプロセッサ(または、ポストプロセッサ)を使って CSS を書くという選択肢、それらのエコシステムの既存のライブラリを活用できます。あなたがビルドサイズやアプリケーションの複雑さの増加を引き起こす特殊なライブラリをインポートするのではなく、ビルド時に色の操作を行うようなデザイン中心の運用を行う事ができるようにしています。

規模

スケールアップ

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

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

最後に、Vue は CLI によるプロジェクト生成ツールを提供しており、それによってあなたは好きなビルドシステムを使った新しいプロジェクトをとても簡単に始めることができます。ビルドシステムには、webpackBrowserify、さらにビルドシステム無しなどがあります。React も create-react-app でこの領域に取り組んでいますが、現在いくつかの制限があります:

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

スケールダウン

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

React ほどではないかもしれませんが、Vue は単にうまく規模を大きくできますし、一方で、jQuery のように規模を小さくすることもできます。そうです - あなたはページの中に 1 つの script タグを放り込むだけで良いのです:

<script src="https://unpkg.com/vue/dist/vue.js"></script>

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

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

ネイティブレンダリング

React Native によって同じ React コンポーネントモデルを使って iOS や Android のためのネイティブ描画を行うアプリを書くことができます。これは開発者にとっては素晴らしいことで、あなたは複数のプラットフォームをまたいであなたのフレームワークの知識を適用することができます。この点において Vue は、アリババグループによって開発されていて、JavaScript フレームワークのランタイムとして Vue が用いられている、クロスプラットフォームな UI フレームワークの Weex と公式に協業しています。これが意味するのは、Weex とともに用いることにより、あなたは同じ Vue コンポーネントの構文で、ブラウザの描画だけではなく、iOS や Android のネイティブ描画を行うことのできるコンポーネントを作れるということです!

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

MobX と用いた場合

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

AngularJS (Angular 1)

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

複雑性

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

柔軟性とモジュール性

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

これは私たちが、1 分以内にセットアップ可能で、さらに、Hot Module Reload、Lint、CSS 抽出などといった高度な機能を使用可能にする、webpack のテンプレートを提供している理由になります。

データバインディング

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 チームと積極的に協力しています。

サイズと性能

性能面では、2 つのフレームワークは非常に速く、判決するための現実世界のユースケースでの十分なデータはありません。しかしながら、もしあなたがいくつかの数字を見ることを決意したのなら、このサードパーティのベンチマークから Vue 2.0 は Angular よりも優位なようです。

Angular の最近のバージョンは、AOT コンパイルと tree-shaking によって、サイズを大幅に縮小することができました。しかしながら、Vuex + vue-router (〜 30 kb gzipped) を含むフル機能の Vue 2 プロジェクトは、angular-cli (〜 130 kb gzipped) によって生成された独創的な AOT コンパイルされたアプリケーションよりもかなり軽量です。

柔軟性

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

Polymer の Custom Elements は HTML ファイルの中に書くことになりますが、これはつまり、あなたはプレーンな JavaScript/CSS(と現在のブラウザによってサポートされている言語機能)しか書けないということです。それと比べて、Vue の単一ファイルコンポーネントでは、あなたが欲する ES2015+ や任意の CSS プリプロセッサを簡単に使うことができます。

プロダクション環境にデプロイする時、Polymer はすべてを HTML Imports によってその場で読み込むことを推奨しています、これはブラウザがその仕様を実装していることと、サーバーとクライアントの両方の HTTP/2 サポートを前提としています。これはあなたが対象としているユーザやデプロイ環境によっては適しているかもしれないし、そうではないかもしれません。これが適していない場合は、あなたは Polymer の要素をバンドルするために Vulcanizer と呼ばれる特別なツールを使う必要があるでしょう。この面では、Vue は遅延読み込みのためにアプリケーションバンドルの一部を簡単に分割することを目的として、webpack のコード分割機能を使い、非同期コンポーネントの機能を統合することができます。これはアプリのすばらしい読み込み性能を維持しつつ、古いブラウザとの互換性を保証しています。

さらに、Vue と、Custom Elements や Shadow DOM のスタイルカプセル化のような Web Component 仕様の深い統合を提供することは全体的に適しています - しかしながら今の段階では、私たちは本格的にコミットする前に、その仕様が熟し、すべての主要なブラウザ上に広く実装されるのをまだ待っています。

Riot

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