Image may be NSFW.
Clik here to view.
最もJavaScriptに近いJavaScriptコンパイル言語
先日MicrosoftからTypeScriptというJavaScriptコンパイル言語が公開されました。ファーストインプレッションとしては今までのJavaScriptコンパイラと比べると若干敷居が低く感じます。まず驚いたのはドキュメントがWordファイルだったこと。早速ダウンロードしてみたら一部文字化けしていました。さすが。PDFも用意されていたのでかろうじてドキュメントを読めました。Webページで用意して欲しい。
JavaScriptの記法そのままに型付けができる
TypeScriptでまず好印象なのがJavaScriptのコードをそのまま書いてもコンパイルされるところ。又、「Type」ScriptというだけあってさらにJavaScriptの記法に型を付けられる。例えばstringと指定すればstringのプロパティをシンタックスサポートまでしてくれる。ActionScript2からActionScript3になったときの感覚を思い出す。
Image may be NSFW.
Clik here to view.
他のJavaScriptコンパイラとどこが違うのか
CoffeeScript、JSX、Dart、HAXE、GWT…いろいろあり全てを使ったわけではありませんが、Module定義のわかりやすさは結構好きです。イメージとしてはJavaScriptの感覚から逸脱しないようにオブジェクト指向言語に拡張したという感じ。ただ記法が近いだけにJavaScriptを学習中の人は頭がこんがらがるかもしれない。
学習コストの問題
CoffeeScriptでよく挙げられている批評に学習コストの問題がある。JS開発者としてはJavaScriptのビルトインを把握するだけでなく、jQueryやjQmの記法、BackboneやSpineベースの開発も覚えておく必要になってきている、さらにCoffeeScriptの記述を覚えるなんて厳しいという話。それはたしかに一理あるし、例えば炎上中のDartベースのプロジェクトに放りこまれてもたしかに厳しいと思う。
むしろJavaScriptの学習教材にすればいい
プログラミングに必要な一定のキーワードさえ押さえておけば、ベストプラクティスを学ぶための学習教材にもなる。 無理にJavaScriptコンパイル言語で運用するルールを設けるのではなく、吐き出されるコードをガイドラインにしてしまうのも一つの手かもしれない。そういう意味ではTypeScriptはClass, Extends, Module, Public, Private, Staticなど押さえておきたいキーワードでわかりやすく使えるようになっている。
例えばTypeScriptのModule生成のコードは下記の通り
module Utils
{
var toString = Object.prototype.toString;
export function isFunction(obj) {
return toString.call(obj) == "[object Function]";
}
export function isNumber(obj) {
return toString.call(obj) == "[object Function]";
}
}
と書けば下記のようなコードを吐き出してくれる
var Utils;
(function (Utils) {
var toString = Object.prototype.toString;
function isFunction(obj) {
return toString.call(obj) == "[object Function]";
}
Utils.isFunction = isFunction;
function isNumber(obj) {
return toString.call(obj) == "[object Function]";
}
Utils.isNumber = isNumber;
})(Utils || (Utils = {}));
JavaScriptを１から勉強してこの記述方法にたどり着くまでには時間がかかる。
なぜ次々とJavaScriptコンパイラが生まれるのか
Image may be NSFW.
Clik here to view.oosugi20-blog — CoffeeScriptを社内ルールとすることについては反対だっていう俺の考えImage may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.CoffeeScriptの件 – きしだのはてなImage may be NSFW.
Clik here to view.
CoffeeScriptの賛否両論を見ているとJSのチーム開発における不用意なバグやルールが保てないといった所が主な原因なのだろうと思われる。
JavaScriptはご存知のとおりのフリーダム言語だ。インデントがあってもなくてもfunction(){}でくくれば関数になるし、varを付けても付けなくても登場したら勝手に変数として認識されるし、スコープはコロコロ変わる。prototypeとか言われても最初は何のことやら抵抗があるだろうし、==で比較をすると勝手に型を変えて訳の分からない比較をして気づきにくいバグを生みやすい。
又、他言語の開発者がJSを書くケースも増えていると思う。プロジェクトのコーディングルールを規定しても時間のないプロジェクトではいちいち気にしてられない人も出てくるだろうし、普段の癖が出ると思う。こういう癖を吸収して、一定のフォーマットに則ったコード品質を保つための施策の一つなのだと感じる。
どのJavaScriptコンパイラを選ぶか
例えばJSXはモバゲーのDeNAが開発している言語ですが、開発者の方のブログで下記のように語られていた。
JSXは、このような「人間が行うのは現実的には不可能な最適化」を自動的に行うことで、「JavaScriptよりも速い」プログラミング言語になっているのだ
JSX はなぜ「速い」のか – kazuhoのメモ置き場Image may be NSFW.
Clik here to view.
さすがモバゲープラットフォーム用に開発された言語。衝突判定のコードの最適化など、経験がモノをいいそうな記述がJSXを用いることで「人間が行うのは現実的には不可能な最適化」を自動的に行えるというのは言語設計の目的としてとても明確。これからゲーム開発をする人には最適な学習教材にもなり得るし、JSXを活用してそのまま開発をするという選択肢も出てくるかも。
HAXEなどはActionScriptから派生した言語でFlashDeveloper、JavaDeveloper、JSDeveloperには馴染みやすいでしょう。話はJSから若干それますがTitaniumやUnityなど他言語にコンパイルするプラットフォームは様々な分野で生まれており、ライトなものであればそのままリリースできるレベルの物が作れたりする時代です。モック制作やプロトタイピングなど素早いアウトプットを求められる状況においては1からコードを書くより早い成果が出せる場合もある。
どれも一長一短だし、長所はどれをとってもすばらしい。特性を把握して、目的を絞って活用していきたいところ。どっかでコンパイラを掘り下げた記事を書きたいと思う。
Image may be NSFW.
Clik here to view.
Clik here to view.
