CoffeeScript と TypeScript をそれぞれ実務案件で使ってみた感想

山田直樹

2014.05.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

そんな訳で、CoffeeScript を触り始めて半年弱、TypeScript を触り始めて1ヶ月弱ほど経ちました。まだまだ日は浅いですが、いちおう両方とも実務案件にて使用したということで、ここらで双方に対する振り返りを簡単にしておくとします。

CoffeeScript について

http://coffeescript.org/

学習開始時期:: 2014年1月頃
始めたきっかけ:: Middleman や Ruby on Rails が標準サポートしているため、面倒な環境構築等をしなくて済んだから; Ruby や Haml のようなテキスト量の少ない文法が好みだったから

そんな訳でとっかかりとしての基礎学習期間はだいたい2〜３日くらいで、そこから既存のプロダクションコードを CoffeeScript に書き換えつつ実案件に取り入れていきました。

おおまかな特徴

要は JavaScript をより少ないタイプ数・文字数でコーディングしたい というモノ
JavaScript のシンタックスシュガーという位置づけ
- 他の Alt JS とはそもそものコンセプトから違う
- && は and と記述できる
- || は or と記述できる
- foo === bar は foo is bar と記述できる
- this. は @ と記述できる
Ruby や Python にインスパイアされたような文法
- var とか function とか書くの面倒臭い
- (), {} とか面倒臭い。というか括弧で閉じるというのが面倒臭い
- ハッシュは改行とインデントだけで表現したい。カンマも要らん！
- 行末のセミコロンも要らん！！
class 宣言することでクラスが書ける
extends と書くことでクラスの継承が出来る
Ruby on Rails が v3.1 から標準サポートしたので、Rubyist にとっては馴染みやすい
テキストエディタ使い（not IDE）にはうってつけ ^*1
コンパイルされた JavaScript と CoffeeScript のコードは一対になる
- 素直な JavaScript コードで読みやすい
- SourceMap といった機能が無くても JavaScript コードから CoffeeScript 上の場所は容易に推測できる
コンパイルされた JavaScript は、1ファイルあたりのコード全体をコールバック関数（即時関数）でラップされる仕様
- グローバル汚染の予防にはなる
- ファイル単位でクラスを作るうえでは余計なお世話　そのままだと外から呼べないじゃないか！！！！
メソッド内の最終行が無条件（暗黙的）に return されるという仕様
- この辺りは Ruby がルーツなのかな
- なのでコンパイルされた JavaScript を読むと、「このreturn にはどんな意味が…？」と困惑してしまう人が出てくるかも
コンパイル速度は速い
- 利用したのが小規模なプログラムというのもあるかもしれないけど、コンパイルにかかる時間を意識したことは一度もない

TypeScript について

http://www.typescriptlang.org/

学習開始時期:: 2014年4月頃
始めたきっかけ:: 何かひとつくらいは静的型付け言語を習得しといた方が芸の肥やしになるかなぁという、ふわっとした動機; クラスメソッド（弊社）には Java 使いが多いので、TypeScript であれば言語が違っても文法や言語仕様が似ていることから、オブジェクト指向に関する質問や相談をする相手が身近にいくらでもいる; JavaScript をガチで書くエンジニアが社内で不足しているので、JavaSceript アレルギーの Java 使いを引きずり込みたい ^*2

そんな訳で、こちらの基礎学習期間はだいたい5日くらいでした（環境構築に関する調査機関は除く）。やはり既存案件のプロダクションコードを TypeScript に書き換えるところから導入しました。

おおまかな特徴

JavaScript に静的型付け機能を追加したもの
- いわゆる Better JavaScript （JavaScript のスーパーセットとも言う）という位置づけ
Java や C# にインスパイアされたような文法 ^*3
ECMAScript6 の仕様を積極的に取り込んでいる
- 将来的に JavaScript に実装されるであろう機能が先行して利用できるという見方ができる
class 宣言することでクラスが書ける
extends と書くことでクラスの継承が出来る
interface も使えるのでクラスの多重継承も出来る
module を使うことで名前空間の定義が出来る
型や名前空間に関する記述が増える分タイプ数は多めなので、テキストエディタよりも IDE 推奨
- ドザーなら VisualStudio、マカーなら WebStorm / IntelliJ IDEA がデファクトスタンダード
- テキストエディタだと結構しんどい
コンパイルされた JavaScript と TypeScript のコードは一対になる
- 素直な JavaScript コードで読みやすい
- SourceMap といった機能が無くても JavaScript コードから TypeScript 上の場所は容易に推測できる
素の JavaScrpt で書かれた既存ライブラリを使うには定義ファイルを別途用意して予め読み込む必要あり
- 有名ドコロの多くは https://github.com/borisyankov/DefinitelyTyped で管理されてる
- 無ければ自作しよう
Closure を利用したプライベートメソッドってどうやって作るの？
- アクセス修飾子はあれど、コンパイル後の JavaScript コードは普通にパブリックなメソッドになってしまうよね？
コンパイル速度は遅め
- 小規模なプログラムであればそれほどストレスを感じるほどではないが、CoffeeScript より遅いのは明らか
- ファイル数が増えたり規模が大きくなってくると結構しんどくなるかも

それぞれを使ってみて

CoffeeScript

開発期間が短く、小規模で余りスケールしなさそうなプロジェクトにはうってつけです。反面、クラス等が増えてきて継承が多くなってきてしまったりすると厳しいかもしれません。コード量が多くなってくるにつれて IDE の補完機能も欲しくなってくるでしょう。型を持たないということはブラウザで実際に動かしてみるまでエラーがあるかどうか分かりません。ずっと JavaScript だけを書いている人にとってはそれが当たり前なのですが、実はこれがかなりの重労働であり、IDEやコンパイラ等で吸収してもらいたい箇所と言えます。

開発の規模さえ問題にならないのであれば、動的型付け（LL言語）に慣れた人にはこれくらいのユルさがちょうど良いのではないでしょうか。何でもかんでも型を明確に意識するのは時にはしんどいものです ^*4。もちろん変数や関数のネーミング等、ある程度は意識しますが……。また、型が無いということは定義ファイルがなくとも既存の JavaScript ライブラリがそのまま使えることになるので、マイナーなライブラリや自作のライブラリとの共存もそのまま出来ます。

TypeScript

開発期間がそれなりに長くて、中長期的にスケールしそうなプロジェクトならこっちです。クラスの数が増えようが、継承、インターフェース、モジュールなどがあるため、大規模になっても大概のモノは管理しきれるでしょう。優秀なIDE があれば巨大に膨れ上がったコードのリファクタリングに対する抵抗も少なくなると思います。

ほかにも静的片付けによる恩恵に、コンパイル時に不正なコードの大部分を見つけることが出来るというのがあります。個人的な体感ですが、ブラウザ上での動作確認よりもエラーを見つけやすくなったうえ、ブラウザ上でエラーを見る機会が明らかに減りました。

で、どっち使えばいいですか？

両方とも充分によくに出来た言語なので、ケースに応じて柔軟に選択するべき
これから学ぶという貴方は、自分のエンジニアとしてのバックグラウンドに応じて選択すれば OK
習得までの学習コストはそれぞれのインスパイア元となってる言語の習得具合によるものが大きいが、どちらもそれほど大変ではないはず
- 公式サイトの整備が行き届いている
- Playground でちょっとした動作確認ができるのは大きい
- ブログ等の情報が豊富
ただし、JavaScript 自体が問題なく書けることが大前提なのは言うまでもない！
- JavaScript で何が出来て何が出来ないのかを把握していないと、そもそもプロダクトコードを書くことは出来ないだろ
- JavaScript の基礎はおさえた上で、CoffeeScript や TypeScript を通じて更なるレベルアップを図るというのは非常に良いと思われ