🧗🏾 🧑 💠 JSフレームワークの概要。 JavaScript MVCのジャングルを旅する。パート1 😉 🎐 ▫️

（2012年7月27日）

ネイティブWebアプリケーションを作成するとき、DOMライブラリ（ jQueryなど）と少数のサービスプラグインだけで作業できる~~神のような~~気分になりやすいです。ネストされたjQuery戻り関数の山と、アプリケーションではなく構造のない分散DOM要素という形で、すぐに問題が発生します。

要するに、私たちはスパゲッティコードで立ち往生しています。幸い、最新のJSフレームワーク（機能に加えて、コードを整理するためのルールを指定するライブラリ-およそTransl）があります。これは、プロジェクトの構造と組織を維持し、将来の保守性を促進します。

■MVCとは何ですか？

これらの最新のライブラリにより、開発者はMVC （Model-View-Controller）として知られるデザインパターンのバリエーションを使用してコードを整理する簡単な方法を得ることができます。 MVCは、アプリケーション内のタスクを3つの部分に分割します。

モデル （ロジック）は、アプリケーションの問題指向の知識とデータを表します。それらは、ユーザー、写真、メモなど、モデル化できるデータのタイプと考えてください。モデルは、現在の状態を観察しながら何かについて通知する必要があります。

ビューは通常、レイアウトやテンプレートなどのユーザーインターフェイスとして設計されていますが、インタラクティブではありません。モデルの存在を認識している必要がありますが、モデルと直接通信することはできません。

コントローラー （ディスパッチャー）はアプリケーションの入力データ（クリック、ユーザーアクション）を処理し、ビューは処理の出力製品と見なすことができます。コントローラーがモデルの状態を変更した場合（たとえば、写真のキャプションを編集した場合）、ビューは直接変更されません。これは、モデルとビューの関係が機能する場合です。

コードの構造化に役立つJavascript MVCフレームワークは、必ずしも説明されているパターンに厳密に従うとは限りません。一部の人にとっては、コントローラーはプレゼンテーション（ backbone.js ）を担当し、自信を持ってコンポーネントを混合し、これがこれまでよりも良いと信じています。

したがって、このようなフレームワークをMV *パターンと呼びます。つまり、ビューとモデルはそうである可能性がありますが、 （コントローラー-およそTransl。だけではなく）別のものが追加されます。

備考 MVP（モデル-ビュー-プレゼンター）およびMVVM（モデル-ビュー-ViewModel）と呼ばれるMVCのバリアントがあります。 あなたがこれらの概念に不慣れであり、それらを信仰に乗せることに反対しているなら、心配しないでください。 パターンに慣れるには時間がかかります。 ヘルプが必要な場合に備えて、オンラインチュートリアル「 Learning JavaScript Design Patterns」でそれらについて詳しく説明しました。

■JS MV *フレームワークが必要になるのはいつですか？

1ページのアプリケーションを構築する場合、または複雑なユーザーインターフェイスを作成する場合、または単にHTTPリクエストの数を減らす場合、おそらくBackboneやEmberのようなMV *フレームワークの構造の多くの部分を発明するでしょう。

作業の最初に、スパゲッティコードを回避するための何らかの~~自転車~~メカニズムを提供するアプリケーションフレームワークを記述することはそれほど難しくありません。しかし、これは「ある種の」 バックボーンを書くことほど難しいことではないと言うことは、あまりにも間違っているでしょう。

構造化アプリケーションには、DOM操作のバインド、テンプレート化、および関係の表示よりもはるかに多くのことがあります。成熟したMV *フレームワークには、通常、作成する多くの部分が含まれるだけでなく、将来の問題に対する解決策も含まれます。これにより時間を節約できますが、過小評価することはできません。

■MV *はどこで必要ですか？

APIと通信するため、またはデータを表示または管理する主な負担がブラウザーにあるバックエンドデータを処理するためのアプリケーションを作成している場合、JavaScript MV *フレームワークが役立ちます。

この種のアプリケーションの良い例は、 Google DocsとGMailです。通常、このようなアプリケーションは、一般的なタスクのすべてのスクリプト、スタイル、およびマークアップをペイロードに一度ロードしてから、ページのバックグラウンドで多くの小さなアクションを実行します。これらは、メールや文書を読むことから手紙を書くことへの移行であり、新しいページをダウンロードする必要はまったくありません。

しかし、大量のビュー（ページ）用のサーバーを必要とするアプリケーションを構築し、共有に小さなJavaScriptまたはjQueryを使用する場合、MVパターンは致命的です。もちろん、ビューの部分表示が単一ページのアプリケーションでうまく動作する可能性のある複雑なアプリケーションがウェブ上にありますが、それ以外の場合は、より単純なロードメカニズムを選択する方が適切です。

■選択の問題：オプションが多すぎますか？

過去数年にわたり、JavaScriptコミュニティはルネッサンスのようなものを経験し、さらに複雑で膨大なアプリケーションを構築してきました。それらのスタイルは、C ++、Javaで構築された古典的なソフトウェアアーキテクチャとは非常に異なり、Web開発用の言語（PHP、Python、.Netなど）とともにWebでも使用されます。その結果、他の言語で見たものからアプリケーションを構築するというアイデアを借りることがよくあります。

私のトピック「 JavaScript MVC分類：虐待または開発？ （Eng。） 、JSアプリケーションを構築するためのツールの選択肢が多すぎるという疑問を提起しました。問題の一部は、さまざまなJavaScript開発者がスケーラブルなアプリケーション（MVC、MVP、MVVM）を編成する方法に起因していますか？それとも何か？毎週、膨大な量の新しいMV *フレームワークが生まれています。なぜなら、「正しい方法」が存在する場合、それを私たち全員が探しているからです。多くの開発者はそうではないと考えています。

「Yet Another Framework Syndrome」（またはYAFS）としてよく登場する新しいフレームワークを選択します。革新として、何かが確かに歓迎されますが、YAFSは開発者がアプリケーションの作成を開始するときに大きな混乱とフラストレーションにつながる可能性があり、30のツールを手動で評価してあまり不適切でないものを選択する必要があります。一部のフレームワークの違いは、区別するのが難しくないにしても、非常に微妙です。

■TodoMVC：学習と比較のための一般的なアプリ

（4月にロシア語でメモがありました： habrahabr.ru/post/142301 ）

過去数年間で、このようなMV *フレームワークの数に大きなブームが見られます。

Backbone.js 、 Ember.js 、 AngularJS 、 Spine 、 CanJS ...新しく有効なソリューションのリストは毎週増え続けています。開発者はオプションの海ですぐに迷子になります。彼らはたくさんの選択肢があります。ライブラリに影響を与えた複雑なアプリケーション（ Yehuda KatzやJeremy Ashkenasなど）に取り組んでいる心から多くの強力な競合ソリューションがあります。質問：使用するものと選択方法

この状況を認識し、開発者が選択プロセスをできる限り簡素化できるようにしたいと考えました。 TodoMVCは、現在人気のあるさまざまなMV *フレームワークに同じTodoアプリケーションを実装するプロジェクトです。フレームワークのデータを操作するための速度計と考えてください。実装は同じように機能し、機能し、異なるフレームワークの構文と構造を比較するのに役立ちます。このようにして、最も快適に感じるものを選択することができます。少なくとも、比較することで選択範囲を狭めることができます。

今週（2012年7月14日） TodoMVCの完全に新しいバージョンをリリースします。詳細については、アプリケーションセクションで説明します。

近い将来、このフレームワークの使用を検討する必要があるアプリケーションの種類に関する相違点と推奨事項についてのメモを提供することにより、作業をさらに発展させたいと考えています。

■フレームワークを選択するための提案された基準

フレームワークを選択することは、ToDoアプリケーションの動作を単純に比較するだけではありません。したがって、選択した候補が複数ある場合は、仕事から少し離れて見回すことをお勧めします。おそらく、フレームワークは重要な機能をサポートする必要があり、長年サポートする必要があることが判明する可能性があります。質問に答えてみてください。

フレームワークは本当に何ができるのですか？

フレームワークのソースコードと機能の公式リストを読んで、要件をどのように満たしているかを確認してください。ソースコードの変更や追加が必要なプロジェクトがあります。自分で実行できると考える場合、コードはテストに合格しています。

フレームワークは動作確認済みですか？

このライブラリを使用して、大規模な公開アプリケーションを構築および実装した開発者はいますか？ Backboneにはそのような深刻なリスト（SoundCloud、LinkedIn）がありますが、すべてが揃っているわけではありません。 Emberは、Squareのユーザーツールを含む多くの大規模なアプリケーションで動作します。 JavaScriptMVCは IBMの大規模なアプリケーションで使用され、他の場所は考慮していません。フレームワークが機能することを知るだけでなく、実際のコードを見て、どのように構築できるかを理解することも重要です。

フレームワークは完全ですか？

開発者は、「選んで仕事をする」以上のことを行うことをお勧めします。多くの場合、新しいプロジェクトにはリリースに関する多くの議論が伴います。それらについては忘れずに、本番レベルのアプリケーションのリリースを選択してください。緊急のリファクタリングまたはその他の故障によりプロジェクトで停止するリスクはありません。フレームワークがうまく機能しデバッグされている場合は、より予測しやすくなります。成熟したプロジェクトは通常、正式に、またはコミュニティを通じて文書化されます。

フレームワークは柔軟であるか、管理が困難ですか？

さまざまな「キャラクター」のライブラリがあることを知ってください。厳密に管理されたフレームワークでは、特定のフレームワーク内でプログラミングする必要があります。それらはアプリケーションの設計を制限し、それがどのように機能するかを独自に把握する開発者にあまり注意を払いません。

フレームワークで実際に「遊んだ」ことがありますか？

フレームワークを使用せずに小さなアプリケーションを作成し、フレームワークで動作するようにコードを作り直して、簡単に動作するかどうかを評価してください。コードを扱うことはあなたの決定に影響を与えるので、デザインを使って快適に作業できるように、動くコードを書くことが重要です。

完全なドキュメントはありますか？

デモアプリケーションはリンクと表示に役立ちますが、ほとんどの場合、フレームワークの公式開発者とやり取りし、APIサポート、一般的な問題の解決方法、コンポーネントの作成方法、注目されるバグについて学習します。価値のあるフレームワークには、開発者が理解するのに役立つ詳細なドキュメントが必要です。それがなければ、開発チームとのIRCチャンネルを見つけたり、独立した研究を行うことができます。それ自体は素晴らしいですが、多くの場合、事前に提供されたドキュメントのセットに比べて時間がかかります。

フレームワークの範囲、縮小、圧縮、モジュール化の機能は何ですか？

フレームワークにはどのような依存関係がありますか？

フレームワークの場合、ファイルのサイズを示す傾向がありますが、依存ライブラリのサイズは言うまでもありません。たとえば、 jQueryまたは他のライブラリに依存している場合、小さなライブラリは予想外に大きくなります。

フレームワークの開発者のコミュニティに精通していますか？

問題が発生した場合に支援できるプロジェクト参加者とユーザーの活発なコミュニティはありますか？十分な開発者がフレームワークを使用しましたが、アプリケーション、チュートリアル、および場合によってはスクリーンキャストを実行するためのリンクがありますか？

■ DojoとJavaScriptフレームワークの複雑さ

多くの人が知っているように、 Dojo Toolkitは、開発者に複雑なアプリケーションを開発するためのツールを提供する最初の試みの1つでした。珍しいアプリケーションのタスクについてもっと考えるようになったと言う人もいるかもしれません。 Dojoの開発者であるDylan Schiemann氏、Kitson Kelly氏、およびJames Thomas氏に[手紙で]質問しました。MV*フレームワークの出現について彼らはどう思いますか。

Q ： Dojoライブラリでこれをすべて解決できますか？より構造化された重要なアプリケーションを構築したい人にとって、なぜそれが好ましいソリューションにならなかったのですか？

O。：数年前、JavaScript環境が単純なAjaxと効果をページに追加することから進化したとき、 DojoはWeb上で複雑なアプリケーションを構築するための「ツール」アプローチを提唱しました。

これらの機能の多くは、ほとんどの開発者のニーズをはるかに上回っていました。主要なアプリケーションプラットフォームとしてのブラウザーの出現により、多くの革新がDojo Toolkitに導入され、現在では新しいツールに登場しています。 MVCは、 Dojoが他のコードモジュールと共にかなり長い間提供していた別のパッケージでした：JSのOOP、UIウィジェット、クロスブラウザグラフィックス、テンプレート、国際化、データアクセス、データウェアハウス、テストフレームワーク、システムビルドなど。

Javascriptライブラリーは、 Dojoが初期段階からエンタープライズレベルのアプリケーション開発の全サイクルに努力を集中した理由を「主張」すべきではありません。 MVCの焦点は同じになりました。1つの「セットからのツール」にすぎません。

Dojoが支配的なツールボックスではないのはなぜですか？彼女の目標は決して唯一の選択肢ではなかった。目標は、プロジェクト内の他の何かと連携し、他のプロジェクトへの移植性を備えたツールのオープンセットを提供することでした。 道場は遅いと批判され、それを服用した後でも、彼女は遅いと批判されました。ショートカットを取り除くことは困難な作業です。豊富なツールセットの機能を文書化することは困難です。 Dojo 1.8には175個のサブパッケージと1,400を超えるモジュールがあります。

これは、文書化の目標を達成するという問題だけでなく、 Dojoが複数のタスクを実行することを意味します。プログラムを作成するのは良いことですが、最初にどこから始めればよいかを判断するのは非常に困難です。改善されたドキュメントとチュートリアルは、 Dojo 1.8を支援しようとします。

Q ：開発者がDojoを選択する理由と、将来のプロジェクトのためにどのようなアイデアのリストを持っているのですか？ 1.8の後、別の目標があると言われています。

O。：Dojo 1.8では、 dojox / mvcパッケージが成熟に向けてさらに一歩踏み出しました。パッケージには多くの時間、労力、テスト、コミュニティの注意が払われました。彼は、 Dojoの残りの部分を活用するMVCモデルの提供を専門としています。これは、デスクトップおよびモバイルデバイス用のリッチアプリケーションを構築するためのdojox / appアプリケーションパッケージと一緒に、クライアント側の統合システムを作成します。

そしてこれは、典型的なDojoアプローチでアプリケーションを構築する実行可能な方法の1つにすぎません。

1.8では、MVCサブモジュールがより成熟するだけでなく、堅牢なフレームワークに基づいています。 Viewコンポーネントの作成、モデルの表現、またはコントローラーの設計にマークアップ言語を提供するだけではありません。これは、別のモジュールをデータソースに接続するだけではありません。これはDojoの残りの部分に接続されているため、必要なものはすべて接続できます。

Dojo 2.0では、モジュール化を新たなレベルに引き上げ、一方と他方を取りまとめてすべてをより簡単にすることを試みます。また、クライアントまたはサーバーでコードが実行される場所がユーザーにとって問題にならないように、同型の概念を調査します。最終的に、これは開発者に透過的でなければなりません。

■TodoMVCコレクション

弊社の最新リリースには、最も人気のあるフレームワークのTodo実装が含まれており、他の多くの適度に使用されているフレームワークがLabsで実行されています。これらの実装には多くの改訂が行われ、多くの場合、フレームワークの作成者、開発への参加者、コミュニティのユーザーからのベストプラクティスや提案からヒントを取り入れました。

Backbone.js Jeremey AshkenasとYehuda Katzの著者によるコメントに続いて、 TodoMVCは現在、ナビゲーション（または状態管理）など、アプリケーションの公式仕様で行われた関連実装も提供しています。（？）

比較のためのより複雑なアプリケーションが不可能（もちろん可能）であるふりはしませんが、Todoアプリケーションのシンプルさにより、開発者はコード構造、コンポーネントの構文、およびフレームワークの比較やそのソリューションの詳細を確認するのに十分な「フローセンス」を認識できます決定。

当社のアプリケーションは次のとおりです。

AMDバージョンに興味のある方へ：

Backbone.js + RequireJS （AMDを使用）
Ember.js + RequireJS （AMDを使用）

私たちのラボには以下が含まれます：

備考 Todoアプリケーションの1つのバージョンを純粋なJavaScriptで作成し、別のバージョンでは、まずjQueryアプローチを使用しました。 ご覧のとおり、これらのアプリケーションはMVCフレームワークで記述されたものと機能的に同等ですが、タスクの分離はなく、ボリュームが大きくなるにつれてコードの読み取りと保守が難しくなります。

昨年、フレームワークの作成者の一部が、ソリューションを改善する方法についての議論に参加してくれたことを光栄に思います。さらに、TodoMVCにゆっくりと移行しました。これはほとんど事実上のアプリケーションでした。新しいフレームワークが追加されたため、初期比較が簡単になりました。

（ここで最も面白い場所で停止する必要があります-テキストのサイズが大きくなります-許容されるスピーチを停止します。休憩の直後に、私たちの時間の最も予想される質問が尋ねられます。エディー・オスマニ自身のレシピにある「使用...！」という驚異的なソース！）

さらに、最後の部分では：

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

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

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

■MVを超える*

■結論。

同様のレビュー： Rich JavaScript Applications-the Seven Frameworks（Throne of JS、2012）、Steven Sanderson、2012年8月1日。Backbone、Meteor、Ember、AngularJS、Knockout、Spine、Batman、CanJSアプローチの違いと一致-Throne会議の結果に基づくJS、2012年。」

（続き： 2番目の最後の部分）

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