以前component + Backbone.jsでTODOアプリ書きましたが、
今回はcomponentのライバル(?)bowerを試したくて
bower + RequireJS + Backbone.jsでTODOアプリを書いてみました。
たぶんここ1年、クライアントサイドのMVCにはまって書く30個目くらいのTODOアプリ、
いい加減サーバクライアントで実装するのに飽きたので今回はChromeのExtensionとして実現してみました。一応Chrome Storeにあげてあります
https://github.com/p-baleine/todo-extension
以下、componentとbowerを比較した感想と雑記です
componentとbower
componentはExpressとかstylusで知られるTJが去年(2012)の8月くらいに
リリースした、パッケージ管理 + モジュール化機構 + αなフレームワーク(ツール?)です。
- Webアプリは外部(Github)及びローカルcomponentをボトムアップに組み合わせた、componentとして構築する
- componentは必要なJavaScript、css、image、fontをひっくるめて提供する
- 実はjQueryだとかのプラグインとして提供しているって事実は隠蔽して純粋なJavaScriptのオブジェクトとして提供する
…等、TJの哲学が色濃く出ていてるフレームワークです、詳細は起点のこのブログにて
http://tjholowaychuk.com/post/27984551477/components
bowerはTwitter主導で作っているパッケージ管理ツールで去年(2012)の9月くらいにリリースされています。
bowerは単なるパッケージ管理ツールなので、今回のTODOではモジュール管理にRequireJSを利用しています。
componentとbower両方でアプリを組んでみた実感としては、
両者はあまり比較対象としてふさわしくないなと思っています。
たしかにbowerは若干componentを参考にしているふしが見られるが
そもそも両者のスコープが違いすぎるし、componentの厳格な哲学に対して
bowerは節操がなさすぎ、
ネット上に転がってるbower.jsonもない単なるJSファイルをbowerのパッケージとして設定できる(https://github.com/p-baleine/todo-extension/blob/master/bower.json#L14)のはいかがなもんかと思った。
bowerとcomponentの比較は以下の記事が詳しいです
http://dailyjs.com/2013/01/28/components/
あと、この前のbower0.9へのアップデートでbowerパッケージの設定ファイルが
`component.json`から`bower.json`にリネームされましたが
これはTJがbowerに投げたこのissueが発端です
https://github.com/twitter/bower/issues/39
componentsというgithub上のグループがあります、
これはbowerのメンツがメインでcomponentとは関係ないようです(ややこしい)
componentsの目標はcomponent、bower、volo等々の
種々のパッケージ管理ツールに対応したComponentを提供すること、
実際にcomponents/jqueryとかみるとcomponent.json、bower.json
composer.jsonのファイルがおいて有ります。
まあ流行った方が残るんだろうが、個人的にはbowerはちょっと依存関係を解決してくれるダウンロードツールくらい、componentはRails並の強い哲学に基づいたフレームワークってイメージです。
Backobone 1.0.x
こっからは本当に雑記です。
今回初めてBackbone 1.0.xを使ってみました。
`Collection#fetch`の`reset: true`オプションが本当にオプションになったこと
以外はあまり意識しなかったかな、`View#listenTo`がどう作用するのか気になります。
Grunt 0.4.x
これも今回からです。
0.3.xではgruntでこける度に、さてgruntのソースから探るか
それともgruntが内部で利用しているパッケージのソースを探るかって悩んだが、
0.4.x以降そもそも全て外部プラグインになっているので整然としてやりやすくなった気がします。
CoffeeScript
1年ぶりくらいにさわりました。
component含めExpressとかTJのプロダクトを利用しているとCoffeeScriptを
使う機会が減りますが(TJはcoffee嫌い https://github.com/visionmedia/jade/issues/430)
今回はそこから解放されてCoffeeScript使ってみました笑。
gruntでSourceMap enableでwatchしておくと
そもそもそれがJavaScriptにコンパイルされている事実を意識せずにコーディングできるようになっていて結構感動でした。
Backbone.jsとの相性の良さも魅力、
;(function() {
// ...
var ListView = Backbone.View.extend({
// ...
});
}());
って書く代わりに
class ListView extends Backbone.View
# ...
って書けるのは気持ち良いです。
`=>`のおかげで拙作`expect-change`もやっとRSpecっぽくなりました。
it "should remove `editable` class from el", ->
expect(=> @view.$(".edit").trigger @event)
.to.change(=> @view.$el.hasClass("editable")).from(on).to(off)
karma
いつの間にかtesacularからkarmaに名前変わっていたんですね。
以前はなぜかEmacsの吐くlockファイルが邪魔してテストの自動実行が出来なかったんですが、今回は特に問題もなく、
エディタでソース編集して保存→
CoffeeScriptからJavaScriptへのコンパイル→
karmaでテスト実行→
テスト結果をGrowlで通知
まで自動化の理想的なフローを実現できました。
そもそもBDDではこれって理想というより必須だと思っています。
ただkarma + Require.jsはちょっと苦労しました。
同じ理由で躓く人がいたらこのリポジトリが参考になったらいいな
https://github.com/p-baleine/todo-extension/blob/master/app/coffee/spec-main.coffee
設定ファイル
これ、ルートディレクトリの直下のtreeです
$ tree -L 1
├── .bowerrc # bowerの設定ファイル
├── .git
├── .gitignore
├── .travis.yml # Travis CIの設定ファイル
├── Gruntfile.coffee # gruntの設定ファイル
├── README.md
├── app
├── bower.json # bowerパッケージの定義ファイル
├── icon.png
├── karma.conf.js # karmaの設定ファイル
├── manifest.json # Chrome Extensionのmanifest
├── package.json # nodeのパッケージの定義ファイル
├── screenshot.png
├── style.css
└── todo.html
まあjQueryのリポジトリとかみても似たようなものですが、
設定ファイル多すぎです。サーバサイドに比べて自分で選んだ
フレームワークやツールの集まりでリポジトリが構成されていくので
こうなっちゃうんだと思うんですが、
フロントエンドの人たちって職人臭強いなあと思います。