JavaScript MVCフレームワーク：マリオネットとチャップリンの比較

JavaScriptアプリケーションの開発はホットなトピックであり、人々はどのフレームワークを選択するのが良いのかと考えています。 この記事では、そのうちの2つを比較します。



MarionetteとChaplinは、人気のあるBackbone.jsライブラリの上で動作するフレームワークです。 どちらも、単一ページのJSアプリケーションの開発を促進したいと考えています。 このようなアプリケーションでは、フロントエンドは以前にサーバーで実行されていたタスク（データからHTMLをレンダリングするなど）を実行します。



Backboneは、本格的なフレームワークとしてではなく、最小限のライブラリとして設計されています。 私の経験では、BackboneはJSアプリケーションアーキテクチャのコアとしてのみ優れていることが示されています。 Bacbonは実際のアプリケーションにほとんど構造化を提供しないため、PuppetとChaplinの両方が登場しました。 彼らは同じ問題を解決します。 そのため、それらの間にはかなりの数の類似点があります-おそらく違いよりも多くの点です。







何よりもまず、私はチャップリンの共著者であることを宣言したいと思います。 しかし、私はPuppetとも協力し、Puppetの開発をフォローしました。 別の野心的なバックボーンフレームワーク-Thoraxがあります。 私は彼と仕事をしなかったので、この比較には彼を含めませんでした。

内容

1. 非技術的側面
2. バックボーンの欠陥を解消する一般的な機能
3. Puppetの利点
4. 人形の不利な点
5. チャップリンのメリット
6. チャップリンの欠点
7. おわりに

非技術的側面

技術的な詳細については後で説明しますが、それに直面しましょう-それらのマーケティング、評判、成功事例、およびドキュメントは、プログラムを選択する決定に大きく影響します。



PuppetとChaplinは、MITライセンスの下でリリースされたオープンソースプロジェクトであり、Githubで積極的に開発されています。 著者は、いくつかの大規模なバックボーンアプリケーションの開発に参加し、同じレーキを踏む必要がないように、優れたアーキテクチャを作成する経験を移転しました。



有名な企業はPuppetとChaplinを使用しています。 確かに言うのは難しいですが、全体的にユーザーの数はほぼ同じです。 Puppetエコシステムはより大きく、多くの人がPuppet全体ではなく一部のみを使用しています。



チャップリンは最初はより人気がありましたが、人形は後に有名になりました。 人形は初心者にとってより親しみやすく、十分に文書化されています。これは明らかに、彼らがそれを選んだ理由の1つです。 人気のもう1つの理由は、人形の作成者であるDaryk Baileyの貢献です。DarykBaileyは、Backboneアップリケの開発に関する一連の記事を執筆しました。 また、会議で講演し、 ビデオレッスンを記録しています。

バックボーンの欠点を解消する一般的な機能

混乱のないイベント指向のアーキテクチャ

Backbonの重要な機能は、ビューとモデル間の責任の分割です。 イベント（ Publish / Subscribe ）を介して対話します。 Backbone.Events



を使用すると、イベント指向のアーキテクチャを作成できます 。 これは、アプリケーションの各部分を互いに分離するのに適した方法です。



PuppetとChaplinはどちらも、Backboneのアプリケーションのボトルネックを特定します。 イベントドリブンアーキテクチャでは、イベントリスナーをクリアすることが重要です。 ライフサイクルは重要です。他のコンポーネントを作成したコンポーネントがそれを削除する責任があります。 PuppetとChaplinは、これらの問題をさまざまな方法で解決します。 パブリッシュ/サブスクライブの使用を推奨するだけでなく、一般的なアプローチエラーを回避するツールも提供します。

アプリケーションの構造化

モデルとビューは低レベルのパターンです。 さらに、BackbonはRouterのみを提供します 。 これは非常に薄い層で、おそらくベーコンの最も問題のある部分です。 純粋なバックボーンルーターでは、メモリ管理を備えた通常の高レベルアーキテクチャを作成できません。 PuppetとChaplinは両方ともコントローラーによって導入されます。

強力なビューの規則

ベーコンのシンプルさに従って、彼のビューとレンダリングは抽象的な要素です。 Backboneビューは1つのDOM要素を担当しますが、Backboneは、データを要素に挿入してページに挿入するためのツールをボックスから提供しません-デフォルトでは、 View#render



メソッドは空です。



PuppetとChaplinは、堅牢なレンダリングエンジンを備えたビュークラスを提供します（ Marionette.ItemViewおよびChaplin.Viewを参照）。 さらに、 Mustache / Hogan 、 HandlebarsまたはHAML-coffeeなどのテンプレート言語を選択する必要があります。



両方のライブラリには、ビューをレンダリングするタイミングと、それらをDOMに埋め込む方法に関する規則があります。 モデルデータをテンプレートに送信する前に変換できます。 これは、計算プロパティなどに便利です。



ビューはおそらくアプリケーションの最も難しい部分なので、PuppetとChaplinはさらにヘルパーを提供します。 それらを使用して、ネストされたビューを作成し、名前付き領域を宣言できます。 宣言的にモデルイベントを登録できます（ this.listenTo(this.model, ...);



より簡単で読みやすい）。



Pure Backboneは、コレクションビュービューのマイナスでもあります（ Marionette.CompositeViewおよびChaplin.CollectionViewを参照）。 要するに、各コレクションモデルに個別のビューを使用します。 これにより、単純な構造化コードを使用して複雑なリストを実装できます。 コレクションビューはそれ自体がスマートであり、1つのモデルのためにリスト全体を再生成しません。

Puppetの利点

人形-有用なパターンの倉庫。 モジュール式であり、Puppetのすべての部品を使用する必要はありません。 いくつかの部分から始めて、残りを後で結合できます。 Puppetの機能の一部は、たとえばBackbone.BabySitterやBackbone.Wreqrなど、Baconの個別のプラグインから来ています。



Puppetにはユニークな機能もあります。 私の意見では、最も強力なのはアプリケーションモジュールとスマートビュー管理です。

モジュール

アプリケーションモジュールはアーキテクチャの独立した部分であり、ルーター、コントローラー、モデル、およびビューで構成できます。 モジュールは開始および停止できますが、停止する前に実行される「フック」を定義できます。 また、ルートがモジュールに設定されたルートと一致する場合、遅延ロードすることもできます。



BBCloneMailは、2つのモジュール（ mailおよびcontact ）で構成されるサンプルアプリケーションです。 この例では、1つの期間に1つのモジュールのみがアクティブです。 しかし、一般的に、モジュールは互いに「置換」することはできません。 モジュールには独自のルーターがあり、最初から起動する必要があります（ 連絡先 ルーター、メールルーター ）。



モジュールは互いに入れ子にすることができます。 メインアプリケーションであるMarionette.Applicationもモジュールです。 技術的には、Marionette.ApplicationとMarionette.Moduleにはいくつかの違いがありますが、将来的にはより均一になることを願っています 。



ほとんどの場合、最初からいくつかのモジュールを使用する必要はありませんが、これはアプリケーションを小さな接続ユニットに分割するのに役立つ優れた機能です。

ビュー管理

Puppetのもう1つの強力な部分は、スマートビュー管理です。 BabySitterを使用すると、ビューを簡単にネストできます。 さらに、Puppetはレイアウトやリージョンなどのいくつかの抽象化を追加します。 レイアウト -名前付き領域を含むビュー。 リージョン -DOM要素を担当するオブジェクト。 領域の例には、ヘッダー、ナビゲーション、メイン、サイドバー、およびフッターがあります。



ビューをレンダリングしてDOMに埋め込む必要があるのはどこですか？ 地域で！ DOM要素を直接制御する代わりに、Regionを一度定義してから、たとえばmainRegion.show(view)



記述するだけです。 これにより、ビューがレンダリングされ、リージョンに対応するDOM要素に追加されます。 リージョンには一度に1つのビューしか保持されないため、古いビューは「閉じます」（DOMから削除され、メモリから安全に解放されます）。



ネストされた領域を使用すると、読み取り可能でサポートされているコードを使用するだけで複雑なインターフェイスを構築できます。

人形の不利な点

簡潔にするために、Puppetのユニークな機能をいくつか説明しました。



弱い抽象化や効果的な使用のための明確な推奨は好きではありません。

ルーティングとコントローラー

たとえば、PuppetはBackbone.Routerの上に非常に少数のアドオンを提供します。 私の意見では、バックボーンルーターは、次のルートがアクティブになったときに、作成されたオブジェクトをメモリからクリアすることに関して合意を提供しないため、これは重要です。 原則として、 route



イベントを使用して集中クリーニングを実装できますが、これは松葉杖です。



Puppetには、 停止できるモジュールと閉じることができる領域があります。 ただし、モジュールを起動および停止するたびに、またはリージョンを閉じるたびに、明らかに面倒なことはありません。



Marionette.AppRouterは正しい方向への一歩です。 彼のアイデアは、コードからルート構成を分離することです。 ルートが一致する場合、AppRouterはControllerの対応するインスタンスにアクセスします 。



Puppetのコントローラーには特定の目的はなく、何かを「制御」するだけです。 Backbone.Events



を介してイベントをサブスクライブできます。また、 initialize



メソッドとclose



メソッドがclose



ます。 これは間違いなく便利ですが、いつどのように使用するかを自分で考える必要があります。 通常、モデルとビューはそこに作成されます。

グローバルオブジェクトとプライベートオブジェクト

Puppetでは、モジュールとクラスは、 window.BBCloneMail.MailApp.Controller



などのグローバル変数にwindow.BBCloneMail.MailApp.Controller



ます。 人形を使用すると、クラスのグローバルにアクセス可能なインスタンスを作成するのは魅力的ですが、そうすることはまったくクールではありません。 BBCloneMailの例では、一部のオブジェクトは関数から転送されて返されますが、他のオブジェクトはグローバルにアクセス可能です（たとえば、 BBCloneMail.MailApp.controller ）。



コードを読むとき、どのオブジェクトがグローバルにアクセス可能で、どのオブジェクトがグローバルに使用されているかは明らかではありません。 Puppetでは、グローバル名前空間なしでオブジェクトを関連付けることができるオブジェクト機能パターンを使用することをお勧めします。

デフォルトのテンプレート

デフォルトでは、ビューはDOMからテンプレートを読み取り、テンプレートのAnderskor言語（ _.template ）でコンパイルします。 シンプルですが、HTMLにテンプレートを埋め込むことはお勧めしません（たとえば、Chromeウェブストアのガイドライン-オンザフライでコンパイルされたテンプレートを使用するアプリケーションは、単にそれらを許可しません）。 最後に、テンプレートは別々のファイルにプリコンパイルされている必要があります。 しかし、もちろん、これをPuppetに簡単に追加できます-Rendererを使用するだけです。

チャップリンのメリット

Puppetと比較して、Chaplinはフレームワークに似ています。 彼はより頑固で、さまざまな分野でより強い合意を持っています。 彼は、Ruby on RailsなどのサーバーベースのMVCフレームワークから、構成より規約の原則に従うアイデアを取り入れました。 Chaplinの目標は、実績のあるベストプラクティスと便利な開発環境を提供することです。

コーヒースクリプトとOOP

Chaplinは、JavaScriptでコンパイルされたメタ言語であるCoffee Scriptで記述されています。 ただし、ChaplinはJSライブラリにすぎないため、Chaplin上のアプリケーションではコーヒーを使用できない場合があります。



コーヒースクリプトを使用することは、開発が単純でなければならないというチャップリンの考えの一部です。 コーヒースクリプトは、「JavaScript-The Good Parts」という本のDouglas Crockfordのガイドラインを実施しています。 操り人形として、ChaplinはECMAScript 5 Strict Modeの使用を促進しています 。



coffeeスクリプトを使用すると、 Backbone.extend



よりも簡単にクラスを定義して継承できます。



Chaplinはまた、子クラスでのメソッドの再定義とcoffeスクリプトsuper



（またはJavaScriptでの同等物）の使用を積極的に促進し、クラスの継承を明確に機能させようとします。 たとえば、クラスとその子孫に対して（ View#events



を介して）宣言的にイベントを定義すると、両方が適用されます。

AMDまたはCommonJSを介したモジュール化

Chaplinにはモジュールの使用が必要です-CommonJSまたはAMDがダウンします。 各モジュールは、その依存関係を判別し、何か（コンストラクター関数または単一オブジェクト）をエクスポートする必要があります。 通常、Chaplinでは、1つのクラスと1つのモジュールが1つのファイルに分類されます。



AMDの使用は簡単ではありません。reboot.jsのようなブートローダーとr.jsのようなオプティマイザーを知る必要があります。 別の方法として、CommonJSモジュールとBrunchコレクターを使用できます。そこではすべてがはるかに簡単です。



人形はAMDもサポートしていますが、強制的に使用することはありません。

固定アプリケーション構造

チャップリンは固定構造を提供します。 すべてのアクションの大部分を処理します。

• Application
  
  
  
  は、これらの部分を実行するルートクラスです
• Router
  
  
  
  はBackbone.Router
  
  
  
  置き換えます
• ルートが一致すると、 Dispatcher
  
  
  
  はコントローラーを開始および停止します
• Layout
  
  
  
  は、リンクのクリックを監視するメインビューです

チャップリンでは、すべてのルートを特定する中心的な場所があります。 ルートは、コントローラーのアクションを示します。 たとえば、 cars/:id



リンクテンプレートは、 cars#show



、つまりCarsController



コントローラーのshow



アクション（メソッド）をCarsController



ます。



コントローラーは、モデルとビューが初期化される場所です（サイドバーヘッダー用ではなく、画面の主要部分用）。 一般に、コントローラーのアクションは通常、アプリケーションの1つの画面に応答します。

メモリ管理

Chaplinの主なアイデアは、コントローラーがメモリから消去されることです。 主なルールは、現在のコントローラーとそのすべてのプロパティ （モデル、コレクション、ビュー）が次のコントローラーで削除されることです。 ルートが同じコントローラーの別のアクションを指している場合でも、古いコントローラーインスタンスは削除され、新しいインスタンスが作成されます。



次のルートが一致したときに前のオブジェクトを削除することは、リンクをクリアする簡単で効果的な方法です。 しかし、いくつかのオブジェクトは、いくつかまたはすべてのアクションのためにメモリに保持した方が良いでしょう。 この目的のために、モデルとビューを共有できるChaplin.Composerがあります。 保存されたオブジェクトが次のルートで使用されない場合、自動的にクリアされます。



Chaplinのアプリケーションでは、すべてのオブジェクトを簡単にクリーニングできます。 すべてのChaplinクラスには、オブジェクトを使用不可にし、すべての接続を削除し、 凍結 dispose



メソッドがあります。

クラスの非表示インスタンスとパブリッシュ/サブスクライブ

よく知られているJavaScriptプログラミングルールは、グローバル変数を避けることであり、Chaplinはそれらを使用しないように強制しようとしています。 Chaplinのクラスは、グローバル名前空間では使用できないCommonJS / AMDモジュールです。 次に、すべてのインスタンスが非表示になります。 2つのインスタンスは、ビューとそのモデルのように密接に関連している場合を除き、相互にリンクしないでください。



オブジェクトは、 パブリッシュ/サブスクライブパターンを使用して、無関係な形式で相互に通信できます。 この目的のために、 Chaplin.Mediatorがあります 。 メディエーターは、現在のユーザーのモデルなど、頻繁に使用されるものを保管するためにも使用できます。 必要なプロパティを作成した後、メディエータはアプリケーションのグローバルガベージダンプにならないようにシールされます。

ヴィシュクの管理

チャップリンはビューの管理も得意です。 名前付き領域とネストされたビューがあります。 Chaplinは、ビューをレンダリングしてDOMに挿入するための異なるアプローチを採用しています。 ビューにはautoRender



フラグとcontainer



オプションがあります。 そうである場合、ビューは作成直後にレンダリングされ、DOMに自動的に挿入されます。 container



オプションの代わりに、DOM要素に直接リンクする代わりに、以前に登録された領域にビューをアタッチするようにregion



を指定できます。



チャップリンには、グローバル地域に加えて、 Marionette.Layout



およびMarionette.Region



パペットの抽象化はありません。 Puppetを使用したアプリケーションでは、通常、いくつかのネストされた領域とレイアウトがあります。 Chaplinを使用したアプリケーションでは、メインリージョンが少なくなり、それらに埋め込まれたビューが増えます。 もちろん、 ThreePaneView



などのMarionette.Layout



の動作を使用して、再利用可能なビューを作成することもできます。

チャップリンの欠点

チャップリンの共著者として、私は偏見があるかもしれません。 しかし、弱点と改善の可能性も見ています。 明らかに、パペットはいくつかの問題に対してより適切な解決策を見つけました。



すでに述べたように、Chaplinは各コンポーネントのライフサイクルの概要を示しているため、メモリの管理に優れています。 これは、BackboneでWebアプリケーションを作成する際の主な問題の1つです。 チャップリンはうまく機能する解決策を見つけましたが、それは完全ではなく論争の的でもありません。 この機能は開発されており、さらに開発されるはずです。



初心者がチャップリンの全体像をすぐに理解することは困難です。 Chaplinのメモリ管理、モジュール性、およびその他の概念は、多くのJavaScript開発者にとって新しいものです。 同時に、最初にこれらの機能が「負担」と思われる場合、アプリケーションは長期的にこれらの機能の恩恵を受けます。



パブリッシュ/パペットと比較した場合、パブリッシュ/サブスクライブはチャップリンのユニークな機会ではありません。 実際、各モジュールには独自のイベントアグリゲーターが付属しているため、アプリベントはより柔軟です。



Chaplinは、イベントのブロードキャストだけでなく、コマンドの起動にもPub / Subを使用します。これはpubsubの悪用です。 Backbone.Wreqrは、この場合のコマンド/リクエスト/レスポンスパターンを実装します。 チャップリンはパペットからこの機会を利用すべきです。

おわりに

パペットはよりモジュール化されており、好きな部分のみを使用できます（アプリケーションを改善できるため、それらのほとんどを使用する必要があると思います）。 単一の中央構造の代わりに、独立したモジュールで複合アーキテクチャを作成できます。 これにより、コンポーネントがより分離されますが、それらを正しく使用する方法を理解する必要があります。



Chaplinはフレームワークに似ており、一元化され厳密です。 Chaplinの著者は、契約によりユーザビリティと生産性が向上すると考えています。 しかし、もちろん、この主題に関するあなたの意見は異なる場合があります。



彼の目標により、チャップリンは他の図書館よりも多くの問題を扱っています。 たとえば、Backbone.Routerを置き換える機能豊富なルーティングおよびディスパッチシステムがありますが、Backbone.Historyを使用します。



人形と比較して、チャップリンはモノリシックです。 これは、あなたが別のことをすることができないという意味ではありません。 基本クラスを調整、変更、または変更し、すべてのルールを破ることができます。

巨人の肩の上に立って

では、どのライブラリを選択するのでしょうか？ 私は選択が明確だとは思わない。 明らかに、ニーズにより適したライブラリ上にアーキテクチャを構築する必要があります。 しかし、そのベストプラクティスを適用するための理解と学習も必要です。



Backboneを使用して、スケーラブルなアプリケーションアーキテクチャを自分で開発する必要があります。 純粋なBackboneでアプリケーションを作成したり 、他のレーキと同じレーキを踏んだりしないでください 。 人形劇、胸郭、 オーラ 、チャップリンなどの建築を散策して、それらを研究してください。



Chaplinの使用を開始するには、基本的なボイラープレートの1つを使用することをお勧めします。HandlebarsテンプレートをサポートするCoffeeScriptボイラープレート 、または純粋なJavaScriptの同等物。 これらには、フォルダ構造とファイルの命名規則、コーディングスタイル、テンプレートエンジンなど、非常に役立つ規則が含まれています。



クイックスタートのために成熟した開発環境を探しているなら、試してみてください

チャップリンまたはチャップリン+レールボイラープレート 付きブランチ 。



Puppetのより実用的な紹介については、Smashing Magazineの記事を読んでください（ 第1部、 第2部）。 Puppets wikiには、多数の記事、ビデオチュートリアル、およびプレゼンテーションがあります。

謝辞

Derik Bailey、Sebastian Deutsch、Paul Miller、Paul Wittmannに、この記事のレビューとPuppetとChaplinの開発への貢献に感謝します。