「Backbone.jsガイドブック」執筆しました

（告知が若干遅れてしまいましたが）色々な縁があって、この度「Backbone.jsガイドブック」という本を執筆しました。
2011年のBackbone.js Advent Calendarで僕が書いた「Backbone.js入門シリーズ」を、原文の跡形が微塵の欠片も無いくらい、改定したものです。

もくじは「Backbone.jsガイドブック」サポートページで見ることができます。
あと、チュートリアルで作るアプリケーションはここで動いています。PCサイト向けと、jQueryMobileを使ったモバイルアプリがあります。デザインが糞なのは勘弁してください。。

Backbone.jsガイドブック

本書の位置づけ的な

Backboneはコメントを含めてたったの1500行しかない非常にコンパクトなライブラリです。必要最低限な機能しか持たない一方、個々の機能が柔軟でいろいろな使い方ができます。が、それ故に気をつけないと直ぐにコードがスパゲッティ化して、Backboneを導入した意味が無くなってしまいます。

本書は僕がBackboneを使って数多のスパゲッティ生成を行った果てに（＋Web上で共有されているノウハウその他を吸収して）たどり着いたベスト・プラクティスをできるだけ集めようとしたものです。もちろん基礎的な話題（どうやってViewを書くかみたいな）も取り上げているのですが、そういうのはドキュメント読めば分かるわけで、個人的にはドキュメントに現れない知見にできるだけ光を当てたつもりです。

あとRequireJS、Jasmine、Gruntなどのライブラリを、Backboneアプリケーションを作るのに使う、という文脈から取り上げています。最後のチュートリアルではこいつら全部使ってアプリケーションを作ってます。（サンプルコードはここ）超実践的ですね！

どこかの誰かの役に立てばいいなーと願っています。

執筆裏話的な

この本はBackbone1.0に対応しています。1.0が出たのが3月下旬で、本の発売が4月末。分かると思いますが、間違っても1.0が出てから執筆を開始したのではなく、0.9.9の頃からGitHubのPRを睨みつつ「このPRは取り込まれそうだからちょっと書いとくか」「これは取り込まれないだろうな」とか予想しつつ執筆していたわけです。

で、当初は0.9.9の次が1.0だったはずが、気がついたら0.9.10になり、一時はコミュニティが1.0にすべきでない（メジャーバージョンにできるほど安定してないだろという意見が噴出した）とか言い出して、1.0対応を目指して本書いてた僕はかなりがっくり来ていたんですが、Backbone生みの親のjashkenas氏が降臨して、有無を言わさず1.0をリリースしたのでした。

それにしてもjashkenas凄いです。Backboneにはパッと見で一貫性が取れていないような箇所がいくつもあって、それを修正するPRがそれなりの頻度で投げられるのですが、実はもっと深いところではその不一貫性が重要な意味を持っていたりして、そういうBackboneの思想を与えているのがjashkenasなんですよね。

kyoto.js #3 で "Detecting Memory Leak" という発表をしました

kyoto.js #2 で "Write Once Loadable Anywhere" というLTをしました

LESSとSassの比較した結果LESSを採用することにした

CSSを拡張するメタ言語としてLESSとSassが有名。どっちかを使おうと思ったので、LESSとSassを比較してみた。その結果LESSを採用することにした。
採用に至った理由は以下のよう

• LESSの方が学習コストが低そう
  • LESSの方が読む必要があるドキュメントが少ない
  • LESSの方がCSSに書き方が近い
    • 今後非プログラマなデザイナの人が参加するようになるとしたらCSSに近い方がよさげ
• LESSはサーバサイドでコンパイルしておく必要がない
  • lessファイルとless.jsをブラウザに読むこむと勝手にいい具合にしてくれる
    • Rails3を使ってるならSassを書くと勝手にCSSにRailsが変換してくれるけど、要するにそれ
    • 開発時はlessファイルだけいじって、デプロイ時にコンパイルするだけでいいのは楽そう
  • もしかしたらSassもそういうブラウザでコンパイルする機能あるかも知れない
• 内部にJSを埋め込める
  • 使うかはよく分からない
  • けど、ブラウザの画面の大きさとかの情報をスタイルシートに埋め込めるのは見通しがよくなりそう
• BootstrapがLESS使ってる
  • Bootstrapは使うことにした
  • Bootstrapを使うとどこかで見たような感じになりがち
    • LESSならBootstrapが用意してる変数とかを弄るだけで簡単にカスタマイズできる

Backbone.LazyViewというのを作った

taka84u9/backbone-lazyview · GitHub
Backbone.Viewのel要素がブラウザ上で表示されたタイミングでappearイベントをtriggerする、Backbone.LazyViewというのを作りました。
使い方はBackbone.Viewと全く同じ。

var FooLazyView = Backbone.LazyView.extend({
    events: {
        "appear": "appear"
    },
    appear: function () {
        /* do something */
    }
});
var foo = new FooLazyView({el: $("#element")});

これで$("#element")がブラウザに表示された瞬間にfoo.trigger("appear")が実行されます。主にrenderや、サーバとの通信などを遅延させるために使います。

JavaScriptにおけるvoid演算子とはいったい何のために存在するのか

JavaScriptにはvoid演算子なるものがあり、その動作は何をしてもundefinedを返すというもの。

void 0 // # => undefined

ECMAScript 5の11.4.2 The void Operatorによれば、void演算子は次のように評価される。

1. void exprとする
2. exprを評価する
3. undefinedを返す

exprをわざわざ一回評価している分だけ、単純にundefinedを返すよりも遅くなる。exprを評価し、かつundefinedを渡したい場面があったとしても、2文に分けて記述すればいいだけのように感じる。一体何が嬉しいのか。
考えられる嬉しさは2つある。
1つ目がJavaScriptのコードを圧縮する際にundefinedの代わりにvoid 0と書くことで3Byte節約することができる。それに上記のように、2文に分けて記述する場合と比較すると、少なくともセミコロン1つ、void+スペースとundefinedの差を合わせて5Byteほど圧縮になる。Googleレベルならいざしらず、一般のWebサイトを構築する際に使うことは絶対にないテクニックだろう。
もう1つは、実行はしたいが、値を返したくない場合だ。例えばaタグのonclickイベントを抑制するのに、return falseをするが、何かしらの関数を実行したいだけなら、次のように書くことができる。

<a onclick="hoge(); return undefined;">hoge</a>
<a onclick="return void hoge();">hoge</a>

どちらにせよ、滅多に使うことがなさそうな演算子だ。
追記
コメントによると、undefined を上書きされてても void 0 はプリミティブ値の undefined を返すらしい。
undefined が上書き可能なのは知っていたけど、こんな回避方法があるとは知らなかった。
情報ありがとうございます！ > id:kitokitoki さん

変数のデフォルト設定をちょっとだけ早くする小ネタ

Backbone.jsのコードを眺めていたら、こんなのがあった。(関数名は適当)

function foo(options) {
  options || (options = {});
  // ...
}

ここでやってるのは、optionsが偽だったらObjectで初期化する、という操作だが、次のような書き方の方が一般的だし理解するのも簡単な気がする。

function foo(options) {
  options = options || {};
  // ...
}

なんでわざわざこんな書き方をしているのか（文字数だって増えている！）考えてみたら、後者では必ずoptionsへの代入が行われるのに対し、Backbone.jsの方式ではoptionsが真の場合代入が行われない。その分高速なのだろう。
普段使いのコードでは、こんな最適化は行わなくてもいい気がするけど、覚えておいて損はなさそう。