開発言語やフレームワークの比較は、参考になるところはありつつも、その結果、不愉快な気分になる人がいるわけですが、それを懸念して、「（これを読んだ人は、他人の）意見を読んでいるだけだと思い返してほしい。貴方にどうすべきだと言ってるのではなく、自分にもしくはチームのために何がよいかは自分で判断すべきこと。」と前置きして、Henrik Joretegが、JavaScriptフレームワークについて私見をシェアしています。

反対意見も併記しようと思ったのですが、TwitterやHNでの反応がまだないようなので、注目すべきコメントがでてくれば、後日まとめます。

1) Angular.js

pros

• 最初がものすごく簡単。スクリプトタグでng-属性をアプリに追加すれば、マジックのように振る舞う。
• 開発のコアチームの多くがGoogleの社員で構成され、手厚い陣容。
• ユーザベース/コミュニティの規模が大きい。

cons

• Angularを選ぶということは、JavaScriptで問題を解決するというよりは、Angularというフレームワークを学ぶことになる。JavaScriptのスキルではなく、Angularのスキルがあるエンジニアが育つ。
• 関心の分離（Separation of concerns）の原則に反している。古臭いと言われるかもしれないが、CSSはスタイル、HTMLはストラクチャ、JavaScriptはアプリのロジックという役割。しかし、Angularは、JavaScriptではなく、HTML上で振る舞いを記述することが多い。それだとアプリのロジックを記述しているのでなく、ストラクチャドキュメントのマークアップをしている。これを実現するために、HTML内で新しい言語を書き、JavaScriptで更に補足するという手法をとっているので、アプリづくりが複雑になる。
• マジックの程度が行き過ぎ。抽象化しすぎると、中で何が起きてるかわからないので、自信をもって改善やデバックができなくなる。
• 従うべき構造が少ないので、Angularでの正統なシングルページアプリのつくり方がわからない。人それぞれのやり方になるということは、他人がつくったAngularアプリを直したり、他人のAngularモジュールを取り込むのは難しくなる。

2) Ember.js

pros

• とにかく良くも悪くも、”The Ember Way” を強調している。もし人数も出入りも多いチームでこのような厳密な構造をもつフレームワークを採用した場合、生産性高くコードベースを共有できるか、もしくは「このフレームワークはいやだ。」と分裂するか、両方の可能性がある。
• シングルページアプリをつくる上での難しい問題の解決を、それに起因する様々なトレードオフを判断してくれる、ものすごく賢い人たちに任せている。
• コミュニティの規模が大きく、親切にサポートしてくれる。
• ドキュメントのサイトがよくできている。
• 問題を解決してくれるボリュームと、それに使えるコンポーネントが豊富。

cons

• “The Ember Way” が強調されることにより、ルールに縛られる感が強い。基本をはずれることはテクニカルには可能だが、おそらくそのケースはほぼ起きない。
• たくさんの知見が既にフレームワークに取り込まれていて、それに従わないで自力で機能を置き換えた場合、利用しないことになったコードもブラウザに送られる。これだとバグの原因を特定しづらい。
• メモリ消費が辛い。特にモバイルでは難あり。
• 意図的かつ構造的にフレキシブルではない。「フレキシブルが好みな人は、Emberを使うべきでない。」と明言されている。

3) React

フレームワークではなくて、viewレイヤであるが、話題になっているので追加。FacebookのFluxアプリアーキテクチャになると、フレームワーク的になる。

pros

• バーチャルに都度、再レンダリングし、実際のDOMとの差分を確認のうえ、変更箇所だけをうまく反映してくれる。
• バーチャルDOMによる抽象化が、うまくコンプライアンス的に働き、どのブラウザでも整合性のとれたイベントモデルを実現してくれる。
• フレームワークではなく、viewモデルなので、柔軟にアプリを構成できる。例えば、Backbone.jsとの連携も可能。

cons

• テンプレートの構文とDOM (+JSX) のつくり方に違和感あり。JavaScriptのエンジニアにとっては、引用しないHTMLをJavaScriptに組みような感じ。
• DOMに何がどう適用されるか完全にコントロールしたい人にとっては不向き。
• 複雑なアプリが自動的に再レンダリングされると相当なdiffがでるので、把握できなくなることを恐れ、理解できているコンポーネントだけをアップデートするエンジニアの話を聞いたことがある。それでは本末転倒。

4) Polymer

pros

• ブラウザから独立したかたちで、入力フォームのカスタマイズなどができるのは素晴らしい。
• Polymerはポリフィルとしてブラウザ機能を拡張できるので、今から即利用可能なテクノロジー。
• webにとって長年の課題であった、ウィジェットをつくる際の適切なスタイルの分離を、ブラウザレベルで問題を解決してくれている。

cons

• web開発の万能薬的なポジショントークにはちょっと違和感を抱く。シングルページアプリづくりは、素敵なカスタマイズした要素に置き換えるだけではダメで、全体の要素の生成/終了を管理する仕組みが別途必要。
• Googleにとっては、JavaScriptを把握してなくても、Googleのサービスを理解できるようにさせるという戦略ではないか。マーケティング的に盛り上りをつくり、技術標準化しようとしている意図を感じてしまう。Google内で採用されているのが、Polymerのサイトだけというのも危険信号。
• HTML Importは、CSS@import問題の再来ではないか。かなりコンポーネント化されたアプリをつくると、大量のネットワークリクエストが行ったり来たりすることになる。vulcanizerでまとめるというソリューションもあるようだが、それをインラインするオプションはないと思う。詳細はこちらのブログ参照されたし。

5) Backbone.js

pros

• model / collection / view / routerは、十分テストされていて、フレキシブルに使える。
• 基本的な問題をしっかり解決してくれている。
• スコープが限定されているので、理解しやすい。新しく採用したフロントエンドエンジニアへの最初のタスクとして、Backbone.jsのドキュメントを読ませるようにしている。

cons

• 問題を全て解決してくれるわけではないので、ほとんどのメジャーな利用事例は「Backbone + 何とか」というフレームワークになる。
• Backboneを使っていてよく迷うのは、
  • modelで生成されるプロパティをつくる方法
  • 既存のプロパティと生成されたプロパティをviewにバインドする方法
  • 要素内で一連のviewをレンダーする方法
  • subviewやネスト構造をきれいにつくる方法
• Backboneはミニマム主義であるものの、各ピースが密に連携しすぎている。例えば、Backbone collection内では他の型のmodelは使えない。Backbone以外のアプリがアクセスするデータを保持するmodelをつくるときなどは困る。モンキーパッチするか、Backbone全体をincludeするか。

6) フレームワークに頼らない

pros

• 究極なフレキシブルさ。
• アプリに本当に必要なコードだけを残せる。

cons

• Ryan Florence曰く、「パブリックなフレームワークを使わないという選択をした場合、最終的にはフレームワークを利用することになる。自分独自のというフレームワークを。」
• 誰かがつくってくれているはずのソリューションを自分でつくることになる。
• 正しいmoduleの選択は難易度が高い。
• 後から新しいエンジニアが参加しても、ドキュメントは不十分で、頼るべき慣習がわからない。
• 次のプロジェクトにコードを再利用するのは本当に難しい。
• 他人のコードで恩恵を受けるのではなく、結局は自分の失敗から学ぶという機会になる。

6) Ampersand.js

（注）Henrikは、Ampersand.jsを担いでいる &yet社のメンバです。原文をかなり省略してますので、詳細はサイトを確認ください。

pros

• フレキシブルだが適度な結合度
• スタートにあたって、構文は明示すべきだが、強制するのはよくないと考えている。そこでCLIを用意し、これから開発にトライしたい人も、参照するだけという需要にも応えられるようにしている。
• 試しにつくるというのではなく、本格的なアプリづくりの道具にしたいので、Backbone.jsを利用して構築している。
• 考え方を浸透させるために、Human JavaScriptという本（オンライン購読無料）にまとめた。
• npmを利用し、モジュール検索機能も提供。
• browserifyにデプロイのワークフローを加えた moonboots を用意した。

cons

• コードが未成熟なところがあり、ツール群の充実はこれから。
• コミュニティも立ち上げ中。
• 古いブラウザのサポートは不十分。

#angularjs #emberjs #react #polymer #backbonejs #ampersandjs