Marionette.jsに切り替えた理由

デスクトップアプリケーションの履歴を見ると、シンクライアントにテキスト画面を送信できる強力なサーバーで開始されたことがわかります。 シンクライアントは、サーバーが処理したコマンドを与え、新しい画面をクライアントに送り返しました。



時間が経つにつれて、機器が安価になり、クライアントが作業の大部分を行い、情報の受信、情報の保存、または安全で制御された環境で実行するコマンドを与えるためだけにサーバーと通信するときに、現在のモデルになりました。



さて、考えてみると、当時はすべてのユーザーがハードウェアによって等しく制限されていたため、開発が容易でした。



残念ながら（開発者にとって）、このモデルによって課せられた制限もエンドユーザーにはまったく受け入れられません。 応答性が高く、高速で美しいソフトウェアが必要です。これは、小さなアクションがリモートサーバーへの要求応答につながる状況ではほとんど不可能です。

Webインターフェイスの進化

Web開発でも同様の進化が見られます。 私たちはパラダイムシフトの状態にあり、さらに先へ進むほど、古いパラダイムで書かれたアプリケーションにとっては難しくなります。 応答性がなく、代替物を用意しているときに少し対話性を提供するものを使用するのはなぜですか？



UIアーキテクチャは設計が非常に難しい問題であり、大企業が長年にわたってソリューションに数百万ドルを投資してきたとしても、これを行うための「正しい方法」さえありません。 多くのJavaScript「MVC」フレームワーク（これはサーバーMVCフレームワークとほぼ同じくらい悪い用語です）が過去数年にわたって登場しており、過去50年のUIアーキテクチャのアイデアをWebに適用する方法が根本的に異なっています。

フレームワークの選択

多くのフレームワークを試しましたが、簡潔にするために、最も一般的な4つのバックボーン、Ember、Knockout、Angularについて説明します。

始める前に、これらはすべて、人気に値する本当に素晴らしいプロジェクトだと言いたいと思います。 開発には、すべての状況と問題に適した「銀の弾丸」のようなものはなく、これらのフレームワークにはそれぞれ長所と短所があります。

私たちの状況

産業用Railsアプリケーションには（約）25万行のコードがあります。 Railsパスに沿ってほとんどの時間を過ごしましたが、これから多くのことを学びました。 アプリケーションには、非現実的な量のビジネスロジックが含まれています。 したがって、スケーラビリティと柔軟性は、フレームワークを選択する際の指針となる2つの重要な基準でした。

Ember.js

ドキュメントとYehuda Katz（wycats）によるEmber.jsについての話に基づいて、これは基本的にクライアント側でRailsを実行しようとする試みです。

Emberは現在利用可能な最も野心的なフレームワークであり、その強みは明らかです。 場合によっては選択肢を奪われ、非常に便利です。 特に、ルーティングへのアプローチ（State Manager / StateManager）が気に入っています。他の実装よりもはるかに優れていると思います。



Emberの弱点は、その利点の結果です。 エンバーの道をたどりたくない場合-あなたのために苦労が来る。 問題が発生した場合は、非常に複雑なフレームワークを扱っているため、ほとんどの場合、問題を迅速に解決することはできません。 Emberはバージョン1.0に達しましたが、今後数年間で大幅に変更される予定です。 コードのあらゆる面でこのようなレベルの存在するフレームワークでは、更新は難しいテストになる可能性があります（Railsを3番目のバージョンにアップグレードするのに1年以上かかりました）。



私にとって最後のストローは、Emberがあなたのアーキテクチャをコントロールすることでした。 私たちは自分で選択するのに十分なスキルを持っているので、私たちに非常に多くの制限を課すことは悪い選択だと思います。

Angular.js

Angularは、HTMLとJavaScriptが複雑なインターフェイスの作成に適した重要な要素を持たないアプローチを使用します。 JavaScriptの場合、必要なのは監視可能なオブジェクトです。 HTMLの場合、欠けている部分は何らかのテンプレートです。 どちらも拡張可能な言語であるため、Angularはそのような機能を追加します。

私はAngularの大ファンです。 ビューとビジネスロジックの間の透過的な分離を提供します。これは、現在のWebが本当に必要とする動作と構造を組み合わせたコンポーネント実装です。 また、多くの開発者が冗長と考える依存性注入フレームワークも含まれていますが、これは良いアイデアだと思います。



私が同意するのをやめた場所は、テンプレート実装の実装方法です。 私は2000年からWeb開発に携わってきましたが、この間、Webテクノロジーの3つの部分（スタイル、動作、構造）を区別する傾向が着実にありました。 私はこの動きを見て（そしてその一部でした）、HTMLの振る舞いやJavaScriptのHTMLを奨励することは悪い方法だと思います。 結局のところ、違いは何ですか

onclick="foo();"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして

 ng-click="foo();"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Xcodeのような環境では、「ビュー」は私にとってはコードではなく、デザインサーフェスであるため、このスタイルのビューでのバインディングに問題はありません。 しかし、私たちは異なる方法でウェブを構築しているので、これは悪い開発方向だと思います。



私はこれを弱点だとは思わず、むしろアプローチの違いだと考えています。 Angularの弱点はこれだと思います。面倒なAPI、Web標準がAngularとは異なる方向に進むという事実、そして抽象化は非常に脆弱です。 これがどのように機能し、どこで/どのように戻るかについての深い理解が必要な場合、規制されたAngularの世界の外にいるのは十分簡単です。



私にとって決定的なマイナス点は、フレームワーク全体の中で最も価値のある機能であると考えている独自のディレクティブを作成することがどれほど難しいかでした。 私のキャリアの中で、苦痛のレベルを拡大しようとしたときに苦しみのレベルに近づいた唯一のプラットフォームは、ASP.net WebFormsのサーバーコントロールです。 これは解決可能な問題であり、Angularが2番目または3番目のバージョンに到達した時点でそれが私の選択だと思います。

Knockout.js

Knockoutは、Microsoft MVVMにヒントを得たフロントエンドアプローチを採用しています。 データバインディング用の強力な言語と、モデルを表示するためのhtmlのバインディングがあります。 基本的なルーターがあり、それだけです。 Knockoutは、データバインディングに適したライブラリとしての「フレームワーク」ではありません。



Knockoutの理想的な使用法は、「ハイブリッド」アプリケーションを作成するとき、ページのリロード間のやり取りはあるが、サーバーはほとんどのロジックを保持しているときだと思います。 これがあなたの場合であるなら、あなたはクライアント側にささやかなニーズがあり、状態と動作の分離はおそらくあなたが必要なものです。



Knockoutの弱点は、大量のクライアントロジックが必要な場合、これがソリューションの一部になることです。

Backbone.js

バックボーンは、このタイプの最も人気のあるフロントエンドライブラリですが、最もシンプルでもあります。 Backboneの哲学は、Web上でフロントエンドコードを構造化するために必要な最小限のものを提供することです。 Backboneを簡単に使用できるようになります（そして、コードベースを最初から最後まで1時間で読むことができます）。



適度なニーズがある場合（または最初は中程度ですが、徐々に成長する場合）は、Backboneを使用してください。 バックボーンは、フレームワークというよりも哲学です。 Backboneには驚くほど活発なコミュニティもあります。つまり、さまざまなサードパーティの拡張機能やライブラリから選択することで、「独自のフレームワークを構築する」ことができます。 Backboneは非常にJavaScriptベースです。つまり、記述している言語を理解していれば、JavaScriptスタイルのすべてを実行するため、フレームワークを理解できます。



Backboneの弱点は、それ自体ではあまり何もしないことです。何に接続するかわからない場合は、自分で悪いサービスを行うことになります。 多くの「Web開発者」はWebテクノロジーの知識が乏しいため、この「JavaScript性」も邪魔になる可能性があります。その1つであれば、Backboneで簡単に迷子になります。

Backbone.Marionette

Marionetteは、Backboneがあらゆるタイプのアプリケーションを構築するために最低限必要なものを提供すると、大規模なアプリケーションは大量の定型コードになると主張しています。 Marionetteは、これらの種類のアプリケーションに必要なフレームワークを提供し、大量のコードを整理する方法に関するガイダンスも提供します。



Marionetteを選択した理由は、コードを整理するアプローチであり、多くの点で私たちのものと一致しています。 明確に定義されたシンプルなインターフェイスを使用して、互いに通信する小さなコードに大きなコードブロックを分離します。 表現コードを可能な限り宣言的にするための管理とコンピューティングの分離、およびコード管理-可能な限り高レベル。 また、大規模で複雑なコードベースを扱う確立されたパターンに従ってください。



マリオネットは、最大のバックボーン問題を解決します-ビュー内のこのすべての定型コード。 また、独自のコンポーネントアーキテクチャ（Angularでは複雑すぎます）を簡単に構築し、必要なすべての最小限の構造を取得できます（Knockoutとは異なります）。 優れたアーキテクチャを完成させてインフラストラクチャを構築するには手間がかかりますが、私たちの要求と他のライブラリの現状を考えると、これは良い妥協だと思います。

UIは複雑で、Silver Bulletはありません

これは特定の状況と視点の評価であり、私たちの製品と開発チームにとって意味があると信じています。 冒頭で述べたように、これらのオプションはすべて独自の目的に最適です。 「Xフレームワークを使用していて、それが悪いのですが、今はYフレームワークを使用しているので、魔法の馬に乗って日当たりの良いフィールドを旅しているように感じます。」



原作者のマット・ブリッグス。