Angular, Ember, Backbone：どのJavaScriptフレームワークを選ぶべきか？
JavaScriptフレームワークの選択は、開発者の好みよりもプロジェクトとの相性が大切だ。
JavaScriptベースのアプリケーションやウェブサイトのアイデアを思いついたとして、次にしなければならないのが正しいオープンソース・フレームワークを選ぶことだ。
この記事を読んでいるということは、あなたはまだ初心者や見習いの開発者かもしれない。あるいは自分のアイデアの開発を外部に委託しようと考えているのかもしれない。Angular、Ember、Backboneの名前ぐらいは聞いたことがあるかもしれないが、それらがどういったもので、なぜそれらがウェブ開発の助けになるかについてまでは知らないかもしれない。
開発者はJavaScriptを様々なウェブ・アプリケーションに使用している。それはJavaScriptがクライアント側（すなわちユーザー側）の動作と見栄えを美しくしてくれるからだ。それほど古臭くは見えないかもしれないが、JavaScriptという言語は20年ほど前から存在しており、多くの種類と幅広い用途がある。複数のブラウザとユースケースで動作するようにコードを加えていくと、とたんにコードは膨大で、複雑に入り組んだものになってしまう。
そこでJavaScriptフレームワークの登場となる。Angular、Backbone、Emberのようなフレームワークは、JavaScriptコードの構造を整理された状態に保つことができる。これらはすべてオープンソースのため、それぞれのコミュニティーによって絶えず改善されている。さらに、これらはそれぞれjQuery（JavaScriptの複雑な操作をより簡単かつ高い可読性で実行することができるパワフルなライブラリ）上に構築されるため、開発時間の節約にも繋がるはずだ。
jQueryを使うことでいかにコーディングのプロセスが改良されるかの例を挙げよう。テーブル（表）を生成するために退屈なコードを何行も書く代わりに、たった一行のコードを書いて、JavaScriptライブラリへの参照を挿入するだけで済んでしまう。それにこれらのショートカットは、単にコーディングを早く済ませることができるだけでなく、同時に複数の環境にも対応させてくれるのだ。
しかしながら、JavaScriptフレームワークの選択はTシャツの色を選ぶようには簡単にはいかない。完全に用途の異なる３つの衣服から１つを選ぶようなものなのだ。３つとも同じ衣服には違いないが、それぞれの機能と見た目は全く違っている。例えば寒い気候の中で水着は着られないし、ビーチで冬用のコートを羽織るわけにもいかない。同様に、JavaScriptフレームワークもアプリケーションのタイプに応じて適材適所で選ぶ必要があるのだ。
以下に今最も人気のある３つのJavaScriptフレームワークのそれぞれの概要と、その適正を紹介しよう。
Angular JS
2009年にリリースされたAngularJSは、３つのフレームワークの中で一番古い。そして恐らくそのためだろうが、最大のコミュニティーを有している。
2013年にはGitHub上でユーザー数が4番目に多く、星の数（Facebookでの「いいね」のようなもの）も３番目に多い言語となった。Built With AngularJSでは、これまでにAngularを使って開発されたアプリケーションを見ることができる。
JavaScriptフレームワークとしてAngularJSを利用している有名な企業にはグーグルやナイキが含まれている。2013年8月から、General Motorsの車載アプリケーションもAngularで構築されている。また、the Guardian、the Huffington Post、MSNBCなど、多くのニュースサイトのトップページでAngularJSが使われているのを見ることができる。
グーグルでのAngularJSの主任開発者イゴール・ミナールによると、ニュースサイトにおける需要よりも、その適応性こそがAngularの選ばれる理由だという。
「Angularがニュースサイト以外のサイトやアプリケーションに適していないとは思いませんが、ニュースサイトの実績が多いのは確かです」とミナールは語っている。「これが目立つ理由はおそらく、ニュースサイトは競争の激しいマーケットであり、ユーザ・エクスペリエンスを効果的に改善していくために最新の技術を取り入れているためでしょう」
何故Angularを採用しているサイトはすばやい変更に対応できるのだろうか？それは恐らくAngularの性質上、開発者が他のあらゆるフレームワークよりも簡単にテスト用のコードを作成し、頻繁にテストを行えるからだろう。このガイダンスをうっとうしいと思う開発者も少なくはないが、小さなコーディング・エラーを早期に発見することで、それがより大きな問題に発展してしまうことを未然に防ぐことができるのだ。
Angularのもう一つの特徴は、独自の単語や専門用語が多くあることだ。ミナールはこれはAngularフレームワークが、他のJavaScriptソリューションにはないいくつかの機能を含んでいるためであると考えている。
「我々が頻繁に使ういくつかの単語はAngular独自のもので不思議な専門用語に聞こえるかもしれません」と彼は話す。「幸いなことに、最近ではAngularのコンセプトにウェブ・スタンダードが追いついてきており、正式な名前が付けられるようになってきています」
Angularを使ってコーディングをする場合にはこうした堅苦しい用語を使うことになるが、Google Trendsによればこれはそう悪いことでもないようである。確かに専門用語を使う必要はあるし、テスト可能なコードを書くには時間もかかるが、これが結果としてAngularの適応性につながるのだ。
Backbone.js
2010年6月に登場したBackboneは、Angularに匹敵する規模のコミュニティーを持っている。
Twitter、Foursquare、LinkedIn Mobileを含む多くの人気アプリケーションがこのBackboneフレームワークを使っている。さらに注目すべきは、Soundcloud、Pitchfork、Pandoraを含む多くの音楽アプリが同じくBackboneで作られていることだ。
他のフレームワークに比べてBackboneはダウンロード・サイズが非常に小さいことに特徴がある。AngularJSの場合は圧縮され最小化された状態で約36Kだ。Emberのスターターキットはさらに大きく69Kなのだが、Backboneはたった6.4Kしかない。
この小型のサイズこそがBackbone最大のセールス・ポイントだ。複数のライブラリに依存していないため、たった１つのJavaScriptライブラリで足りてしまう。その結果Backboneは非常に軽量であり、速くレスポンスの良いアプリケーションの構築に適している。最も効果を発揮するのは、ウェブ・アプリケーション自身が小さく、シングル・ページあるいはページの一部に収まる場合（まさに現在Backboneを使っている音楽アプリのような場合）だ。
Backboneにはもう一つ特徴的な点がある。それはこのフレームワークがかなり「ハンズ・オフ」、つまり開発者のコードに干渉しないということだ。経験を積んだJavaScript開発者であればすぐに始められるだろうが、経験の浅い開発者は「boilerplate（決まり文句のコード）」を何度も繰り返して書くことになってしまうかもしれない。
Backboneの生みの親ジェレミー・アシュケナスによれば、無駄に決まり文句のコードが多いという批判は「ばかげたネガティブ・キャンペーン」だという。
「Backboneで決まり文句のコードをたくさん使っているような人は、その正しい使い方を理解していないのです。」とアシュケナスは言っている。「一般的にプログラミングでは、もし同じことを何度も書くのであれば、自動的にそれをやってくれる関数を作って解決するものです。」
それでも解決しない場合、Backboneには特に活動的なコミュニティーが多く存在しており、そこでこのフレームワークを使い始めるための無料のチュートリアルが提供されている。多くの開発者達が有用なサンプルやハウツーをGitHubを使ってアップロードして、他のプラットフォームに匹敵するサポートを実現してくれている。
もしあなたがシングル・ページのアプリケーションやウィジェットに取り掛かっていて、自身で調べて勉強する気概があるなら、Backboneは恐らくあなたに最適な軽量のフレームワークだ。
Ember.js
2011年にリリースされたEmberは、昨年バージョン1.0になったばかりだが、すでに大きな影響力を持つ人気のプラットフォームとなっている。最近ではCode Schoolが新たにEmberのコースを設立した。Code SchoolではすでにAngularとBackboneのコースが用意されているが、Emberのコースも同じぐらいの人気を集めそうだ。
LivingSocial、Groupon、Zendesk、Discourse、SquareなどがEmberを採用している最も有名なアプリケーションだ。Ember創設者トム・デールとイェフダ・カッツは、サイトがEmberを使っているかどうかはそのローディング速度ですぐに分かるという。
「それらは普通のウェブサイトのように見えますが、普段使い慣れているものよりもはるかに速く動作します」とデールは語る。「それは全てのレンダリングがブラウザの中で行われるからです。通常のウェブサイトに見えるかもしれませんが、その中身はiOSやAndroidのアプリのように構築されていて、サーバーによってレンダリングされていないのです」
小型化され圧縮された状態で69Kのサイズで、今回紹介したものの中で一番大きいフレームワークだが、カッツはよくある中型のjpeg画像と変わらないぐらいの大きさであると指摘する。
「Emberに含まれる機能が必要だと我々は確信を持っています。コンパイルされたEmberアプリのサイズは、よく他のアプリと並べて比較しても、ほとんど同じサイズに収まっているのです」とカッツは説明している。つまり他のプラットフォームを使う開発者は、ビルドの過程で追加のライブラリやツールをダウンロードしたりしていて、最終的なアプリは同じぐらいの大きさになってしまうというのだ。
このJavascriptフレームワークのダウンロードサイズが、今回紹介する3つの中で最大であるもう一つの理由は、Emberには標準的なコード機能のための、多くのビルトインのサポートが含まれていることだ。例えばウェブサイトで「戻る」ボタンをクリックして何も起こらない場合、JavaScriptプログラムが壊れている場合がほとんどだ。Emberのサポート機能は、このような細かいがやっかいなエラーを防いでくれる。
Emberのライブラリ・サイズとサポート・ネットワークがこのフレームワークの大きな強みだが、シングルページのアプリや小さなウィジェットを作る場合には少し過剰かもしれない。もしマルチ・ページで、ナビゲーションのある、長期的なプロジェクトに取り組む場合には、Emberを選ぶべきだろう。
開発者同士がこれら３つのフレームワークについてオンラインで議論すると、最後は個人的な好みに行き着いてしまう。しかし客観的に見れば、アプリケーションの種別とニーズに応じて最適なフレームワークを使い分けることが最高のパフォーマンスにつながることは明らかだ。
画像提供：Madeleine Weiss
Lauren Orsini
[原文]
