Wir haben eine ziemlich große JavaScript-Codebasis und vor ungefähr einem Monat beschlossen wir, CoffeeScript auszuprobieren. Einer unserer Entwickler begann mit der Migration eines unserer Module von JS zu CS unter 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 an diesem Punkt bemerkt haben:
Der resultierende CoffeeScript-Code war gut lesbar.
Wir haben es wieder in JavaScript kompiliert und es war ziemlich einfach zu navigieren und zu debuggen. Während wir dieses Modul portierten, entdeckte ein anderer Entwickler aus unserem Team einen Fehler darin. Diese beiden Entwickler haben den Fehler in unserem alten JavaScript-Code und im neuen JavaScript-Code, der aus dem CS-Compiler stammt, behoben. Sie arbeiteten unabhängig und es dauerte ungefähr die gleiche Zeit (15-20 Minuten).
Aufgrund der Tatsache, dass es sich um einen Port handelte, verwendete der resultierende Code keine für Kaffee geeigneten oder wünschenswerten Funktionen. 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.
Im Allgemeinen ist die Lesbarkeit der kürzeren Funktion und des kleineren Objekts in gewissem Maße 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, insbesondere Objektliterale, schienen ziemlich verwirrend. CS lässt geschweifte Klammern um Elementdefinitionen weg und kombiniert sie mit "Alles-ist-ein-Ausdruck" und implizit return, was das Lesen einiger Codebits ziemlich schwierig 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 Elementen unterschiedlichen Typs und mehreren Verschachtelungsebenen. In unserem Fall war das allgemeine Gefühl, dass CoffeeScript-Code tatsächlich schwerer zu lesen war als einfacher JavaScript-Code.
Obwohl sich das Debuggen von CoffeeScript als einfacher herausstellte, als wir erwartet hatten, 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 verschiedene Tools. Tatsächlich sind sich alle in einem Team einig, dass ihr Tool bei einem Wechsel zu CoffeeScript einen eher schlechten Support bietet. IDE- und Editor-Plug-ins sind in einem sehr frühen Stadium und können uns in einigen Fällen nicht einmal eine ordnungsgemäße Syntaxhervorhebung oder Einrückungsunterstützung bieten. Ich spreche nicht von Codeausschnitten oder Refactoring. Wir verwenden WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ und SublimeText2.
Apropos Tools Ich sollte erwähnen, dass der CoffeScript-Compiler selbst als Node-JS-Paket geliefert wird. Wir sind in erster Linie ein Java / .NET-Shop, daher entwickeln alle auf Windows-Boxen. Bis vor kurzem gab es in Node kaum Windows-Unterstützung. Der CoffeeScript-Compiler konnte nicht unter Windows ausgeführt werden. Daher entschieden wir uns vorerst, bei <script type="text/coffeescript">Tags und dem browserbasierten 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 bearbeitet wird evalund es etwas schwierig ist, in den Entwicklertools der Browser (insbesondere in IE8) Haltepunkte zu setzen. Wenn wir Probleme mit dem Debuggen haben, kompilieren wir CoffeeScript-Code mit demselben Migrationstool, das ich oben aufgeführt habe, aber das ist immer noch nicht sehr praktisch.
Andere Versprechungen von CoffeeScript wie automatisches varEinfügen oder halbtransparentes Verwalten thismit dem Operator fat arrow ( =>) haben nicht so viel Gewinn gebracht, wie wir gehofft hatten. Wir verwenden JSLint bereits als Teil unseres Erstellungsprozesses und schreiben Code in einer ES3 x ES5-StrictTeilmenge der Sprache. Wie auch immer, die Tatsache, dass Coffee denselben "sauberen" Code produziert, ist eine gute Sache . Ich wünsche mir, dass jedes serverseitige Framework auch gültige HTML5- und CSS3-Markups erzeugt!
Das heißt, ich würde nicht sagen, dass CoffeeScript viel Zeit spart, indem es varmir Keywords hinzufügt. Fehlende vars werden leicht von JSLint abgefangen und können leicht behoben werden. Darüber hinaus schreiben Sie nach einer gewissen Korrektur automatisch gutes JavaScript . So würde ich nicht sagen Kaffee wirklich ist , dass in dieser Hinsicht hilfreich.
Wir haben CoffeeScript etwa eine Woche lang getestet. Alle Teammitglieder schrieben Code darin und wir tauschten unsere Erfahrungen miteinander aus. Wir haben damit einen neuen Code geschrieben und einen vorhandenen Code portiert, wenn wir das für richtig hielten. Unsere Gefühle für die Sprache waren gemischt.
Im Allgemeinen würde ich sagen, dass es unsere Entwicklung nicht beschleunigt hat, aber es hat uns auch nicht gebremst. Einige Geschwindigkeitszuwächse aufgrund von weniger Eingabe und weniger Fehlerfläche wurden durch Verlangsamungen in anderen Bereichen ausgeglichen, hauptsächlich durch die Unterstützung von Werkzeugen. Nach einer Woche haben wir beschlossen, die Verwendung von CoffeeScript nicht zu verbieten, aber auch nicht zu verbieten . Bei einer freien Wahl wird sie in der Praxis zumindest vorerst von niemandem verwendet. Von Zeit zu Zeit denke ich darüber nach, ein neues Feature zu prototypisieren und dann den Code in JavaScript zu konvertieren, bevor ich ihn in den Rest des Projekts integriere, um einen schnelleren Start zu erzielen, aber ich habe diesen Ansatz noch nicht ausprobiert.