<commit_before>---
title: 他のフレームワークとの比較
type: guide
order: 28
---

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

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

さらに、私たちは**あなた**がこのドキュメントを最新の情報に保っていただけることを望みます。なぜなら、JavaScript の世界は速く動いているからです！もし、あなたが正確ではない部分や、あまり正しくないように見える部分に気がついたら、[Issue を開いて](https://github.com/vuejs/vuejs.org/issues/new?title=Inaccuracy+in+comparisons+guide)教えてください。

## React

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

- 仮想 DOM を活用しています
- リアクティブで組み合わせ可能なビューのコンポーネントを提供しています
- コアライブラリに焦点をあわせることに努めており、ルーティングやグローバルの状態管理のような関心事は関連ライブラリに担当させています

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

React のコミュニティは、私たちがこのバランスを達成するのを[手助けしてくださいました](https://github.com/vuejs/vuejs.org/issues/364)。React チームの <NAME> 氏には心から感謝いたします。彼にはとても寛容に時間を費やしていただき、私たちが[お互いに最終結果に満足するまで](https://github.com/vuejs/vuejs.org/issues/364#issuecomment-244575740)このドキュメントを改善するための数多くの助言をいただきました。

ですので、下記で私たちがこれらの 2 つのライブラリの違いを探求したように、あなたが確かに公平な考察だと感じることができるのを願います。

### パフォーマンスの分析

私たちがこれまでにテストした現実世界と同様のシナリオのすべてにおいて、Vue は React よりもかなり優れたパフォーマンスを発揮しました。あなたが直ちに驚きたい場合は、ぜひ読んでください。私たちは (React チームと協力して開発されたベンチマークも含めて) ブレークダウンしています。

#### 描画のパフォーマンス

UI をレンダリングする時、DOM 操作は通常最も高いコストのかかる操作になり、また、残念ながら、そういった低レベルの操作をより速くするライブラリは存在しません。私たちができる最良の方法は：

1. 必要な DOM 操作の回数を最小にします。React と Vue は両者ともこれを果たすために仮想 DOM による抽象化を用いており、どちらの実装もほぼ同様によく動いています。
2. これらの DOM 操作の上に乗るオーバーヘッドをできる限り小さくします。これが Vue と React で異なる点です。

React では、DOM 要素をレンダリングする追加のオーバーヘッドを 1、そして、平均的なコンポーネントのオーバーヘッドを 2 としましょう。Vue では DOM 要素のオーバーヘッドは 0.1 に近くなるでしょうが、平均的なコンポーネントのオーバーヘッドは、リアクティブシステムのセットアップが必要になるため、4 になるでしょう。

これが意味するのは、コンポーネントよりも DOM 要素がより多くレンダリングされるような通常のアプリケーションにおいて、Vue は React よりも大きく優れたパフォーマンスを発揮するということです。しかしながら、1 つの普通のコンポーネントがそれぞれの要素をレンダリングするような極端なケースでは、Vue は大抵もっと遅くなってしまうでしょう。しかし、これでこの話は終わりではありません。

Vue と React は両者ともに、状態を持たず、インスタンス化できない関数型コンポーネントを提供しています - そしてこれにより、オーバーヘッドはより少なくなります。これがパフォーマンスが重要な状況で使用された時、Vue は再び React よりも速くなります。これをデモするために、私たちは 10,000 個のリスト要素を 100 回描画するだけのシンプルな[ベンチマークプロジェクト](https://github.com/chrisvfritz/vue-render-performance-comparisons)を構築しました。このベンチマークの結果はハードウェアやブラウザ - 特に実行している JavaScript エンジンの性質によっても異なりますので、あなた自身で試してみることをおすすめします。

しかし、もしあなたが面倒に感じるのなら、以下に 2014 MacBook Air 上の Chrome 52 で実行した時の結果を載せます。恣意的な結果の選択を避けるために、2 つのベンチマークは実際に独立して 20 回実行され、最も良い結果を採用しています。

{% raw %}
<table class="benchmark-table">
  <thead>
    <tr>
      <th></th>
      <th>Vue</th>
      <th>React</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>最速値</th>
      <td>23ms</td>
      <td>63ms</td>
    </tr>
    <tr>
      <th>中央値</th>
      <td>42ms</td>
      <td>81ms</td>
    </tr>
    <tr>
      <th>平均値</th>
      <td>51ms</td>
      <td>94ms</td>
    </tr>
    <tr>
      <th>95 パーセンタイル</th>
      <td>73ms</td>
      <td>164ms</td>
    </tr>
    <tr>
      <th>最遅値</th>
      <td>343ms</td>
      <td>453ms</td>
    </tr>
    </tr>
  </tbody>
</table>
{% endraw %}

#### 更新のパフォーマンス

React では、完全に最適化された再描画を実現するために、あなたは `shouldComponentUpdate` をすべての場所で実装し、イミュータブルなデータ構造を使用する必要があります。Vue では、コンポーネントの依存関係は自動的に追跡されるため、コンポーネントは依存関係のうち 1 つが変更された時にのみ更新されます。唯一、長いリスト中の要素に `key` 属性を付与することが、時に Vue で役立つ更なる最適化となります。

これが意味するのは、最適化されていない Vue の更新処理は、最適化されていない React よりもとても速く、特に Vue の改善されたレンダリングパフォーマンスによって、完全に最適化された React ですらも大抵の場合は最適化されていない Vue よりも遅いです。

#### 開発時

明らかに、プロダクション環境におけるパフォーマンスは最も重要で、それは今まで私たちが議論してきたことです。しかしながら、開発時のパフォーマンスもまた重要です。良い知らせとして、Vue と React は両者ともほとんどの標準的なアプリケーションにおいては開発時に十分な速さを維持しています。

しかしながら、もしあなたが高パフォーマンスなデータの可視化やアニメーションをプロトタイピングをするのなら、開発時に Vue が 10 fps 以上の処理をできない状況において、私たちは React が約 1 fps まで遅くなるのを確認したということを知っておくのは、あなたの役に立つでしょう。

これは React の多くの厳密な不変条件のチェックによるもので、多くの素晴らしい警告やエラーメッセージを提供するのに役立っています。私たちはこれが Vue において重要なことは同意できますが、これらのチェックを実装する一方で、パフォーマンスに関しても注意深く気にすることに努めています。

### HTML & CSS

React では、すべてのものは単なる JavaScript で、これはとてもシンプルで洗練されているように聞こえます - それを深く知るまでは。悲しいことに、HTML や CSS を JavaScript の中で再発明することは多くの痛みを伴うというのが現実です。Vue はそうではなく、Web の技術を利用し、また Web の技術の上に構築されています。これが意味することをあなたに見せるために、いくつかの例をお見せしましょう。

#### JSX vs Templates

React では、すべてのコンポーネントは JSX を用いた render 関数の中でそれらの UI を表現します。JSX とは JavaScript の中で用いることのできる、宣言的で XML のような構文です。ここに [React のコミュニティによって吟味された](https://github.com/vuejs/vuejs.org/issues/364#issuecomment-244582684)例があります：

``` jsx
render () {
  let { items } = this.props

  let children
  if (items.length > 0) {
    children = (
      <ul>
        {items.map(item =>
          <li key={item.id}>{item.name}</li>
        )}
      </ul>
    )
  } else {
    children = <p>No items found.</p>
  }

  return (
    <div className='list-container'>
      {children}
    </div>
  )
}
```

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

- あなたはビューを構築するために完全なプログラミング言語（JavaScript）の力を使うことができます。
- JSX のためのツールのサポート（例えば、Lint、型チェック、エディタのオートコンプリート）は現在 Vue のテンプレートで利用可能なものよりもいくつかの点で優れています。

Vue は、[render 関数](render-function.html)と、さらに [JSX のサポート](render-function.html#JSX)を備えています、なぜなら、あなたは時折その力を必要とするためです。しかしながら、render 関数はほとんどのコンポーネントでは推奨されていません。

その代わりに、私たちはテンプレートをより単純な代替方法として提供しています：

``` html
<template>
  <div class="list-container">
    <ul v-if="items.length">
      <li v-for="item in items">
        {{ item.name }}
      </li>
    </ul>
    <p v-else>項目は見つかりませんでした。</p>
  </div>
</template>
```

ここにいくつかの優位な点を示します：

- テンプレートを書く上で必要となる実装やコーディングスタイルの決定はずっと少ないです
- テンプレートは常に宣言的になります
- すべての正しい HTML はテンプレートとしても正しくなります
- それはより英語らしく読めます（例えば、for each item in items - 訳注：items の中のそれぞれの item）
- より読みやすくするための上位版の JavaScript は必要としません

これは、それを書いている開発者がもっと簡単にできるというだけではなく、デザイナーや経験の浅い開発者がもっと簡単に理解することができ、コードに貢献することができることでしょう。

しかもそれだけではありません。JavaScript の中で HTML を再発明しようとするのではなく HTML を利用することで、Vue ではまた、Pug（Jade の後継として知られています）のようなプリプロセッサをあなたのテンプレート内で使用できるようにしています。

React のエコシステムにもあなたがテンプレートを書けるようにする[プロジェクト](https://wix.github.io/react-templates/)がありますが、いくつか劣っている点があります：

- Vue のテンプレートシステムほど機能が豊富ではありません
- コンポーネントのファイルから HTML を分けることが必要になります
- 公式にサポートされているものではなく、サードパーティのライブラリなので、将来的に React のコアとともに更新され続けられるかは不確定です

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

あなたがコンポーネントを複数のファイルに分けない限り（例えば、[CSS モジュール](https://github.com/gajus/react-css-modules)を使うなど）、React で CSS のスコープを限定するときには注意が必要です。特に基本的な CSS はそのまま動作しますが、hover 状態、メディアクエリや、疑似セレクタのようなより複雑な機能はすべて、CSS がすでに行っていることを再発明するために多くの依存を必要とするか - 単に動作しません。

その一方で Vue は、[単一ファイルコンポーネント](single-file-components.html)の中で CSS のすべての機能を使用できるようにしています：

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

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

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

### 規模

#### スケールアップ

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

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

最後に、Vue は [CLI によるプロジェクト生成ツール](https://github.com/vuejs/vue-cli)を提供しており、それによってあなたは好きなビルドシステムを使った新しいプロジェクトをとても簡単に始めることができます。ビルドシステムには、[Webpack](https://github.com/vuejs-templates/webpack)、[Browserify](https://github.com/vuejs-templates/browserify)、さらに[ビルドシステム無し](https://github.com/vuejs-templates/simple)などがあります。React も [create-react-app](https://github.com/facebookincubator/create-react-app) でこの領域に取り組んでいますが、現在いくつかの制限があります：

- Vue のプロジェクトテンプレートが Yeoman ライクなカスタマイズ機能を持つ一方で、それはプロジェクトの生成においてどのような設定も許可していません。
- Vue が様々な目的やビルドシステムのために広い種類のテンプレートを提供している一方で、それはシングルページアプリケーションを構築することを仮定した 1 つのテンプレートしか提供していません。
- ユーザーが作ったテンプレートからプロジェクトを生成することは、開発スタイルを決定する前の企業の環境では特に役立ちますが、そのようなことはできません。

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

#### スケールダウン

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

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

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

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

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

### ネイティブレンダリング

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

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

### MobX と用いた場合

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

## Angular 1

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

### 複雑性

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

### 柔軟性とモジュール性

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

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

### データバインディング

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

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

Vue はディレクティブとコンポーネントの間に明確な線引きをしています。ディレクティブは DOM の操作のみをカプセル化するように意図されている一方で、コンポーネントは自身のビューとデータロジックを持つ独立した構成単位です。Angular では、それらの間には多くの混乱があります。

### パフォーマンス

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

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

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

## Angular 2

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

### TypeScript

Angular 1 がより小さなアプリケーションのために使用することができたのに対して、Angular 2 は企業が作るような大きなアプリケーションに最適となるようにフォーカスが移っています。この一部として、それはほぼ TypeScript が必須となっています。TypeScript は Java や C# のような言語の型安全がほしい開発者にはとても役立つものです。

Vue もまた、[企業での開発](https://github.com/vuejs/awesome-vue#enterprise-usage)によく適しており、また、特に私たちの[公式の型定義](https://github.com/vuejs/vue/tree/dev/types)や[ユーザーが貢献したデコレータ](https://github.com/itsFrank/vue-typescript)によって TypeScript で使用することができます。しかしながら、当然それは私たちの場合は当然オプションとなります。

### サイズとパフォーマンス

パフォーマンスの面では、2 つのフレームワークは非常に早く、判決するための現実世界のユースケースでの十分なデータはありません。しかしながら、もしあなたがいくつかの数字を見ることを決意したのなら、この[サードパーティのベンチマーク](http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html)から Vue 2.0 は Angular 2 よりも優位なようです。

サイズの面では、Angular 2 にその公式のコンパイルと Tree-shaking を適用したものは大幅にそのサイズを削減することができますが、コンパイラを含むフル機能の Vue 2.0（23kb）はまだ Tree-shaking をした必要最小限の Angular 2 のコード例（50kb）よりも軽いです。そしてここで留意すべきなのは、Angular 2 のアプリのサイズは、使用されていない機能のコードを削除する Tree-shaking のために小さいということです。あなたがフレームワークの機能をインポートして使うにつれて、最終的にはその実際のサイズに向かって再度大きくなっていくでしょう。

### 柔軟性

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

### 学習曲線

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

Angular 2 の学習曲線はもっと急です。TypeScript 抜きにしても、その[クイックスタートガイド](https://angular.io/docs/js/latest/quickstart.html)は ES2015 JavaScript や 18 の NPM パッケージへの依存、4 つのファイル、そしてそのすべてを説明するのに 3,000 単語以上が使われるアプリから始まります - ただ Hello World と言わせるだけで。[Vue の Hello World](index.html#Hello-World) はもっと大幅に単純です、というのは控えめな表現でしょう。実際には、私たちはそれのためにガイドのすべてのページを読み込むことはしないので、それはとても些細な事です。

## Ember

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

ですので、Vue のコアと Ember の[テンプレート](https://guides.emberjs.com/v2.7.0/templates/handlebars-basics/)と[オブジェクトモデル](https://guides.emberjs.com/v2.7.0/object-model/)レイヤーを比較することは比較をより良いものにすることでしょう：

- Vue はプレーンな JavaScript 上で控えめなリアクティビティと完全に自動的な算出プロパティを提供しています。Ember では、あなたはすべてを Ember のオブジェクトの中にラップし、算出プロパティの依存を手動で定義する必要があります。

- Vue のテンプレート構文は JavaScript の式の完全な力を利用しているのに対し、Handlebars の式とヘルパの構文は意図的にかなり制限されています。

- パフォーマンスの面では、Vue は大きく差をつけて Ember よりも優れています、Ember 2.0 で最新の Glimmer エンジンのアップデートがされた後でもです。Ember ではパフォーマンスが重要な状況において、手動でランループ（run loop）を管理する必要がある一方で、Vue は自動的にバッチ更新を行います。

## Knockout

Knockout は MVVM と依存追跡の分野における先駆者で、そのリアクティブシステムは Vue のものととてもよく似ています。その[ブラウザサポート](http://knockoutjs.com/documentation/browser-support.html)もまた他の機能を考慮しても特にすばらしく、IE6 からをサポートしています！Vue は一方で、IE9 以上のみをサポートしています。

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

さらに、あなたが興味を持っているかもしれない API デザインにも哲学的な違いがあるようで、[単純な TODO リスト](https://gist.github.com/chrisvfritz/9e5f2d6826af00fcbace7be8f6dccb89)の作成をそれぞれどのように扱うのかによって実演することができます。これは確かに少々主観的ですが、多くの人は 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 はいくつか著しく優れた点を持っています：

- 真の条件付きレンダリング。Riot はすべての if 分岐を描画し、そして単純にそれらを表示／非表示しています。
- ずっと強力なルータ。Riot のルーティング API は極めて最小限です。
- より熟成したツールのサポート。Vue は [Webpack](https://github.com/vuejs/vue-loader)、[Browserify](https://github.com/vuejs/vueify)と、さらに[SystemJS](https://github.com/vuejs/systemjs-plugin-vue)の公式サポートを提供していますが、対して Riot はビルドシステムの統合についてはコミュニティのサポートに頼っています。
- [トランジションエフェクトシステム](transitions.html)。Riot にはありません。
- より優れたパフォーマンス。仮想 DOM を使用しているという[宣伝をしているにも関わらず](https://github.com/vuejs/vuejs.org/issues/346)、Riot は実際には Dirty Checking を用いており、それにより Angular 1 と同じパフォーマンスの問題に苦しめられています。<commit_msg>remove SystemJS mention from Riot comparison<commit_after>---
title: 他のフレームワークとの比較
type: guide
order: 28
---

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

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

さらに、私たちは**あなた**がこのドキュメントを最新の情報に保っていただけることを望みます。なぜなら、JavaScript の世界は速く動いているからです！もし、あなたが正確ではない部分や、あまり正しくないように見える部分に気がついたら、[Issue を開いて](https://github.com/vuejs/vuejs.org/issues/new?title=Inaccuracy+in+comparisons+guide)教えてください。

## React

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

- 仮想 DOM を活用しています
- リアクティブで組み合わせ可能なビューのコンポーネントを提供しています
- コアライブラリに焦点をあわせることに努めており、ルーティングやグローバルの状態管理のような関心事は関連ライブラリに担当させています

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

React のコミュニティは、私たちがこのバランスを達成するのを[手助けしてくださいました](https://github.com/vuejs/vuejs.org/issues/364)。React チームの <NAME> 氏には心から感謝いたします。彼にはとても寛容に時間を費やしていただき、私たちが[お互いに最終結果に満足するまで](https://github.com/vuejs/vuejs.org/issues/364#issuecomment-244575740)このドキュメントを改善するための数多くの助言をいただきました。

ですので、下記で私たちがこれらの 2 つのライブラリの違いを探求したように、あなたが確かに公平な考察だと感じることができるのを願います。

### パフォーマンスの分析

私たちがこれまでにテストした現実世界と同様のシナリオのすべてにおいて、Vue は React よりもかなり優れたパフォーマンスを発揮しました。あなたが直ちに驚きたい場合は、ぜひ読んでください。私たちは (React チームと協力して開発されたベンチマークも含めて) ブレークダウンしています。

#### 描画のパフォーマンス

UI をレンダリングする時、DOM 操作は通常最も高いコストのかかる操作になり、また、残念ながら、そういった低レベルの操作をより速くするライブラリは存在しません。私たちができる最良の方法は：

1. 必要な DOM 操作の回数を最小にします。React と Vue は両者ともこれを果たすために仮想 DOM による抽象化を用いており、どちらの実装もほぼ同様によく動いています。
2. これらの DOM 操作の上に乗るオーバーヘッドをできる限り小さくします。これが Vue と React で異なる点です。

React では、DOM 要素をレンダリングする追加のオーバーヘッドを 1、そして、平均的なコンポーネントのオーバーヘッドを 2 としましょう。Vue では DOM 要素のオーバーヘッドは 0.1 に近くなるでしょうが、平均的なコンポーネントのオーバーヘッドは、リアクティブシステムのセットアップが必要になるため、4 になるでしょう。

これが意味するのは、コンポーネントよりも DOM 要素がより多くレンダリングされるような通常のアプリケーションにおいて、Vue は React よりも大きく優れたパフォーマンスを発揮するということです。しかしながら、1 つの普通のコンポーネントがそれぞれの要素をレンダリングするような極端なケースでは、Vue は大抵もっと遅くなってしまうでしょう。しかし、これでこの話は終わりではありません。

Vue と React は両者ともに、状態を持たず、インスタンス化できない関数型コンポーネントを提供しています - そしてこれにより、オーバーヘッドはより少なくなります。これがパフォーマンスが重要な状況で使用された時、Vue は再び React よりも速くなります。これをデモするために、私たちは 10,000 個のリスト要素を 100 回描画するだけのシンプルな[ベンチマークプロジェクト](https://github.com/chrisvfritz/vue-render-performance-comparisons)を構築しました。このベンチマークの結果はハードウェアやブラウザ - 特に実行している JavaScript エンジンの性質によっても異なりますので、あなた自身で試してみることをおすすめします。

しかし、もしあなたが面倒に感じるのなら、以下に 2014 MacBook Air 上の Chrome 52 で実行した時の結果を載せます。恣意的な結果の選択を避けるために、2 つのベンチマークは実際に独立して 20 回実行され、最も良い結果を採用しています。

{% raw %}
<table class="benchmark-table">
  <thead>
    <tr>
      <th></th>
      <th>Vue</th>
      <th>React</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>最速値</th>
      <td>23ms</td>
      <td>63ms</td>
    </tr>
    <tr>
      <th>中央値</th>
      <td>42ms</td>
      <td>81ms</td>
    </tr>
    <tr>
      <th>平均値</th>
      <td>51ms</td>
      <td>94ms</td>
    </tr>
    <tr>
      <th>95 パーセンタイル</th>
      <td>73ms</td>
      <td>164ms</td>
    </tr>
    <tr>
      <th>最遅値</th>
      <td>343ms</td>
      <td>453ms</td>
    </tr>
    </tr>
  </tbody>
</table>
{% endraw %}

#### 更新のパフォーマンス

React では、完全に最適化された再描画を実現するために、あなたは `shouldComponentUpdate` をすべての場所で実装し、イミュータブルなデータ構造を使用する必要があります。Vue では、コンポーネントの依存関係は自動的に追跡されるため、コンポーネントは依存関係のうち 1 つが変更された時にのみ更新されます。唯一、長いリスト中の要素に `key` 属性を付与することが、時に Vue で役立つ更なる最適化となります。

これが意味するのは、最適化されていない Vue の更新処理は、最適化されていない React よりもとても速く、特に Vue の改善されたレンダリングパフォーマンスによって、完全に最適化された React ですらも大抵の場合は最適化されていない Vue よりも遅いです。

#### 開発時

明らかに、プロダクション環境におけるパフォーマンスは最も重要で、それは今まで私たちが議論してきたことです。しかしながら、開発時のパフォーマンスもまた重要です。良い知らせとして、Vue と React は両者ともほとんどの標準的なアプリケーションにおいては開発時に十分な速さを維持しています。

しかしながら、もしあなたが高パフォーマンスなデータの可視化やアニメーションをプロトタイピングをするのなら、開発時に Vue が 10 fps 以上の処理をできない状況において、私たちは React が約 1 fps まで遅くなるのを確認したということを知っておくのは、あなたの役に立つでしょう。

これは React の多くの厳密な不変条件のチェックによるもので、多くの素晴らしい警告やエラーメッセージを提供するのに役立っています。私たちはこれが Vue において重要なことは同意できますが、これらのチェックを実装する一方で、パフォーマンスに関しても注意深く気にすることに努めています。

### HTML & CSS

React では、すべてのものは単なる JavaScript で、これはとてもシンプルで洗練されているように聞こえます - それを深く知るまでは。悲しいことに、HTML や CSS を JavaScript の中で再発明することは多くの痛みを伴うというのが現実です。Vue はそうではなく、Web の技術を利用し、また Web の技術の上に構築されています。これが意味することをあなたに見せるために、いくつかの例をお見せしましょう。

#### JSX vs Templates

React では、すべてのコンポーネントは JSX を用いた render 関数の中でそれらの UI を表現します。JSX とは JavaScript の中で用いることのできる、宣言的で XML のような構文です。ここに [React のコミュニティによって吟味された](https://github.com/vuejs/vuejs.org/issues/364#issuecomment-244582684)例があります：

``` jsx
render () {
  let { items } = this.props

  let children
  if (items.length > 0) {
    children = (
      <ul>
        {items.map(item =>
          <li key={item.id}>{item.name}</li>
        )}
      </ul>
    )
  } else {
    children = <p>No items found.</p>
  }

  return (
    <div className='list-container'>
      {children}
    </div>
  )
}
```

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

- あなたはビューを構築するために完全なプログラミング言語（JavaScript）の力を使うことができます。
- JSX のためのツールのサポート（例えば、Lint、型チェック、エディタのオートコンプリート）は現在 Vue のテンプレートで利用可能なものよりもいくつかの点で優れています。

Vue は、[render 関数](render-function.html)と、さらに [JSX のサポート](render-function.html#JSX)を備えています、なぜなら、あなたは時折その力を必要とするためです。しかしながら、render 関数はほとんどのコンポーネントでは推奨されていません。

その代わりに、私たちはテンプレートをより単純な代替方法として提供しています：

``` html
<template>
  <div class="list-container">
    <ul v-if="items.length">
      <li v-for="item in items">
        {{ item.name }}
      </li>
    </ul>
    <p v-else>項目は見つかりませんでした。</p>
  </div>
</template>
```

ここにいくつかの優位な点を示します：

- テンプレートを書く上で必要となる実装やコーディングスタイルの決定はずっと少ないです
- テンプレートは常に宣言的になります
- すべての正しい HTML はテンプレートとしても正しくなります
- それはより英語らしく読めます（例えば、for each item in items - 訳注：items の中のそれぞれの item）
- より読みやすくするための上位版の JavaScript は必要としません

これは、それを書いている開発者がもっと簡単にできるというだけではなく、デザイナーや経験の浅い開発者がもっと簡単に理解することができ、コードに貢献することができることでしょう。

しかもそれだけではありません。JavaScript の中で HTML を再発明しようとするのではなく HTML を利用することで、Vue ではまた、Pug（Jade の後継として知られています）のようなプリプロセッサをあなたのテンプレート内で使用できるようにしています。

React のエコシステムにもあなたがテンプレートを書けるようにする[プロジェクト](https://wix.github.io/react-templates/)がありますが、いくつか劣っている点があります：

- Vue のテンプレートシステムほど機能が豊富ではありません
- コンポーネントのファイルから HTML を分けることが必要になります
- 公式にサポートされているものではなく、サードパーティのライブラリなので、将来的に React のコアとともに更新され続けられるかは不確定です

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

あなたがコンポーネントを複数のファイルに分けない限り（例えば、[CSS モジュール](https://github.com/gajus/react-css-modules)を使うなど）、React で CSS のスコープを限定するときには注意が必要です。特に基本的な CSS はそのまま動作しますが、hover 状態、メディアクエリや、疑似セレクタのようなより複雑な機能はすべて、CSS がすでに行っていることを再発明するために多くの依存を必要とするか - 単に動作しません。

その一方で Vue は、[単一ファイルコンポーネント](single-file-components.html)の中で CSS のすべての機能を使用できるようにしています：

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

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

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

### 規模

#### スケールアップ

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

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

最後に、Vue は [CLI によるプロジェクト生成ツール](https://github.com/vuejs/vue-cli)を提供しており、それによってあなたは好きなビルドシステムを使った新しいプロジェクトをとても簡単に始めることができます。ビルドシステムには、[Webpack](https://github.com/vuejs-templates/webpack)、[Browserify](https://github.com/vuejs-templates/browserify)、さらに[ビルドシステム無し](https://github.com/vuejs-templates/simple)などがあります。React も [create-react-app](https://github.com/facebookincubator/create-react-app) でこの領域に取り組んでいますが、現在いくつかの制限があります：

- Vue のプロジェクトテンプレートが Yeoman ライクなカスタマイズ機能を持つ一方で、それはプロジェクトの生成においてどのような設定も許可していません。
- Vue が様々な目的やビルドシステムのために広い種類のテンプレートを提供している一方で、それはシングルページアプリケーションを構築することを仮定した 1 つのテンプレートしか提供していません。
- ユーザーが作ったテンプレートからプロジェクトを生成することは、開発スタイルを決定する前の企業の環境では特に役立ちますが、そのようなことはできません。

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

#### スケールダウン

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

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

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

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

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

### ネイティブレンダリング

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

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

### MobX と用いた場合

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

## Angular 1

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

### 複雑性

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

### 柔軟性とモジュール性

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

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

### データバインディング

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

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

Vue はディレクティブとコンポーネントの間に明確な線引きをしています。ディレクティブは DOM の操作のみをカプセル化するように意図されている一方で、コンポーネントは自身のビューとデータロジックを持つ独立した構成単位です。Angular では、それらの間には多くの混乱があります。

### パフォーマンス

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

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

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

## Angular 2

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

### TypeScript

Angular 1 がより小さなアプリケーションのために使用することができたのに対して、Angular 2 は企業が作るような大きなアプリケーションに最適となるようにフォーカスが移っています。この一部として、それはほぼ TypeScript が必須となっています。TypeScript は Java や C# のような言語の型安全がほしい開発者にはとても役立つものです。

Vue もまた、[企業での開発](https://github.com/vuejs/awesome-vue#enterprise-usage)によく適しており、また、特に私たちの[公式の型定義](https://github.com/vuejs/vue/tree/dev/types)や[ユーザーが貢献したデコレータ](https://github.com/itsFrank/vue-typescript)によって TypeScript で使用することができます。しかしながら、当然それは私たちの場合は当然オプションとなります。

### サイズとパフォーマンス

パフォーマンスの面では、2 つのフレームワークは非常に早く、判決するための現実世界のユースケースでの十分なデータはありません。しかしながら、もしあなたがいくつかの数字を見ることを決意したのなら、この[サードパーティのベンチマーク](http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html)から Vue 2.0 は Angular 2 よりも優位なようです。

サイズの面では、Angular 2 にその公式のコンパイルと Tree-shaking を適用したものは大幅にそのサイズを削減することができますが、コンパイラを含むフル機能の Vue 2.0（23kb）はまだ Tree-shaking をした必要最小限の Angular 2 のコード例（50kb）よりも軽いです。そしてここで留意すべきなのは、Angular 2 のアプリのサイズは、使用されていない機能のコードを削除する Tree-shaking のために小さいということです。あなたがフレームワークの機能をインポートして使うにつれて、最終的にはその実際のサイズに向かって再度大きくなっていくでしょう。

### 柔軟性

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

### 学習曲線

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

Angular 2 の学習曲線はもっと急です。TypeScript 抜きにしても、その[クイックスタートガイド](https://angular.io/docs/js/latest/quickstart.html)は ES2015 JavaScript や 18 の NPM パッケージへの依存、4 つのファイル、そしてそのすべてを説明するのに 3,000 単語以上が使われるアプリから始まります - ただ Hello World と言わせるだけで。[Vue の Hello World](index.html#Hello-World) はもっと大幅に単純です、というのは控えめな表現でしょう。実際には、私たちはそれのためにガイドのすべてのページを読み込むことはしないので、それはとても些細な事です。

## Ember

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

ですので、Vue のコアと Ember の[テンプレート](https://guides.emberjs.com/v2.7.0/templates/handlebars-basics/)と[オブジェクトモデル](https://guides.emberjs.com/v2.7.0/object-model/)レイヤーを比較することは比較をより良いものにすることでしょう：

- Vue はプレーンな JavaScript 上で控えめなリアクティビティと完全に自動的な算出プロパティを提供しています。Ember では、あなたはすべてを Ember のオブジェクトの中にラップし、算出プロパティの依存を手動で定義する必要があります。

- Vue のテンプレート構文は JavaScript の式の完全な力を利用しているのに対し、Handlebars の式とヘルパの構文は意図的にかなり制限されています。

- パフォーマンスの面では、Vue は大きく差をつけて Ember よりも優れています、Ember 2.0 で最新の Glimmer エンジンのアップデートがされた後でもです。Ember ではパフォーマンスが重要な状況において、手動でランループ（run loop）を管理する必要がある一方で、Vue は自動的にバッチ更新を行います。

## Knockout

Knockout は MVVM と依存追跡の分野における先駆者で、そのリアクティブシステムは Vue のものととてもよく似ています。その[ブラウザサポート](http://knockoutjs.com/documentation/browser-support.html)もまた他の機能を考慮しても特にすばらしく、IE6 からをサポートしています！Vue は一方で、IE9 以上のみをサポートしています。

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

さらに、あなたが興味を持っているかもしれない API デザインにも哲学的な違いがあるようで、[単純な TODO リスト](https://gist.github.com/chrisvfritz/9e5f2d6826af00fcbace7be8f6dccb89)の作成をそれぞれどのように扱うのかによって実演することができます。これは確かに少々主観的ですが、多くの人は 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 はいくつか著しく優れた点を持っています：

- 真の条件付きレンダリング。Riot はすべての if 分岐を描画し、そして単純にそれらを表示／非表示しています。
- ずっと強力なルータ。Riot のルーティング API は極めて最小限です。
- より熟成したツールのサポート。Vue は [Webpack](https://github.com/vuejs/vue-loader)、[Browserify](https://github.com/vuejs/vueify) の公式サポートを提供していますが、対して Riot はビルドシステムの統合についてはコミュニティのサポートに頼っています。
- [トランジションエフェクトシステム](transitions.html)。Riot にはありません。
- より優れたパフォーマンス。仮想 DOM を使用しているという[宣伝をしているにも関わらず](https://github.com/vuejs/vuejs.org/issues/346)、Riot は実際には Dirty Checking を用いており、それにより Angular 1 と同じパフォーマンスの問題に苦しめられています。
{'fraction_non_alphanumeric': 0.08599422622692678, 'fraction_numerical': 0.010789373924707666, 'mean_word_length': 9.03335283791691, 'pattern_counts': {'":': 0, '<': 159, '<?xml version=': 0, '>': 163, 'https://': 59, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2324408', 'n_tokens_mistral': 28584, 'n_tokens_neox': 25721, 'n_words': 1667}