なぜ AngularJS を採用したのか


今回は、AngularJS を採用した理由について軽くまとめておく。

JavaScript MVC 系のフレームワーク導入を検討することにし、もっとも普及している Backbone.js と、双方向データバインドなど高機能な Ember.js および AngularJS を検討した。

それぞれのフレームワークを順に 3 週間ほどずつ学習・実装してみた結果、AngularJS を採用した。

Ember.js を採用しなかった理由

まず Ember.js を 3 週間ほど別のプロジェクトで実装してみたところ、なんか難しかった…。ただの知識不足か実力不足かも…。

Ember.js の GUIDES ページや API ページをひととおり目を通し、Ember.js の書籍・動画・ブログなどでざっと学習したものの、簡単なところはともかく、ちょっと複雑なことをしようとすると、どう実装したらいいのかわからない…。jQuery でならとっくに終わってるぞ、と…。

そして挫折…。

いや、Ember.js は悪くないです。相性の問題というか、ごめんなさい。

Backbone.js を採用しなかった理由

次に、もともと本命に考えていた Backbone.js について。実際には AngularJS の後に評価したんだけれど、先に書く。

本命と考えていた理由は、普及度と、jQuery を使い慣れていた自分が最もすんなり入れるかなと考えていたから。MVC を明確に分離して記述することになってコードの見通しがよくなる。ただ、コード量は減るというより少し増える印象。

Backbone.js については、Underscore.js と併せて公式ページ・書籍・動画・ブログなどでざっと学習。ついでに Marionette.js についても軽く学習。

Backbone.js を不採用としたのは、評価時点で、すでに AngularJS をかなり気に入っていたことが大きい。あと、自由度が高過ぎるという印象を持ったことも大きい。Ember.js や AngularJS が実現している機能を加えることは可能なもののアドオンの選択肢が多く、ベストプラクティスと言える構成がわからずにいろいろ迷いそうだなと。

AngularJS を採用した理由

AngularJS をなぜ気に入ったのかと言えば、簡単なことが驚くほど簡単にできるというところ。そのとっつきのよさに驚いた。他のメンバーが入るときに敷居が低そうで、知識不足や考慮不足による問題を発生させにくそうだと思えた。

もちろん独自の directive を書くのは簡単ではないし、初めのころはモデルをどう宣言するのかや、HTML テンプレートをどう記述すればいいのかさえわからない始末だった。けれど、難しいところは一部のメンバーがわかってればいいので、ちょうどいいなと。

その後すでに数か月プロトタイプで AngularJS のコードを書いてるけど、特に困難にぶち当たることもなく、AngularJS のプロジェクトへの採用は成功しそうだなと安心している。よかったよかった。

なぜ jQuery だけじゃダメなのか

ところで、jQuery だけじゃダメなのか。jQuery はクロスブラウザに対応し、コードが簡潔で可読性が高く、普及率も高い。

ただし、DOM(HTML の構造ツリー)操作が主用途で、ある程度の規模でシングルページアプリケーションを制作する場合には、コード量が多くなり、どのタグにどんなイベントが付いているのか複雑でわかりにくくなりやすい。

なので、Backbone.js 使いましょうというのが主流なんだと思う。

もしコードを比較したいなら

自分の経験からも、フレームワークの選定にはいくつかのフレームワークを試用してみたほうがいいと思う。

そのとっかかりとして、同じ機能をそれぞれのフレームワークで実装している例 TodoMVC がある。ここで各フレームワークのコードを見れるので、雰囲気をつかんでみるといいかも。

私のオススメはもちろん、AngularJS ということで。