JSフレームワークの概要。 JavaScript MVCのジャングルを旅する。 パート2

（クライアントで重要なJSの役割を持つプロジェクトのライブラリーの比較と選択に関するEddie Osmaniの記事の翻訳の終わり。）
最初の部分の内容：

■MVCとは何ですか？
■JS MV *フレームワークが必要になるのはいつですか？
■MV *はどこで必要ですか？
■選択の問題：オプションが多すぎますか？
■TodoMVC：学習と比較のための一般的なアプリ
■フレームワークを選択するための提案された基準
■ DojoとJavaScriptフレームワークの複雑さ
■TodoMVCコレクション（Todoテストアプリケーションの実装が行われるフレームワーク）

■どのフレームワークをいつ使用する必要がありますか？

フレームワークの検索範囲を絞り込むために、サンプルのいくつかのオプションを選択するのに役立つ機能に基づいて、高レベルのフレームワークの選択を提供したいと考えています。

アプリケーション内のタスクを分離するための最小限のソリューションを備えた柔軟なものが必要です。 一定の接続性とREST同期、モデル、ビュー（コントローラー付き）、イベント駆動型データ交換、テンプレート、およびナビゲーション（URLアンカー経由）をサポートします。 モデルが変更されると、ビューはすぐに変更されます。 自分でアーキテクチャを適切に管理したいと思います。 理想的なのは、多くの大企業が自明でないアプリケーションのためにソリューションを使用した場合です。 私は複雑なものを得ることができるので、フレームワークの周りの活発なコミュニティを見たいと思います。あなたはいつでも簡単な質問ではありません（ Marionette、Chaplin、Aura、Thorax ）。 ビルドツール（ grunt-bbb、brunch ）を持つことも理想的です。 Backbone.jsを使用します。

Web用のデスクトップレベルのアプリケーションの基礎が必要です 。 このフレームワークは、すべてを手動で組み立て、永続性（ファイルのメタファーを持つ永続オブジェクト、デバイス）、計算されたプロパティ、および自動更新テンプレートを必要としない、高レベルのモジュール式MVCである必要があります。 これは、手動構成ではなく、多くの隣接するフレームワークとの互換性のあるインテリジェントな状態管理に必要です。 適切なドキュメント、使用パターン、ビルドツール（ ember.gem、ember for brunch ）を使用する必要があります。 Ember.jsを使用します。

テンプレートをオンザフライで接続、ナビゲーション、主要なライブラリ（ jQueryやDojoなど ）との統合、高速で、大規模アプリケーションではまだ動作しない可能性のあるMVCコンポーネントの継承をサポートする、軽量なものが必要です。 複雑なアプリケーションを作成した経験のある人が行う場合に最適です。 CanJSを使用します 。

Viewを使用して、アプリケーションのルールに従ってHTMLとコンポーネントをカスタマイズすることにより、ユーザーの行動に関するデータを収集する宣言型ラッパーが必要です。 MVCまたはそのバリアントを介したURLナビゲーションとタスク共有を使用した、シンプルなテストシステムのサポート。 これにより、HTMLで独自のDSL （サブジェクト指向言語）を構築するためにHTMLコンパイルを行う関連ライブラリにカスタマイズされたアプローチが提供されます。 これは、Webコンポーネントなどのネットワークプラットフォーム要素に必要です。 まだ組み立てツール（ 角度付きシード ）が必要です。 AngularJSを使用します。

膨大なアプリケーションの優れた基盤が必要です。これには、実績のあるウィジェットのインフラストラクチャ、ポストローディングを備えたモジュールが必要です。 おそらく-非同期でシンプルなCDNとの統合、モジュールとウィジェット（グラフ、チャート、テーブルなど）の選択、優れた多言語（i18n、l10n）。 複雑なアーキテクチャを作成するには、OOP、MVC、およびブロックビルダー（モジュール）のサポートが必要です。 Dojoを使用します。

YUI拡張機能を使用するために最適化されたものが必要です 。 モデル、ビュー、ナビゲーションのサポートにより、情報をさまざまな方法で表示したり、表示オプションを相互に切り替えたりするアプリケーションを簡単に作成できます。 これは、ウィジェット/コンポーネントを備えた完全なソリューションであり、アプリケーションのアーキテクチャを記述することができます。 ビルドツール（ yuiproject ）が存在する場合がありますが、他のツールの代わりになる可能性があります。 YUIを使用します。

MVC、イベント、ナビゲーションをサポートしながら、コンパクトなままで、アプリケーションを構築する際に柔軟で、非同期インターフェイスで依存関係のないシンプルなものが必要です 。 詳細なドキュメントとともに、CoffeeScript用に最適化されています。 Spineを使用します。

データモデルと宣言型バインディングスタイルに基づいて複雑な動的UIを構築するツールが必要です 。 モデルが変更されたときのUIの更新では、データトラッキングによる双方向バインディングと依存関係のサポートを使用します。 これは、任意のフレームワークまたは既製のアプリケーションでも使用できるはずです。 組み込みのテンプレートと簡単な拡張性が必要です。 KnockoutJSを使用します。

シンプルなWebアプリケーションやサイト用のものが欲しい 。 私はそこに多くのコードがあるとは思わないので、あまり干渉しません。 タスクに集中するためのクロスブラウザ。 簡単なイベント処理、リモートサービスとのやり取り、拡張性、膨大なプラグインセット。 jQueryを使用します。

■開発者は、最も人気のあるフレームワークについてどう思いますか？

TodoMVCのMV *フレームワークとこの記事の研究の一環として、開発者を対象に調査を実施しました。 彼らはどのフレームワークをより頻繁に使用しますか、そして最も重要なのは、なぜそれを推奨するのですか？ このフレームワークがプロジェクトになかったら、彼らは何を感じますか？

最も興味深い答えのいくつかを次に示します。

Ember.js

長所：ライブパターンと監視可能なオブジェクトの組み合わせにより、JavaScriptの動作が変わりました。 最初は少し混乱しているように見えるかもしれませんが、コードの責任を適切に分担して作業を終了します。 すべてを説明したらすぐに、かなり複雑な機能を追加するには数行かかることがわかりました。 Emberがなければ、これらの同じ機能を実装するのは非常に困難です。

短所 ： Emberは引き続きバージョン1.0に到達する必要があります。 ルーターやEmberデータなど、多くのものがまだ動いています。 新しいWebサイトは非常に便利ですが、他のフレームワーク、特にBackboneのようなEmberのドキュメントはありません。 フレームワークに多くの魔法があるため、少し怖いです。 何かが壊れた場合、その理由を正確に把握することはできません。 また、 Emberのエラーメッセージはしばしば不正確です。

「対象」 ：主な要因：
a）ボイラープレートコード（バインディング、計算されたプロパティ、優れたプレゼンテーションコントロールレイヤー）を回避できる機能。
b）開発チーム。 私はルビストであり、イェフダ・カッツの価値を知っています。 私は男を信頼する=）。

短所 ：ドキュメント。 Emberに優れたドキュメント、チュートリアル、 Backbone、Angularなどのフレームワークなどのスクリーンキャストがないことは本当に残念です。 現在、完全ではないドキュメントを探しているコードを探しています。

短所 ：構成契約。 エンバーはあなたのために多くの小さな仕事を取ります。 これは、最近ではクライアント側のアプリケーションを構築する最も簡単な方法です。

短所 ：学習のしきい値。 Backboneのような他のフレームワークのために存在する初心者向けのチュートリアルが多くないのは、一部は小さなコミュニティによるものですが、バージョン1.0に備えたコードモビリティのためだと思います。

長所：バインドの容易さ、コントロールとの緊密な統合、独自のコードの簡単なモジュール性。

短所 ： Emberデータとの安定した統合と、REST APIと同期された統合されたlocalStorageサポートが必要です。これらはすべて夢のようなものです。

Backbone.js

「対象」 ：シンプル-4つの主要コンポーネント（コレクション、モデル、ビュー、ルーター）のみ。 StackOverflowの巨大なコミュニティ（エコシステム）と多くのソリューション。 MarionetteやVertebraeなどの高次フレームワーク-内部に多くのスマートコードがあります。 誰かが「低レベル」を好む-あなたは定型的なコードをたくさん書く必要があるが、あなたのために作られたアーキテクチャを手に入れなさい。

「反対」 ：継承が好きではありません-親オブジェクトの内容が新しいオブジェクトにコピーされます。 プロトタイプの継承が必要です。 ドックの例で「現実のシナリオ」を読んでいないことがあります。 TODOを使用したチュートリアルを読んだ後、少し複雑なアプリケーションを作成する方法を見つけるために、多くの調査を行う必要があります。

DocumentCloud（ Backbone、Underscore ）のプロジェクトでは、 AMDの公式サポートを使用しません[ただし、これはRequireJS 2.0の新しいshim（）メソッドの問題ではありません]。

「対象」 ： Backboneの最初の不可解な研究の後、これはすべて非常に実用的であることが判明しました。 実用性-適切に管理され、軽量で、常に更新されるライブラリーが適切な環境にあります。 Underscore、jQuery / Zepto 、私のスタジオのほとんどのプロジェクトで使用できるツールのフレンドリーなサポート。

短所 ： Backboneの操作方法に関するチュートリアルの数は、バージョンによって異なります。 私は他の開発者にBackboneを見てもらい、バージョン0.3のコードを書くことにしました。 知らずに。 問題はありませんが、 Backboneはそれを修正できますが、これはおそらくそれに関連する主な不便です。

理論的には、何でも同じことが言えますが、 Backboneでは、目の前で定期的に繰り返されます。 地獄、私は一ヶ月前に古代の方法と技術を使った記事を見さえしました。

フレームワークに対する私の態度に関係なく、合理的な編集とアプローチでコミュニティが修正できるのはこの問題です。 これが、コミュニティのサポートのために、 Backboneが私を尊敬するに値する理由です。

「For」 ：合理的な制限なしに最小限の抽象化のみを提供します-ニーズに応じてプロジェクトを組み立てることを可能にします。

短所 ： Backbone.syncを書き換えるか削除します。 これはHTTPプロトコル用に構築されており、WebSocket機能にうまく適応しません。

「のために」 ：働き始めるのは非常に簡単で、知るための良い方法を提供します。 それは比較的よくカスタマイズ可能であり、それを使用している他の多くの人々が助けることができます。

短所 ：デフォルトのビューバインディングがないという事実（指定できますが）。 単一のプロパティが変更されたときにビュー全体を更新することは不経済です。

REST APIには多くの利点がありますが、多数のレコードには問題があり（確かに、RESTの問題は独自のものですが、まだ残っています）、さまざまなタイプの操作を処理するためのさまざまなURIスキームを取得する際に不快な問題があります。

Angularjs

賛成 ：
a）双方向のデータバインディングは非常に強力なアプローチです。 一連のイベントを整理するのではなく、モデルと状態についてもっと考えます。 モデルは唯一の真実の源です。
b）スピード。 AngularJSは簡単にダウンロードできます。 innerHTMLの代わりにノードを構築することでテンプレート化され、理論的には生産性が向上します。
c）最新のブラウザおよび/またはむしろth約によって導かれている場合は、jQueryなしで行うことができます。

短所 ：モデルによって変更されるUI状態遷移を示すことができるようにしたいと思います。 つまり、 ng-show / ng-hideを使用する要素は、単純な宣言で非表示または折りたたみたいと思います。

長所 ：それは非常に直感的で、優れたドキュメントがあります。 データバインディング、ビューベースのHTML、スコープへのアプローチが気に入っています。 Backbone / ThoraxからAngularに切り替えましたが、振り返ることはありませんでした。 Chromeの新しいBatarangアドオンはChrome開発者ツールと統合され、 Angularデータ構造へのリアルタイムアクセスを提供します。

短所 ：ドラッグアンドドロップなどの機能の組み込みサポートが必要ですが、これはGitHubで利用可能な外部コンポーネントを介して追加できます。 再利用に適したサードパーティのコンポーネントをもっと見たいです。 これは、 AngularJSを取り巻くエコシステムがより成熟するための時間の問題であり、 jQueryのようなコミュニティのように、アクセス可能で多様になると思います。

長所：定型コードを大幅に削減し、コンポーネントを介してコードを再利用できるようにし、多くの複雑な機能がHTMLで属性を記述するのと同じくらい簡単になるようにHTML構文を拡張し、依存関係の完全な説明のおかげでテストが非常に簡単になります。
DOMを直接制御することなく、 jQueryを使用せずに重要なアプリケーションを作成できます。 そのような楽器を作ることは本当のスキルです。

「Against」 ：彼女の学習しきい値はBackboneの学習しきい値（マスターにとって非常に簡単です）よりもわずかに高いですが、結果は価値があります。 ドキュメントが改善される可能性があります。

ノックアウト

長所 ：常に使用するわけではありませんが、 KnockoutJSは単一ページのアプリケーションに最適です。 オブジェクトを変更するための非常に簡単なサブスクリプション。 観測可能な配列を使用する、いわゆるバックボーン 「コレクションビュー」用のはるかに優れたAPI。 また、観察されたオブジェクトのエフェクトなどのカスタムイベント

短所 ：APIを拡張するのは難しいと感じています。 大規模なアプリケーション（コミュニティのサポートなどを含む）でBackboneを選択することをお勧めします。

「For」 ：データバインディングのメカニズムとその便利な使用が好きです。 特に、テンプレートが制御ロジックへのバインドに置き換えられたことが気に入っています。

短所 ：アプリケーション構造に関するベストプラクティスガイドがないのは悪いことです。 フレームワークは、ビューモデルを持っているだけでなく、適切に構造化されたビューモデルを記述するのに役立ちません。 大きなアンマネージ関数で非常に簡単に終了します。

道場

長所 ：構文的に-Dojoは非常に単純です。 これは、通常6 KBのサイズの初期ローダーファイルを使用した動的で堅牢なビルドに適しています。 AMD互換（ブート後）であるため、非常にコンパクトになり、DOMの基本的な作業から複雑なSVG、VML、キャンバスに至るまで多くの拡張機能を備えています。 Dijitウィジェットシステムは 、使いやすさと拡張性に優れています。 これは非常に適切で完全なツールボックスです。

短所 ：dojo / _base / declare機能は100％厳密に管理されたツールではありませんが、下位互換性のためにいくつかのオーバーレイがありますが、これはほとんどDojo 2.0で修正されます 。

「対象」 ：Goodコンポーネント：タブ、データテーブル、フォームマネージャー...すべてのブラウザーで同じ。 働くAMD。 データシミュレータを使用した簡単なテスト。 AMDのおかげで他のフレームワークとうまく統合できます（ JMVCと統合します ）。

短所 ：プロジェクトは、古いコンポーネント用にデフォルトで構成されています。 完全にhtml5ではありません。 ドキュメントはまあまあです。 標準化の悪いシステム（「オンザフライ」でのバインディングなし）。

ゆい

長所 ： YUI3は、Backboneなどのすべての利点を含む、モジュール式で自由に実行できるコンポーネントライブラリです。 私の意見では、バックボーンの概念の一部を改善し、いくつかのことを共有します（たとえば、属性は任意のオブジェクトに混合できる別個のモジュールです-イベントの「モジュール」も混合できます）。

短所 ： YUI3がEmberからの自動配線をサポートしていることを確認したいと思います。 これはエンバーにとって本当に素晴らしい成果だと思います。 そうでなければ、 YUI3は必要なものを見つけることができる優れたコンポーネントライブラリだと思います。 改善されたAMD互換性モジュールローダーを見たい。 今日は問題なく動作しますが、AMDモジュールで新しいプロジェクトを開始し、 YUI3やその他のサードパーティのものをAMDを使用するAMDコンポーネントに挿入できるとよいでしょう。

JavascriptMVC

「対象」 ：すべてのツールが「すぐに使える」状態であり、チームを実行してアセンブリを開始するためだけに残ります。 私は6か月使用しましたが、本当に良かったです。

短所 ：私が見たいのは、次のバージョンの開発をスピードアップすることだけです。 開発者は問題を認識して解決しますが、プロセスは異なる場合があります-修正して解決策を送信したいいくつかの問題については数か月ではなく-その後、パッチを作成してリクエストをプルできます。

マリア

長所 ： Mariaは純粋なMVCを実装するためのフレームワークであるため、MVCフレームワークであることに焦点を当てています。 これ以上でもそれ以下でもありません。 すべてがシンプルです。

短所 ：ソースコードで書かれたドキュメントよりも少し多くのドキュメントといくつかのテストケース。 MariaでのMVCの実際の使用の基本を示すチュートリアルはうまくいきます。

Cujo.js

「対象」 ：実際のアプリケーションの場合、MV *はすぐに使用できるものではなく、最も重要なツールキットはすぐに使用できる場合がほとんどです。 cujo.jsを使用して、ボックスを定義します。

はい、 cujo.jsにはビュー、モデル、コントローラーなどを作成するための高レベルのMV *のような機能がありますが、各アプリケーションは異なり、100％のソリューションになるフレームワークはありません。 cujo.jsは、みんなを喜ばせようとする代わりに、低レベルのツール、アーキテクチャのカスタマイズ、および他のMV *フレームワークを組み合わせて拡張することもできる豊富なプラグインシステムを提供します。

誰かのアーキテクチャにアプリケーションを配置する代わりに、アプリケーションに最適なアーキテクチャを作成します。

「反対」 ：JavaScriptの大部分は完全に準備が整っておらず、大規模なアプリケーションを開発するためのトレーニングを受けていません。 それらのほとんどは、設計パターンとアーキテクチャの存在を認識していません。

cujo.jsは他のものとは非常に異なるため、APIとコードサンプルへの単なる参照以上のものが必要です。 チュートリアル、教材、および教育用の例がなければ、 cujo.jsは見た目が奇妙で気のめいるように見えますが、すぐにドキュメントが作成される予定です。

Extjs

長所 ： ExtJSはExt Designerで最適に機能すると思います。 他のGUIフレームワークから分離されるため、プログラマー以外のユーザーがUIをモックでき、プログラマーは空白を埋めることができます。 私の意見では、 BackboneなどのMVCフレームワークとの比較は間違っています。ExtJSの強みは、軽量のWebアプリケーションではなく、リッチなGUIを作成することにあります。

商用、リモートオフィス、リッチアプリケーションの場合、JavaScriptソリューションに関してはExtJSが最適な選択肢であると思います（ GWTなどを除く）。 パブリックWebアプリケーションの場合、マークアップをより詳細に制御できる（そして完全にグレースフルデグラデーションを実現する）ものがあります。

「Against」 ：他の多くの現代の構造フレームワークよりも高いエントリーしきい値を持っています。 , ExtJS , , , .

«» : , ExtJS 4 — MVC . Dojo , , ExtJS , .

ExtJS , , HTML. , , HTML .

, , - . , DOM .

«» : . ExtJS , , . , , — .

«» : ExtJS — RIA . , , HTML JavaScript, . ExtJS , HTML, , , , UI.

«» : … , , , . , — , . , Sikuli , Selenium .

Batman

«» : . — .

«» : , , Shopify , , .

■実験することを恐れないでください

, . ( ) , .

: , Batman.js . CoffeeScript- Batman.js , . , . , , Batman.js , .

, , , .

■ MV*

MV* , , , Views, , . .

, MVC, .

. , Backbone , , . Backbone (, ), . Initializer .

, MVC . — , , .

, Marionette . — , ( ) , .

Marionette TodoMVC, Backbone , MV*.

Derick Bailey — Marionette

JavaScript MVC, . , API , , .

, , , MV* . « », — , - . , , JavaScript .

J2EE. , «PHP Objects, Patterns, and Practice», Matt Zandstra, , ! J2EE , , URL . , , , .

J2EE , .

Dustin Boston — Aura

■おわりに

, -, : , . , .

TodoMVC . , , , , .

, .

, TodoMVC Sindre Sorhus .

: Addy Osmani — - Chrome Google. JavaScript, : « JavaScript » " Backbone ", Modernizr JQuery . " Yeoman " — .