JavaScript MVCフレームワークの未来

Omの紹介

ClojureScriptコーナーでは、これを長い間知っています。すべてのデータ構造は不変であり、Javaで記述されたClojureの元のコレクションに基づいています。 現在、最新のJavaScriptエンジンは非常に最適化されており、JVMの0.4倍以内でこれらのコレクションのパフォーマンスをよく観測しています。



停止、停止、停止。 しかし、不変データ構造のパフォーマンスはJavaScript MVCと何の関係がありますか？ -必要不可欠です。



説明するのは簡単ではないかもしれませんが、それでも試してみます。 実際、新しいOmライブラリで提供される不変のデータ構造により、MVC Backbone.jsなどの一般的なJS MVCフレームワークよりもはるかに効率的にアプリケーションを作成できます（手動最適化なし）。 Omは、Facebookの優れたフレームワークReact上に構築されています。 聞いたことがないなら、JSConf EU 2013のビデオを見ることをお勧めします。興味深い事実は、不変のコレクションのために、OmはReactを修正なしで使用する場合よりも良い結果を示すことができるということです。



以下に示すベンチマークは、OmがUIを構築するための世界最速のライブラリであることを証明するために作成されたものではありません。 これらは、グローバルに最適化できない決定が非常に頻繁に行われることを示すために作成されました。 また、現代のフレームワークは、多くの場合、ユーザーがパフォーマンスの問題につながる決定を下す際に、少量のドキュメントとヘルプを提供します。



もちろん、アプリケーションの問題を次々に解決するのは面倒です。 ただし、複雑なレベルのコンポーネント抽象化を提供するOmのようなフレームワークを使用できます。 これにより、多くの単純で時間のかかる手動の最適化方法を取り除くことができます。

ベンチマークゲーム

ブラウザでOm TodoMVCを開き、最初のベンチマークを起動します。 200個のリストアイテムを作成し、Safari 7の11インチMacbook Airで120ミリ秒で実行します。



Backbone.js TodoMVCを開き、同様のベンチマークを実行します。 私のマシンでは、ページは約500ミリ秒でレンダリングされました。



ChromeとFirefoxでは、OmはBackbone.jsの約2〜4倍の速度で結果を表示します。

すべてのリストアイテムを切り替えようとすると、Omはすぐに切り替えますが、同様のアクションでBackbone.jsはわずかにフリーズします。

この違いは、 requestAnimationFrameイベント中にOmがページを再描画したためと思われます。 これにより、アプリケーションを大幅に最適化できます。



これらのベンチマークについて、Chrome Dev Toolsのプロファイラーを見てみましょう。 最適化されていないBackbone.jsと比較して、React / Omの初期設定の動作には大きな違いがあります。



反応/ Om：





Backbone.js：





私の意見では、React / Omグラフは、グローバルな最適化と改善の機会がはるかに多いことを示しています。



わかりました、すばらしい仕事です！ しかし、それでも... 3つの主要なブラウザの生産性が2〜4倍向上するという事実だけが、多くの人の関心を引くはずです。 特に、不変のデータ構造のおかげでこのレベルに達していることを考慮してください。 Twitterで30〜40倍の増加はありません。



次に、2番目のOmベンチマークを試してください-200個の要素を作成し、5回すべて切り替えてから削除します。 MacBookのSafari 7では、すべて5ms程度で発生します。



次に、Backbone.jsを実行します。 最初にすべてのアイテムを削除してから、2番目のベンチマークを試してください。 私のマシンでは、Safariブラウザーで4200ミリ秒実行されました。



これはどのように可能ですか？ -シンプル。



Omはほとんど不要な作業を行いません。 データ、ビュー、コントローラーロジックは相互接続されていません。 データを変更するとき、すぐにページをレンダリングすることはありません。 requestAnimationFrameイベントまで再描画の変更を単に延期します。 基本的に、OmはブラウザとしてGPUとして動作します。



多くのJS MVCアプリケーションはBackbone.js TodoMVCアプリケーションのアーキテクチャに従い、モデルとビューの変更、およびLocalStorageでのアプリケーション状態のシリアル化など、他の独立した部分をリンクしていると想定しています。 アプリケーションのアーキテクチャを適切に構築するために必要なサポートを提供するフレームワークはわずかです。 実際、ほとんどのフレームワークは文字列テンプレート、CSSセレクター、およびDOMの直接操作に基づいているため、この状況は驚くことではありません。 Omは、場所指向のプログラミングスタイルやその他の潜在的なパフォーマンスの脆弱性の兆候をすべて残しています。



もちろん、ReactでBackbone.jsまたはお気に入りのJS MVCフレームワークを使用できますが、これは大きなメリットの 良い組み合わせです。 ただし、イベント指向のMVCシステムは信じていません。 そして、上記のベンチマークはこれを裏付けています。 モデルとビューを分離することは、最初の重要なステップにすぎません。



これが、現在のJS MVCフレームワークのファン、さらにはネイティブのJavaScriptとjQueryのみを使用することを信じる人々に、何らかの考えの理由を与えることを願っています。 上記では、より複雑なインターフェースを構築するために、遅いデータ構造を使用するJavaScriptコンパイル言語が競合他社よりも最終的に高速であることを示しました。 最良の結果のリストの一番上にあるのは、他のすべてのフレームワークと同じ機能を備えたOm TodoMVC 、 最大 260行のコード（すべてのテンプレートを含む）、63Kのgzip圧縮された軽量化です（これには、React-27K、標準ClojureScriptライブラリ、 core.async、ルーティングライブラリ、およびGoogle Closureのいくつかのヘルパー）。



JavaScript開発者の方は、Reactをよく見てください。 将来、Reactをmoriなどの永続的なデータ構造の使用を提供するライブラリにリンクすると、JavaScriptアプリケーションをOmが提供する柔軟で非常によく調整されたアーキテクチャに導くことができると思います。 不変のデータ構造はより多くのガーベッジを生成するという事実にもかかわらず、現代の開発者がこの問題に対処することを期待しています。 また、ポケットに入れて持ち運ぶデバイスのパフォーマンスは常に向上しています。



技術的な説明が続きます。

仕組み

DOMツリーの変更とクエリはパフォーマンスの大きな脆弱性であり、Reactは表現力を犠牲にしてこれらの場所をバイパスするアプローチを使用します。 適切に設計されたオブジェクト指向インターフェイスを提供しますが、内部を見ると、機能プログラマの実用性の観点から作成されたソースが表示されます。 DOMツリーの仮想バージョンを生成し、アプリケーションで変更が発生するとすぐに、OmはDOMツリーの仮想バージョン間の変更を定期的にマークします。 実際のDOMツリーに必要な最小限の変更を取得するために使用されます。



Reactには、コンポーネントによって表される仮想DOMの違いを計算するために使用される、かなり重要な関数shouldComponentUpdateがあります。 falseを返す場合、Reactはこのコンポーネントの子を計算しません。 したがって、Reactは仮想DOMツリーを徐々に構築して、変更が必要な要素に関するデータを取得します。



JavaScript開発者は通常、オブジェクトと配列を変更するため、shouldComponentUpdateのデフォルトの実装は控えめすぎます。 したがって、変更されたコンポーネントのプロパティを確認するには、オブジェクトと配列を手動で確認する必要があります。



JavaScriptオブジェクトを使用する代わりに、OmはClojureScriptのデータ構造を使用します。これは、ご存じのとおり、変更できません。 これに基づいて、リンクが同等かどうかの最速チェックを使用して、shouldComponentUpdateを実装するコンポーネントを提供できます。 これは、変化した構造を対数時間でいつでも決定できることを意味します。



したがって、setStateのような操作は必要ありません。setStateは、ツリーノードへの効率的な更新と、優れたオブジェクト指向スタイルをサポートするために使用されます。 Omでツリーノードを更新する場合は、トップポイントから開始する方が常に高速です。なぜなら、途中でリンクを比較するだけだからです。

また、ツリーの最上部から常に再描画するため、更新の組み合わせは簡単に実装できます。 Reactはこれらのケースを処理するように設計されているため、Reactとの複合更新のサポートについて心配する必要はありません。



最後に、データの各部分には常に初期UI状態があるため、アプリケーションのすべての重要な状態を単純にシリアル化できます。 Om UIの状態は常にシリアル化可能であるため、シリアル化プロトコルに関する心配はもうありません。



また、Om UIはすぐにステータスを返します。 任意の状態をメモリに簡単に保存でき、いつでも好きなときに戻ることができます。 ClojureScriptのデータ構造はメモリ共有を使用して実装されるため、これはメモリの効率的な使用です。

最終的な考え

結論として、JavaScript MVCフレームワークの現在の世代には、将来多くの可能性があるとは思いません。 座って考えると、React / Omに似たものが得られると思います。 これにより、シンプルさ、パフォーマンス、表現力の最適なバランスを実現できます。 これまで知られていなかったものは何もありません...ブラウザをリモートでページをレンダリングする手段として認識し、そこにゴミを保存するのをやめれば、すべてがずっと速く動作します。 おなじみのようですね。 はい、コンピューターグラフィックプログラミングのように。