オブジェクトのシンタックスを提供することができます。変換するので、そのプロパティがアクセスまたは変更された場合には通知を受けることができます。シリアライズすると、データがまったく同じになります。束しか表示されません。使うとさらに検出可能なログを出力できます。定義することはできません。取得するので、これはあまり大した問題ではありません。ループには表示されません。それらを上書きした場合は、おそらく解除されます。ループは通常どおりに動作します。上記の配慮は必要ないでしょう。変更を経てリリースされました。以前の最後に計画されたポイントリリースです。ライセンスの下でソースを公開しています。柔軟で自己を主張しないライブラリと言えます。余儀なくされるのに対して、自分の好みのやり方でアプリを構築できます。作成せずとも、インターフェイス・レイヤーとしてページ内に軽度の機能実装を実現できるので、他のライブラリとの組み合わせを自由に選ぶ余地が生まれます。多くのアーキテクチャ上の意思決定する責任があります。機能が付属しておらず、そして通常は、外部モジュールバンドラを使用してアプリケーションを構築していると前提としています。これが、おそらく最も重要な違いと言えるでしょう。比べて全体にとてもシンプルです。学習効率が非常に高いと言えます。行わないため優れたパフォーマンスを持ち、より容易に最適化できます。スコープに変更がある度、すべてのウォッチャを評価し直すため、ウォッチャが多く存在すると遅くなりがちです。複数回実行しなければならない可能性があります。回避するために難解な技術に頼る必要があり、そしていくつかの状況では多数のウォッチャを伴うスコープを容易に最適化する方法は存在しません。非同期のキューイングによって透過性依存的追跡を監視するシステムを採用しているので、明らかな依存関係が無い限りすべての変更のトリガは独立して機能し、この問題に悩まされることはありません。操作の紐付け(カプセル化)を行うものとして、両者の役割を明確に分離しています。両者の使い分けに多くの曖昧な点が存在しています。比較的若いプロジェクトであることに注意してください。コンポーネントを提供し、いくつかの類似性があります。内部実装は基本的に異なっています。どのように動作するかをメモリ内で表現しています。操作は差分を算出して実行されます。デフォルトでステートフルであり、内部のデータは変更可能です。変更はイベントを通じてトリガーされます。テンプレートとして使用し、データバインディングのために実際にノードへのリファレンスを保持します。描画する機能的な方法を提供します。データと常に同期がされていることが保証されます。アプリケーションでも同様の可能性を与えることができます。設計思想の大ファンです。おける1つの問題は、描画関数は多くの場合に多数のロジックを伴い、むしろインターフェイスの視覚的な表現というよりもプログラムの一部のように見えることです。はるかに簡単に視覚的に捉えられるようにしてくれます。ロジックを組み合わせるのは、私がコードをデザインに変換していくために必要としている視覚モデルの邪魔になります。よりコストをかけており、そのために視覚的に構築可能なテンプレートと、ディレクティブとフィルタにカプセル化されたロジックを持っています。委任されていることです。思想に反する結果になります)。操作を必要とするアプリケーションの場合、これがかなり厄介な制限になることになります。同様、インスピレーションの源でした。カスタム要素と比較して緩く、そして両方ともとても似た開発スタイルを提供します。まで依存せずに動作します。パフォーマンスを保証するために非常に限定的なデータバインディングのシステムしか持たされていませんでした。テンプレートでサポートされる唯一の式は、ブール否定と単一メソッド呼び出しです。実装もまた非常に柔軟であるとは言えません。依存のツールによってバンドルされる必要があります。プリプロセッサを簡単に利用できます。プロパティの取得や設定で、クリーンな構文を組みやすいという点があります。コンポーネントシステムはトップダウン設計による手続き型の設計戦略に基づき、まずシステム全体を定義します。組み上げてシステムを構成していきます。リクエストを投げることが出来ます)。そのデータへプロキシ経由でアクセスするものです。要素に生データを接続している状態になります。境界はかなり曖昧なものになっています。構造をもたらす可能性が高いです。多くの設計哲学を共有していると考えます。対していくつかの重要な利点を提供します。