Aus Gerüchten wurde Dart – eine Sprache, die JavaScript ersetzen soll

Google Dart – Mitten ins Schwarze?
Kommentare

Seit dieser vollmundigen Ankündigung und der Veröffentlichung des Sourcecodes steht die Blogosphäre nicht mehr still: das soll Dart sein? Es nehme einem die Flexibilität von JavaScript, sagen die einen. Auch nicht besser, irgendwie, sagen die anderen. Ein Streitfall also. Ganz klar.

Vor gut 10 Jahren gehörte zumindest eines zu den grundlegenden Anforderungen einer jeden Webanwendung: Wenn schon JavaScript verwendet wird, dann muss die Anwendung zur Not aber auch ohne laufen. Was ist, wenn der Besucher JavaScript ausgeschaltet hat? Was ist, wenn irgendein kurioser Browser dieses JavaScript doch ganz anders interpretiert als gedacht? Zudem – Geschäftslogik im Browser? Das ist doch manipulierbar! Und überhaupt … dünn müssen die Clients sein. Das beschränkte JavaScript mehr oder weniger auf nette Hover-Effekte.

JavaScript – verteufelt, gehasst, verehrt

JavaScript ist einfach anders als PHP – und zwar richtig anders. PHP erinnert mit seiner Syntax eher an C, später mit seinen Interfaces auch etwas an Java. Jeder PHP-Entwickler, der objektorientiert arbeitet, weiß: Um ein Objekt zu erstellen, man muss eine Klasse schreiben. Objektorientierung gilt auch in der PHP-Welt mittlerweile als Standard. Natürlich gibt es zahlreiche Ausnahmen – Funktionen sind eben gleich gemacht, und überhaupt, das grundlegende API ist auch recht prozedural aufgebaut. Egal, der PHP-Entwickler hat Klassen, und daraus macht er Objekte. So ist das.

Allerdings wurden die Stimmen laut, die auch JavaScript als objektorientierte Sprache bezeichneten. Mehr noch, sie verzichten auf Klassen und arbeiten nur mit Objekten. Prototypbasierte Entwicklung ist angesagt, Klassen sind zu unflexibel. Zur Laufzeit Methoden zu Objekten hinzufügen – das ist einfach viel besser. Gibt es denn mehr Objektorientierung als das? Spätestens, wenn man von Funktionsreferenzen spricht und davon, dass eine Funktion in JavaScript auch schon ein Objekt ist – da hört der Spaß für viele auf.

Aber es gibt noch viel mehr, was der gemeine, klassenschreibende Entwickler im Allgemeinen als Teufelszeug abtut: zum Beispiel das seltsame „Prototype“-Schlüsselwort. Und haben Sie schon mal versucht herauszufinden, wie man mit JavaScript private Member-Variablen erstellt? JavaScript kann erlernt werden. Aber seine Ecken, Kanten und Vorzüge erfordern es, dass man sich wirklich damit beschäftigt. Zumindest wer Frontends schreiben will, die den heutigen Maßstäben gerecht werden, benötigt ein gewisses Pensum an Zeit. Es ist nicht nur eine andere Sprache, es ist auch eine eigene Philosophie. Um die Sprache JavaScript herum hat sich eine hyperagile Community gebildet, für die Typisierung ein Schimpfwort ist und die als Lieblingsserver Node.JS sehen. Oder gleich ganz auf „Server“ verzichten und eine CouchDB mit JavaScript abfragen. Immerhin – sind Server nicht so was von Achtziger? Die Cloud macht’s eben möglich.

Wir stellen fest – es ist nicht leicht, als PHP-Entwickler in die Welt des JavaScriptings vorzudringen. Gerade hat man sich noch an PHP 5 und seine Interfaces gewöhnt – und dann gibt’s das alles einfach nicht in der JavaScript-Welt? Fühlt sich an wie PHP 3, ist aber topmodern.

Die Idee des Herrn Google

Der nette Onkel Google hatte nun die Idee, das Skripten im Browser leichter zu machen. Es gibt zwar mittlerweile viele JavaScriptler, aber der Einstieg ist einfach zu schwer. Und das, obwohl jeder sagt, JavaScript wäre einfach. Zumindest jeder, der es kann. Also hat er sich gedacht: warum nicht das Beste aus verschiedenen Welten? Gerade die Java-Welt hat es ihm dabei besonders angetan, wenn wir ehrlich sind. Wenn man aber genau hinsieht, könnte man auch irgendwie sagen: Wenn Java nicht so auf seine Typen bestehen würde und PHP objektorientierter wäre, dann würde man sich in der Mitte treffen – eine Syntax wie die von Dart wäre die Folge [2]. Also hat Herr Google zunächst wieder Klassen in das Browserskripting eingeführt. Und außerdem gibt es jetzt eine Main-Methode. Das kennt man in der PHP-Welt nicht so unbedingt, aber in der Java-Welt hat das eine Bedeutung: es ist nämlich der Startpunkt eines Java-Programms. Mit PHP wäre es die erste Zeile des aufgerufenen PHP-Skripts, die nicht gerade Klassen oder Funktionen definieren. Und Interfaces gibt es auch – ganz anders als in JavaScript. Und Typisierung. Zumindest so ungefähr, und nur optional. Das erinnert dann schon eher wieder an PHP. Denn auch in PHP kann man optional Typen in die Methodensignatur legen.

Im JavaScript-Lager ist man dagegen aber recht unzufrieden – denn Klassen sind oldschool, die braucht einfach kein Mensch mehr. Ebenso wie Interfaces. Das ist genauso, als würde man seinen MP3 Player wieder mit Modern-Talking-Alben füttern, nur weil sie digital remastert wurden. Oder?

Im Prinzip könnte man sagen, es sieht so aus, als würde Dart die Entwicklung von Web-Frontends im Speziellen für Java- und PHP-Entwickler leichter und verständlicher machen. Das wurde so nie gesagt – aber wenn man sich die Syntax ansieht, dann ist das so. Vor allem, wenn man ein wenig Java spricht, tut man sich recht leicht.

[ header = Seite 2: Status quo ]

Status quo

Leider ist Dart noch nicht im Browser verfügbar – zum Zeitpunkt dieses Artikels noch nicht einmal für Google Chrome. Aber es gibt die Kommandozeile: dart ihrdartscript.dart. Und natürlich gibt es auch den dartc-Compiler. Er kompiliert eigentlich nicht wirklich – er transformiert ihr Dart-Skript in JavaScript. Dummerweise ist die Ausgabedatei etwa 7 MB groß. Damit ist das für den praktischen Einsatz noch untauglich. Etwas weniger dürfte es wirklich sein. Zu guter Letzt ist derzeit auch noch Selberkompilieren angesagt, denn Dart selbst ist nur im Quellcode verfügbar. Auf meinem Blog habe ich unter [2] ein fertig kompiliertes Binary für Mac OS X 10.6.x im Angebot. Aber wer mit OS X und Linux arbeitet, hat es ohnehin noch gut. Für Windows kompiliert sich das Ganze etwas schwerer.

Script Isolation, Skriptausführung

In JavaScript benötigt man einiges an Konsequenz, um den „globalen Namespace“ einigermaßen sauber zu halten. Jedes aufgerufene Script hat auf den gleichen globalen Namespace Zugriff. Wer also eine Variable in Script A.js definiert, hat diese auch in B.js verfügbar. So ist das mit Dart nicht – glücklicherweise. Jede Dart-Datei läuft isoliert von der anderen. Somit kann also jede Dart-Datei eine eigene main()-Methode haben. Allerdings können dann Definitionen von A.dart in B.dart nicht einfach so gelesen werden. Wer es dennoch gerne so hätte, der muss sich mit den Keywords #source oder #import behelfen. Gut ist natürlich, dass jedes Skript eine Art eigenen Thread darstellt. Der weiß nichts von dem anderen, es ist also etwas Vorsicht geboten. Diese so genannten „Isolates“ können aber Ports öffnen und mit anderen Isolates kommunizieren. Dart-Skripte werden damit nebenläufig durchgeführt.

Dart-Skripte können andere Isolates erzeugen. Damit wird eine Art „Multithreaded Programming“ möglich – im Browser wie auch auf der Serverseite; in PHP geht das ja leider nicht. Man könnte also sagen, dass A.php als ein Isolate abläuft. A.php kann aber keine anderen Isolates erzeugen, geschweige denn kann es mit einem anderen Isolate kommunizieren und sich somit synchronisieren. Man stelle sich also vor, A.php könnte einen neuen Serverprozess starten und das Script B.php mit ein paar Parametern auf die Reise schicken. Das kann Dart. Main-Methoden werden in Dart übrigens erst dann aufgerufen, wenn der DOM-Baum komplett geladen wurde. Das ist ein weiterer Unterschied zu JavaScript, das quasi sofort läuft, wenn man sich nicht mühselig mit dem „Dokument-geladen“-Event herumschlägt.

Klassen und Konstruktoren

Wie sieht Dart nun jetzt eigentlich aus? Listing 1 zeigt es. Unsere erste Klasse hat den spektakulären Namen „MyClass“. Darin befindet sich eine Variable namens „value“. Es folgen zwei Konstruktoren, wobei der erste recht leicht erklärt sein dürfte: eine Art „default“-Konstruktor wie in Java. Anders als in (modernem) PHP wird der Konstruktor nach der Klasse benannt. Das hat in älteren PHP-Versionen funktioniert, heute verwendet man bekanntermaßen __construct(). Die print-Anweisung ist selbsterklärend.

Der zweite Konstruktor ist schon etwas gewöhnungsbedürftiger: In einer typenlosen Sprache wie Dart ist Methodenüberladung nicht so einfach zu bewerkstelligen. Die Probleme sind natürlich auch in der PHP-Welt bekannt. Man behilft sich mit __set und Konsorten. In der Java-Welt ist das anders, denn hier können die Methoden alle gleich heißen, auch wenn sie unterschiedliche Parameter annehmen. In Dart hilft man sich hier mit „named Constructors“, benannten Konstruktoren. Diese verhalten sich wie normale Konstruktoren und werden im Prinzip auch so aufgerufen:

new MyClass.woho("test");

Nach der Bezeichnung der Klasse folgt der Name des Konstruktors, dann erst die Parameter. Die Definition, die wir in Listing 1 für den Konstruktor verwendet haben, ermöglicht es übrigens, dass der Parameter sofort der Member-Variable value zugewiesen wird. Das Folgende funktioniert also auch:

MyClass.woho(this.value) {
print(this.value);
}

Wer aber lieber auf eine so schnelle Zuweisung verzichten möchte, kann natürlich auch lokale Variablen verwenden:

MyClass.woho(var value) {
print(this.value);
}

Schon auf den ersten Blick wird klar, dass sich die Dart-Entwickler ganz schön von Java haben inspirieren lassen. Glücklicherweise liegt PHP ja auch nicht so weit daneben.

class MyClass {
var value;

MyClass() {
print ("constructor");
}

MyClass.woho(this.value);
}

main() {
MyClass my = new MyClass.woho("something");
MyClass default = new MyClass();
}

[ header = Seite 3: Typisierung ]

Typisierung

Der JavaScript-Entwicker (und so manch anderer) findet es überflüssig – doch der Java-Entwickler beharrt darauf. Nur wer anständig typisiert, kann große System entwickeln. Wenn wir ehrlich sind, werden PHP-Entwickler von den Kollegen aus der Bytecode-Welt genau aus diesem Grund nicht richtig ernst genommen. In PHP fand einmal der Versuch statt, Typen einzuführen. Meiner Meinung nach nicht recht gelungen [3]. Die Idee war jedoch die gleiche wie in Dart: den Philosophiekonflikt kann man mit optionalen Typen auflösen!

Wer Types benutzt, sollte eines wissen: Das Programm wird auch laufen, wenn falsche Typen verwendet werden. Es wird auch richtig zu JavaScript kompiliert werden. Der Typ in Dart dient laut Google nur dazu, es Menschen einfacher zu machen, den Code zu verstehen. Daher ist der Type Checker eher eine Art „Lint“. Prinzipiell produziert der Type Checker also keine Fehler – nur Warnungen. Code kann dementsprechend auch mit Typfehlern ausgeführt werden. Listing 2 zeigt unser Beispiel mit String-Typen im Sourcecode.

class MyClass {
String value;
MyClass.woho(String value) {
this.value = value;
}
}

main() {
MyClass my = new MyClass.woho("something");
print ( my.value );
}

Wenn Sie dem woho-Konstruktor eine Zahl übergeben und das Programm starten – passiert gar nichts. Aber mit dem Aufruf dart –enable_type_checks myfile.dart meckert Dart wegen inkompatibler Typen. So sollen die Dart-Entwickler ein Werkzeug in die Hand bekommen, das Ihnen hilft, typsicheren Code zu schreiben – aber im Fall der Fälle das Programm nicht zum Absturz zu bringen.

Und das DOM?

Bob Nystrom schrieb in seinem Artikel über DOM-Behandlung, dass es vorher Methoden wie getElementById in JavaScript gab (davon gibt es jede Menge). Dann kam jQuery und hat uns vom hohen Berg verkündet, man soll seine DOM-Knoten mit CSS.Selektoren finden. Und genau das wurde in Dart übernommen. Genau zwei Methoden gibt es, die Elemente selektieren: query undqueryAll. Während also in JavaScript ein HTML anhand seiner ID folgt selektiert wird:

elem.getElementById(‘myDiv’);

Und es in jQuery etwa so aussieht:

$('.#myDiv'); bzw. $().find('#myDiv');

Gibt es in Dart:

elem.query('#myDiv');

Hier wurde also ganz massiv von jQuery entlehnt. Auch Selektionen nach CSS-Klassen oder Elementnamen sind mit der jQuery-Syntax möglich:

elem.queryAll('.myClass .otherClass');

In JavaScript kommt übrigens ein Array zurück, das die Elemente vorhält. In Dart werden Collections geliefert, die dem gewieften Java-Entwickler bereits bekannt sein dürften. Auch der Zugriff auf Attribute und Knoten wurde vereinheitlicht. So liest sich das API insgesamt wesentlich eingängiger und verständlicher.

Was noch?

Es gibt schon so einiges zu berichten über Dart – das Factory Pattern beispielsweise wurde direkt in die Sprache eingebettet. Es sind klare, gut lesbare APIs vorhanden, die bereits die wichtigste Funktionalität ermöglichen. Exceptions sind auch mit an Bord. Und zu guter Letzt unterstützt Dart auch Generics. Die sind in der PHP-Welt unbekannt, sie helfen aber dabei, in Listen (vergleichbar mit PHP-Arrays) oder Maps (vergleichbar mit assoziierten Arrays) nur bestimmte Typen zu akzeptieren. Ach ja – und die mitgelieferte VM kann auf TCP-Ports lauschen. Damit ist dann endlich klar: Dart eignet sich nicht nur als wunderbarer JavaScript- oder PHP-Ersatz – eigentlich könnte man damit auch in der Java-Welt ein wenig aufräumen.

Fazit

Dart ist eine junge Sprache, die noch massiv entwickelt werden muss. Eines ist ganz klar: noch ist sie nicht für den produktiven Einsatz vorgesehen. Das geht auch nicht wirklich – so ohne Browserunterstützung und mit den gewaltigen Mengen an JavaScript-Code, die der Compiler produziert.

Natürlich gibt es einige Kritikpunkte. Warum eine neue VM? Warum nicht JavaScript besser machen? … und einige mehr. Wer sich Dart jedoch ansieht, der merkt, wie smart es ist. Es ist einfach zu schreiben, und wenn irgendwann die Tools und Frameworks verfügbar sind – wow. Dart kann als Server laufen und im Browser; es macht damit den Traum wahr, der mit JavaScript und Node.JS begonnen hat. Auf der anderen Seite ist es lesbar und verständlich, wenn man in der Java-Welt zu Hause ist – aber auch, wenn man sich „nur“ in der PHP-Welt bewegt, ist Dart schnell erlernt. Immerhin fühlt es sich schon ein bisschen wie PHP an; und die Typlosigkeit kennen PHP-Programmierer ja schon recht gut. Dart kann man wie Java aussehen lassen, aber auch wie JavaScript. Jedem das Seine.

Dart kann Träume erfüllen: Endlich eine Sprache, die fast von Anfang an offen und unter Open-Source-Lizenz verfügbar ist. Im Fall von Java ist das ja nicht ganz so – wer die Presse der Kollegen verfolgt, hat sicherlich schon mitbekommen, dass es eine Menge Unmut gerade in Verbindung mit Oracle gab und gibt. Server sind möglich – Client ist möglich. Und Gerüchte sagen, Dart wird wohl auch auf Android eine Rolle spielen. Damit hat es die besten Voraussetzungen, den populären Sprachen ein wenig Feuer unterm Hintern zu machen. Ob es wirklich die Sprache der Zukunft wird, bleibt abzuwarten. Dart wirft immerhin Dinge zusammen, die lange kontrovers diskutiert wurden – wie beispielsweise Typen (oder nicht). Manche gehen sogar so weit und behaupten, Design Patterns wären out.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -