BackboneマンがAngular勉強会いってきたけどそんなに好きになれなかった話 #ng_jp

最初に僕のポジションは表明しておくけど、今までbackbone.js, というかそのラッパーであるchaplin.jsべったりの環境で開発してて、今のプロジェクトをゼロから作り直す機会があるので次バージョンのためのライブラリ選定のためにとりあえず比較として angularを試した見た程度の人間なので、深くは理解してない。

Angularのメリット

僕の浅い理解と勉強会での話を総合した感じ

  • レールに乗り切った時の開発効率が半端ない
  • レールがしっかり敷かれているので開発者の能力差が問題にならない
  • HTMLがテンプレートなので意味的な乖離が少ない
  • ビューモデルに対する操作が一貫していてテスタビリティがある

自分もモジュラリティがあるHTML/CSSは幻想だと思っているので、HTMLに直接属性を書くのは別に構わないと思っている。 ただ、集団開発でも開発者の能力差が問題にならない、という発表をしていた人が、「ビュー同士がデータを共有するのに困って$rootScopeを作って共有した」といっていて、え、それは一番やばいやつでは感あった。

angularの問題点

  • ドキュメント必須の割にドキュメントのググラビリティが低い
  • 途中から急に学習コストが高い
  • HTMLセマンティクスみたいなものは放棄している
  • 「全部入り」でモジュラリティが少ない。angularを辞めた時に知識を持ち回せない。
  • 画面に直結しないパラメータの置き場所がない

最近Angularの検索数が跳ね上がってて一番人気です！っていう紹介をたくさんみるようになったんだけど、正直「ググらなければわからないこと」が多すぎて他のフレームワークより検索という行為に高度に依存しているというのを感じている。この場合の検索数は、人気ではなく複雑さに依存している。この辺railsに似ている。

比較対象としてのBackbone

Backboneは薄いライブラリだから公式リファレンスかソース読めばわかる。それと同時にBackboneってクッソ薄くて何もしてないよね、というのも同意する。あれは規律のための骨格を用意しているだけで、まさに「背骨」であると思う。プロジェクトの中で規律を作る行為は開発者側に任されてる。それが出来ないならchaplinとかmarionetteとかの更なるラッパー使えばいいと思う。僕が気に入ってるのは、各構成要素がMでもVでもCでもプラガブルで取り替えが聞くので、Angularのように激しくロックインされることはない。

僕はJSで結構複雑なクライアントロジックを持つアプリを書くことが多くて、ビューに表出しないデータを大量に抱えていることが多いんだけど、Angularはそういうデータをビューモデルに置いてしまうというのは結構致命的に思えた。

最後に、backbone用のデータバインディングライブラリである backbone.stickitのFAQで痛烈なangular批判をしていたので、それを引用したいと思います

Why Stickit?

JavaScript frameworks seem to be headed in the wrong direction - controller callbacks/directives, configuration, and special tags are being forced into the template/presentation layer. Who wants to program and debug templates?

If you are writing a custom frontend, then you're going to need to write custom JavaScript. Backbone helps you organize with a strong focus on the model, but stays the hell out of your presentation. Configuration and callbacks should only be in one place - the View/JavaScript.

落とし所

僕もそんな印象です。

QuipperはBackboneでデータバインディング採用してMVVMな感じにしてます。 参考: CoffeeScript - Backboneでデータバインディングを使ってMVVMをするフロントエンドアーキテクチャ - Qiita [キータ]