Coffeescriptはかなりクールに見えます。誰かがそれを使用しましたか?その長所と短所は何ですか?
7 に答える
私たちは、基本的に特定の種類のデータを閲覧するためのアプリである、非公開の Web サイトである私たちの製品で CoffeeScript の使用を開始しました。私たちは CoffeeScript をコマンドライン コンパイラとして使用します (サーバー上ではなく、最終的にはそうしたいと考えています)。
長所(私たちにとって):
- 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 年後、いくつかの更新を投稿する価値があります。
- Ruby on Rails 3.1 では、CoffeeScript の公式サポートが組み込まれています。これは、実際の使用がはるかに増えることを意味します。私は先月、RailsConf で講演を行いました。参加者のほとんどは、CoffeeScript について聞いたことがなく、dhh の強力な支持を得て、CoffeeScript に参加することを熱望していました。
- 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 の本番環境での使用のほとんどは、iPhone/Android アプリを作成するために Appcelerator と組み合わせて使用されていると言えます。(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 アプリケーションではありません)。この場合、Coffeescript を使用することにしました。これにより、大量の JS の整理と保守がはるかに簡単になるからです。また、Coffeescript を使用してコードを記述する方が (JavaScript と比べて) 単純にはるかに楽しいと思います。また、Rails アプリの JS に Coffeescript を使用していますが、これは電話アプリ全体に比べて非常にマイナー/少量のコードです。
長所は主に、より優れた構文であることだけでなく、オブジェクト指向メカニズムを標準化し、いくつかの優れた追加機能 (リスト内包表記、いくつかのスコープなど) を追加することにも関係しています。
私にとってデメリットはほぼゼロです。主なものは、デバッグするための余分なレイヤーであることです。生成された JS (非常に読みやすく、優れています) を見て、それを Coffeescript コードにマップする必要があります。私たちにとって、これはまったく問題ではありませんでしたが、YMMV.
結局のところ、私の見解では、本番アプリで使用するという点ではリスクはゼロなので、それを阻害要因にしないでください。それでは、試してみてください。それを使ってコードを書き、それをJSで書いたものと比較し、生成されたコードを見て、デバッグの必要性のためにそれを読むことができるかどうかを確認してください. また、#coffeescript IRC にたむろしてください。人々は親切です。そして最後に、あなたのアプリとどのように統合されるかを確認してください。たとえば、「ビルド」プロセスは何か (たとえば、Rails の場合は Barista を試してください。スタンドアロンの場合は、付属の「coffee -w」を使用するだけです)。
コンパイラはありますが、JavaScriptの動的な性質により、静的チェックは取得されないことに注意してください。FAQに書かれているように:
静的解析
CoffeeScriptは、ストレートなソースツーソースコンパイラを使用します。型チェックは行われず、変数が存在するかどうかさえもわかりません。これは、コストのかかるランタイムチェックなしでは、他の言語がネイティブに組み込むことができる機能を実装できないことを意味します。結果として、この種の分析に依存する機能は考慮されません。
IDEのサポートはJavaScriptのサポートよりも成熟していません(Cloud9には構文ハイライトのサポートがありますが、Eclipse JSDTにはリファクタリングなどがあります):https ://stackoverflow.com/questions/4084167/ide-or-its-add-in-for-coffescript -プログラミング
Coffeescript は本当に JS の記述を容易にします。最終的には、よりクリーンで効率的なコードになります。
そうは言っても、バニラの JS でできることはまだできます。coffeescript を十分に使用すると、(優れた) JS を作成するのがずっと簡単になります。
したがって、JS をあまり使用していない場合は、代わりに coffescript を学習することをお勧めします。より良く、よりクリーンで、バグの少ないコードが得られます。すでに JS に精通している場合、「実際の」アプリで coffeescript を使い始めるのは得策ではないかもしれません。
(また、coffeescript はかなり「ふざけた」コードを奨励しているように見えるという点で、私を少しいらいらさせます。それが良いことなのか悪いことなのかはわかりませんが、TMTOWTDI の極端なケースのようです)