- タイプスクリプト！私たちがずっとやってきたプレーンでシンプルなJSコードを書く代わりに、より良いパフォーマンスを得るためにtypescriptを使うことが本当に必要ですか？typescript がパフォーマンスの向上に役立つというコメントをいくつか見つけました。
Angular2 を使用するためにTypeScript は必要ありません。
表示されるほとんどの例では、JavaScript が使用されます。
classes(ES6)decorators(ES7/Typescript)types- (タイプスクリプト)
ただし、ブラウザーはこれらの機能をまだサポートしていないため、すべての Angular2 ソースを ES5 にトランスパイルする必要があります。
したがって、ES5 では次のようになります。
classesプロトタイプを拡張することで偽装できますdecoratorsラッパー関数を使用して偽装できますtypesそもそも必要ではありません。安全のために追加されたシンタティック シュガーです。
既存のユーザーが実験的/最先端の標準を使用するリスクを継承すると期待するのは非現実的です。そのため、このドキュメントでは、ES5、ES6/7、および Typescript での Angular2 アプリの作成について説明しています。
余談ですが、私は個人的に TypeScript を使用したくないと思っています。Traceur は @decorators の実験的な拡張機能をサポートするように構成でき、system.jsは提案されたes6-moduler-loader仕様のポリフィルを提供します。
Angular2 Documentationを見てください。
- ES6 の機能。angular 2 は多くの es6 機能を使用するため、運用アプリケーションでそれを開始する前に、すべてのブラウザーが少なくとも angular 2 で必要な機能をサポートするまで待つ必要があることを意味します。
すでに述べたように、ES6 はまだすべてのブラウザーで正式にサポートされているわけではありません。たとえそうであったとしても、ほとんどのサイトでは、古いブラウザーに後方互換性を提供するためにポリフィルが必要です。
の優れた機能の 1 つは、es6-module-loader依存関係をその場で動的にロードできることです。Angular2 のベータ版が終了する頃には、これを機能検出戦略としてアプリに簡単に組み込むことができるはずです。
- Web コンポーネント。angular 2はWebコンポーネントを作成する機能を提供し、独自の作成（ポリマーを使用）に関するいくつかのブログに出くわしたので、私たちのチームがそれらを作成するのはどれくらい難しいでしょうか? それとも、古いディレクティブの作成に固執するほうがよいのでしょうか?
Angular2 固有の Web コンポーネントを使用する必要があるかもしれませんが、難しいことではありません。その理由は、Angular2 は単なるフロントエンド Web フレームワークではありません。また、同形 (つまり、バックエンドで事前レンダリング)、ネイティブ、およびモバイル アプリにも使用できます。つまり、DOM に直接触れることはお勧めできません。
コンポーネント自体の作成に関しては... Angular2 で他のコンポーネントを作成するのと同じです。タイプ (つまり、モデル、ビュー、コントローラー) ごとにコードをグループ化する古い MVC モデルとは異なり、コンポーネント モデルでは、コンテキストごとにコードをグループ化することが推奨されます。
再利用可能なコンポーネントをインポートするときは、それを使用するために必要なディレクティブ、サービスなどが付属している必要があります。
例については、私が作成しました。GH からレポを直接クローンするだけでなく、コードを JSPM 経由で直接インストールしてインポートすることもできます。
importコンポーネント クラスをビューに追加するだけで、テンプレート内のdirectives任意の要素が機能します。<ng2-markdowm>それはそれほど簡単ではありません。
- パフォーマンス。angular と angular + react と angular 2 の良い比較を提供する Angular + React のこのビデオを見てきました。 angular + 反応アプリをビルドして、angular 2 が安定するのを待つか、ブラウザーが angular が使用する es6 機能をサポートするのを待つことを回避します。
Angular2 で導入された 3 つの主要なパフォーマンスの改善があります。
1. 双方向データバインディングはデフォルトではなくなりました
データ バインディングを必要とする要素は、テンプレートで明示的にマークする必要があります (つまり、心配する必要はありません。新しい構文により、これが非常に簡単になります)。その結果、DOM でダーティ チェックを行うために必要なオーバーヘッドが大幅に削減されます。
つまり、HTML マークアップでの $scope、$scope.apply()、および奇妙なスコープ ルールはもう必要ありません。代わりに、カスタムの階層が<elements>Angular2 コンポーネントで定義されます。
2. Angular2 は仮想 DOM を活用します
jQuery により、DOM を直接操作することが非常に簡単になりました。その結果、経験の浅い開発者が DOM をスラッシングし、頻繁な増分更新によってレイアウトのリフローをトリガーすることも非常に簡単になりました。
VDOM は、基本的に DOM の簡略化されたメモリ内表現です。増分更新は VDOM に直接適用され、後で実際の DOM にバッチで適用されます。
ネットワーク リクエストは別として、DOM 操作は JavaScript の最大のパフォーマンスの弱点です。一方、VDOM は桁違いに高速です。開発者が DOM への更新を手動でバッチ処理して「ベスト プラクティス」に従うことを期待する代わりに、Angular はバッチ処理を透過的に処理します。
DOM 操作が少ない = UI レンダリング/リフローが少ない = ユーザー エクスペリエンスの応答性が大幅に向上します。
3. Angular2 はバックグラウンド ワーカーで実行されます
これはまったく新しい概念ではありません。デスクトップ GUI は何年もの間このように機能してきましたが、HTML5 バックグラウンド ワーカーの導入は技術的に不可能でした。
ほとんどのデスクトップ アプリケーションでは、メイン コンテキストは同期的に実行され+、UI は独自の別のスレッドで非同期的に実行されます。これにより、アプリケーションがメイン コンテキストで何を行っているかに関係なく、ユーザー エクスペリエンスがレスポンシブになります。
+注: これは必ずしも正しいとは限りませんが、わかりやすくするためです。
ブラウザでは、すべての実行がメイン コンテキストで発生します+。つまり、Javascript が CPU 負荷の高い操作をブロックする必要があるたびに、ユーザー インターフェイスがユーザーに応答しなくなります。これは理想的ではなく、お粗末で一貫性のないユーザー エクスペリエンスをもたらします。
+注: 実際には、ブラウザの実装は大きく異なりますが、物事をシンプルに保つことができます。
Web ワーカーを使用すると、DOM+ 以外のすべてをバックグラウンド ワーカー コンテキストにプッシュできます。理想的には、Javascript は UI の応答性にほとんどまたはまったく影響を与えないようにする必要があります。
+注: DOM の状態は、レンダラーからアクセスできる必要があります。
この移行の副作用の 1 つは、Angular2 アーキテクチャが UI/DOM から完全に切り離されたことです。つまり、同じ Angular2 コードでネイティブに実行される他のプラットフォーム (IOS、Android、SmartTV など) 用の UI アダプターを作成できるようになりました。
反応する
私が知る限り、React は Angular と同じパフォーマンスの改善をすべて使用しています。彼らは VDOM を使用して更新をバッチ処理し、他のプラットフォームへのネイティブな移植性について言及したので、Angular と同じアーキテクチャ変更を行ったと思います。
正直なところ、バックグラウンド処理を使用して UI を解放することは、デスクトップ アプリケーションと同等の機能を実現するための進化のもう 1 つのステップにすぎません。
Angular2 と React
動画を最後までもう一度見ることをお勧めします。プレゼンターがコードを書いたときに失敗したため、ライブ デモは正直な比較にはなりませんでした。
そうは言っても、どちらが速いかは問題ではありません。どちらも劇的に速くなるわけではありませんが、他の UI フレームワークと比べて応答性とスケーラビリティが大幅に向上します。
アップデート：
質問への回答を改善するために、Web コンポーネントに関するセクションを書き直しました。