Wie allgemein bekannt ist, ist JavaScript ein janusköpfiges Biest mit einer Syntax, die es (wie auch seinen Namen) seinerzeit nur bekommen hat, weil damals alles als cool galt, was bloß entfernt an Java erinnerte. Wie sähe JavaScript aus wenn es heute erfunden würde? Vielleicht wie CoffeeScript. CoffeeScript ist eine kleine Sprache mit entrümpelter Syntax, die zu sauberem JS-Code ohne all die bad parts
kompiliert. Beispiel:
# Grupen bei der Fußball-WM, sortiert nach Platzierung in der Vorrunde gruppen: { a: ["Uruguay", "Mexiko", "Südafrika", "Frankreich"] b: ["Argentinien", "Südkorea", "Griechenland", "Nigeria"] c: ["USA", "England", "Slowenien", "Algerien"] d: ["Deutschland", "Ghana", "Australien", "Serbien"] } # Die Platzierungen in einer Gruppe ermitteln ermittle_gruppensieger: (gruppe) -> gruppensieger: gruppenzweiter: teilnehmer: "Unbekannt" ergebnis: (erster, zweiter, rest...) -> gruppensieger: erster gruppenzweiter: zweiter teilnehmer: rest ergebnis gruppen[gruppe]... alert "Gruppensieger wurde " + gruppensieger + " vor " + gruppenzweiter + ". Außerdem in der Gruppe: " + teilnehmer # Wer ist in Gruppe D weitergekommen? ermittle_gruppensieger('d')
Wird zu:
var ermittle_gruppensieger, gruppen;
var __slice = Array.prototype.slice;
gruppen = {
a: ["Uruguay", "Mexiko", "Südafrika", "Frankreich"],
b: ["Argentinien", "Südkorea", "Griechenland", "Nigeria"],
c: ["USA", "England", "Slowenien", "Algerien"],
d: ["Deutschland", "Ghana", "Australien", "Serbien"]
};
ermittle_gruppensieger = function(gruppe) {
var ergebnis, gruppensieger, gruppenzweiter, teilnehmer;
gruppensieger = (gruppenzweiter = (teilnehmer = "Unbekannt"));
ergebnis = function(erster, zweiter) {
var rest;
var _a = arguments.length, _b = _a >= 3;
rest = __slice.call(arguments, 2, _a - 0);
gruppensieger = erster;
gruppenzweiter = zweiter;
teilnehmer = rest;
return teilnehmer;
};
ergebnis.apply(this, gruppen[gruppe]);
return alert("Gruppensieger wurde " + gruppensieger + " vor " + gruppenzweiter + ". Außerdem in der Gruppe: " + teilnehmer);
};
ermittle_gruppensieger('d');
Sieht gut aus, oder? Wer mehr wissen möchte kann sich die neueste Episode von The Changelog reinziehen, in der CoffeeScript-Erfinder Jeremy Ashkenas interviewt wird oder sich in den folgenden nur 30 Minuten langen Talk ansehen. Hierin erklärt und demonstriert Ashkenas alles, was es zu CoffeeScript zu wissen gibt:
CoffeeScript demonstriert genau die Einstellung, die man haben muss: Wenn die Browser es so schwer haben, den Müll, den sie in sich tragen, loszuwerden, muss man als Entwickler halt selbst ran.
Kommentare (14)
Herr Gabriel ¶
27. Juli 2010, 05:29 Uhr
Linkfail.
Peter ¶
27. Juli 2010, 06:55 Uhr
Ist gefixt, danke für den Hinweis!
Struppi ¶
27. Juli 2010, 07:37 Uhr
Das Codebeispiel ist 100% Javascript (wenn man die entities umwandelt) oder wo soll der Unterschied in der Syntax sein?
Struppi ¶
27. Juli 2010, 07:42 Uhr
OK, jetzt hab ich's verstanden.
Marcel ¶
27. Juli 2010, 13:11 Uhr
Man(n) / Frau lernt nie aus :D
Marco Laspe ¶
27. Juli 2010, 19:14 Uhr
Wie sieht es denn mit euren Erfahrungen aus? Kann CoffeeScript, JS wirklich ersetzten in der täglichen Arbeit?
Peter ¶
28. Juli 2010, 06:50 Uhr
Praktische Erfahrung habe ich persönlich noch keine. Es scrollte aber an mir vorbei, dass es der Eine oder Andere schon produktiv einsetzt. Offizielle Linie ist aber, dass es noch nicht stable sein soll. Also kurz gesagt: Man weiß es nicht :)
André ¶
28. Juli 2010, 19:07 Uhr
Wenn ich nur wüsste, wofür der Compiler die Variable _b deklariert hat. Weiß CoffeeScript da mehr als ich? Oder muss man doch JavaScript beherrschen, um wirklich sicher sein zu können, das am Ende alles funktioniert? Wenn man es hinterher sowieso kontrollieren muss – und das sollte man tunlichst –, wozu dann der Umweg über CoffeeScript?
Und die Syntax von dem Dingens ist ja gruslig.
Peter ¶
29. Juli 2010, 12:38 Uhr
Zitat André:
Die Unterstrich-Vars sind temporäre Variablen, sowas wie
i
in For-Schleifen.Warum schaust du nicht einfach am Ende, ob dein Programm das macht, was es soll?
Was ist daran gruselig? Flexibler und Kompakter = Win!
Robert Agthe ¶
30. Juli 2010, 11:50 Uhr
Ich habe da irgendwie immer Probleme damit Pseudo Syntax zu lernen (ähnlich wie bei Turbine). Da man nie genau weiss, was passiert mit dem Compiler in 2 Jahren und was fang ich dann mit meinem Wissen dann an das ich evtl. nicht 100% mit nach Javascript oder in die jeweilige Source Sprache nehmen kann. Dann muss man noch mit Compiler Fehlern dealen und äh ja muss das eben noch durch Compiler schleussen usw. usw.
An sich finde ich so ne Idee cool, aber dann doch lieber gleich die Zeit nutzen un lernen sauberen JS Code zu schreiben. Halte ich für Sinnvoller.
Peter ¶
30. Juli 2010, 21:44 Uhr
Weißt du, ich hab hier ein Buch im Regal stehen, das heißt „Coders at Work“. Darin werden laute bekannte und berühmte Programmier-Gurus interviewt. Die ganz alten Recken sagen darin genau das gleiche über C, Java u.Ä. und den Assemblercode den die Compiler ausspucken, wie heute über CoffeeScript, Sass, Turbine etc gesprochen wird. Alle Kritiker haben auch sicher mit dem was sie von sich geben in der Sache nicht ganz unrecht, nur sind die vorgetragenen Probleme oftmals einfach nicht relevant, weil mit den kleinen Nachteilen und Risiken große Produktivitätsvorteile einhergehen. Und auf Produktivität kommt‘s nun mal an.
Außerdem, was ist „Pseudo-Syntax“?
Robert Agthe ¶
30. Juli 2010, 22:03 Uhr
Ja ich denke in gewissen Projekten kann das durchaus Sinn machen. Muss man abschätzen halt nä.
Mit Pseudo Syntax mein ich Syntax die zur Generierung von Syntax der selben Sprache dient. Weiss nicht obs der passende Begriff ist, aber war auch nicht abwertend gemeint.
André ¶
3. August 2010, 21:43 Uhr
Zitat Peter:
zu 1: Schon, aber _b wird nirgends gebraucht. _b wird mit einem Wert gesetzt, der aber nie abgefragt wird. Also ist _b überflüssig.
zu 2: Und wenn es nicht tut, was es soll, wo suche ich dann nach dem Fehler? Im CoffeeScript oder im daraus erzeugten JavaScript? Wenn ich Pech habe – also im sprichwörtlichen "worst case" – in beidem. Denn erfahrungsgemäß steigt die Wahrscheinlichkeit von Konvertierungsfehlern mit der Komplexität des Ausgangsmaterials – und das überflüssige _b ist ein ganz typisches Symptom dafür.
Wenn ich nun ein Programm schreibe, welches schon von sich aus, also durch seine Aufgabenstellung, komplex ist, dann tue ich gut daran, mir nicht noch zusätzliche Komplexität inform eines Konverters einzuhandeln. Die JavaScript-Engines sind schon komplex genug, was man auch daran sehen kann, dass es praktisch keine fehlerfreie JavaScript-Engine gibt. Wenn also eine Konverter-Engine die Komplexität der Ziel-Engine komplett abdecken soll, muss sie mindestens genauso komplex sein – und damit ebenso fehlerbehaftet. Es ist nun leider so, dass sich mit jedem hinzukommenden Fehler die Zahl der Kombinationsmöglichkeiten aller Fehler verdoppelt, d. h., die "Macken" des Endproduktes steigen schlimmstenfalls exponentiell. Man denke auch an Occam's razor.
zu 3: Naja, was heißt kompakter. Dass der JavaScript-Code etwas länglicher ist als der CoffeeScript-Code, weil da – flexibel, wie wir sind – eine unnütze Variable namens _b hineinfantasiert wurde, dafür kann ja JavaScript nichts. Aber im Ernst: Flexibler und kompakter heißt ja nicht unbedingt, dass es auch einfacher ist. Wenn ein kompliziertes Problem zu lösen ist, dann ist es irrelevant, ob ich dafür ein oder zwei Zeilen mehr oder weniger eintippen muss, denn die Hauptarbeit muss in die "abstrakte" Problemlösung gesteckt werden. Wenn ich nicht in der Lage bin, das Problem in JavaScript zu lösen, dann bin ich auch nicht in der Lage, es in CoffeeScript zu lösen. Wenn ich es aber in CoffeeScript lösen kann, kann ich's auch in JavaScript lösen. Denn merke: CoffeeScript kann – das liegt nunmal in der Natur eines Konverters – nicht mehr als JavaScript, sondern allerhöchstens genau dasselbe. Und dann ist die Frage: wozu brauche ich einen blauen Schraubenzieher, wenn ich den gleichen schon in grün habe?
Johann Philipp Strathausen ¶
23. Januar 2011, 18:05 Uhr
Die wirklichen Vorteile von CoffeeScript erschließen sich erst nach einigem Studium aus den Beispielen der CoffeeScript-Website selbst.
Und klar: CoffeeScript ist nur etwas für JavaScript-Profis! Denn zum Debuggen sollte man schon sehr genau wissen, was CoffeeScript da macht. Ich persönlich schreibe meine JavaScript-Projekte inzwischen sehr gern ohne die vielen Klammern und das nervige Semikolon am Zeilenende, ganz zu schweigen von CoffeScripts list comprehensions. So kann ich mich auf das wesentliche konzentrieren.
Sicher ist CoffeScript Geschmackssache. Ich persönlich mag eben Python und Haskell mehr als Java oder PHP :-)