対象読者
- jQueryなどを使っているJavaScript開発者
- JavaScriptを使った複数人でのプロジェクトに参加している方
- JavaScriptを使ってサーバ等と連携したフロントエンドの開発をしている方
必要な環境
この記事では、AngularJSを使用し、Chrome（36.0）、IE11、Firefox（31.0）、Safari（7.0.5）の環境で確認を行っています。
JavaScript開発の歴史
フレームワークを説明する前に、10年ほど前から現在までのJavaScriptが歩んできた流れが分かると、どうして今、JavaScriptにもフレームワークが必要になってきているのか、または開発者はフレームワークに何を求めているのかが多少は見えてくることと思います。
2005年くらいまではJavaScriptは利用者や開発者から避けられていた技術で、たとえ使われても、非常に簡単で、しかも限定した利用用途でした。というのも、JavaScriptはデフォルトで利用不可という前提でありJavaScriptが必須であってはいけませんでした。Ajaxの手法を使ったGoogle Mapなどのサービスが出てきて、Ajaxという技術を使うと非常に便利なことができるということが認知され始め、Ajaxという言葉が技術トレンドとしてはやりだしました。
それでも、まだ当時は、同じようなものを作るなら、AjaxよりもFlashのほうがよいという認識がありました。しかし、Google MapやGoogleストリートビューなどのサービスのおかげで、JavaScriptを気軽に使ってもよい風潮が出始め、2006年頃からJavaScriptの用途がだんだんと広がり、jQueryなどを含めてJavaScriptのライブラリ化がゆっくりではありますが進んできました。
さらに、iPhone（第2世代以降）、Androidというスマートフォン（以下、スマホ）の流れや、PCでもChromeブラウザの利用率が高まるなど、HTML5をサポートするブラウザの普及がその流れを加速させました。特にスマホでは、JavaScriptがブラウザで動作する唯一のプログラム言語となったために利用が広がりました。また、jQuery MobileのようにHTMLをAjaxで取得してからページの表示を切り替えるアプリケーション（シングルページアプリケーション）が最近では広まりつつあり、アプリケーションの規模の拡大とともに複雑さが増してきています。
現在のJavaScriptを用いた開発で発生しやすい問題点、課題点
スマートフォンアプリやシングルページアプリなどの手法が使われる最近のJavaScriptでの開発では以下のような問題、課題が挙がるようになってきました。
- JavaScriptのグローバル関数、グローバル変数による他の開発者との重複問題やそのことによる生じる不具合（名前空間の汚染問題）
- 再利用可能なコードの作成方法
- メンテナンス性を考慮したフォルダ構造やファイル名のルール
- jQueryなどを利用する際のHTML要素のidやclassの管理とその依存管理
- テストなどを考慮した品質管理の必要性
- シングルページアプリケーションのブラウザバックなどの問題
シングルページアプリケーションでは、画面遷移する際に実際にURLが変わって遷移する代わりに、ajaxで取得したページを表示することで画面遷移を行います。そのため、ブラウザバッグをすると最初のページに戻ってしまいます。この問題を回避するためには、画面を変更した際にURLをそれに合わせて変更する必要があります。そのようにすることで、ブラウザでの戻るボタンを押しても通常の利用のように前の画面を表示することができます。
AngularJSなどのMVCフレームワークは、これらの問題に対して解決方法を提示してくれています。従って、うまくフレームワークを使うことによって問題を解決できます。
また、実際にはこのような状態にはまだなっていなくても、すでに1つのHTMLにつき複数ファイルのJavaScriptの作成が必要という状態にはなっていると思います。
そのようなケースでも、将来起こりえる問題や課題をスムーズに解決するために、あらかじめ知っておくことは決して無駄ではありません。
