CoffeeScriptは是か否かという話は、CoffeeScriptを調べていれば否応なしに引っかかる話題で、自分もそれについてはかなり考えさせられた。何回かこのブログでも書いたとおり、CoffeeScriptいいなーと思ってはいて、ここ１，２ヶ月はずっとCoffeeScriptでJavaScriptを書いているんだけども、いい点はもちろんあるにせよ、書いているうちに、最初は見えてなかった問題も見えてきたりした感じがするので、その点について少し書きます。

• なぜ CoffeeScript がよいか - 0xff.toBlog()
• なぜ CoffeeScript がダメか - 冬通りに消え行く制服ガールは✖夢物語にリアルを求めない。 - subtech

• CoffeeScriptいいかも - Takazudo hamalog
• CoffeeScriptをおすすめしたいワケ - Takazudo hamalog

あんたの仕事は何なの

まず、自分は受託制作がメインの会社（PixelGrid）に務めていて、一応、JavaScriptやる会社ですと謳っているのもあって、JavaScriptでUIを組む仕事が結構多い。自分は、マークアップ出身なJavaScriptプログラマーみたいな感じになってる。最近よくあるのが、いままでFlashで作っていたものをJSでーとかだったり、WebアプリをAjaxベースでーとか、そういうのとかをメインにやったりしてる。

そのような状況で、複雑なUIを組むためには、設計方法に悩む。jQueryは素晴らしいけども、入り組んだUIを設計するための手段は提供してくれない。そんな状況で、自分はjQuery UIのベースになっているwidgetというフレームワークを使ってイベントのやりくりをしていたけれども、これはあくまでjQueryプラグインをOOPで書けるようにしたようにしたもので、そこまで豊富な機能があるわけじゃない。

サーバーとの連携を多く行うような場合、最近だと、Backbone.jsを使うようにしたりしているんだけども、それでもちいさなクラス的な働きをするものはconstructorとprototypeをポチポチ自分で書いたりしていた。別にそれが悪いという気はさっぱりしないけれども、とにかく、その「ちいさなクラス的な働きをするもの」が必要だと感じていた。

あと、似たような機能を書くことが多い。自分と同じようなことをしている人は分かるかもしれないけれども、ページ上には沢山のパーツがあり、それを管理するクラスを作り、それらをイベントで連携させる - ということを無数にやるため、そこまで複雑ではないが、無くてはならない - しかし、サイトによってちがうしCSSにも依存する - みたいなものを沢山作る必要がある。

CoffeeScirptが解決したモノ

そんな状況で、CoffeeScriptを使い出したんだけれども、CoffeeScriptは、この欠けていた部分を補完してくれたものと感じている。The Little Book on CoffeeScriptには、こう書いてある。

Classes in JavaScript seem to have the kind of effect that cloves of garlic have to Dracula for some purists; although, let’s be honest, if you’re that way inclined, you’re unlikely to be reading a book on CoffeeScript. However, it turns out that classes are just as damn useful in JavaScript as they are in other languages and CoffeeScript provides a great abstraction.

JavaScriptにおいてクラスは、JavaScript原理主義の人にとっては、ドラキュラにニンニクを与えたように嫌がるものだが、CoffeeScriptはこれを役立つものと考え、抽象化した機能として提供する - みたいな感じ。

Webアプリのように複雑にUIが組み合わさって作られる様な状況では、自分はこの意見に同意する。そして、コレを実現しようとした時、そんなわざわざ新しい言語でラップする必要はないよ、この小さいライブラリを使いなよ - と言われるかもしれないけれども、それでも、その「小さいライブラリ」とやらを使うことで、一枚フレームワークの上に立ってコードを書くということになる。CoffeeScriptを使えば、それが既に存在する状態で始められるので、コードを書くのが非常に楽。

これは特に、Backbone.jsと組み合わせて使った時に、大きな効果を発揮したと思う。Backbone.jsのコンポーネントはクラス的に作られているので、CoffeeScriptと合わせて書くと、本当にサクサク書けた。やってみると実感できるけれども、この相性の良さはかなりすごい。

だとしても、そこでCoffeeScriptをあえて使うのは必須ではないでしょうときっと言われるだろう。それは確かにYESだけれども、僕が言いたいのは、この、CoffeeScript + Backbone.jsの組み合わせでコードを書くことで、実際に実務をこなすためにかかった時間を、かなり短縮できたというのが、一つ、事実としてあったということ。CoffeeScriptを大プッシュする人がいたら、きっと同じようなことを経験したのではないかと思う。

とあるプロジェクトで自分が書いたJavaScriptは、1万行を超えてた。これは別に、同じコードをひたすらコピペしていってそうなったわけじゃない。Backbone.jsのModelだのViewだのjQueryプラグインだのを延々必要なだけ書いて行ったらそうなった。今となっては、まぁその時はもっとCoffeeScriptは下火だったけれども、これをCoffeeScriptで書いていたら、自分の潰れた土日はもっと少なかっただろうと思う。今数えたら、 var self = this; を、おおよそ200回書いていた。

CoffeeScirptはたぶんこんな感じ

CoffeeScriptは、JavaScriptの煩わしい括弧だのfunctionだのを省略できますよーという点が大きなメリットの一つだけれども、それも含め、クラスだったり、argumentsの展開だったり、単純なループだったり、printfみたいな機能などなど、JavaScriptに欠けてパーツをいくつか補ったような存在だと思う。なので、それがピッタリフィットするような状況では、CoffeeScriptは最高だねと思えるだろうし、そんなものは僕の書くコードには元々いらないものだよと思うのであれば、わざわざ言語をラップした言語を作るなんて無駄にもほどがある！と感じるんじゃないんだろーか。

で、自分は、こういう、CoffeeScriptが補ったものは、緻密なライブラリを作ったりするのであれば、細かい調整もいるし、そんなのはいらんと感じるかもしれないけども、そういったライブラリを色々と使い、実プロダクトに近いコードを書くのであればあるほど、あーこれが欲しかったんですよーと感じるものじゃないかなーと思う。

なので、そういうのを普段から書いてる人であれば、使ってみるといーんでないのかとは思う。もし、将来的に使わなくなったとしても、学んで見る価値はあるものかなーと。

自分のCoffeeScriptに対する認識は、「フレームワークが一枚かまされたJavaScript」という感じだ。そういう意味で、あらゆるJavaScriptはCoffeeScriptで書かれるべきだとかは別に思わない。

CoffeeScriptメンドクセーと思うこと

そんなこんなで、CoffeeScriptは使うといいよと思ってる自分だけれども、これはでかい問題だと思うことがあった。CoffeeScript書きだしてから、延々とコードを書いていて、クライアントワークで使ったコードを書きなおしてライブラリ化するのが結構楽しくなってきていて、趣味になってた。以下にその、CoffeeScriptで書いたライブラリがある。

• Takazudo/jQuery.ImgLoader
• Takazudo/jQuery.ui.domwindow
• Takazudo/jQuery.TmplDeck
• Takazudo/jQuery.PresetPreloader
• Takazudo/jQuery.LazyJaxDavis

で、このライブラリを作って、それを別の仕事で使おうとコピってくるんだけれども、そうしていると、当然、バグだったり、機能追加したいことが出てくる。そんな時、つくったライブラリをいじるのが非常にめんどくさい。

なぜなら、読み込んでいるのは、コンパイルされたJavaScriptだ。CoffeeScriptをコンパイルした結果は、かなり読める感じだけれども、それを直接いじったら、オリジナルのCoffeeScriptにも反映しなければならない。もし、そうしないのであれば、バグをオリジナルのスクリプトのレポジトリで直し、またコピってくるか、ライブラリのCoffeeScriptのソースも一緒に、そのプロジェクトのソースとして扱って、一緒にビルドしたりとか、そういうことをしなければならない。まぁ、理想は、オリジナルのレポジトリで直し、コンパイルしたものを再度持ってくる - だろうけど、これは結構めんどい。gitのレポジトリをネストする形にして、ライブラリのレポジトリも、親プロジェクトに含めてしまえばいいんだろうか。ここのところのうまい方法が分からない。誰か知ってたら教えて欲しい。

で、これが他の人が書いたCoffeeScriptだったらどうだろう？自分は、CoffeeScriptのビルドを、gruntというnodeで書かれたビルドツールを使ってやってる。ただ、gruntとターミナルで打てば、設定されたとおりにコンパイルし、簡単なバナー用コメントを追加してくれるものではあるけれども、このライブラリをデバッグするためには、少なくともそのようなステップが必要。ライブラリのレポジトリごとにビルドを設定しているから。

これは、まだ自分が書いたコードだからいい。たぶん、ほかのCoffeeScriptで書かれたようなライブラリも、同じような仕組みを使ってビルドしたりしていると思う。10個のライブラリを使っていて、それぞれにバグがあったとしたら、それらをチョコっと直すのだけでも、相当しんどいんじゃないかと思うんじゃないだろうか？

これは、Ryan Florenceが、以下の記事の中でも言及している。

• A Case Against Using CoffeeScript ☃ Ryan Florence Online

初めにこの記事を見た時、「フーン、まぁこの人はみんなのコードを見る立場のひとだからねー」と思っていたのだけれども、自分でちょこちょこライブラリを作っているうちに、この問題がとても大きいということがわかってきた。

上の記事のコメント欄をざっと眺めてみるといい。たぶん、どこでも同じような議論がかわされていて、「オレにとってはなんの問題もない」とか「保守的に見れば採用は避けるべき」だとか言われており、この問題の結論はきっと出ないだろう。

Source Map とやらの機能で、この問題がかなり改善されそうな兆しが見えてきているものの、このコンパイル問題は、現時点で、CoffeeScriptが抱えている、かなりでかい問題だと感じてる。

ほか、些細な利点

カンマ忘れてIEでエラーとかでない利点。これは、JSlintかけろよとか言われるだろうが、実際、自分はvimでボタンをポンと押せばJSlintをかけられるようにはしているものの、それでも忘れることはある。これを、全く無くせると言うのは、思ったよりもでかいと感じる。

コードが短くなる利点。これは、特に自分のように、プロダクト用のUIみたいな、同じようなコードを沢山書く人間にとっては、思ったよりも効果がでかいと思った。特に、jQueryのdeferredなりイベントなりなんなりで、やたら括弧が入れ子になる状況を、さっぱり綺麗にできるのは、見やすくなるし、単純に書いていて楽しい。

などなど。これらは、些細ではあるものの、業務効率を大きくアップさせるものであるとは思う。自分は、var self = this; を200回書きたいとは思わない。

自分の中での結論

とりあえず、自分はこれからもCoffeeScriptで書いていくつもり。もしCoffeeScriptが使われなくなったとしても、そんなことはいちいち気にしていない。もし自分の関わっているのが、大きなオープンソースのプロジェクトであれば、確かに、それをCoffeeScriptにするのは、思い切った決断のように思う。だけれども、自分は、具体的なプロダクトのためのコードをガリガリ書くような立場の人間なので、そうではない。そのような状況において、CoffeeScriptの採用は、作業スピードとメンテナンス性をあげるものだと感じている。上記で挙げたような問題はあるにせよ。

もしあなたが、CoffeeScriptに興味があるものの、その将来性を不安視して手を付けないでいるのであれば、さっさと試してみろと言いたい。特に、自分と同じような立場の仕事をしていた場合。

この人とは長く続くだろうか？などと不安ばかり抱えて恋人を作る人などいないだろう。

以下の記事では著名人がインタビューに答えているので、読んでみると面白いと思う。

• Should You Learn CoffeeScript? | Nettuts+

この記事の中で、「ユニットテストにだけCoffeeScriptを使う人はいるだろうね」という意見がある。ユニットテストのために書いたコードが他の何かで使いまわされることは、ほとんど無いだろう。単にサクッと書けるゆえ、コードを書くのを楽にしてくれるはず。CoffeeScriptとはつまり、そういうものだ。たぶん。今のところは。

学習コストがあるという点については、それほどではないと思ってる。CoffeeScriptの恩恵を感じられる人は、そもそも、プログラムの基本的な設計の考え方が分かっている人であると思うから。