私たちは、CoffeeScriptを私たちの製品（基本的に特定の種類のデータを閲覧するためのアプリである非公開向けのWebサイト）で使用し始めました。私たちは、CoffeeScriptをコマンドラインコンパイラとして使用します（サーバー上ではなく、最終的には実行したいと考えています）。
[〜＃〜] pros [〜＃〜]（私たちにとって）：
- それは、コードがJavaScriptよりもクリーンで一目で理解しやすい程度に、JavaScriptの多くの不要な乱雑さ（中括弧、セミコロン、いくつかの括弧など）を取り除きます。
- JavaScriptよりもコード行が20〜30％少ない（まったく同じことを行うため）
- CoffeeScriptはノイズを除去するだけでなく、キーワード、クラス、およびヒアドキュメントのような機能を追加して、コーディングをよりクリーンでやや楽しいものにします
- 以前のポイントを考えると、ロープを習得すると、CoffeeScriptでコーディングする方が間違いなく高速になります。
[〜＃〜] cons [〜＃〜]
- コマンドラインコンパイラを使用する場合：デバッグするために、問題（javascript）を解決するときと、修正（coffeescript）を書くときとで異なるコードを調べています。ただし、信じられないほど、CoffeeScriptは非常に優れているので、デバッグする必要はありませんでした。
重要なのは、いつでも引き返すことができることです。私たちのcoffeescriptコンパイラーは読み取り可能なjavascriptを生成しているだけなので、誰かが気が変わったり何かを理解できない場合は、coffeescriptが生成したjavascriptの使用に戻り、コーディングを続けることができます。
BusyConf では、JavaScriptのallにコーヒースクリプトを使用します。 BusyConfの大部分は、オフラインモードのサポートを含め、ブラウザーで実行されるクライアント側アプリケーションです。
すべてのcoffeescriptコードは完全にテストされています。テスト自体はcoffeescriptで書かれており、 Qunit フレームワーク（javascriptで書かれています）を使用しています。また、テストをより快適にするQunitフレームワークの拡張機能も作成しました。 Qunit拡張機能は CoffeeScript で記述されています。このアプリケーションには、CoffeeScriptで記述されたモバイルバージョンがあり、--- JavaScriptで記述された Sencha Touch フレームワークを使用しています。
アプリケーションからjavascriptの依存関係を自由に混在させることができますが、作成するすべてのコード（アプリケーションコード、テストなど）はcoffeescriptにすることができます（すべきです）。
ほぼ1年後、いくつかの更新を投稿する価値があります。
- Ruby on Rails 3.1は公式のCoffeeScriptサポートを組み込んでいるので、実際の使用がはるかに増えるでしょう。参加者のほとんどが聞いていなかったRailsConfで先月私は講演しました以前、CoffeeScriptを使用しており、dhhの強力な裏書があれば、それに熱心に取り組みました。
- CoffeeScriptに関する本が現在eBookにあり、間もなくThe Pragmatic Bookshelfから印刷される予定です。それは CoffeeScript：Accelerated JavaScript Development と呼ばれ、まさにあなた次第です。それはCoffeeScript 1.1.1に基づいています。
- 言語は実際には、1.0と1.1.1の間の6か月の間にほとんど変化していません。ほぼすべての変更が「バグ修正」と見なされます。 1.0.1から1.1.1への移行のために、本のコードをほんの少し調整する必要がありました。ただし、言語は今後さらに重要な変更が行われると確信しています。
CoffeeScriptプロジェクトの最も決定的なリストは、CoffeeScript wikiの In the Wild ページにあります。
これまでのところ、CoffeeScriptのプロダクション用途のほとんどはAppceleratorと組み合わせてiPhone/Androidアプリを作成していると思います。 （The ChangelogのWynn Netherlandは、CoffeeScriptを「iOS、Android、およびWebOSモバイル開発の秘密兵器」と説明することで私の本をぼかしました）が、本番環境での使用がさらに増えるRailsアプリ-そして、私は、他の場所で-今後数か月のうちに。
Coffeescriptは、iPad用のArs Technicaリーダーで使用されました http://arstechnica.com/Apple/news/2010/11/introducing-the-ars-technica-reader-for-ipad.ars
私は最近、Coffeescriptが大好きです。基本的に HotelTonight iPhoneアプリケーション全体が書き込まれます（JavaScriptで「ネイティブ」アプリを記述できるAppcelerator Titaniumを使用します。これらはPhonegapのようなWebアプリではありません）。この場合、大量のJSの整理と保守が非常に簡単になるため、Coffeescriptを使用することにしました。また、Coffeescript（vs. JavaScript）を使用してコードを記述する方がはるかに楽しいと感じました。 RailsアプリでJSにCoffeescriptも使用していますが、これは電話アプリ全体に比べて非常にマイナー/少量のコードです。
プロは主に、より優れた構文であることに関係していますが、OOメカニズムを標準化し、Niceの追加（リスト内包、スコープなど））を追加します。
短所は私にとってほとんどゼロです。主なものは、デバッグするための追加のレイヤーであることです。生成されたJS（非常に読みやすくニースです）を確認し、それをCoffeescriptコードにマッピングする必要があります。私たちにとって、これはまったく問題ではありませんでしたが、YMMVです。
結局、私の見解では、製品版アプリでの使用に関してリスクはゼロなので、それをブロッカーにしないでください。その後、試してみてください。それを使ってコードを書き、それをJSで書くものと比較し、生成されたコードを見て、デバッグの必要性のためにそれを読むことができるかどうかを確認します。また、＃coffeescript IRCに参加してください。人々はそこにいます。そして最後に、それがアプリとどのように統合されるかを確認します。 「ビルド」プロセスは何ですか（たとえば、Railsの場合は、バリスタを試してください。スタンドアロンの場合は、付属の「coffee -w」を使用してください）。
コンパイラはありますが、JavaScriptの動的な性質のため、静的チェックは行われません。 FAQに書かれているように：
静的分析
CoffeeScriptは、単純なソース間コンパイラーを使用します。型チェックは行われず、変数が存在するかどうかさえ判断できません。これは、コストのかかるランタイムチェックなしでは、他の言語がネイティブに構築できる機能を実装できないことを意味します。その結果、この種の分析に依存する機能は考慮されません。
IDEサポートはJavaScriptのサポートほど成熟していません（Cloud9には構文強調表示サポートがありますが、Eclipse JSDTにはリファクタリングなどがあります）： https://stackoverflow.com/questions/4084167/ide-or-its-add-in -for-coffescript-programming
Coffeescriptは本当にJSの記述を簡単にするだけです。最終的には、よりクリーンで効率的なコードになります。
そうは言っても、あなたはまだバニラJSでできることしかできません。 coffeescriptを十分に使えば、JSを書くのがずっと簡単になります。
したがって、JSを1トンも使用していない場合は、代わりにコーヒースクリプトを学習することをお勧めします。あなたはより良く、よりクリーンで、バグの少ないコードを得るでしょう。すでにJSに精通している場合は、「実際の」アプリでcoffeescriptを使い始めることはお勧めできません。
（また、coffeescriptは、コードが「ふわふわした」コードを助長しているように見えるので、少しイライラします。それが良いことなのか悪いことなのかはわかりませんが、TMTOWTDIの極端なケースのようです）