it-swarm.dev

Was sind die Vor- und Nachteile von Coffeescript?

Ein großer Vorteil ist natürlich die Menge an syntaktischem Zucker, die in vielen Fällen zu kürzerem Code führt. Auf http://jashkenas.github.com/coffee-script/ gibt es beeindruckende Beispiele. Andererseits habe ich Zweifel, dass diese Beispiele Code komplexer Anwendungen in der realen Welt darstellen. In meinem Code füge ich beispielsweise niemals Funktionen zu bloßen Objekten hinzu, sondern zu deren Prototypen. Darüber hinaus ist die Prototypfunktion vor dem Benutzer verborgen, was eher auf klassisches OOP als auf idiomatisches Javascript hindeutet).

Das Beispiel für das Array-Verständnis würde in meinem Code wahrscheinlich so aussehen:

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

Ich bin der Autor eines bevorstehenden Buches über CoffeeScript:
http://pragprog.com/titles/tbcoffee/coffeescript

Ich war überzeugt, dass es sich nach etwa einer Woche Spielzeit lohnt, CoffeeScript zu verwenden, obwohl die Sprache zu diesem Zeitpunkt erst einige Monate alt war und viel mehr Ecken und Kanten aufwies als jetzt. Auf der offiziellen Website werden (die meisten) Funktionen der Sprache hervorragend aufgelistet, daher werde ich diese hier nicht wiederholen. Ich sage nur, dass die Profis der Sprache sind:

  1. Ermutigt zur Verwendung guter JavaScript-Muster
  2. Entmutigt JavaScript-Anti-Patterns
  3. Macht selbst guten JavaScript-Code kürzer und lesbarer

Nr. 3 bekommt viel mehr Aufmerksamkeit als die ersten beiden (sogar in meinem Buch), aber je mehr ich darüber nachdenke, desto mehr wird mir klar, dass ich den Sprung nicht nur wegen der hübschen Syntax gemacht habe; Ich habe den Sprung gemacht, weil mich die Sprache zu besserem, weniger fehleranfälligem JavaScript getrieben hat. Um einige kurze Beispiele zu nennen:

  • Da Variablen einen automatischen Gültigkeitsbereich haben, können Sie Globals nicht versehentlich überschreiben, indem Sie var weglassen, eine Variable mit demselben Namen (außer mit benannten Argumenten) beschatten oder Variablen in verschiedenen Dateien haben, die interagieren (siehe https://stackoverflow.com/questions/5211638/pattern-for-coffeescript-modules/5212449 ).
  • Da -> Viel einfacher zu schreiben ist als function(){}, ist es einfacher, Rückrufe zu verwenden. Die semantische Einrückung macht deutlich, wann Rückrufe verschachtelt sind. Und => Erleichtert es, this bei Bedarf beizubehalten.
  • Da unless x Für Englischsprachige einfacher zu analysieren ist als if (!x) und if x? Einfacher als if (x != null), um nur zwei Beispiele zu nennen, können Sie Geld ausgeben weniger Gehirnzyklen in Bezug auf die Logiksyntax und mehr in Bezug auf die Logik selbst.

Eine großartige Bibliothek wie nderscore.js kann einige dieser Probleme lösen, aber nicht alle.

Nun zu den Nachteilen:

  1. Zusammenstellung kann ein Schmerz sein. Die Syntaxfehler, die der CoffeeScript-Compiler auslöst, sind häufig vage. Ich gehe davon aus, dass auf diesem Weg in Zukunft Fortschritte erzielt werden. (Zur Verteidigung des Compilers werden häufig Dinge abgefangen, die - wenn Sie sie in JavaScript geschrieben haben - erst dann als Fehler erkannt werden, wenn diese Codezeile ausgeführt wird. Es ist besser, diese Fehler früher als später abzufangen.)
  2. In ähnlicher Weise kann das Debuggen ein Schmerz sein. Es gibt noch keine Möglichkeit, kompilierte JS-Zeilen mit dem ursprünglichen CoffeeScript abzugleichen (obwohl die Firefox-Leute versprochen haben, dass dies kommen wird).
  3. Es ist anfällig für Veränderungen. Ihr Code wird unter einer zukünftigen Version von CoffeeScript möglicherweise anders oder gar nicht ausgeführt. Dies ist natürlich bei den meisten Sprachen der Fall - bei einer neuen Version von Ruby oder Python ist ähnlich) - ist dies bei JavaScript jedoch nicht der Fall Sie können davon ausgehen, dass Code, der heute in allen gängigen Browsern einwandfrei funktioniert, in gängigen Browsern einwandfrei funktioniert, solange das Web, wie wir es kennen, vorhanden ist.
  4. Es ist nicht so bekannt. JavaScript ist eine Verkehrssprache . CoffeeScript ist in kurzer Zeit sehr beliebt geworden, aber es ist unwahrscheinlich, dass es jemals eine so große Community wie JavaScript genießen wird.

Natürlich denke ich, dass die Vorteile für mich persönlich die Nachteile überwiegen, aber das wird nicht für jede Person, jedes Team oder jedes Projekt der Fall sein. (Sogar Jeremy Ashkenas schreibt viel JavaScript.) CoffeeScript wird am besten als gute Ergänzung zu JavaScript angesehen, nicht als Ersatz.

54
Trevor Burnham

Wir haben eine ziemlich große JavaScript-Codebasis und vor ungefähr einem Monat haben wir uns entschlossen, CoffeeScript auszuprobieren. Einer unserer Entwickler begann mit der Migration eines unserer Module von JS nach CS mit http://js2coffee.org/ . Dieses Tool war ziemlich praktisch und es dauerte ungefähr zwei oder drei Stunden, um 1000 Zeilen JavaScript zu portieren. Einige Beobachtungen, die wir zu diesem Zeitpunkt bemerkt haben:

  1. Der resultierende CoffeeScript-Code war gut lesbar.

  2. Wir haben es wieder in JavaScript kompiliert und es war ziemlich einfach zu navigieren und zu debuggen. Während wir dieses Modul portierten, fand ein anderer Entwickler aus unserem Team einen Fehler darin. Diese beiden Entwickler haben diesen Fehler in unserem alten JavaScript-Code und im neuen JavaScript-Code behoben, der aus dem CS-Compiler stammt. Sie arbeiteten unabhängig und brauchten ungefähr die gleiche Zeit (15-20 Minuten).

  3. Aufgrund der Tatsache, dass es sich um einen Port handelte, verwendete der resultierende Code keine kaffeespezifischen Funktionen, die angemessen oder wünschenswert waren. Wenn wir von Grund auf in CoffeeScript schreiben würden, wäre der Code idiomatischer. Aus diesem Grund haben wir später beschlossen, den vorhandenen Code nicht zu portieren.

  4. Im Allgemeinen ist die Lesbarkeit der kürzeren Funktion und des kleineren Objekts teilweise erhöht. Bei längeren Methoden war dies jedoch überhaupt nicht der Fall. Die größten Einsparungen beim Aufblähen kamen von -> Und explizit return, aber ansonsten war unser Code nicht wesentlich kürzer oder einfacher geworden. Einige Syntaxelemente schienen ziemlich verwirrend, insbesondere Objektliterale. CS lässt geschweifte Klammern um Elementdefinitionen weg und kombiniert mit "alles ist ein Ausdruck" und implizitem return, was einige Codebits ziemlich schwer lesbar machte.

    Hier ist 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
    }
    

    Und so würde der entsprechende CoffeeScript-Code aussehen:

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

    Da es jetzt ziemlich schwierig ist herauszufinden, dass die return-Anweisung in der Zeile (*) Beginnt. In unserem Projekt verlassen wir uns stark auf Objektliterale: Wir übergeben sie als Funktionsparameter und geben sie von anderen Funktionen zurück. In vielen Fällen sind diese Objekte recht komplex: mit Mitgliedern verschiedener Typen und mehreren Verschachtelungsebenen. In unserem Fall war das allgemeine Gefühl, dass CoffeeScript-Code tatsächlich schwerer zu lesen war als einfacher JavaScript-Code.

  5. Obwohl sich das Debuggen von CoffeeScript als einfacher herausstellte als erwartet, hat sich die Bearbeitungserfahrung erheblich verschlechtert. Wir konnten keinen guten Editor/IDE für diese Sprache finden. Wir haben Editor/IDE für clientseitigen Code für unser Projekt nicht standardisiert, und tatsächlich verwenden wir alle unterschiedliche Tools. Tatsächlich sind sich alle in einem Team einig, dass sie beim Wechsel zu CoffeeScript eine eher schlechte Unterstützung von ihrem Tool erhalten. IDE und Editor-Plugins sind in einem sehr frühen Zustand und können uns in einigen Fällen nicht einmal eine angemessene Syntaxhervorhebung oder Einrückungsunterstützung bieten. Wir sprechen nicht über Codefragmente oder Refactoring. Wir verwenden WebStorm, Eclipse , NetBeans, VisualStudio, Notepad ++ und SublimeText2.

  6. In Bezug auf Tools sollte ich erwähnen, dass der CoffeScript-Compiler selbst als Node JS-Paket) geliefert wird. Wir sind in erster Linie ein Java/.NET-Shop, daher entwickeln sich alle auf Windows-Boxen. Bis vor kurzem war die Windows-Unterstützung fast nicht verfügbar -existent in Node. Wir konnten den CoffeeScript-Compiler unter Windows nicht zum Laufen bringen, daher haben wir uns vorerst entschieden, bei <script type="text/coffeescript"> -Tags und browserbasiertem On-the-Fly-Compiler zu bleiben.

    Der Compiler ist ziemlich schnell und verlängert die Startzeit nicht wesentlich. Der Nachteil ist, dass das resultierende JavaScript evaled wird und es ein wenig schwierig ist, Haltepunkte in den Entwicklertools der Browser (insbesondere in IE8) einzufügen. Wenn wir Schwierigkeiten beim Debuggen haben, kompilieren wir CoffeeScript-Code mit demselben Migrationstool vor, das ich oben aufgeführt habe, aber das ist immer noch nicht sehr praktisch.

  7. Andere Versprechen von CoffeeScript wie das automatische Einfügen von var oder die halbtransparente Verwaltung von this mit dem Fettpfeiloperator (=>) Haben nicht so viel Gewinn gebracht, wie wir gehofft hatten. Wir verwenden JSLint bereits als Teil unseres Erstellungsprozesses und schreiben Code in die Teilmenge ES3 x ES5-Strict Der Sprache. Wie auch immer, die Tatsache, dass Kaffee dieselbe Art von "sauberem" Code erzeugt, ist eine gute Sache . Ich wünschte, jedes serverseitige Framework würde auch gültiges HTML5- und CSS3-Markup erzeugen!

    Das heißt, ich würde nicht sagen, dass CoffeeScript viel Zeit spart, indem ich var Schlüsselwörter für mich setze. Fehlende vars werden von JSLint leicht abgefangen und können leicht repariert werden. Darüber hinaus beginnen Sie, sobald Sie einige Zeit damit korrigiert wurden, automatisch automatisch gutes JavaScript zu schreiben. Daher würde ich nicht sagen, dass Kaffee wirklich so hilfreich ist in dieser Hinsicht.

Wir haben CoffeeScript ungefähr eine Woche lang evaluiert. Alle Teammitglieder haben Code darin geschrieben und wir haben unsere Erfahrungen miteinander geteilt. Wir haben neuen Code damit geschrieben und vorhandenen Code portiert, wenn wir es für richtig hielten. Unsere Gefühle gegenüber der Sprache waren gemischt.

Im Allgemeinen würde ich sagen, dass es unsere Entwicklung nicht beschleunigt hat, aber es hat uns auch nicht verlangsamt. Einige Geschwindigkeitsgewinne aufgrund weniger Eingabe und weniger Fehleroberfläche wurden durch Verlangsamungen in anderen Bereichen ausgeglichen, hauptsächlich durch Werkzeugunterstützung. Nach einer Woche haben wir beschlossen, die Verwendung von CoffeeScript nicht zu beauftragen, aber wir werden es auch nicht verbieten . Bei freier Wahl wird sie in der Praxis zumindest vorerst von niemandem verwendet. Von Zeit zu Zeit denke ich darüber nach, einige neue Funktionen darin zu prototypisieren und dann Konvertieren Sie den Code in JavaScript, bevor Sie ihn in den Rest des Projekts integrieren, um einen schnelleren Start zu erzielen, aber ich habe diesen Ansatz noch nicht ausprobiert.

Vorteile

ansicht Trevor Burnhams Antwort .

außerdem können Sie sich als einen hippen Kerl vorstellen, der trendige Sachen macht, anstatt sich mit dem Dreck von Javascript herumzuschlagen.

Nachteile

CoffeeScript ist nichts anderes als syntaktischer Zucker und rosa Gläser.

Für einfache Dinge - CoffeeScript ist überflüssig, da einfache Dinge in jeder Sprache einfach sind. Und jQuery ist wahrscheinlich noch einfacher als CoffeeScript.

Für harte Sachen - Sie müssen Ihr Medium verstehen. Und Ihr Medium ist HTML, DOM und CSS. Javascript ist lediglich ein Werkzeug, um sie miteinander zu verbinden. Alle APIs wurden speziell für Javascript geschrieben. Die Verwendung einer anderen Sprache, die dann zu einer "echten" Sprache kompiliert wird, ist ziemlich riskant, sei es Java (GWT), Dart oder CoffeeScript.

Anti-Muster oder banale Unkenntnis der Sprachregeln können durch das Lesen von ein bis zwei guten Büchern behoben werden. Und ich bin mir ziemlich sicher, dass Coffeescript seine eigenen Anti-Patterns hat.

Die IDE-Unterstützung für Coffeescript ist noch schlechter als für JS.

11
c69

Der größte Profi ist meiner Meinung nach:

Einfaches Coffescript wird in das Javascript kompiliert, das Sie hätten schreiben sollen , aber nicht, weil es nicht einfach war.

Es gibt einige böse Ecken von Javascript, die nur mit Wachsamkeit vermieden werden können - Beispiele aus meinem Kopf:

  • stellen Sie den Prototyp richtig ein
  • verwenden von === anstelle von ==
  • auf null prüfen
  • deklarieren aller Variablen mit var
  • alles in eine selbstausführende anonyme Funktion einwickeln.

Wenn Sie Coffeescript schreiben, werden alle diese für Sie erledigt automatisch.

Die Nachteile sind, IMO, meist gering:

  • Debuggen ist ein Schmerz
  • Es gibt weniger Coffeescript-Programmierer
  • Sie müssen die Dokumentation von Javascript in Coffeescript übersetzen.
7
Sean McMillan

profis

  1. CoffeeScript hat mir geholfen, mehr über JavaScript zu erfahren
  2. ist ziemlich einfach zu lesen, selbst für komplexe verschachtelte Rückrufe
  3. bietet Sicherheit bei einigen schwer zu findenden Sprachproblemen von Javascript

Das obige Arbeitsbeispiel von Andrew fand ich aufschlussreich. Ich glaube, die Lesbarkeit der vorhandenen Objektliteral-Rückgaben würde verbessert, indem die Rückgabe einfach manuell identifiziert wird

rückkehr

// Objektliteral hier

Die IDE Tools wurden verbessert, TextMate und Cloud9 unterstützen CoffeeScript. Zugegebenermaßen ist die Windows-Unterstützung zurückgeblieben (gilt das nicht für die Webentwicklung im Allgemeinen?)

nachteile

Browser-interpretiertes CoffeeScript kann schwierig zu debuggen sein.

Es ist eine zusätzliche Ebene über JavaScript, die ein gewisses Verständnis und Überlegungen der Entwickler erfordert.

3
user38265

profis

  1. sie haben die gängigen Fälle wirklich syntaktisch optimiert. Tatsächlich ist CoffeeScript eine der prägnantesten Sprachen, die "häufig" verwendet wird http://redmonk.com/dberkholz/2013/03/25/programming-). Sprachen nach Ausdruckskraft geordnet /
  2. verbirgt die schlechten Teile von JavaScript (Auto-Zwang ==, implizite Globale, traditionelleres Klassensystem erleichtert allgemeine Dinge)
  3. für Python/Ruby-Programmierer extrem einfach zu erlernen
  4. mehrzeilige anonyme Funktionen + Whitespace-Syntax

nachteile

  1. das Entfernen von var bedeutet, dass Sie eine Variable für den äußeren Bereich innerhalb eines inneren Bereichs nicht ändern können, ohne ein Objekt zu verwenden, oder `var fall_back_to_js;` hacks [why keine andere Zuweisungsanweisung ': =', die nur einen Wert neu zuweist, so dass obj.naem: = 5 Tippfehler leichter zu debuggen sind]
  2. sie müssen jedes Tool darüber informieren, es sei denn, Sie möchten JavaScript debuggen :(; Übrigens: Sie können CoffeeScript von Chrome durch Debuggen von Unterstützung für Quellkarten debuggen; yeoman (npm install yeoman) kann helfen Sie schreiben eine Gulp- oder Grunz-Konfigurationsdatei für CoffeeScript
  3. keine optionale statische Eingabe (muss auf den nächsten EcmaScript-Standard warten)
  4. benötigen weiterhin Bibliotheken von Drittanbietern für ein Modulsystem
  5. syntaxfallen, auf die Sie achten sollten: implizite Rückgaben, abgo bedeutet a (b (g (o))) , fp, b: 2, c: 8 bedeutet eher f (p, {b: 2, c: 8}) als f (p, {b: 2}, {c: 8} )
  6. ändert das kaputte JavaScript-Nummern-/Typsystem nicht
0
aoeu256