世の中には CoffeeScript を親の仇のようにdisる人達がいる。TypeScript とか他の altJS と比較してアレアレの機能が無いとかそういうのではなく、素の JavaScript と比較して、素の JavaScript を使った方がいいとか言う。そんな彼らの言説を適当に取り上げて、反論しようではないか。
CoffeeScript が駄目な理由
メリットが無い
素の JavaScript で書いても同じ事が出来るのだから、CoffeeScript で書くメリットなど無い。
プログラミング言語の選択基準が持てない人にこのような意見が多い。駄目なプログラマの多くは一つの言語しか知らず、その言語のみで済ませようとする傾向にある。彼らは他の言語を知らないし、知ろうともしない。つまり、彼らは選択基準を持つ前に、他の言語がどのようなものかすら知らないので、選択するという手段を持たないのだ。そして、自分が使っている言語が否定され、他の言語を勧めらたとき、「それなら○○でもできる!なので□□は不要だ!」と彼らは主張する。
プログラミング言語を選ぶ重要な基準の一つとして、安全なコードを書けるかというのがある1。CoffeeScript は JavaScript の危険な部分を無くそうと、下記のような工夫をしている。
- 全ての変数は
var
ありとなるため、勝手にグローバル変数もどきにはならない。 - バグの元になりやすい曖昧な
==
が使えない。 - swich文では末尾に
break
があると見なされる。 - インデントによるブロックを採用し、暗黙のセミコロン問題を発生させない。
- デフォルトの変換では
function(){...}()
で囲まれため、名前空間の汚染が無い。
そして、もう一つ重要なのは読みやすさだ。Python から採用したインデントによるブロックはかなり強力だ。これだけでも、採用する価値は十分にある。
class構文やリスト内包表記、文字列の式展開なども有用ではあるが、上のことに比べれば些細なメリットにすぎない。だが、それを認めない人は、その些細なメリットのみを否定し、重要なメリットについては目を向けようとしない。いや、正確には気づく事ができないのだ。
学習コストが高い
CoffeeScript は JavaScript の知識が前提で、その分学習コストが高い。
まず、言語の学習というのは大きく二つの側面があることに注意しなければならない。
- 言語仕様
- コーディング方法
なお、「ライブラリ」に関しては学習する物ではない。あれはリファレンスを(文字通り)参照する物であって、覚えようとすること自体が愚かな行為である。
さて、CoffeeScript を使いこなすにあたって、JavaScript の言語仕様について知識が必要かというと、確かに必要ではあるが、全部では無い。CoffeeScript を変換して生成される JavaScript を読める程度の知識があればいいのだ。つまり、次の JavaScript の仕様は別に知らなくてもいい。
-
==
のくだらないルール - 暗黙のセミコロン(;)の複雑なルール
-
"use strict";
有り無しで変わるカオスなルール -
var
がない変数宣言での破滅的なルール
JavaScript には直感的では無いルールが多すぎるが、その大半を詳しく知らなくても、CoffeeScript では問題ない。CoffeeScript はそのような黒歴史なコードを生成することは無いからだ。
次にコーディング方法だが、これもまた全てを覚える必要は無い。たとえば、次のような物だ。
- クラスベースオブジェクト指向のように使う方法
- クラスやコンストラクタ、メソッドの一般的な作成方法
- 親クラスに副作用が発生しないクラスの継承方法
- Array のforループの書き方
- this問題の解決方法
CoffeeScript はクラスベースオブジェクト指向で書けるようにclass構文が用意されている。プロトタイプベースオブジェクト指向を工夫してなんとかクラスのように使おうと苦労しなくても、多くの人により精錬された状態の工夫された JavaScript を生成してくれる。また、Array 用のforループが存在するし、this問題は =>
を使うだけで解決できる。
このように、JavaScript の学習コストの内、非常にコストが高い物は不要である。そして、CoffeeScript には上記のような高コストの部分がないため、トータルコストはむしろ JavaScript より低いと言える。
変換が必要
CoffeeScriptはそのままブラウザ上で実行できないため、変換ツールの導入や、毎回変換処理が必要になる。
前提からして間違っている。そもそも、現在の JavaScript において、何かしらの変換をしないことはあり得るのだろうか? 転送量削減や描画までの速度向上、効率的なブラウザキャッシュの利用を行うため、複数のライブラリをまとめることや、圧縮(minify)は必須とも言える。つまり、素の JavaScript であっても、変換が不要になるわけではなく、「変換が必要」ということ自体がデメリットになり得ない。
また、JavaScript の変換については、Grunt や gulp 等の自動化ツールが整備されており、それほど苦も無く環境は用意できるだろう。一通りの開発環境さえ揃ってしまえば、変換が必要なことは重要な問題とはならない。
エラーがあったときにデバッグができない
実行時にエラーがあっても、変換後のJavaScript上でしかエラー箇所がわからないため、元々の CoffeeScript のどこでエラーがあったかがわからない。
最新のブラウザではソースマップファイルを解釈できるようになっている。ソースマップファイルがあれば、エラーの箇所を変換前の場所で指摘してくれる。変換時に適切なソースマップファイルを生成すれば、デバッグ時にエラー箇所がわからないなどという問題は起きない。第一、圧縮(minify)された JavaScript でデバッグするにはソースマップファイルは必須と言える。
ソースマップファイルに対応していない古いブラウザは?というのであれば、そもそも、サポート期限が切れたそんなブラウザにいつまで対応するつもりなのか? とっと、ユーザに最新のブラウザを使うよう促した方が世の中のためである。
ECMAScript 2015 があるから不要
ECMAScript 2015 からはclass構文や
=>
等のこれまで JavaScript で不十分だった部分を補っている。これによって CoffeeScript にあったメリットは無くなるため、CoffeeScript を採用する価値が無い。
残念ながら、ECMScript 2015 は過去の互換性を保っているため、数々あった問題が全てなくなった訳では無い。より安全なコードになるという CoffeeScript のメリットは完全に残っており、ECMAScript 2015 が取って代わる事はできない。
また、ECMAScript 2015 をそのまま使える状態というわけではない。まず、完全対応した実装はなく、どの環境でも一部の機能は使用できない。特に、そこそこのユーザがいる Internet Explorer 11 は ECMAScript 2015 にほとんど対応しておらず、今後対応する可能性も極めて薄い2。ブラウザ向けのコードを ECMAScript 2015 でそのままにできる日が来るのはかなり先の未来となる。結局、Babel 等を用いて旧来の JavaScript へ変換が必要であり、CoffeeScript よりメリットがあるとは思えない。
現行において、ECMAScript 2015 をそのまま(ただし、全ての機能ではない)使えるのは node.js 等でサーバサイドに使用するか、Electron 等でデスクトップアプリとして作るときぐらいである。だが、それらの環境でのアプリ制作は CoffeeScript であっても環境が整っており、ECMAScript 2015 がそのまま使用できるというメリットはほとんどない。
JavaScript の方がプログラマが多い
CoffeeScript が書けるプログラマよりも JavaScript が書けるプログラマの方が圧倒的に多いので、開発人員を集めやすい。
プログラミングそのものをしっかり理解しており、JavaScript を学習済みのまともなプログラマであれば、CoffeeScript の学習はすぐに終わる。逆にそれすら出来ないようなプログラマを開発人員に加えること自体が間違っている。CoffeeScript が書ける、または、今書けなくてもすぐに書けるようになる、というのは優秀なプログラマを集めるための質のいいフィルターになる。
人気が落ち目
TIOBE Index では100位圏内にも入らず(2016年1月版)、The RedMonk Programming Language Rankings: June 2015 でも20位圏外の22位とランクが落ちてきている。PYPL PopularitY of Programming Language では調査対象にすらなっておらず、人気が無いと言わざるを得ない。
プログラミング言語ランキングでは、どのような手法を行っても altJS に対する正当な評価は難しい。altJS への言及は JavaScript についても言及することになってしまうからだ。第一、RedMonk の調査にあるとおり、GitHub で使用されている言語はメジャーな部類と言っても良い。Stack Overflow での評価が低いのは、CoffeeScript が優れているため、質問することが少ないという側面もあると考えられる。
むしろ注目すべきは Google Trend から調査した人気上昇中のJavaScriptライブラリを調べてみた【2016年版】と開発者へアンケートを取った2015年、人気の「JavaScriptライブラリ&ツール」はどれ? Angular vs. Reactの行方である。TypeScript については後ほど述べるが、TypeScript を除けば、CoffeeScript はまだまだ健在と言える。
どう考えても TypeScript の方がいいだろう
動的型付けは大規模開発では問題が多い。静的型付けの TypeScript の方がいいに決まっている。
動的型付けと静的型付けのそれぞれにメリットとデメリットがあることを理解しているのであれば、片方がもう片方より優れているとか、代替になるという考えには至らないはずだ。
大規模開発3では TypeScript が有利ではあるが、かといってどんな開発でも使えるほど万能というわけではない。TypeScript が使いにくい場合に CoffeeScript を選択することは間違ってはいない。
俺たちの戦いはこれからだ!!
CoffeeScript が駄目でない事を理解していただけたと思う。いつまでも素の JavaScript しか使えない JSer はそのうちいらなくなることは必至だろう。今すぐ、素の JavaScript を捨てて、TypeScript を使うことをお勧めする。そして、関数型プログラミングが大好きなあなたは、純粋がいいなら PureScript を、非純粋がいいなら LiveScript をするといいだろう。
え、CoffeeScript をしなくていいのかって? 何言ってんの、あんなのオワコンでしょ。緩いコードを書きたいなら Opal を使うっちゅうの。
ご愛読ありがとうございました。
raccy先生の次回作にご期待ください。
-
安全なコードを書けない言語を全て否定するわけでは無い。たとえば、C/C++ は危険なメモリ操作出来てしまうため安全とは言えない。しかし、それを補って余りあるほどのパフォーマンスというメリットがある。しかし、素の JavaScript にはそのようなメリットは存在しない。また、C/C++ についても、より安全な Go や、多少パフォーマンスが落ちても Java/Scala/C# 等が使われるなど、その存在価値が低下しつつある。 ↩
-
Microsoft は Microsoft Edge の開発にシフトしており、Internet Expoler への新機能追加はほぼ絶望的である。 ↩
-
Angular や React の登場により、JavaScript (実際はにコーディングするときは altJS になる) を用いた大規模開発が増えてきていることは注目に値すべき事であるが、それは別の話だ。 ↩