Facebookの長所と短所React対Webコンポーネント（ポリマー）
Facebookの主な利点は何ですか React 今後の Web Components 仕様およびその逆（またはより多くのリンゴ同士の比較はGoogleの ポリマー ライブラリー）？
このJSConf EUトーク およびReactホームページによると、Reactの主な利点は次のとおりです。
- コンポーネントモデルを使用したデカップリングと凝集度の向上
- 抽象化、構成、表現力
- 仮想DOMと合成イベント（つまり、基本的には、DOMとそのイベントシステムが完全に再実装されたことを意味します）
- IE 8で最新のHTML5イベントを有効にします
- サーバー側レンダリング
- テスト容易性
- SVG、VML、および
<canvas>へのバインディング
言及されているほとんどすべては、この仮想DOMの概念（明らかに）を除いて、Webコンポーネントを介してネイティブにブラウザーに統合されています。今日、仮想DOMと合成イベントが古いブラウザーをサポートするためにどのように有益であるかがわかりますが、ネイティブブラウザーコードの巨大なチャンクを長期的に自分の足で撃つようなものを捨てていませんか？現代のブラウザに関する限り、それは多くの不必要なオーバーヘッド/ホイールの再発明ではないですか？
ここにいくつか私が考えるReactが欠けているため、Webコンポーネントがあなたに代わって処理します。間違っている。
- ネイティブブラウザのサポート（「高速化が保証されている」をお読みください）
- スクリプト言語でスクリプトを書き、スタイル言語でスタイルを書き、マークアップ言語でマークアップを書きます。
- Shadow DOMを使用したスタイルのカプセル化
- 代わりに、Reactには this があり、JavaScriptでCSSを記述する必要があります。きれいじゃない。
- 双方向バインディング
Reactの人はReactとWebコンポーネントの比較について かなり良い説明 を持っています：
2つのライブラリは異なる問題を解決するために作成されているため、ReactをWebComponentsと比較して対比しようとすると、必然的に結論が異なります。 WebComponentsは再利用可能なコンポーネントの強力なカプセル化を提供し、ReactはDOMをデータと常に同期させる宣言型ライブラリを提供します。 2つの目標は相補的です。エンジニアはテクノロジーを組み合わせることができます。開発者は、WebComponentsでReactを使用するか、ReactでWebComponentsを使用するか、またはその両方を自由に行えます。
ポリマーは素晴らしいです。 Reactは素晴らしいです。同じものではありません。
Polymerは、下位互換性のあるWebコンポーネントを構築するためのライブラリです。
ReactはMVCのVです。それはビューであり、他には何もありません。少なくともそれ自体ではありません。
Reactはフレームワークではありません。
React + Flux + Node +（GulpまたはGrunt）はフレームワークに匹敵しますが、そのうちの3つは反応の一部ではありません。
開発者がフォローする反応、パターン、およびアーキテクチャスタイルは数多くありますが、それ自体はフレームワークではありません。
最も簡単なことを言うのに誰も時間をかけなかったこと、悲惨なことです。それらはいくつかのオーバーラップがありますが、同じではありません。
どちらの方法でも、Webコンポーネントを定義できますが、方法は異なります。それを超えて、それらは非常に非常に異なるツールです。
ある時点での別の答えは、具体的には：
JavaScriptをVanilla JavaScriptで記述し、CSSをCSSで記述し、HTMLをHTMLで記述します。
たとえば、CoffeeScript、TypeScript、ClojureScriptなどでJavaScriptを書くことを妨げるものは何もありません。それは純粋に好みの問題です。
HTMLは静的 HTMLドキュメントに最適なDSLです。しかし、それは動的HTMLには何も提供しません。また、ブラウザーでは、HTMLを動的にするのに最適な言語はJavaScriptであり、アドホックJavascript DOM操作を備えた純粋なHTMLや、半言語でさえないハンドルバーのようなテンプレート言語ではありません。
CSSの場合、CSSが静的であれば、通常どおりに記述します。いくつかのランタイム値に基づいて動的にする必要がある場合、それはHTMLと同じです。動的にするためにはJavaScriptが最適です。
私はWebコンポーネントを使用していませんが、手動でコーディングしたミューテーションロジックをイベントハンドラーに追加する必要があるようです。
Polymerの例のスニペット：
<script>
Polymer({
counterChanged: function() {
this.$.counterVal.classList.add('highlight');
},
...
Reactの要点は、ミューテーションロジックを排除して複雑さを軽減することです。代わりに、仮想DOMを単純に再生成し、Reactのdiffアルゴリズムに実際のDOMで何を変更する必要があるかを判断させます。
私の意見では、Reactの最大の欠点は、Web標準に基づいていないことです。 Reactは現在非常に強力なツールですが、ブラウザーが提供する機能の多くを可能な限り回避するため、今では意味があると思われる決定がブラウザーとして数年後に意味をなさなくなる可能性がありますビルトイン設備は改善を続けています。そこで、それについてお話ししたいと思います。それがWebアプリケーションのいくつかの異なる側面にどのように影響するかについてお話ししたいと思います。
パフォーマンス
Reactの利点は、DOMとイベントモデル全体を完全に再発明することであり、既存の標準DOMは重くて高価であり、何もないということですが、結局のところ、パフォーマンスがわかりません。 Reactは、適切に記述されたバックボーンまたはPolymerアプリケーションから得られるものよりも優れています。実際、私の専門的な経験のほとんどで、Reactのパフォーマンスは実際には少し悪くなっています。それはReactが遅いと言っているわけではありません...私たちがそれを手に入れる前に皆が思っていた最先端のパフォーマンス選択ではありません。
Rspの回答では、divに対するReactのDOMモデルは、ネイティブDOM divよりもはるかに軽いと指摘しており、それは確かに当てはまります。ただし、Reactが役立つためには、その「仮想」divが、ある時点で実際のdivになる必要があります。したがって、私の世界観では、React divとネイティブdivの問題ではありません。これはReact div +ネイティブdiv対単なるネイティブdivです。 ReactのバージョンのDOMのオーバーヘッドは自明ではありません。標準がこれらの不要な属性の一部を削除し、ネイティブDOMノードを大幅に軽量化すると、突然、そのオーバーヘッドは非常に高く見えるようになります。
私の以前の就職先の1つでは、Polymerにいくつかのアプリケーションがあり、Reactにいくつかのアプリケーションがありました。初期のPolymerアプリケーションの1つがReactに書き直されました。これは、会社が標準にしていたものであり、私がReactを測定した結果に基づいています_この同じアプリケーションのバージョンは、Polymerバージョンよりも約30％多くのメモリを使用してしまい、違いはわずかでしたが、Polymerバージョンもより短い時間でレンダリングされました。ここで考慮すべきことの1つは、人が作成したアプリケーションについて話していることであり、人は完璧ではないため、このアプリケーションのReact実装がすべてを活用していない可能性がありますReactは可能です。ただし、少なくとも一部は、独自のバージョンのDOMを使用することによるオーバーヘッドReactに関係していると思います。
Reactは独自のモデルを使用してDOM全体を再発明し、それを使用して主要なパフォーマンス最適化を行います。ビューは仮想DOMにレンダリングされ、それが実際のDOMに投影されます。変更があり、ビューを更新する必要がある場合、ビューは再び仮想DOMに再レンダリングされ、そのツリーは前のツリーと比較されて、この変更を反映するために実際のDOMで変更する必要があるノードを決定します。ビューで。これは効率的なDOM更新を行うための非常に巧妙なアプローチですが、これらすべての仮想DOMツリーを維持し、それらを比較して実際のDOMで何を変更するかを決定することにはオーバーヘッドがあります。現在、このオーバーヘッドはパフォーマンスの利点によって大幅に相殺されますが、ネイティブDOMが時間とともに改善されるにつれて、スケールは他の方向にシフトします。私はReactアプリがどのように古くなるのかを心配しています。3年後には、DOMを直接扱うものよりもはるかに遅くなります。この仮想DOMアプローチはそりハンマーのようなものであり、Polymerのような他のライブラリは、DOMをより微妙な方法で処理するための非常に効率的なアプローチを実装できました。
パフォーマンス向上のための更新：私がしばらく偶然見つけたライブラリの1つは、DOMの更新を管理するためのより良い仕事であると私が思うことを実行します。これはGoogleのIncremental Domライブラリであり、domインプレースで動作し、「仮想コピー」を作成する必要がないという事実は、はるかにクリーンなアプローチであり、メモリオーバーヘッドがはるかに少ないと思います。詳細はこちら： http://google.github.io/incremental-dom/#about
宣言型コンポーネントと命令型コンポーネント
アプリケーションのコンポーネント化について話しているときにいつも耳にするのは、コンポーネントが宣言型であることのすべての利点です。 Reactの世界観の中では、すべてが素晴らしく宣言的です。マークアップを返すJavaScriptを記述し、Reactがそれをすべて一緒に接着します。そして、Reactのみを使用し、それ以外はまったく使用しない、まったく新しいアプリケーションを扱っている場合、それは素晴らしいことです。いくつかのコンポーネントを書くことができ、Reactが所有するDOMの一部の内部にある限り、コンポーネントにタグを付けるだけでページにタグを配置できます。
しかし、これらのコンポーネントを取得してReactの外部で使用するようになるとすぐに、事態は非常に複雑になります。 Reactコンポーネントをタグにする方法はWeb標準が提供するものとは完全に異なるため、React以外には、これらのコンポーネントを宣言的に使用する方法を提供する方法はありません。ハンドルバーテンプレートを使用している既存のバックボーンビューにReactコンポーネントを配置する場合は、ハンドルとして使用できるクラスまたはIDを使用してテンプレートにダミーdivをレンダリングし、命令型JavaScriptをそのダミーのdivを見つけて、それにコンポーネントをマウントします。サーバーサイドテンプレートを使用しているExpress.jsアプリケーションをお持ちですか？まあそれは同じ曲とダンスです。 JSPページ？あなたは笑いますが、まだそれらを使用しているアプリケーションはたくさんあります。既存のコードがないスタートアップの場合を除き、多くのアプリケーションでReactコンポーネントを再利用するために、いくつかの配管を作成する必要があります。一方、PolymerはWebコンポーネント標準を通じてコンポーネントを実現し、カスタム要素仕様を使用することで、Polymerは、ブラウザーがネイティブに使用する方法を知っているコンポーネントを作成できます。 PolymerコンポーネントをJSPページ、Express.jsテンプレート、ASP.NETビュー、バックボーンビューなど、Reactコンポーネントの内部に配置することもできます。文字通り、HTMLを使用できる場所ならどこでも、Polymerコンポーネントを使用できます。標準とは相互に互換性を持たせることを容易にする契約であるため、再利用のためにエンジニアリングしている人々はWeb標準に目を向けています。 YouTubeはPolymerでより多くのものを作成し続けています（ソース： http://react-etc.net/entry/youtube-is-being-rebuilt-on-web-components-and- Polymer ）、そして私はPolymerの標準ベースの側面だけが理由であると想像できます。 YouTubeページの中央にあるそのYouTubeプレーヤーは、コンテンツソースをプロパティとして取り込むコンポーネントに変えることができ、突然、YouTubeプレーヤーをページに埋め込もうとする人は、YouTubeが使用しているものとまったく同じプレーヤーコードを文字通り使用できます。 、そして彼らは自分のページにタグを貼り付けるだけでそれを行うことができます。
まとめ
確かにReactの魅力的な側面が確かにあるのは確かです。使用しているのがReactだけの場合は、いくつかのウィジェットといくつかのコンポーネントを作成し、それらを宣言的に再利用できます。しかし、Reactは、ブラウザ内でブラウザを作成して複雑なメカニズムを構築するのではなく、Webコンポーネント標準の一部を使用してその機能を実現するのであれば、はるかに優れていると思います。すべてを同期させます。