Quali sono i pro e i contro di Coffeescript? [chiuso]

Naturalmente un grande professionista è la quantità di zucchero sintattico che porta a un codice più breve in molti casi. Su http://jashkenas.github.com/coffee-script/ ci sono esempi impressionanti. D'altro canto, dubito che questi esempi rappresentino il codice di complesse applicazioni nel mondo reale. Nel mio codice, ad esempio, non aggiungo mai funzioni agli oggetti nudi ma piuttosto ai loro prototipi. Inoltre, la funzione prototipo è nascosta all'utente, suggerendo OOP classico anziché Javascript idiomatico.

L'esempio di comprensione dell'array dovrebbe apparire nel mio codice probabilmente in questo modo:

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

Sono l'autore di un prossimo libro su CoffeeScript:
http://pragprog.com/titles/tbcoffee/coffeescript

Ero convinto che valesse la pena usare CoffeeScript dopo circa una settimana di gioco, anche se il linguaggio aveva solo pochi mesi e aveva molti più margini di quanto non lo sia ora. Il sito ufficiale fa un ottimo lavoro elencando (la maggior parte) delle funzionalità della lingua, quindi non le ripeterò qui. Piuttosto, dirò solo che i pro della lingua sono:

1. Incoraggia l'uso di buoni modelli JavaScript
2. Scoraggia gli anti-pattern JavaScript
3. Rende il codice JavaScript anche più breve più breve e più leggibile

Il n. 3 riceve molta più attenzione dei primi due (anche nel mio libro), ma più ci penso, più mi rendo conto di non aver fatto il salto solo per la bella sintassi; Ho fatto il salto perché la lingua mi ha spinto verso JavaScript migliore, meno soggetto a errori. Per fare alcuni brevi esempi:

• Poiché le variabili sono auto-scoping, non è possibile sovrascrivere accidentalmente i globuli omettendo var, ombreggiando una variabile con lo stesso nome (tranne con argomenti con nome) o avere variabili in file diversi che interagiscono (consultare https://stackoverflow.com/questions / 5211638 / pattern-for-coffeescript-modules / 5212449 ).
• Perché ->è molto più facile da scrivere rispetto a function(){}, è più facile usare i callback. Il rientro semantico chiarisce quando i callback sono nidificati. E =>facilita la conservazione thisquando appropriato.
• Poiché unless xè più facile per chi parla inglese analizzare if (!x), ed if x?è più facile if (x != null), per dare solo due esempi, è possibile dedicare meno cicli cerebrali alla sintassi della logica e altro alla logica stessa.

Una grande libreria come Underscore.js può occuparsi di alcuni di questi problemi, ma non di tutti.

Ora per i contro:

1. La compilazione può essere un dolore. Gli errori di sintassi generati dal compilatore CoffeeScript sono spesso vaghi. Mi aspetto che in futuro vengano fatti progressi su questa pista. (A difesa del compilatore, spesso vengono rilevati elementi che, se li scrivessi in JavaScript, non verrebbero rilevati come errori fino a quando non verrà eseguita quella riga di codice. Meglio catturare quei bug prima che poi.)
2. Allo stesso modo, il debug può essere un problema. Non c'è ancora alcun modo per abbinare le linee JS compilate al CoffeeScript originale (anche se la gente di Firefox ha promesso che questo sta arrivando).
3. È incline a cambiare. Il codice può essere eseguito in modo diverso o non eseguito affatto in una versione futura di CoffeeScript. Ovviamente, questo è il caso della maggior parte delle lingue — passare a una nuova versione di Ruby o Python è simile — ma non è il caso di JavaScript, dove ci si può ragionevolmente aspettare che il codice che funziona bene sui principali browser oggi funzionerà bene su tutti i principali browser per tutto il tempo in cui esiste il Web.
4. Non è così noto. JavaScript è una lingua francese . CoffeeScript è diventato molto popolare in breve tempo, ma è improbabile che possa mai godere di una comunità così vasta come JavaScript.

Ovviamente penso che i pro superino i contro per me personalmente, ma non sarà così per ogni persona, squadra o progetto. (Anche Jeremy Ashkenas scrive molto JavaScript.) CoffeeScript è considerato un ottimo complemento di JavaScript, non un rimpiazzo.

Abbiamo una base di codice JavaScript piuttosto grande e circa un mese fa abbiamo voluto provare CoffeeScript. Uno dei nostri sviluppatori ha iniziato con la migrazione di uno dei nostri moduli da JS a CS utilizzando http://js2coffee.org/ . Questo strumento è stato piuttosto utile e ci sono volute circa due o tre ore per il porting di una linea di JavaScript di 1000 qualcosa. Alcune osservazioni che abbiamo notato a quel punto:

1. Il codice CoffeeScript risultante era abbastanza leggibile.

2. Lo abbiamo compilato di nuovo in JavaScript ed è stato abbastanza facile navigare e eseguire il debug. Durante il porting di quel modulo, un altro sviluppatore del nostro team ha riscontrato un bug. Questi due sviluppatori hanno risolto quel bug nel nostro vecchio codice JavaScript e nel nuovo codice JavaScript uscito dal compilatore CS. Lavorarono in modo indipendente e impiegarono circa la stessa quantità di tempo (15-20 minuti).

3. A causa del fatto che si trattava di una porta, il codice risultante non utilizzava funzionalità specifiche di Coffee che erano appropriate o desiderabili. Se scrivessimo da zero in CoffeeScript il codice sarebbe più idiomatico. Per questo motivo, in seguito, abbiamo deciso di non trasferire il codice esistente.

4. In generale la leggibilità della funzione più breve e dell'oggetto più piccolo sono aumentate in una certa misura. Tuttavia, per metodi più lunghi non è stato affatto il caso. Il più grande risparmio derivava da ->ed esplicito return, ma a parte questo il nostro codice non era diventato significativamente più breve o più semplice. Alcuni pezzi di sintassi sembravano piuttosto confusi, specialmente oggetti letterali. CS omette parentesi graffe attorno alle definizioni dei membri e combinato con "tutto-è-un'espressione" e implicito returnche ha reso alcuni pezzi di codice piuttosto difficili da leggere.

   Ecco 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
   }
   

   Ed ecco come sarebbe il codice CoffeeScript corrispondente:

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

   Come è ora è abbastanza difficile capire che la dichiarazione di ritorno inizia alla (*)riga. Nel nostro progetto facciamo molto affidamento sui letterali degli oggetti: li passiamo come parametri di funzione e li restituiamo da altre funzioni. In molti casi questi oggetti tendono ad essere piuttosto complessi: con membri di diversi tipi e diversi livelli di nidificazione. Nel nostro caso, la sensazione generale era che il codice CoffeeScript fosse effettivamente più difficile da leggere rispetto al semplice codice JavaScript.

5. Sebbene il debug di CoffeeScript si sia rivelato più semplice di quanto ci aspettassimo, l'esperienza di modifica è peggiorata un po '. Non siamo riusciti a trovare un buon editor / IDE per questa lingua. Non abbiamo standardizzato l'editor / IDE per il codice lato client per il nostro progetto e in effetti tutti usiamo strumenti diversi. In effetti tutti in un team concordano sul fatto che quando passano a CoffeeScript ottengono un supporto piuttosto scarso dal loro strumento. I plug-in IDE ed editor sono in una forma molto precoce e in alcuni casi non possono nemmeno darci un supporto per l'evidenziazione o il rientro della sintassi. Non parliamo di frammenti di codice o refactoring. Utilizziamo WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ e SublimeText2.

6. A proposito di strumenti, dovrei menzionare che il compilatore CoffeScript stesso viene fornito come pacchetto JS Node. Siamo primari in un negozio Java / .NET, quindi tutti stanno sviluppando su scatole di Windows. Fino a poco tempo fa il supporto di Windows era quasi inesistente in Nodo. Non siamo riusciti a far funzionare il compilatore CoffeeScript su Windows, quindi per il momento abbiamo deciso di attenerci ai <script type="text/coffeescript">tag e al compilatore al volo basato su browser.

   Il compilatore è abbastanza veloce e non aumenta molto il tempo di avvio. Il rovescio della medaglia è che il JavaScript risultante viene evaleditato ed è un po 'difficile inserire punti di interruzione negli strumenti di sviluppo dei browser (specialmente in IE8). Se abbiamo difficoltà con il debug pre-compiliamo il codice CoffeeScript con lo stesso strumento di migrazione che ho elencato sopra, ma non è ancora molto conveniente.

7. Altre promesse di CoffeeScript come l' varinserimento automatico o la gestione semitrasparente di thiscon l'operatore freccia grassa ( =>) si sono rivelate non dare il guadagno che speravamo. Usiamo già JSLint come parte del nostro processo di compilazione e scriviamo il codice in un ES3 x ES5-Strictsottoinsieme della lingua. Ad ogni modo, il fatto che Coffee produca lo stesso tipo di codice "pulito" è una buona cosa . Vorrei che anche ogni framework lato server producesse markup HTML5 e CSS3 validi!

   Detto questo, non direi che CoffeeScript fa risparmiare molto tempo inserendo varparole chiave per me. I messaggi mancanti varvengono rilevati facilmente da JSLint e sono facilmente risolvibili. Inoltre, una volta corretto da qualche tempo, inizi a scrivere comunque bene JavaScript automaticamente. Quindi non direi che il caffè sia davvero così utile in questo senso.

Abbiamo valutato CoffeeScript per circa una settimana. Tutti i membri del team scrivevano codice e condividevamo le nostre esperienze. Abbiamo scritto un nuovo codice con esso e portato un codice esistente quando lo abbiamo ritenuto opportuno. I nostri sentimenti sulla lingua erano misti.

In generale, direi che non ha accelerato il nostro sviluppo, ma non ci ha nemmeno rallentato. Alcuni aumenti di velocità dovuti alla minore digitazione e alla minore superficie di errore sono stati compensati dai rallentamenti in altre aree, principalmente il supporto degli utensili. Dopo una settimana abbiamo deciso di non imporre l'uso di CoffeeScript ma non lo vieteremo nemmeno . Data una libera scelta, in pratica nessuno la usa, almeno per ora. Di tanto in tanto penso di prototipare alcune nuove funzionalità al suo interno e quindi convertire il codice in JavaScript prima di integrarmi con il resto del progetto per iniziare più velocemente, ma non ho ancora provato questo approccio.

Professionisti

visualizza la risposta di Trevor Burnham .

Inoltre, puoi pensare a te stesso come a un ragazzo alla moda, che sta facendo cose alla moda, invece di fare casino con la sporcizia di JavaScript.

Contro

CoffeeScript non è altro che zucchero sintetico e bicchieri rosa.

Per cose semplici - CoffeeScript è ridondante, perché fare cose semplici è facile in qualsiasi lingua. E jQuery è probabilmente anche più semplice di CoffeeScript.

Per cose difficili - devi capire il tuo mezzo. E il tuo mezzo è HTML, DOM e CSS, Javascript è solo uno strumento per interconnetterli, tuttavia - tutte le API sono scritte appositamente per Javascript. L'uso di un altro linguaggio, che verrebbe quindi compilato in uno "reale", è piuttosto rischioso, sia esso Java (GWT), Dart o CoffeeScript.

Anti-schemi o banale ignoranza delle regole del linguaggio, possono essere risolti leggendo uno o due buoni libri. E sono abbastanza sicuro che Coffeescript abbia i suoi anti-schemi.

Il supporto IDE per Coffeescript è persino peggio che per JS.

Il più grande professionista, nella mia mente è:

La semplice caffettiera si compila nel javascript che avresti dovuto scrivere, ma non l'hai fatto, perché non era semplice.

Ci sono alcuni cattivi angoli di javascript che vengono evitati solo con cautela - esempi dalla parte superiore della mia testa:

• impostare correttamente il prototipo
• usando === invece di ==
• verifica null
• dichiarando tutte le variabili con var
• avvolgendo tutto in una funzione anonima autoeseguente.

Se scrivi un coffeescript, tutti questi vengono gestiti automaticamente per te .

I contro sono, IMO, principalmente minori:

• Il debug è un dolore
• Ci sono meno programmatori di caffè
• Devi tradurre la documentazione da JavaScript in coffeescript.

professionisti

1. CoffeeScript mi ​​ha aiutato a saperne di più su JavaScript
2. è abbastanza facile da leggere, anche per callback complessi nidificati
3. fornisce sicurezza su alcuni dei problemi di javascript difficili da rintracciare la lingua

Il precedente esempio di Andrew che ho trovato illuminante. Credo che la leggibilità dei loro rendimenti letterali di oggetti esistenti sarebbe migliorata semplicemente identificando manualmente il ritorno

ritorno

// oggetto letterale qui

Gli strumenti IDE sono stati migliorati, TextMate e Cloud9 supportano CoffeeScript. È vero che il supporto di Windows è in ritardo (non è vero per lo sviluppo web in generale?)

cons

CoffeeScript interpretato dal browser può essere difficile da eseguire il debug.

È un livello aggiuntivo in aggiunta a JavaScript che richiede una certa comprensione e considerazione da parte degli sviluppatori.

professionisti

1. hanno davvero ottimizzato i casi comuni in modo sintetico, infatti, CoffeeScript è uno dei, se non il linguaggio più conciso che viene "comunemente" usato http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked- by-espressività /
2. nasconde le parti difettose di JavaScript (coercizione automatica ==, globalità implicite, un sistema di classe più tradizionale semplifica le cose comuni)
3. estremamente facile da imparare per i programmatori Python / Ruby
4. funzioni anonime multilinea + sintassi degli spazi bianchi

cons

1. la rimozione di var significa che non è possibile modificare una variabile di ambito esterno all'interno di un ambito interno senza usare un oggetto, oppure `var fall_back_to_js;` hacks [why not another task statement ': =' che riassegna solo un valore così obj.naem: = 5 errori di battitura più facili da eseguire il debug]
2. devi far sapere a tutti gli strumenti, a meno che tu non voglia eseguire il debug di JavaScript :(; btw: puoi eseguire il debug di CoffeeScript da Chrome aggiungendo il supporto per le mappe di origine; yeoman (npm install yeoman) può aiutarti a scrivere un file di configurazione gulp o grunt per CoffeeScript
3. nessuna tipizzazione statica opzionale (devo aspettare il prossimo standard EcmaScript)
4. servono ancora librerie di terze parti per un sistema di moduli
5. trappole di sintassi di cui prestare attenzione: ritorni impliciti, abgo significa a (b (g (o))) , fp, b: 2, c: 8 significa f (p, {b: 2, c: 8}) anziché f (p, {b: 2}, {c: 8})
6. non modifica il numero / tipo JavaScript non funzionante