あなたはいつEmber.jsを使うべきか？

今日まで Ember.js の紹介をしてきました。
思えばAdvent Calendarを書き始めた12/1の時点では、私自身、Ember.jsについてはほとんど何も知らない状態でスタートしました。
もっともknockout.jsを業務に使っていたので、データバインディング機能の便利さは理解していましたし、Ember.jsが記述の柔軟性のレベルでは他のデータバインディングより洗練されているので、コンセプトレベルでは間違いなくすばらしいフレームワークである、ということは確信していました。
ただ、Router, ストレージの利用方法、拡張方法についてはまったく分かっていなかったので、どこまで実運用に耐えうるフレームワークかは未知数でした。

それから1ヶ月ほどEmber.jsを調査してみた結果、利用上で心配していた点については問題ないことが分かってきました。
今ではEmber.jsは効率的に動的なアプリケーションを構築するうえで、便利に使えるフレームワークだという実感を持っています。

ただ、Ember.jsを利用することでメリットのあるアプリケーションもありますが、そもそもEmber.jsを利用する必要はないサイトというものも、もちろん存在すると思います。

最終日の今日は、どういうケースでEmber.jsの使用を検討すべきなのか、その際の懸念点、判断材料は何かという点を整理したいと思います。

Ember.jsが向いている機能

複雑なフォーム

データバインディング機能はコントロールパネルなどの複雑なフォームで最も威力を発揮します。複雑なUIを作るときには使用を検討する価値があります。

検索結果の表示

• メリット
  • 画面切り替え無しで結果更新
• デメリット
  • クライアントサイドエラーの可能性
    • エラーが発生した場合、コンテンツが表示されない

検索時に画面切り替えが発生しないことは、メリットと言えると思います。ただ、検索画面で画面切り替えが発生しても、操作感にさほど問題が生じるわけではないので、使用感にこだわりがあれば、使っても良いという感じでしょうか。また、万一JavaScriptのエラーが発生すると、コンテンツ自体が表示されない危険があります。ブラウザごとに動作テストは入念に行いましょう。

Ember.jsが向いていない機能

単純なCRUD

• メリット
  • 表示要素の更新を動的に表示
• デメリット
  • scaffoldに比べてファイル数も構成も複雑に

マスタ編集画面のように、描画内容を全更新してもオペレーションが問題ない機能であれば、Ember.jsを使うメリットはあまりないと思います。
scaffoldで十分なページなら、scaffoldでいいのではないでしょうか。

懸念材料

速度の問題

[obsolete]上記サイトのベンチマークでは、配列へのpushは、Angular.jsより3〜5倍処理時間がかかるという結果が出ています。
[obsolete]項目数が多い時は速度のチューニングが必要になるかもしれません。

現在のバージョンでは、Ember.jsがダントツに速いという結果が出ています(Angular.jsの20倍程度速い!)。詳しくはコメント欄をごらんください。

スマホ対応

データバインディングはクライアント側の処理の負荷(主にCPU)がかかるため、スマホには向かないか、チューニングが必要になってくるとおもいます。

バリデーションエラー

Ember.jsは標準でバリデーションエラーを表示する仕組みを持っていないので、ここが実際にフォームを作るときのネックになってくる恐れがあります。独自にバリデーションエラーを表示する仕組みを導入する必要があるでしょう。

後方互換性

現状まだ活発に開発されているため、後方互換性は十分に保たれていません。
現在のEmber.jsのバージョンは1.0.0-pre.2で、現時点で取り込まれた pull requestには、すでに1.0.0-pre.2で動いてるコードが動かなくなるものも含まれています。

デバッグの問題

データバインディング機能は便利ですが、バグが発生した時に、エラー情報から原因を特定するのはわりと困難です。これは慣れが必要だと思います。
Ember.Objectレベルでのデータバインディングはテストが書きやすいので、テストは積極的に書くことでバグへの対策になると思います。
一方テンプレートへのデータバインディングでバグが発生した時には、原因特定/対処共には難しくなることが多いと思います。

アプリケーション全体をEmber.jsで構築すべきか？

今日まで調べた結論として、無理にアプリケーションすべてをEmber.jsで構築する必要はないと判断します。
入力 -> 確認->完了の一連の処理にのみRouterを利用する、というような、一部の機能にのみ部分的に導入しても問題ありませんし、むしろこのほうがロード時間の短縮につながっていいと思います
。

JavaScript OFF環境では動かない

当然ですが、JavaScriptが効かない環境では、Ember.jsのプログラムは動作しません。JavaScript OFF環境に対応する必要があるなら、別途プレインHTMLによるフォールバック処理を行う必要があり
ます。

学習曲線

私感ですが、データバインディング機能を使ったプログラミングは、そうでないプログラムとは、作る際の脳内モデルの作り方がかなり異なります。
最初はデータバインディングプログラミングに慣れるまでに、わりとつまづきが多いと思います。
一旦概念が理解できれば、あとは理解の度合いが一気に進むと思います。

Ember.jsを使う動機

データバインディング機能は大変便利な仕組みなんですが、いざどこに使うか考えてみると制限が厳しいことに気づきます。
JavaScript OFFの環境へのリーチが必要なら使えませんし、処理速度の問題も出てきます。
モダンブラウザに限定できるサイトで使うというのが、現時点での利用ケースでしょうか。

そういう制限をかけてまでEmber.jsを使う動機は、やはりプログラムの構造化ができる点に尽きます。
動的なページをスパゲッティにならずに構築できるのは、大変楽しいです。
Ember.jsによる構造化でも、どの程度の規模のサイトに適用できるのかは今後検証していく必要がありますが、少なくともknockout.jsだと、大したことない規模のプログラムでも激しいスパゲッティプログラミングに陥ってしまうということを経験してきたので、その程度のプログラムであればEmber.jsなら断然作りやすいという実感を持ちました。

まとめ

以上、Ember.jsを導入するかどうかの判断材料を述べました。
Ember.jsを利用するかどうかの判断の助けになれば幸いです。

最後に

今日までEmber.js Advent Calendarを書いてきましたが、本記事で最後になります。
実は当初からの目標として、Advent Calendarを利用して、Ember.jsの、包括的な入門資料を作るという目標がありました。
手前味噌ですが、この目標はかなり良い形で実現できたのではないかと考えています。
記事の順番も、ほぼ当初の計画通りに進めることができました。

途中で投げ出してしまうかも、という恐れもあったのですが、みなさまからの反応を励みにして、なんとか最後まで書き切ることができました。本当にありがとうございました。
また、私の計画を試す機会と場所を提供していただいたQiitaにも感謝します。
あと、一人Advent Calendarの元ネタになった、一日一面実況ロードランナーにも感謝します。これは傑作やでぇ。
ずっと誰でもAdvent Calendarに登録できる状態だったので、正直いつ頓挫してしまってもおかしくなかったのですが、みなさまが空気を読んで、一つも投稿してくれなかったおかげで最終日まで一人で書ききることができました。ありがとうございました。

来年は倍の50日くらいAdvent Calendar書きたいです。それでは。