Qualcuno ha usato Coffeescript per un'applicazione di produzione? [chiuso]

Coffeescript sembra piuttosto interessante. Qualcuno l'ha usato? Quali sono i suoi pro e contro?

Abbiamo iniziato a utilizzare CoffeeScript nel nostro prodotto, un sito Web non pubblico che è fondamentalmente un'app per la navigazione di determinati tipi di dati. Usiamo CoffeeScript come compilatore a riga di comando (non sul server, cosa che alla fine vorremmo fare).

PRO (per noi):

• Elimina un sacco di inutili disordine in javascript (ad esempio parentesi graffe, punti e virgola, alcune parentesi) nella misura in cui il codice è più pulito e più facile da comprendere a colpo d'occhio rispetto a javascript
• 20-30% in meno di righe di codice rispetto a javascript (per fare esattamente la stessa cosa)
• CoffeeScript non solo rimuove il rumore, ma aggiunge parole chiave, classi e funzionalità come heredocs per rendere la codifica più pulita e un po 'più piacevole
• Dati i punti precedenti, è indubbiamente più veloce scrivere codice in CoffeeScript una volta apprese le basi

CONS

• Quando si utilizza il compilatore della riga di comando: per eseguire il debug, si sta guardando un codice diverso quando si risolve il problema (javascript) come quando si scrive la correzione (coffeescript). Tuttavia, incredibilmente, il nostro CoffeeScript è così fantastico che non abbiamo mai avuto bisogno di eseguirne il debug!

È importante sottolineare che possiamo tornare indietro in qualsiasi momento. Il nostro compilatore coffeescript produce solo javascript leggibile, quindi se qualcuno cambia idea o non riesce a capire qualcosa, allora possiamo semplicemente tornare a utilizzare il javascript prodotto da coffeescript e continuare a scrivere codice.

Usiamo coffeescript per tutto il javascript in BusyConf . Gran parte di BusyConf è un'applicazione lato client che viene eseguita nei browser, incluso il supporto per la modalità offline.

Tutto il nostro codice coffeescript è completamente testato. I test stessi sono scritti in coffeescript e utilizzano il framework Qunit (che è scritto in javascript). Abbiamo anche scritto un'estensione al framework Qunit che rende i test più belli. L'estensione Qunit è scritta in CoffeeScript . La nostra applicazione ha una versione mobile che è scritta in CoffeeScript e utilizza il framework Sencha Touch (che è scritto in javascript).

Il vantaggio è che puoi mescolare liberamente le dipendenze javascript nella tua applicazione, ma tutto il codice che scrivi (il codice dell'applicazione, i test, ecc.) Può (e dovrebbe!) Essere coffeescript.

Quasi un anno dopo, vale la pena pubblicare alcuni aggiornamenti:

1. Ruby on Rails 3.1 sta incorporando il supporto ufficiale di CoffeeScript, il che significa che vedrà un utilizzo molto maggiore nel mondo reale. Ho tenuto un discorso a RailsConf il mese scorso, dove la maggior parte dei partecipanti non aveva mai sentito parlare di CoffeeScript prima e, vista la forte approvazione di dhh, non vedeva l'ora di parlarne.
2. C'è un libro su CoffeeScript, attualmente in eBook e presto in stampa da The Pragmatic Bookshelf. Si chiama CoffeeScript: Accelerated JavaScript Development , ed è veramente tuo. È basato su CoffeeScript 1.1.1.
3. La lingua in realtà è cambiata molto poco nei sei mesi tra 1.0 e 1.1.1; quasi tutte le modifiche si qualificano come "correzioni di bug". Ho dovuto apportare pochissime modifiche al codice nel libro per la transizione dalla 1.0.1 alla 1.1.1. Tuttavia, sono sicuro che la lingua vedrà cambiamenti più significativi in ​​futuro.

L'elenco più definitivo dei progetti CoffeeScript si trova nella pagina In the Wild del wiki di CoffeeScript .

Direi che la maggior parte dell'utilizzo di produzione di CoffeeScript finora è in combinazione con Appcelerator per creare app per iPhone / Android. (Wynn Netherland di The Changelog ha blaterato il mio libro descrivendo CoffeeScript come "la mia arma segreta per lo sviluppo mobile iOS, Android e WebOS"), ma ci sarà molto più utilizzo nelle app Rails di produzione e, spero, altrove - nei prossimi mesi.

Coffeescript è stato utilizzato nel lettore Ars Technica per iPad http://arstechnica.com/apple/news/2010/11/introducing-the-ars-technica-reader-for-ipad.ars

Adoro davvero Coffeescript in questi giorni. Essenzialmente l'intera applicazione iPhone di HotelTonight è scritta al suo interno (utilizzando Appcelerator Titanium, che ti consente di scrivere app "native" in JavaScript - non sono app web, diciamo come Phonegap). Ho scelto di utilizzare Coffeescript in questo caso perché rende molto più facile organizzare e mantenere una grande quantità di JS. Trovo anche semplicemente molto più piacevole scrivere codice con Coffeescript (rispetto a JavaScript). Usiamo anche Coffeescript per JS nella nostra app Rails, ma questa è una quantità di codice incredibilmente piccola / piccola in relazione all'intera app del telefono.

I professionisti hanno principalmente a che fare con una sintassi più gradevole, ma anche con il fatto che standardizza un meccanismo OO e quindi aggiunge alcune belle aggiunte (comprensioni di elenchi, alcune cose di ambito, ecc.).

I contro sono quasi zero per me. Il principale è che è un livello aggiuntivo per il debug. Dovrai guardare il JS generato (che è MOLTO leggibile e carino), e poi mapparlo al tuo codice Coffeescript. Per noi, questo non è stato affatto un problema, ma YMMV.

Alla fine, la mia opinione è che non ci sono rischi in termini di utilizzo su un'app di produzione, quindi non lasciare che sia un blocco. Quindi, vai a provarlo. Scrivici del codice, confrontalo con quello che scriveresti in JS, guarda il codice generato per vedere se sei a tuo agio nel poterlo leggere per esigenze di debug. Inoltre, esci nell'IRC #coffeescript, le persone sono brave lì. E infine, guarda come si integrerebbe con la tua app, ad esempio qual è il tuo processo di "build" (ad es. Per Rails, prova Barista, per qualcosa di autonomo, usa semplicemente "coffee -w" incluso, ecc.).

Coffeescript semplifica davvero la scrittura di JS. Ti ritroverai con un codice più pulito ed efficiente.

Detto questo, puoi ancora fare tutto ciò che puoi fare in vanilla JS. Una volta che usi abbastanza coffeescript, diventa molto più facile scrivere (buono) JS.

Quindi, se non hai usato JS una tonnellata, suggerirei invece di imparare Coffescript. Otterrai un codice migliore, più pulito e con meno bug. Se sei già molto fluente in JS, potrebbe non essere una buona idea iniziare a utilizzare coffeescript su un'app "reale".

(Inoltre, coffeescript mi ​​infastidisce un po 'in quanto sembra incoraggiare un codice piuttosto "floofy". Non so se sia una cosa buona o cattiva, ma sembra un caso estremo di TMTOWTDI)

Nota che sebbene esista un compilatore, non ottieni il controllo statico a causa della natura dinamica di JavaScript. Come scritto nelle FAQ:

Analisi statica

CoffeeScript utilizza un compilatore diretto da sorgente a sorgente. Non viene eseguito alcun controllo del tipo e non possiamo stabilire se una variabile esiste o meno. Ciò significa che non possiamo implementare funzionalità che altri linguaggi possono creare in modo nativo senza costosi controlli di runtime. Di conseguenza, qualsiasi caratteristica che si basa su questo tipo di analisi non verrà presa in considerazione.

Il supporto IDE è meno maturo di quello di JavaScript (Cloud9 ha il supporto per l'evidenziazione della sintassi, ma Eclipse JSDT ha refactoring e altro): /programming/4084167/ide-or-its-add-in-for-coffescript -programmazione