思ったことを。
デバッガについては、こういう記事がある。
圧縮後のJavaScriptやコンパイル後のCoffeeScriptでも、ブラウザ上で元のソースを参照できる新技術「Source Maps」登場 － Publickey
「Source Maps」じゃなくても、なんらかブラウザ側でのサポートは行われていくと思う。
どっちにしろ、JavaScriptをデバッグするにもブラウザのサポートは必要なわけで。
ライブラリの依存関係とかも、ビルドツールとJSライブラリリポジトリが整備されていくんじゃないかなー。そのくらいの勢いはでてきてる気がする。
あと、CoffeeScriptとJavaScriptを両方知らないといけないという話も、複数人で開発するなら、全員が両方しる必要はなくて、コアなメンバが知っておけばいい。
そもそも、複数人で開発するときに、全員がJavaScriptのprototypeなどを使えるというのも、結構無理がある話で。それなら、構文として整理されていたほうがいい。不用意なコードでクラスの構造を壊してしまうということも少なくなるし。
イデオムとしてのクラスというのは、学習もやりにくい。人のコードを参考にしにくいからね。構文であれば、「こういう構文使えばいいのね」ってのがイデオムに比べてわかりやすい。
UIでクラスを利用することが多い場合に、JavaScriptを直接書くのは面倒だし、JavaScriptでのクラスの勉強も難しいし、そのあたりで、なにか定番ができるわけじゃないにしても、JavaScriptに変換する言語が一定数使われるという流れは定着するんじゃないかな。
というか、ゆくゆくは、JavaScriptではなくて、もっと低レイヤーの仕組が使われるようになって、JavaScriptもそのレイヤーの上で動く一言語になるんじゃないかと思ったりしてるのだけど。
現時点でも、圧縮をかけたりして、書くJavaScriptと動かすJavaScriptは別ものになってきてるし。「CoffeeScriptの欠点」として挙げられるもの、コード変換に由来するものはJavaScriptでコード書いてもあてはまるんじゃないかな。
