誰かが本番アプリケーションにCoffeescriptを使用しましたか？[閉まっている]

Coffeescriptはかなりクールに見えます。誰かがそれを使ったことがありますか？その長所と短所は何ですか？

私たちは、CoffeeScriptを私たちの製品（基本的に特定の種類のデータを閲覧するためのアプリである非公開向けのWebサイト）で使用し始めました。私たちは、CoffeeScriptをコマンドラインコンパイラとして使用します（サーバー上ではなく、最終的には実行したいと考えています）。

PROS（私たちにとって）：

• コードがJavaScriptよりも一目で理解しやすくなるまで、JavaScriptの多くの不要な乱雑さ（中かっこ、セミコロン、いくつかの角かっこなど）が取り除かれます。
• JavaScriptよりもコード行が20〜30％少ない（まったく同じことを行うため）
• CoffeeScriptはノイズを取り除くだけでなく、キーワード、クラス、およびヒアドキュメントのような機能を追加して、コーディングをよりクリーンでやや楽しいものにします
• 以前のポイントを考えると、ロープを習得すると、CoffeeScriptでコーディングする方が間違いなく高速です。

短所

• コマンドラインコンパイラを使用する場合：デバッグするために、問題（javascript）を解決するときと、修正（coffeescript）を書くときとで異なるコードを調べています。ただし、信じられないほど、CoffeeScriptは非常にすばらしいので、デバッグする必要はありませんでした。

重要なのは、いつでも引き返すことができることです。私たちのcoffeescriptコンパイラーは読み取り可能なjavascriptを生成しているだけなので、誰かが気が変わったり何かを理解できない場合は、coffeescriptが生成したjavascriptの使用に戻り、コーディングを続けることができます。

BusyConfでは、すべてのJavaScriptにcoffeescriptを使用しています。BusyConfの大部分は、オフラインモードのサポートを含め、ブラウザーで実行されるクライアント側アプリケーションです。

すべてのcoffeescriptコードは完全にテストされています。テスト自体はcoffeescriptで記述され、Qunitフレームワーク（javascriptで記述）を使用します。また、テストをより快適にするQunitフレームワークの拡張機能も作成しました。Qunit拡張機能はCoffeeScriptで記述されています。このアプリケーションには、CoffeeScriptで記述されたモバイルバージョンがあり、Sencha Touchフレームワーク（JavaScriptで記述）を使用しています。

アプリケーションからjavascriptの依存関係を自由に混在させることができますが、作成するすべてのコード（アプリケーションコード、テストなど）はcoffeescriptにすることができます（すべきです）。

ほぼ1年後、いくつかの更新を投稿する価値があります。

1. Ruby on Rails 3.1には公式のCoffeeScriptサポートが組み込まれています。つまり、実際の使用がはるかに増えることになります。先月、RailsConfで講演を行いました。参加者のほとんどがこれまでにCoffeeScriptについて聞いたことがなく、dhhの強力な裏書があれば、熱心にそれに参加しました。
2. CoffeeScriptに関する本が現在eBookにあり、すぐにThe Pragmatic Bookshelfから出版される予定です。それは、CoffeeScript：Accelerated JavaScript Developmentと呼ばれ、あなた次第です。CoffeeScript 1.1.1に基づいています。
3. 言語は実際には、1.0と1.1.1の間の6か月の間にほとんど変化していません。ほぼすべての変更が「バグ修正」と見なされます。1.0.1から1.1.1への移行のために、本のコードをほんの少し調整する必要がありました。ただし、言語は今後さらに重要な変更が行われると確信しています。

CoffeeScriptプロジェクトの最も決定的なリストは、CoffeeScriptウィキの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アプリケーション全体がその中に記述されています（Appcelerator Titaniumを使用して、JavaScriptで「ネイティブ」アプリを記述できます-PhonegapのようなWebアプリではありません）。この場合、大量のJSの整理と保守が非常に簡単になるので、Coffeescriptを使用することにしました。私はまた、Coffeescript（vs. JavaScript）を使用してコードを記述する方がはるかに楽しいと感じています。RailsアプリではJSにCoffeescriptも使用していますが、これは電話アプリ全体に比べて信じられないほどマイナー/少量のコードです。

プロは主に、より優れた構文であるだけでなく、オブジェクト指向メカニズムを標準化し、いくつかの優れた追加（リスト内包、スコープなど）を追加する必要があります。

短所は私にとってほとんどゼロです。主なものは、デバッグするための追加のレイヤーであることです。生成されたJS（非常に読みやすくて素晴らしい）を見て、それをCoffeescriptコードにマッピングする必要があります。私たちにとって、これはまったく問題ではありませんが、YMMVです。

結局、私の見解では、製品版アプリでの使用に関してリスクはゼロなので、それをブロッカーにしないでください。その後、試してみてください。それを使ってコードを書き、それをJSで書くものと比較し、生成されたコードを見て、デバッグの必要性のためにそれを読むことができるかどうかを確認します。また、＃coffeescript IRCに参加してください。人々はそこにいます。そして最後に、それがアプリとどのように統合されるかを確認します。たとえば、「ビルド」プロセスは何か（たとえば、Railsの場合はバリスタを、スタンドアロンの場合は、付属の「coffee -w」を使用するなど）。

Coffeescriptは本当にJSを簡単に書くだけです。最終的には、よりクリーンで効率的なコードになります。

そうは言っても、バニラJSでできることは何でもできるだけです。coffeescriptを十分に使えば、JSを書くのがずっと簡単になります。

したがって、JSを1トンも使用したことがない場合は、代わりにコーヒースクリプトを学習することをお勧めします。あなたはより良く、よりクリーンで、バグの少ないコードを得るでしょう。既にJSに精通している場合は、「実際の」アプリでcoffeescriptを使い始めるのは良い考えではないかもしれません。

（また、coffeescriptは、コードが「ふわふわした」コードを助長しているように見えるので、少し不快です。それが良いことか悪いことかはわかりませんが、TMTOWTDIの極端なケースのようです）

コンパイラはありますが、JavaScriptの動的な性質のため、静的チェックは行われません。FAQに書かれているように：

静的分析

CoffeeScriptは、ソースからソースへの直接のコンパイラーを使用します。型チェックは行われず、変数が存在するかどうかさえ判断できません。これは、コストのかかるランタイムチェックなしでは、他の言語がネイティブに組み込むことができる機能を実装できないことを意味します。その結果、この種の分析に依存する機能は考慮されません。

IDEサポートはJavaScriptのサポートよりも成熟していません（Cloud9には構文強調表示のサポートがありますが、Eclipse JSDTにはリファクタリングなどがあります）：https ://stackoverflow.com/questions/4084167/ide-or-its-add-in-for-coffescript -プログラミング