gihyo.jpサイトのロゴ

実践入門 Ember.js

第1回Ember.jsの世界

2014-12-09


はじめまして。佐藤竜之介︵@tricknotes︶と申します。本連載では、ユニークな特徴を持つJavaScriptフレームワークであるEmber.jsの仕組みと、実践での活用方法について解説させていただきます。

なぜEmber.jsか


ここ数年、ネイティブアプリケーションのような使い勝手を備えたWebサービスが増えています。筆者が利用しているサービスを例に挙げるとGmail, Pivotal Tracker, Idobataなどがあります。これらはどれも画面遷移がなく一枚の画面上であらゆる操作を行うため、﹁⁠Webサイト﹂というよりは﹁アプリケーション﹂と表現する方が適切でしょう。このようなアプリケーションはシングルページアプリケーション︵SPA︶と呼ばれ、従来の画面遷移中心だったWebアプリケーションと区別されることがあります。
ただ、SPAの開発には特有の難しさがあります。それはデータと表示を常に一貫した状態に保つことやアプリケーションの﹁状態﹂を意識すること、オブジェクトのライフサイクルを考慮することです。これらの困難さを軽減するために、SPAを専門にサポートするフレームワークが注目を集めています。
こういったフレームワークはユーザインタフェースを取り扱うパターンである﹁MVC﹂にちなんで、﹁⁠MV* フレームワーク﹂︵⁠※1︶と呼ばれることがあります。
本連載で紹介するEmber.jsも﹁MV* フレームワーク﹂のひとつです。
emberjs.com
画像
[1]SPAの世界ではフレームワークによってMVCのCの解釈が異なったり、MVCの派生系であるMVVMパターンであったりするため、総称してMV*と表現されます。

Ember.jsって？


JavaScriptで開発をしていると﹁このコードいつも書くなぁ…﹂という状況に出くわすことはないでしょうか？ 例えば、﹁⁠オブジェクトの状態を監視して適切にDOMに反映する⁠﹂⁠ ﹁⁠DOMのイベントを受け取ってデータを更新する⁠﹂⁠ ﹁⁠DOMの生成・破棄のタイミングでイベントをon/offする﹂などの処理です。Ember.jsはそういった決まりきった処理をよしなに取り扱ってくれるため、プログラマはアプリケーションの使い勝手や期待通りの機能を満たせているかなどの本質的な部分の開発に集中できます。
もちろん、Ember.js以外にもたくさんの選択肢があります。AngularJSやReact、その他にもMV*フレームワークのサンプル集であるTodoMVCを見てみると、数多くのフレームワークやライブラリが存在していることがわかります。

Ember.jsを選ぶべき場面


では、私たちがEmber.jsを選ぶべきなのはどんな場面なのでしょうか？
一口に MV*フレームワークといっても、アプローチの仕方はそれぞれ異なります。Ember.jsを特徴付けるのは第一に﹁フルスタックである﹂ということが挙げられます。すなわち、リッチなアプリケーション開発のために必要な仕組みすべてを提供することをEmber.jsは目指しています。その結果として、Ember.jsの初期学習コストはその他の軽量なライブラリと比べると大きいと言えるでしょう。ただ、あなたの作ろうとしているアプリケーションがある程度の規模を持つならば、そのコストを差し引いてもEmber.jsの掲げる﹁高い生産性﹂の恩恵を十分に受けられることでしょう。しかしながら、素早いハックが求められる場面ならば他の選択肢を検討したほうがよいかもしれません。
本連載ではEmber.jsの機能についてひとつひとつサンプルを作りながら解説する予定なので、Ember.jsによる快適な開発を体感していただけると嬉しいです。

Ember.jsの歴史


ここからはEmber.jsに親しみを感じてもらえるよう、Ember.jsの誕生した背景を説明します。

SproutCoreの時代


Ember.jsはSproutCoreというMV*フレームワークから派生する形で誕生しました。SproutCoreはMac OS X用のアプリケーションを作成するためのフレームワークであるCocoaの設計思想をJavaScriptで実現しようという方針のもと開発されました。2008年当時、GUIアプリケーションのアイデアをWeb開発に持ち込んだというのは大変画期的で、それまでDOM操作が主流だったJavaScriptの世界に本格的なアプリケーションを作るための可能性が広がりました。
ただ、Webアプリケーションの世界ではHTML+CSSという表現力豊かな画面作成の基盤がすでにあったので、独自のやりかたでGUIを組み立てるよりも既存のやり方をそのまま利用できるほうがメリットが大きかったのです。そのため、当時SproutCoreのコアメンバーであったYehuda Katz氏はSproutCore 2.0を開発することを決意しました。
しかし既存の仕組みから大きく方針転換をするにあたって、単純にバージョンを上げるだけではその違いをアピールするのに不十分と感じたYehuda氏はフレームワークの名前を変えて再出発することを決めました。そうして開発が始まったのがEmber.jsです。2011年12月13日のことでした[2]⁠。

おすすめ記事

記事・ニュース一覧