開発言語やフレームワークの比較は、参考になるところはありつつも、その結果、不愉快な気分になる人がいるわけですが、それを懸念して、「(これを読んだ人は、他人の)意見を読んでいるだけだと思い返してほしい。貴方にどうすべきだと言ってるのではなく、自分にもしくはチームのために何がよいかは自分で判断すべきこと。Joretegが、JavaScriptフレームワークについて私見をシェアしています。反対意見も併記しようと思ったのですが、TwitterやHNでの反応がまだないようなので、注目すべきコメントがでてくれば、後日まとめます。Angular.jspros最初がものすごく簡単。スクリプトタグでng-属性をアプリに追加すれば、マジックのように振る舞う。開発のコアチームの多くがGoogleの社員で構成され、手厚い陣容。ユーザベース/コミュニティの規模が大きい。consAngularを選ぶということは、JavaScriptで問題を解決するというよりは、Angularというフレームワークを学ぶことになる。JavaScriptのスキルではなく、Angularのスキルがあるエンジニアが育つ。concerns)の原則に反している。古臭いと言われるかもしれないが、CSSはスタイル、HTMLはストラクチャ、JavaScriptはアプリのロジックという役割。Angularは、JavaScriptではなく、HTML上で振る舞いを記述することが多い。それだとアプリのロジックを記述しているのでなく、ストラクチャドキュメントのマークアップをしている。これを実現するために、HTML内で新しい言語を書き、JavaScriptで更に補足するという手法をとっているので、アプリづくりが複雑になる。マジックの程度が行き過ぎ。抽象化しすぎると、中で何が起きてるかわからないので、自信をもって改善やデバックができなくなる。従うべき構造が少ないので、Angularでの正統なシングルページアプリのつくり方がわからない。人それぞれのやり方になるということは、他人がつくったAngularアプリを直したり、他人のAngularモジュールを取り込むのは難しくなる。人数も出入りも多いチームでこのような厳密な構造をもつフレームワークを採用した場合、生産性高くコードベースを共有できるか、もしくは「このフレームワークはいやだ。」と分裂するか、両方の可能性がある。シングルページアプリをつくる上での難しい問題の解決を、それに起因する様々なトレードオフを判断してくれる、ものすごく賢い人たちに任せている。コミュニティの規模が大きく、親切にサポートしてくれる。ドキュメントのサイトがよくできている。問題を解決してくれるボリュームと、それに使えるコンポーネントが豊富。強調されることにより、ルールに縛られる感が強い。基本をはずれることはテクニカルには可能だが、おそらくそのケースはほぼ起きない。たくさんの知見が既にフレームワークに取り込まれていて、それに従わないで自力で機能を置き換えた場合、利用しないことになったコードもブラウザに送られる。これだとバグの原因を特定しづらい。