http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html より斜め読み。
- ふたつに分けて答えよう。
- なぜクライアントサイド MVC フレームワークを使うのか？
- なぜ（他のフレームワークではなく）Ember なのか？
何故クライアントサイド MVC フレームワークを使うのか？
- 対話性
- 比較的静的なページならサーバーサイドでレンダリングすれば良い。
- 対話的になればなるほどクライアントサイド MVC フレームワークの便益が向上する。
- なんで昔ながらの jQuery を使わないの？
- jQuery はちょっとした対話機能の実装なら上手くいく。
- でも状態が増えると data-* 属性を使って DOM にデータを埋め込んでいくことになる。
- イベントと属性の対応を覚えるの大変。
- それに DOM の構造と jQuery の実装が密接に結びつく。
- HTML を変えたら jQuery 側の実装も調整しないといけない。
- すぐスパゲッティコードになっちゃう（※ 例は記事を見て下さい）。
- データは DOM に分散。
- ロジックは特定の HTML に依存。
- MVC フレームワーク使うとどうなるか？
- Ember.js 使えば解決。
- バインディング機能があるから HTML の再レンダリングコール不要。
- DOM からデータを見つける必要もない。
- フロントエンド開発者がテンプレートを弄っても大丈夫。
- Ember.js 使えば解決。
- クライアントサイド MVC のパフォーマンス
- こんな心配を良く聞く。
- 巨大な JS ライブラリのダウンロード。
- JSON の送信。
- テンプレートのコンパイル。
- HTML 文字列の生成。
- Ember.js は minified gzipped で 47k。
- そんなに大きくない。
- Discourse は View が変わったときに JSON だけリクエストする。
- production ではテンプレートはコンパイルしない。
- プリコンパイルしておく。
- 確かにサーバーでレンダリングした方が速い。
- 特にしょぼいデバイスだとレンダリングするのが普通より遅くなる。
- でもまぁ良く考えて。JS もデバイスもこれからどんどん速くなるし。
- 最新の iPad だったらスムーズに動くよ。
- データ（JSON）だけ送ってスローなレンダリングする方が速かったりする（テーブルとか）。
- 良い副作用として良くテストされた API が出来上がる。
- 今後 Android や iOS クライアントを作るのは楽になる。
- だって既に流暢に JSON を話すようになってるんだもんね。
- こんな心配を良く聞く。
なぜ（他のフレームワークではなく）Ember なのか？
- ドキュメントがシンプルで分かりやすい。
- Angular.js のドキュメントは内部（詳細）を語ってない。
- Ember.js のドキュメントと比べてみたらシンプルさが分かる。
- 分かりやすいことって大切だと思う。
- 早い段階でちゃんと動いてたし凄い勢いで進化してる。
- API は途方もなく改善されてる。
- オープンソース界隈で実績があるチーム。
- Yehuda Katz は Rails3 と Bundler で凄い仕事をした人だし。
- 彼は Ember.js を放棄するつもりは無いって言ってたし。
- 僕は彼のことを信頼してるし。
- 文字列テンプレート vs DOM テンプレート
- Ember.js は DOM ベースのテンプレートを使う代わりに文字列ベースのテンプレートを使う（Angular.js は DOM ベース）。
- 個人的には DOM に属性追加するより handlebars のシンタックスの方が好き。
- ついでに言うと僕らは幾らかサーバーサイドでレンダリングもするし。
- そんなときは文字列ベースのテンプレートの方が楽。
- PhantomJS 環境を全部動かす必要ないしね。
- ループ処理
- DOM とバインディングのバッチ処理のパフォーマンス。
- 他のフレームワークでは 100 個のアイテムがあったら 100 回の DOM アップデート。
- Ember は 1 回でバッチ更新。
- ユーザーエクスペリエンス考えたら Ember の方が良いよね。
