型破りなAngularJSレビュー

こんにちは、Habr！



多くの人が以前のReactの非伝統的なレビューの翻訳を気に入っており、もちろん、人々はReactと人気のあるAngularJSを比較し始めました。 本日、同じ著者（James Shore、Let's Code：Test-Driven JavaScriptのホスト）からの記事「An Anconventional Review of AngularJS」の翻訳を公開しています。 角度のあるファンは落ち着いてください。







AngularJSは、フレームワークに期待するすべてです。 そして、これは良くありません。



11月、12月、1月に、Let's Code JavaScriptプロジェクトの一環として、一連の「フロントエンドフレームワーク」についてAngularJSをレビューしました。 合計で、問題の調査、プログラミング、および解決に40時間費やしました。 いつものように、私の目標はアプリケーションを構築してAngularJSを学ぶことでした。



現在、 Angularはおそらく最も人気のあるフロントエンドフレームワークです。 Googleのチームによって開発されており、すぐに自信を呼び起こします。 頭字語に含まれているほど人気が​​あります。 Angularは、いわゆるMEANスタックの一部です。MongoDB、Express、AngularJS、Node.JS。 最も先進的なテクノロジー。



Angularは、それ自体をHTMLを改善するツールとして説明しています。 これにより、静的なHTMLドキュメントを動的なテンプレートに変換する新しい定義（ディレクティブ）でHTMLを拡張できます。 ディレクティブは属性またはタグ（またはコメントやクラスでさえありますが、これはもはや普通の話ではありません）であり、静的なHTMLドキュメントをJavaScriptを追加せずに一見生き生きとしたものに変えます。



最良の例は、有名な双方向バインディングです。 HTMLテンプレートには、ほとんどのテンプレート言語と同様に変数を含めることができますが、Angularの場合、変数が更新されるたびにページが自動的に更新されます。



たとえば、レビュー用に作成したアプリケーションには、構成フィールドが変更されると変更されるテーブルがあります。 以下は、テーブルの行をレンダリングするコードのスニペットです。 イベントやステータスの監視に関する作業がないことに注意してください。行のセルを記述するテンプレートにすぎません。 Angularはすべてを自動的に行います。

// Copyright (c) 2014-2015 Titanium IT LLC. All rights reserved. For license, see "README" or "LICENSE" file. (function() { "use strict"; var StockMarketCell = require("./stock_market_cell.js"); var stockMarketRow = module.exports = angular.module("stockMarketRow", [StockMarketCell.name]); stockMarketRow.directive("stockMarketRow", function() { return { restrict: "A", transclude: false, scope: { value: "=" }, template: '<tr>' + '<td stock-market-cell value="value.year()"></td>' + '<td stock-market-cell value="value.startingBalance()"></td>' + '<td stock-market-cell value="value.startingCostBasis()"></td>' + '<td stock-market-cell value="value.totalSellOrders().flipSign()"></td>' + '<td stock-market-cell value="value.capitalGainsTaxIncurred().flipSign()"></td>' + '<td stock-market-cell value="value.growth()"></td>' + '<td stock-market-cell value="value.endingBalance()"></td>' + '</tr>', replace: true }; }); })();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

魔法。



このような例では、Angularがこれほど人気を博した理由が簡単にわかります。 彼にとって、難しい問題はささいなように思えます。 しかし、それは時の試練に耐えますか？

型破りなレビュー

あまりにも多くのフレームワークが閉じ込められています。開始するのは簡単です。これは非常にクールですが、後でコードを維持および拡張することは非常に困難です。 これはあまりクールではありません。



そのため、フレームワークを確認するとき、パフォーマンス、人気、またはサイズの通常の基準を見ていません。 いいえ、1つの重要な質問に対する答えを知りたいです。



今後5〜10年以上、製品をサポートするときに、このコードはより多くの利益や苦しみをもたらしますか？



ほとんどのフレームワークは、製品の最初の作成にかかる時間を節約できるように設計されています。 しかし、これらのコストは、アプリケーションを数年間維持するためのコストと比べると些細です。 フレームワークを推奨する前に、時間の試練に耐えることを知っておく必要があります。 それは私とともに成長し、変化しますか？ それとも、3年後にはほとんど適合しない遺産の束縛に身を置くでしょうか？



私は5つの一般的な危険を見ています。



1.閉鎖（ロックイン）。 新しいまたはより良いフレームワーク（またはライブラリ）にアップグレードすることにした場合、切り替えるのはどれくらい難しいでしょうか？



2.リジッドアーキテクチャ（オピニオンアーキテクチャ）。 アプリケーションが必要とする方法で問題を解決できますか、またはフレームワークの作成者が開発したいくつかのアイデアに従う必要がありますか？



3.サイドの複雑さ（偶発的な複雑さ）。 私は自分の問題を解決するのに時間を無駄にしているのですか、それともフレームワークに苦労していますか？



4.テスト。 標準ツールを使用して、モックオブジェクトで不必要な問題を発生させることなく、コードをテストすることはできますか？



5.サーバーでのレンダリング（サーバー側のレンダリング）。 人々はJavaScriptが役に立つものを見るのを待つでしょうか？ 検索エンジンにサイトのインデックスを作成させるために、タンバリンと踊る必要がありますか？



（uiii！）、（Bueee！）、または⚇（ここでもそこでもない）を使用して、各カテゴリでAngularを評価しました。

1.閉鎖-（bueee！）

質問なし：Angularはあなたを閉じ込めます。 特定のAngular定義とコードを使用して、特定のAngularテンプレートで特定のAngularディレクティブを使用してインターフェイスを定義します。 それから抽象化する方法はありません。 切り替える場合は、すべてをゼロから書き直します。



これは一般的な方法です。 あまりにも普通なので、通常は「ここでもここでもない」という顔をする機会を与えます。 しかし、Angularは正確に「bueee」を獲得しようとしました。



まず、Angularはすべてのクライアントコードのマスターになりたいと考えています。 Angularでアプリケーションを作成する場合、これは、Angular固有の検証を使用し、Angular固有のサービスの形でビジネスロジックを記述し、Angular固有のサービスを介してバックエンドに接続する必要があることを意味します。



次に、Angularチームは、サポートコストが優先事項ではないことを明確にします。 IE 8のサポートはAngular 1.3で廃止され、Angular 2は大幅に書き直され、現在のバージョンのいくつかの重要な概念を忘れています。 これが、アプリケーション全体を書き換える理由である可能性があります。



繰り返しますが、フロントエンド全体がロックされており、何も変更していなくても、おそらく何かを書き換える必要があります。 書き換えはひどい考えです。 あなたはすでに持っているものを繰り返すために多くのお金と時間を費やすでしょう。 ロードマップに「アプリケーションの書き換え」というアイデアが含まれているフレームワークは受け入れられません。

2.リジッドアーキテクチャ-⚇（ここでもここでもない）

Angularは、アプリケーションを特定の形式で構築することを望んでいますが、これをあまり明示的に行いません。 むしろ「受動的で攻撃的なアーキテクチャ」です。



リジッドアーキテクチャは短期的には良いアイデアであり、長期的には悪いアイデアです。 短期的には、タイトなフレームワークにより、アプリケーションの構造を考慮することなく迅速に開始できます。 しかし、長期的には、あまりにも厳格なアーキテクチャが可能性を制限します。 要件が大きくなるにつれて、フレームワーク標準がますます煩わしくなり始めます。



Angularのパッシブ/アグレッシブアーキテクチャには、両方の世界で最悪のものが含まれています。 アプリケーションの設計に関する仮定を行いますが、これらの仮定の理解には役立ちません。 私は今でもこれを理解していると確信していませんが、ここで私は何とか釣り出しました：



「基本的なレベルでは、Angularは、ステートレスの「サービス」オブジェクトをロジックに使用し、データ構造の単純なオブジェクト（メソッドのないオブジェクト）を使用して状態を保存すると考えています。 サービスは基本的にグローバル変数です。 ほとんどの機能はどのサービスでも使用でき、特別な名前でアクセスできます。 データ構造は$スコープに保存され、テンプレートとディレクティブに関連付けられています。 データ構造のオブジェクトは、「コントローラー」（テンプレートとディレクティブに関連付けられた「接着剤」）およびサービスによって制御されます。



私はこのアーキテクチャのファンではありません。 状態をロジックから分離することで、Angularはカプセル化を破り、密接に関連する概念を分離します。 動作するデータの隣にロジックを配置するのではなく、Angularはロジックをアプリケーション全体に広げたいと考えています。 「 ショットガンの犠牲者を操作する 」リスクがあります。変更すると、多数の小さな修正が行われます。



チュートリアルのアプリケーションは、この問題を示しています。 アプリケーションはスマートフォンのリストを表示し、「電話」オブジェクトは重要な概念です。 理想的には、電話オブジェクトの内部構造の変更は何にも影響しないはずです。 ただし、これらは単なるデータオブジェクトであるため、変更すると、アプリケーションの他の部分（電話リスト出力テンプレート、電話情報出力テンプレート 、およびこれらのテンプレートの両方のコントローラー）の変更が必要になります。



状態とビジネスロジックを含むリッチドメインオブジェクトを好みます。 だから私は何も壊さずに変更を加えることができます。 サンプルアプリケーションでは、値を持つ不変オブジェクトに依存するリッチドメインレイヤーを使用しました。 Angularのパッシブ/アグレッシブアーキテクチャはこのアプローチをサポートしていません。Angularの仮定を満たすためにコードを変更しなければならないこともありましたが、これは不可能な作業ではありませんでした。 さらに悪いことかもしれません。

3.担保の複雑さ-（購入者！）

Angularは、急な学習曲線と貧弱なドキュメントで有名です。 これらはより大きな問題の症状だと思います。 これはドキュメントの問題ではなく、角度の問題です。 デザインが悪いだけです。 ここに私が気づいた欠点のほんの一部があります：



漏れやすい抽象化。 自明でないプロジェクトでAngularを使用するには、奥深くに行き、内部でどのように機能するかを理解する必要があります。 プロトタイプ継承のフレームワークでスコープとその仕組みを理解する必要があります。ダイジェストループ。 $ watch、$ watchCollection、および$ apply。 他にもたくさんあります。



マジックラインは、デザインの貧弱な統一性を回避しようとする試みです。 多くの場合、相互接続されているが、異なるファイルにあるコードの断片が表示されます。



どこでも不可解な文字。 Angularには、アプリケーションの文字列に埋め込む必要があるいくつかの小さな言語があります。 「=」、「＆」、「= *」、「@」の違いを理解する準備をします。 「E」、「A」、および「EA」。 演算子「|」; およびその他の象形文字。



とらえどころのない互換性オッズ。 問題はいくつかの方法で解決できます。それぞれの方法には、小さいながらも重要な非互換性があります。 たとえば、コントローラーの作成方法は、テンプレート内の構文と変数が$スコープに格納される方法に影響します。



静かな失敗の傾向。 間違いを犯したり、何か間違ったことをしたり、原因を示すことはできません。 「A」と書く価値のある「E」を書きましたか？ アプリケーションが動作を停止しました。



Reactで初めて同じアプリケーションを書いたとき、28¾時間かかりました。 Reactでの最初の試行からコードの一部を使用できるという事実にもかかわらず、私は同じアプリケーションをAngular39½時間で作成しました。 トップで10時間。 その理由は、Angularの過度の複雑さです。

4.テスト-⚇（ここでもここでもない）

Angularはテストを非常に重要だと考えています。 その主な機能の1つ-依存関係の実装（依存性注入）は、テストを簡素化するために特別に作成されています。



この焦点を考えると、Angularでのテストがいかに悪いかということに驚きました。 コントローラーとサービスのテストロジックに焦点を当てていますが、ユーザーインターフェイスの動作をテストすることはほとんどありません。 ブラウザーイベントのシミュレーションはサポートされていません。また、HTMLテンプレートを単体テストする方法もありません。 カスタムディレクティブはテストできますが、内部に別のディレクティブがあるディレクティブをテストするのは怖いです。



Angularは、ビジネスロジックの単体テスト機能に重点を置いています。 ただし、唯一の理由は、アーキテクチャ自体がUI（特にコントローラーとサービス）にビジネスロジックを配置することを引き起こすからです。 優れたアーキテクチャは、UIに依存しないオブジェクトにビジネスロジックを配置します。



Angularの多くの側面は、自己カットの上のパッチのように感じます。



アプリケーションの場合のようにビジネスロジックを削除しても、AngularがHTMLをレンダリングしてイベントに応答する方法をテストするだけであり、Angularはこれを行うことをサポートしていませんでした。 Angularチームは、特別に設計されたエンドツーエンドのフレームワークを使用してProtractorをテストすることをお勧めします。



エンドツーエンドのテストは時間がかかり、脆弱です。 それらの数は最小化する必要があり、テスト戦略の中心概念としてそれらに依存しないでください。 幸いなことに、アプリケーションのUIをカスタムディレクティブに配置することで、Angularを単体テストする機会がありました。 ここで彼は「ここでもそこでもない」中立的な顔を獲得しましたが、よく見ると、小さな涙が見えます。

5.サーバーでレンダリング-（bueee！）

AngularJSは、サーバー上で動作するようには設計されていません。 驚きはありませんが、検討する価値があります。



結論：避けてください。



Angularでの作業-苦痛。 各ステップは新しい機能またはテストであり、レビューの終わりまでに彼は本当に私を見つけました。 おそらく、Angularが望んでいたことをすべて行い、デザインを実装しようとしない場合、それは私にとって簡単ですが、私の目標は、プロジェクトを長期的にサポートする可能性を探ることであり、できるだけ早くすべてを行うことではありませんでした。



この点で、すべてが悪いです。 Angularは複雑なフレームワークであり、奇妙なものに成長しました。 これは人気がありますが、良くありません。より良い選択肢が現れるとすぐに忘れられると思います。 Angular 2はすでに準備段階にあるため、今日Angularを受け入れることで、数年以内にアプリケーションを書き直すことを（ほとんどの場合）自分自身を非難しています。 将来のバージョンではこれらの欠陥が修正される可能性がありますが、今日のAngularは適切な選択ではありません。 避けてください。