Coffeescriptの長所と短所は何ですか？[閉まっている]

もちろん、1つの大きな長所は、多くの場合にコードを短くする構文糖の量です。上http://jashkenas.github.com/coffee-script/印象的な例があります。一方、これらの例が複雑な現実世界のアプリケーションのコードを表していることには疑問があります。たとえば、私のコードでは、ベアオブジェクトに関数を追加するのではなく、プロトタイプに関数を追加します。さらに、プロトタイプ機能はユーザーから隠されており、慣用的なJavascriptではなく古典的なOOPを示唆しています。

配列内包表記の例は、私のコードでおそらく次のようになります。

cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...

私はCoffeeScriptに関する次の本の著者です：http :
//pragprog.com/titles/tbcoffee/coffeescript

私は、CoffeeScriptを使用してから1週間ほど試してみる価値があると確信しました。当時の言語はほんの数か月しか経っておらず、現在よりもはるかに荒いエッジがありました。公式サイトは、言語の機能（のほとんど）を一覧表示する素晴らしい仕事をしているので、ここではそれらを繰り返しません。むしろ、この言語の長所は次のとおりです。

1. 優れたJavaScriptパターンの使用を奨励します
2. JavaScriptアンチパターンを推奨しない
3. 優れたJavaScriptコードでも短く、読みやすくします

No. 3は最初の2つよりもずっと注目されています（私の本でも）。しかし、考えれば考えるほど、きれいな構文のためだけにジャンプをしなかったことがわかります。言語が私をより良く、よりエラーの少ないJavaScriptに向かわせたので、私はジャンプをしました。簡単な例をいくつか示します。

• 変数は自動スコープであるため、省略することで誤ってグローバルを上書きvarしたり、同じ名前の変数をシャドウしたり（名前付き引数を除く）、相互作用する異なるファイルに変数を持たせたりすることはできません（https://stackoverflow.com/questionsを参照） / 5211638 / pattern-for-coffeescript-modules / 5212449）。
• の->方がはるかに簡単に記述function(){}できるため、コールバックを使用する方が簡単です。セマンティックインデントにより、コールバックがネストされていることが明確になります。また、適切な場合=>に保存しやすくしthisます。
• のでunless xより解析に英語を話すために容易になりif (!x)、かつif x?より簡単ですif (x != null)ちょうど2つの例を与えるために、あなたはロジック自体に複数の論理構文に少ない脳のサイクルを過ごすことができます。

Underscore.jsのような優れたライブラリは、これらの問題の一部を処理できますが、すべてではありません。

短所：

1. コンパイルは面倒です。CoffeeScriptコンパイラーがスローする構文エラーは、しばしばあいまいです。将来、そのトラックで進歩が見られると期待しています。（コンパイラの防御では、JavaScriptで記述した場合、そのコード行が実行されるまでエラーとして発見されないものをしばしばキャッチします。これらのバグを後日より早くキャッ​​チすることをお勧めします。）
2. 関連して、デバッグは苦痛になる可能性があります。コンパイルされたJS行を元のCoffeeScriptに一致させる方法はまだありません（Firefoxの人々はこれが来ると約束しましたが）。
3. 変更する傾向があります。CoffeeScriptの将来のバージョンでは、コードが異なって実行されるか、まったく実行されない可能性があります。もちろん、これはほとんどの言語の場合です。RubyまたはPythonの新しいバージョンへの移行も同様ですが、JavaScriptの場合はそうではありません。ウェブが存在する限り、ブラウザは存在します。
4. それはあまり知られていない。JavaScriptは共通語です。CoffeeScriptは短期間で非常に人気を博しましたが、JavaScriptほどの広大なコミュニティを楽しむことはまずありません。

明らかに、プロは個人的には短所を上回っていると思いますが、すべての人、チーム、またはプロジェクトに当てはまるわけではありません。（Jeremy Ashkenasでも多くのJavaScriptを書いています。）CoffeeScriptは、JavaScriptを補完するものではなく、JavaScriptを補完するものとして最もよく見られています。

ある程度大きなJavaScriptコードベースがあり、約1か月前にCoffeeScriptを試してみることにしました。開発者の1人は、http：//js2coffee.org/を使用してJSからCSにモジュールの1つを移行することから始めました。このツールはかなり便利で、1000行程度のJavaScriptを移植するのに約2〜3時間かかりました。その時点で気付いたいくつかの観察：

1. 結果のCoffeeScriptコードは非常に読みやすくなりました。

2. JavaScriptにコンパイルして戻したので、ナビゲートとデバッグが非常に簡単でした。このモジュールを移植しているときに、チームの別の開発者がバグを発見しました。これら2人の開発者は、古いJavaScriptコードとCSコンパイラーから出た新しいJavaScriptコードのバグを修正しました。彼らは独立して働き、ほぼ同じ時間（15-20分）かかりました。

3. それがポートであるという事実のために、結果のコードは適切または望ましいコーヒー固有の機能を使用していませんでした。CoffeeScriptをゼロから記述する場合、コードはより慣用的です。そのため、後で既存のコードを移植しないことにしました。

4. 一般的に、より短い機能とより小さなオブジェクトの可読性はある程度向上しました。ただし、長いメソッドの場合はまったくそうではありませんでした。最大の肥大化による節約は->明示的returnでしたが、それ以外の点ではコードが大幅に短縮または単純化されていません。構文の一部、特にオブジェクトリテラルは非常に混乱しているように見えました。CSは、メンバー定義を囲む中括弧を省略し、「everything-is-an-expression」および暗黙returnのコードと組み合わせて、コードの一部を読みにくくしました。

   JavaScriptは次のとおりです。

   var rabbitGenerator = {
       makeRabbit: function(rabbitName, growCarrots) {
           if (growCarrots) {
               carrots.growMore(10);
           } else {
               carrots.ensureSupply();
           }
           return {
               name: rabbitName, 
               height: 0,
               actions: {
                   jump: function (height) {
                       this.height += height;
                   },
                   eatCarrot: function () {
                       // etc
                   }
               }
           };
       },
       // more members
   }
   

   そして、対応するCoffeeScriptコードは次のようになります。

   rabbitGenerator = 
     makeRabbit: (rabbitName, growCarrots) ->
       if growCarrots
         carrots.growMore 10
       else
         carrots.ensureSupply()
       name: rabbitName // (*)
       height: 0
       actions: 
         jump: (height) ->
           @height += height
   
         eatCarrot: ->
   

   現在では、returnステートメントが(*)行で始まることを理解するのはかなり困難です。このプロジェクトでは、オブジェクトリテラルに大きく依存しています。これらを関数パラメーターとして渡し、他の関数から返します。多くの場合、これらのオブジェクトは非常に複雑になる傾向があります：異なるタイプのメンバーといくつかのレベルのネスト。私たちのケースでは、CoffeeScriptコードは実際にはプレーンなJavaScriptコードよりも読みにくいと感じていました。

5. CoffeeScriptのデバッグは、予想よりも簡単であることが判明しましたが、編集エクスペリエンスはかなり低下しました。この言語に適したエディター/ IDEが見つかりませんでした。私たちは、プロジェクトのクライアント側コードのエディター/ IDEを標準化しておらず、実際、すべて異なるツールを使用しています。実際、チームの全員がCoffeeScriptに切り替えると、ツールからかなり貧弱なサポートを受けることに同意します。IDEおよびエディターのプラグインは非常に初期の形であり、場合によっては適切な構文の強調表示またはインデントのサポートを提供することさえできません。コードスニペットやリファクタリングについて話していない。WebStorm、Eclipse、NetBeans、VisualStudio、Notepad ++、SublimeText2を使用します。

6. ツールといえば、CoffeScriptコンパイラー自体がNode JSパッケージとして提供されることに言及する必要があります。私たちは主にJava / .NETショップであるため、誰もがWindowsボックスで開発しています。最近まで、WindowsのサポートはNodeにはほとんど存在していませんでした。CoffeeScriptコンパイラをWindowsで実行することはできなかったため、当面は<script type="text/coffeescript">タグとブラウザベースのオンザフライコンパイラを使用することにしました。

   コンパイラーは非常に高速であり、起動時間をあまり長くしません。欠点は、結果のJavaScriptがeval編集され、ブラウザーの開発者ツール（特にIE8）でブレークポイントを設定するのが少し難しいことです。デバッグに苦労する場合は、上にリストしたものと同じ移行ツールを使用してCoffeeScriptコードをプリコンパイルしますが、それでもまだあまり便利ではありません。

7. 自動var挿入やthis太い矢印演算子（=>）の半透明管理など、CoffeeScriptの他の約束は、期待したほどの利益をもたらさないことが判明しました。ビルドプロセスの一部としてすでにJSLintを使用しておりES3 x ES5-Strict、言語のサブセットでコードを記述しています。とにかく、Coffeeが同じ種類の「きれいな」コードを生成するという事実は良いことです。すべてのサーバー側フレームワークが有効なHTML5およびCSS3マークアップも生成することを願っています！

   つまり、CoffeeScriptがvarキーワードを入力して時間を大幅に節約するとは言いません。不足しているvarsはJSLintによって簡単に捕捉され、簡単に修正できます。さらに、しばらくの間修正されると、とにかく良いJavaScriptを自動的に書き始めます。したがって、私はコーヒーが本当に言わないだろうというこの点で役に立ちます。

CoffeeScriptを約1週間評価しました。すべてのチームメンバーがコードを記述しており、お互いの経験を共有しました。それを使って新しいコードを書き、既存のコードを適切に移植した。言語に対する私たちの気持ちはまちまちでした。

一般的に言って、それは私たちの開発を加速しなかったと言いますが、それは私たちを遅くしませんでした。タイピングの減少とエラーサーフェスの減少による速度の向上は、他の領域の速度低下、主にツールのサポートによって相殺されました。一週間後、CoffeeScriptの使用を義務付けないと決めましたが、それも禁止しません。自由な選択が与えられると、実際には誰もそれを使用しません。少なくとも今のところは。時々、新しい機能のプロトタイプを作成し、プロジェクトの残りの部分と統合する前にコードをJavaScriptに変換して、より迅速に開始することを考えていますが、そのアプローチはまだ試していません。

長所

Trevor Burnhamの回答をご覧ください。

さらに、あなたは自分自身をジャバスクリプトの汚れをいじるのではなく、流行のことをしているヒップな男だと考えることができます。

短所

CoffeeScriptは、構文糖とピンクのグラスに過ぎません。

簡単なこと-CoffeeScriptは冗長です。どの言語でも簡単なことは簡単だからです。また、jQueryはおそらくCoffeeScriptよりも簡単です。

ハードなものについては、メディアを理解する必要があります。そしてあなたの媒体はHTML、DOM、CSSであり、Javascriptはそれらを相互接続するための単なるツールにすぎません-すべてのAPIはJavascript専用に書かれています。「実際の」言語にコンパイルされる他の言語を使用すると、Java（GWT）、Dart、CoffeeScriptのいずれであっても、非常に危険です。

アンチパターンまたは言語ルールの平凡な無知は、1〜2冊の良い本を読むことで修正できます。そして、Coffeescriptには独自のアンチパターンがあると確信しています。

CoffeescriptのIDEサポートは、JSよりもさらに悪いです。

私の考えでは、最大のプロは次のとおりです。

簡単なcoffescript は、記述するべき javascriptにコンパイルされますが、そうではありませんでした。

javascriptのいくつかの厄介なコーナーがありますが、これらは警戒によってのみ回避されます-私の頭の上の例：

• プロトタイプを正しく設定する
• ==の代わりに===を使用
• nullのチェック
• varですべての変数を宣言する
• 自己実行型の匿名関数ですべてをラップします。

coffeescriptを記述すると、それらはすべて自動的に処理されます。

短所は、IMO、ほとんどマイナーです：

• デバッグは苦痛です
• coffeescriptプログラマーが少ない
• ドキュメントをjavascriptからcoffeescriptに翻訳する必要があります。

長所

1. CoffeeScriptはJavaScriptの詳細を学ぶのに役立ちました
2. 複雑なネストされたコールバックであっても、かなり読みやすい
3. 言語の問題を追跡するのが困難なJavaScriptのいくつかの安全性を提供します

上記のAndrewの実例は、啓発的であることがわかりました。既存のオブジェクトリテラルリターンの可読性は、単に手動でリターンを識別することによって向上すると考えています

帰る

//ここにオブジェクトリテラル

IDEツールが強化され、TextMateとCloud9はCoffeeScriptをサポートします。確かに、Windowsのサポートは遅れています（ただし、一般的なWeb開発には当てはまりませんか？）

短所

ブラウザで解釈されたCoffeeScriptはデバッグが難しい場合があります。

これはJavaScriptの上にある追加のレイヤーであり、開発者の理解と検討が必要です。

長所

1. 彼らは実際に一般的なケースを構文的に最適化しました。実際、CoffeeScriptは、「一般的に」使用される最も簡潔な言語ではないにしても、 http：//redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-表現力/
2. JavaScriptの悪い部分を隠します（自動強制==、暗黙的なグローバル、より伝統的なクラスシステムにより一般的なことが容易になります）
3. Python / Rubyプログラマーにとって非常に簡単に学ぶことができます
4. 複数行の匿名関数+空白構文

短所

1. varの削除は、オブジェクトを使用せずに内部スコープ内の外部スコープ変数を変更できないことを意味します。または、 `var fall_back_to_js;`がハッキングします[値を再割り当てするだけの別の割り当てステートメント '：='ではないので、 =デバッグしやすい5つのタイプミス]
2. JavaScriptをデバッグする場合を除き、すべてのツールに通知する必要があります:(; btw：ソースマップのサポートを追加することでChromeからCoffeeScriptをデバッグできます; yeoman（npm install yeoman）はCoffeeScript
3. オプションの静的型付けはありません（次のEcmaScript標準を待つ必要があります）
4. モジュールシステム用のサードパーティライブラリがまだ必要
5. 注意すべき構文トラップ：暗黙の戻り値、abgoはa（b（g（o）））、fp、b：2、c：8はfではなくf（p、{b：2、c：8}）を意味します（p、{b：2}、{c：8}）
6. 壊れたJavaScriptの数値/型システムは変更されません