Backbone.jsをいじりはじめての感想

　Backbone.jsをいじって、アプリケーションの準備をしているのだけれども、Backbone.jsは何かと便利だ。とはいえ、それほどBackbone.jsらしいメリットを享受しているわけではないのだが、しかし何かしらの基準があるということは素晴らしいことだ。正直、Backbone.jsのMVCの分け方は少し不器用な感じがしなくもないのだけど（個人的には、ControllerからRouterに名前が変わったところにそういうのを感じてしまう）、でも基準が生まれたことによって書きやすくなっている部分はある。まさに背骨。

　以前に「大規模、大規模というけど、お前の言う大規模とは何か」みたいな話をされてしまって、考えてみればそれほど大規模ではなかった。というより、ミサワ的なドヤ顔をしたいために大規模、太規模言っているだけだった。反省。中規模？ただそういうことを考え始めるとただの定義問題となってしまう。基本的には「ファイルを分けていく必要があれば、とりあえずそれは中規模くらいに考えてもよさそう」という感じの気持ちはある。既に羊頭狗肉になっているけど、気にしないことにする。

　とはいえ、じゃあ「ブラウザに読みこませるためのチューニングアップ的な奴」以外にファイルを分ける必然性があるときってどんなときだろう、というと、自分としては「変更可能性がありそうなパーツを一まとめにしておく」という感じでまとめたりしていた。例えば、Backbone.jsを使う前は、下のような感じだった。

• フォームの値をParseしてデータ構造を作ってくれる関数一式
• 受け取ったデータ構造からHTMLを組み立ててくれる関数一式
• イベントと実際の挙動を結びつけるための関数一式
• 実際の挙動

　みたいな。こういう分け方だったので、結果として、Backbone.jsに手直しするときも、それなりに楽だった気はする。逆に、こういう構造だったときに、辛かったのは、DOM構造自体を一種のModelみたいな扱い方をしていたという点であるところと、あとEventがひとまとまりになっていたので、どの部分がどのEventを必要としているのか、という見通しができなくて、ちょっと辛いことになっているくらいだった。

　逆にBackbone.jsでなれてなかったのは、Model、Collectionをどう取り扱うのが一番いいのか、とか、あと元のURLの仕様自体が別段Backbone的に構成されているわけではない(RESTfulにMethodでPUT/DELETEとか使う感じでは無い）ので、そのあたりを調節していって、現在利用しているフレームワークの利用的に辛い部分とかがちらほらしていたことくらいかなーとは思う。このあたりに関しては、本気で使いたくないときはチューニングできるっぽいので、それはそれでいいかなと思う。現時点では、Backbone.jsにはそれなりに満足している。