Hat Dart das Potenzial, JavaScript zu ersetzen?

Es werde Dart!
Kommentare
Dart [1] ist eine Sprache, die von Goolge erfunden wurde und nun als Open-Source-Projekt öffentlich weiterentwickelt wird. Aufsehen hat es vor allem...

Dart [1] ist eine Sprache, die von Goolge erfunden wurde und nun als Open-Source-Projekt öffentlich weiterentwickelt wird. Aufsehen hat es vor allem erregt, als Google vollmundig erklärte, Dart sei dazu gedacht JavaScript zu ersetzen oder zumindest eine Alternative dazu zu bieten. Doch solche Aussagen sind natürlich kritisch zu betrachten, denn derzeit gibt es nur eine Browsergottheit, und die heißt nun mal JavaScript. Aber ganz von Anfang an: Wo stehen wir denn eigentlich? Derzeit ist Dart nichts weiter als eine „technische Preview“. Nur die waghalsigsten unter uns würden Dart jetzt schon produktiv verwenden. Denn die Sprache wird konstant weiterentwickelt, weswegen sie nicht unbedingt über ein stabiles API verfügt. Ein ganzer Schwarm von kompetenten, jungen Entwicklern kümmert sich darum. Unter ihnen Joshua Bloch und Gilad Bracha. Joshua Bloch ist vor allem in der Java-Welt bekannt, hat er doch so einige Features der Java-Plattform entwickelt und konzipiert. Zudem hat er „Effective Java“ geschrieben, eines der meist zitierten Java-Bücher in der Szene. Jetzt kümmert er sich um das Design des Dart-Kerns, der Core-Lib. Gilad Bracha ist auch so ein Urgestein, auch er hat an der JVM-Spezifikation mitgearbeitet. Zudem zeigt er sich verantwortlich für Newspeak, eine weitere neue Sprache, die an Self und Smalltalk erinnert. Diese beiden bringen also schon eine Menge Erfahrung mit. Aber auch die anderen Teammitglieder glänzen durch ähnliche Verdienste. Fast scheint es, als hätte Google jeden Entwickler, der mal eine anständige Sprache designt hat, unter Vertrag genommen. Es ist schwer, so ein Team zu ignorieren.

Was bietet uns dieses Team?

Derzeit ist eine VM erhältlich, die serverseitiges Dart möglich macht. Zudem gibt es natürlich die Bibliotheken, mit denen man DOM manipulieren kann und somit fancy Features im Browser erzeugt. Und weil wir gerade vom Browser sprechen: Es gibt bereits Dartium, ein Browser-Branch von Chrome, der natives Dart unterstützt. Und natürlich einen Compiler, der aus Dart JavaScript erzeugt sowie einen Eclipse-basierten Editor, der das Arbeiten mit Dart leichter macht, jedenfalls manchmal, denn hier fehlen noch so einige Dinge. Es ist zu erwarten, dass sich alles erwähnte ständig ändert: Joshua Bloch übernimmt gerade das Redesign des Kern-API und natürlich ist der Editor noch lange nicht wirklich in der Praxis einsetzbar, auch wenn es manchmal schon ganz gut klappt. Es fehlt insgesamt noch recht viel, wenn es um die Tools geht: Wie packt man Dart-Bibliotheken anständig ein? Wie führt man eigentlich Unit Tests durch? Solchen Fragen begegnet man ständig auf den Mailinglisten, und derzeit gibt es teils nur hochexperimentelle Ansätze als Antworten. Wer also Dart jetzt schon nutzen will, braucht eine gehörige Portion Spieltrieb, dann aber macht es richtig Spaß.

Liebes Dart, was kannst du denn (besser)?

Die Frage ist, warum eigentlich Dart besser sein soll als JavaScript oder überhaupt jede andere Sprache. Denn von einem haben wir doch eigentlich genug, nämlich von neuen Sprachen. Nicht nur, dass jedermann heutzutage eine eigene JVM-Sprache erstellt, sogar das ein oder andere Tool kann sich mit ANTLR und Konsorten ein eigenes Süppchen kochen. Tatsächlich gibt es über diesen Punkt viele Diskussionen, gerade auf den Dart-Mailinglisten. Hin und wieder taucht dort auch ein fieser Troll mit Schaum vor dem Mund auf, der zwischen wüsten Schimpftiraden das Wort „Warum“ fallen lässt. Die Antwort ist nicht ganz einfach. Google ist bekanntermaßen ein JavaScript-Poweruser. Jedoch kam man irgendwann mit JavaScript an die Grenzen: Die Struktur der Sprache ist löchrig und nicht leicht zu verstehen. Und mal ganz ehrlich: Objektiv gesehen hat Google ja auch recht. Die meisten Sprachen sind klassenbasiert und kennen Schlüsselwörter wie private oder protected. JavaScript bricht quasi mit allem, was als Mainstream bezeichnet wird. Prototypbasierte Entwicklung ganz ohne Klassen. Das erfordert eben einiges an Umdenken. Erst wenn man sich einige Zeit intensiv mit JavaScript auseinandergesetzt und diese „neue Art zu denken“ angenommen hat, kommt man zu dem Schluss, dass JavaScript dann doch ganz einfach ist, abgesehen von den bereits eben erwähnten, kleinen Unstimmigkeiten (this != this). Trotzdem, bis man diesen Punkt erreicht hat, an dem man produktiv und sicher mit JavaScript umgehen kann, braucht man einige Zeit. Und sauberes JavaScript zu schreiben, erfordert letztlich dann doch immer eine ganze Menge Selbstdisziplin und innere Ruhe.

Browserunterstützung

Mit Dart kann man Kommandozeilentools entwickeln, aber vor allem ist die Sprache für den Browser gedacht. Wie sieht es also mit der Browserunterstützung aus? Vor dem letztjährigen Weihnachten wurde ein Branch im WebKit-Projekt vorgeschlagen, der eine Multisprachen-Unterstützung anbietet. Das bedeutet Unterstützung für Dart, aber auch andere Sprachen wie Python, die nativ im Browser laufen könnten. Das führte zu heftigen Diskussionen [2] und wird wohl auch weiterhin kontrovers diskutiert werden. Im Chromium-Projekt steht man dem Multisprachen-Patch etwas offener gegenüber, und derzeit gibt es auch schon einen Branch für den Chrome-Browser (Dartium), der (noch nicht ganz stabil) Dart mitsamt seinem neuen Mime-Type unterstützt:

<script type="application/vnd.dart">
  // Dart code
</script>

Eine flächendeckende Verbreitung von nativem Dart ist jedoch noch in weiter Ferne. Allerdings bietet Dart einen Workaround für dieses Problem: Es gibt einen Compiler, der den Dart-Code zu JavaScript transformiert. Die alte Version dieses Compilers war in Java geschrieben und unter dem Namen DartC bekannt. Er erlangte traurige Berühmtheit, als die Öffentlichkeit feststellte, dass ein einfaches „Hello World“ in Dart zu mehreren Megabyte JavaScript transformiert wurde. Glücklicherweise ist der neue Frog-Compiler um einiges effizienter, wenn er auch noch nicht ganz den Kinderschuhen entwachsen ist. Er kompiliert nun akzeptabel große Datenmengen und dürfte somit recht bald das Werkzeug der Wahl sein. Über kurz oder lang wird also der Transcompiler zum Einsatz kommen und nur in einigen wenigen Projekten wird man von nativem Dart profitieren können. Möglicherweise zählt zu diesen Plattformen jedoch bald die Google AppEngine oder auch die Android-Plattform, was dann einer Verbreitung von Dart einen regelrechten Push geben dürfte.

Wer nun mit CoffeeScript ankommt – ja, das ist derzeit so ähnlich. Auch CoffeeScript wird zu JavaScript kompiliert, und das ist auch das erklärte Ziel. Dart soll jedoch in der VM laufen und eben baldmöglichst nicht mehr mit JavaScript verbandelt sein. Auch ist das Model von CoffeeScript ein anderes: Alles (z. B. Klassen) ist dort veränderlich, ganz wie in JavaScript. CoffeeScript ist also eher ein JavaScript mit besserer Syntax. Dart hat dagegen ein anderes Modell, dort sind Klassen beispielsweise nicht veränderlich. Eine interessante jedoch genauso kurze Ausführung zu diesem Thema gibt Google-Entwickler Bob Nystrom [3].

AbgeDARTed

Dart muss derzeit noch selbst kompiliert werden. Es sei denn, man verwendet den Dart-Editor (Abb. 1), den man sich frei herunterladen kann [4]. Das ist derzeit die einfachste Art, mit Dart loszulegen und sei Ihnen wärmstens ans Herz gelegt, wenn Sie keinen Spaß daran haben, mittels gtools, svn und Konsorten ein „frisches Dart“ zu bauen. Der Editor bietet darüber hinaus gleich die zwei wichtigsten Bibliotheken mit an, wenn ein neues Projekt angelegt wird. In neuester Version kann mit dem Editor auch für die Shell entwickelt werden. Vorher musste man Dart auf dem Systempfad haben und konnte mittels dart MyDart.dart die Anwendung starten. Das ist immer noch meine bevorzugte Entwicklungsweise. Der Editor bietet mittlerweile Code Completion und andere Annehmlichkeiten, zum Beispiel dass er die Anwendung im Browser starten kann.

 

Abb. 1: Der Dart-Editor

Main und andere Funktionen

In Dart gibt es, ähnlich wie in Java, eine main()-Methode. Dort ist der Einstiegspunkt des Skripts. Diese Methode wird durchgeführt, wenn der DOM-Baum vollständig geladen wurde. Mit anderen Worten: Während man mit JavaScript Konstrukte wie onDocumentReady erstellen muss, damit um Himmels Willen nichts geschieht, bevor das vollständige DOM geladen wurde, wartet Dart von Beginn an auf den kompletten Baum. In Listing 1 sieht man, wie so eine main()-Methode aussehen kann. Das führt uns zu einem anderen Punkt: Dart kann je nach Geschmack funktional oder auch objektorientiert entwickelt werden. Denn neben main() sind eben auch weitere, eigene Funktionen möglich. Somit kann Dart wie JavaScript aussehen, aber auch wie Java.

main() {

   BlogPost blogPost = new BlogPost();

   blogPost.doSomething();

}

Klassen, Interfaces, Konstruktoren

In Dart gibt es Klassen, Interfaces und vieles mehr, beispielsweise Factories. Design-Patterns sind sogar so wichtig für Dart, dass sie, wie im Falle von Factories, durchaus in die Sprache eingebettet werden. Konstruktoren sind ebenfalls Teil der Sprache. Wer aus der Java-Welt kommt und mit JavaScript begonnen hat, wundert sich oft, wie man Objekte konstruiert. In JavaScript macht man das nämlich, indem man einem Objekt (!) Funktionen hinzufügt, und das unter Zuhilfenahme des berühmt-berüchtigten prototype-Schlüsselworts. Somit ist ein JavaScript-Objekt im Prinzip eine Art key/value-Map, die Funktionsreferenzen gleichermaßen wie Variablen halten kann. Das kann schon mal verwirren. Das macht JavaScript sehr flexibel, aber man kann sich nie so ganz sicher sein, wer wann welche Funktion zu diesem Objekt hinzufügt oder entfernt.

In Dart gibt es im Prinzip das, was man heutzutage so erwartet. Die Entwickler wollten bewusst eine Mainstreamsprache erstellen, die Neueinsteigern „bekannt vorkommt“. Daher auch der „Java-esque“ Stil. Dementsprechend findet sich auch Klassenvererbung mittels extends und Interfaceimplementierung mittels implements wieder. Und wie kann so eine Klasse nun aussehen? In Listing 2 sieht man nichts Ungewöhnliches, wir implementieren das Interface Post (das offenbar keine Methoden definiert) und leiten von einer Klasse TextBlock ab. Es gibt auch noch einen einfachen Konstruktor, der dann bei Objektkonstruktion noch eine Nachricht ausgibt. Mit dynamischen Sprachen wie Dart gibt es immer ein Problem mit dem Überladen von Methoden. Was ist also, wenn man mehrere Konstruktoren haben möchte, die verschiedene Parameter annehmen? In der Java-Welt sieht man das öfter:

 

class BlogPost extends TextBlock implements Post {

  var value;

  BlogPost() {

      print("Hello World");

  }

}

 

new BlogPost(true, false, true);

new BlogPost(true);

new BlogPost(true, true, true, "Hello");

Wenn wir kritisch auf diesen Code blicken, kann man nicht unbedingt behaupten, dieser wäre schön oder gar selbsterklärend. Ohne JavaDoc wäre man geradezu aufgeschmissen. Schlimm wird es, wenn die Bedeutung der Argumente noch variiert, also zum Beispiel der Boolean-Parameter für „Kommentare erlaubt“ im ersten Fall an zweiter Stelle steht, dann an erster und dann vielleicht an dritter. Dart bietet eine elegante Lösung für die Überladung und für die hässlichen Argumentenlisten: benannte Konstruktoren. Indem man Konstruktoren Namen gibt, kann man auf semantische Art und Weise zwischen ihnen auswählen. Listing 3 zeigt, wie das in der Klasse aussehen kann. Wie man sieht, die verschiedenen Konstruktoren erhalten Bedeutung. Aufgerufen werden sie dann auch mit dem Namen: new BlogPost.noComments();. Das erinnert ein wenig an Javas innere Klassen, hat damit aber nichts zu tun. Die ellenlangen Listen mit Argumenten kann man sich unter Umständen sparen, der Code wird verständlicher. Man könnte auch sagen, benannte Konstruktoren sehen ein wenig aus wie Factory-Methoden.

class BlogPost {

  BlogPost() { } // Standard

  BlogPost.noComments() {} // Kommentare ausschalten

  BlogPost.withOptions(var comments, var followUps) {} // mit Optionen

}

Factories

Wie bereits erwähnt, sind Design-Patterns ein Thema. Den Anfang macht das bekannte Factory Pattern, das manchmal auch (unglücklich) eingedeutscht als „Fabrikmethode“ [5] bezeichnet wird. Das Pattern besagt im Prinzip, dass man ein Objekt ohne direkten Konstruktoraufruf erstellt. Damit wird es möglich, Objekte zu erstellen, deren konkrete Klasse man gar nicht kennt, sondern nur ein bestimmtes Interface zu implementieren. Oder man kann ein bestimmtes Objekt zurückgeben, dass man vielleicht bereits vor einiger Zeit erstellt und gecached hat. Dart kennt das Schlüsselwort factory, genaueres zeigt Listing 4. Ich habe das Beispiel etwas gekürzt, um die wesentlichen Elemente hervorzuheben. Zunächst ist da das static-Schlüsselwort. Wie auch in Sprachen wie Java haben wir damit die Map auf „Klassenebene“ zugänglich gemacht. Man benötigt also kein Objekt, um auf diese Variable zuzugreifen. Gleichermaßen ist der Inhalt dieser Map damit auch für jedes Objekt dieser Klasse zugänglich. Die Map selbst ist eine Art Key/Value-Speicher, in dem anhand eines Keys, in unserem Fall eine ID, ein Objekt abgelegt wird.

class BlogPost {

   static Map<int id, BlogPost> _cache;

   factory BlogPost(int id) {

      if(_cache == null) {

         _cache = {};

      }

      if(_cache.containsKey(id)) {

         return _cache[id];

      } else {

         // neues Objekt erzeugen und in den Cache legen

      }

   }

}

Sehen wir uns den Konstruktor an: Er hat das Schlüsselwort factory abbekommen und ist somit als ein solcher zu behandeln. Das heißt, wird er aufgerufen, muss sich der Entwickler selbst darum kümmern, dass ein entsprechendes Objekt zurückgegeben wird (oder auch nicht). In unserer Implementierung prüfen wir im Cache, ob ein passendes Objekt vorhanden ist und geben dieses gegebenenfalls zurück. Ist das nicht der Fall, erzeugen wir ein neues Objekt und legen es in den Cache, was ich in diesem Listing nicht ausgeschrieben habe. Das Schöne an dem Schlüsselwort ist, dass damit eine Factory wie ein ordinärer Konstruktor new BlogPost(5); benutzt wird. Es ist damit fast jederzeit möglich, aus einem „normalen“ Konstruktor eine Factory zu machen und vice versa. Das birgt einen gewissen Charme, den der geneigte Entwickler von Frameworks wie Spring oder Google Guice her kennt: Denn sie versuchen ebenfalls, die Konstruktion des Objekts vom restlichen Programm zu kapseln.

Get und Set

So ähnlich wie mit den Factories läuft das auch mit den berüchtigten Get/Set-Methoden. Das Beispiel hierzu ist übriges online verfügbar [6]. Unsere BlogPost-Klasse erhält eine Variable _text, die eben unseren Text speichern soll. Nach dem Prinzip der Datenkapselung soll diese Variable nicht direkt beschrieben, sondern über Get/Set-Methoden verändert werden. Listing 5 zeigt das, aber oh Überraschung: Wieder begegnen uns zwei neue Schlüsselwörter, nämlich get und set. Damit können die Methoden so aufgerufen werden, als wären sie „normale“ Eigenschaften des Objekts, die Klammern entfallen, wie man in der main()-Methode sehen kann. Auch das „=>“ ist neu. Im Prinzip ist das eine Art Abkürzung für return. Die geschweiften Klammern entfallen hier ebenfalls. Unsere set-Methode gibt dann folgerichtig auch einen Wert zurück, nämlich den eben gesetzten String. Wer diese nicht möchte, kann natürlich auch auf altbewährte Weise coden: void set text(String text) { _text = text; }. Dieses Konstrukt ermöglicht uns etwas sehr schönes: Get/Set zu schreiben kann am Beginn eines Entwicklungsprojekts erstmal vermieden werden. Es ist sehr leicht, zunächst direkten Zugriff auf eine Eigenschaft zu ermöglichen und dann später, falls notwendig, zu Get/Set-Methoden zu refactoren. Nehmen wir den Code aus Listing 5 an: Der Zugriff erfolgt hier genauso wie mit den obigen Get/Set-Methoden. Wer möchte, kann nun jederzeit umsteigen. Tatsächlich ist es auch so, dass die Google-Entwickler empfehlen, zunächst ohne Get/Set zu entwickeln und nur bei Bedarf auf Methoden umzusteigen.

class BlogPost {

  String _text;

  String get text() => _text;

  String set text(String text) => _text = text;

}

 

main() {

  BlogPost bp = new BlogPost();

  bp.text = "My Test";

  print(bp.text);

}

Typen

Ein großer Kritikpunkt an JavaScript und Java gleichermaßen ist die Verwendung von Typen. Dem einen fehlen sie, dem anderen sind sie zu dogmatisch. Während man oft zu hören bekommt, dass ohne Typen keine „großen Systeme“ möglich seien, sagt man auch oft, dass Typen eigentlich nur die Flexibilität aus dem Programm nehmen und eine schnelle Entwicklung boykottieren. Üblicherweise muss man sich auf eine Seite schlagen wenn man eine neue Sprache entwickelt. Doch im Hause Google ging man einen anderen Weg. Ähnlich wie so mancher deutsche Politiker versucht man, es jedem Recht zu machen und auf die Frage „Ja oder Nein?“ mit einem gepflegten „Muss man von Fall zu Fall entscheiden“ zu antworten. Was bei Politikern oftmals zu tiefgehender Frustration seitens der Wähler führt, verhält sich in Sachen Dart viel angenehmer. Typen sind optional und können nach Bedarf ein oder ausgeschaltet werden. Auf der Kommandozeilenebene wird hier der folgende Parameter benötigt: dart –enable_type_checks BlogPost.dart. Damit wird geprüft, ob die Typen passen oder nicht. Lässt man den Typcheck aus, läuft das Programm, egal welche Typen wohin gesteckt werden (also in der Theorie – Laufzeitfehler fixt Dart nicht von alleine). Typen kann man in Methodenargumenten genauso verwenden wie auch in Variablendeklarationen. Man muss aber nicht. Wer das per se nicht mag, kommt auch mit dem Schlüsselwort var aus. Beide Zeilen sind gültig:

var question = 'Hallo';

String answer = 'Huhu';

Der Typ von question ist Dynamic, und somit kann question alles beinhalten. Unser answer ist ein String. So lange man aber den Typcheck nicht aktiviert, kann man auch hier alles reinstecken, was einem so in die Quere kommt (was aber natürlich nicht ratsam ist).

Wofür eigentlich Typen?

Typen in Dart helfen der Dokumentation und dem Debugging. Es wird erwartet, dass der „typische“ Dart-Entwickler zunächst ziemlich schnell seinen „Programmrahmen“ erstellt, ohne groß auf Typen zu achten. Wächst das Programm, können Typen eingeführt werden – ganz oder teilweise, je nach Bedarf und Wunsch. Nachdem wir uns nun über die Typen im Klaren sind: Dart bietet auch Generics an. Damit kann zum Beispiel sichergestellt werden, dass in eine List nur Strings gesteckt werden: new List<String>();. Auch wenn man sich entscheidet, typisiert zu arbeiten, kann man für die eine oder andere Liste eine Ausnahme machen, nämlich mit dem Typ Dynamic selbst: new List<Dynamic>();. Alternativ kann man natürlich auch das Generic weglassen, denn Dynamic kommt immer dann zu tragen, wenn nichts anderes angegeben wurde.

Isolates

Oft wird bemängelt, dass es in JavaScript keine richtige Nebenläufigkeit gibt (WebWorker bieten mit HTML5 eine solche Möglichkeit). Mit Dart wird dieser Umstand behoben. Glücklicherweise hat man einen etwas anderen Ansatz gewählt, als den Java-Ansatz des Multithreading. Hier geht man in Richtung Erlang, die ebenfalls so ein Konzept mit ihren Aktoren anbieten. Isolates sind kleine, abgekapselte Programmeinheiten, die sich nichts miteinander teilen. Damit meine ich vor allem die internen Zustände. Sie sind also so eigenständig, dass sie nicht einmal auf die gleichen statischen Variablen zugreifen können. Kommunizieren können sie jedoch, nämlich mit den so genannten Ports. Mittels eines Ports kann ein Isolate A eine Nachricht an ein Isolate B schicken. Diese Nachricht kann ein beliebiges Objekt sein. Ich werde in einem der folgenden Artikel noch einmal detaillierter auf Isolates eingehen, daher möchte ich es bei diesem „Gruß aus der Küche“ belassen. Wer aber schon einen kleinen Vorgeschmack haben möchte, dem sei ein Blick auf mein Blog empfohlen [7].

DOM-Manipulation

Auch im Fall der DOM-Manipulation hat Dart etwas in petto. Auch hier möchte ich auf den Artikel im nächsten Heft verweisen. Dort wird beschrieben werden, wie man mit einer jQuery nicht unähnliche Syntaxelemente aus dem DOM-Baum selektiert und manipuliert. Das heißt, wie man Elemente mit Event Handlern versieht und deren CSS verändert.

Sichtbarkeit

Ein letztes Thema, bevor wir den Rundumschlag beenden: Sichtbarkeit. Wir hatten etwas weiter oben schon über Datenkapselung und Sichtbarkeit in Bezug auf Getter und Setter gesprochen. Dort haben wir auch eine bestimmte Schreibweise für Variablen gesehen, die in der heutigen Entwicklerwelt durchaus weit verbreitet ist: der Underscore für private Variablen: String _text = ‚Hallo‘;. Allerdings fehlt hier etwas: das Schlüsselwort, in den meisten Sprachen üblicherweise private. private sollte an dieser Stelle bedeuten, dass die Variable von außen nicht zugreifbar ist. Dart macht es sich hier etwas leichter. Anstatt eines Schlüsselworts hat man den Unterstrich, um private anzudeuten. Wer also den Unterstrich vor einen Bezeichner setzt, markiert damit das Element als private. Allerdings ist das Dart-private etwas anders als in jeder anderen Sprache. Dart kennt nämlich keine „Klassen“-privacy. Das heißt, obwohl man eine Variable als private markiert, ist sie von außen zugreifbar, so lange sie sich in der gleichen Bibliothek befindet.

Eine Bibliothek ist im Prinzip eine Sammlung von Quellcode. Das kann also eine Datei sein, in der alle Klassen, Funktionen etc. definiert sind, oder eben eine Datei, die mehrere andere Dateien einbindet. Wenn man dann #library(‚A‘); davor setzt, hat man schon eine Bibliothek. Diese Bibliothek A kann von einer anderen Bibliothek B importiert und somit verwendet werden: #import(‚A.dart‘);. Bibliothek B hat damit Zugriff auf alle Elemente, die public sind. Demnach nicht auf Underscore-Elemente. Innerhalb der Bibliothek A kann jedoch auf alles zugegriffen werden, egal ob es mit Underscore bezeichnet wurde oder nicht. Also auch auf private Eigenschaften von Klassen. Das ist zunächst ein gewöhnungsbedürftiger Ansatz. Man könnte sagen, innerhalb einer Bibliothek ist alles public. Das zwingt den Entwickler, etwas umzudenken, vielleicht zum ersten Mal, wenn man auf Dart umsteigt. Denn man hat die implizite Aufgabe, seinen Code in anständige Bibliotheken zu teilen. Man muss sauber organisieren, sonst kann es Probleme geben. Dart erwartet von einem, dass man das „Separation of Concerns“-Prinzip verinnerlicht hat. Das mag für manche ein Problem darstellen, bietet aber natürlich auch einiges an Flexibilität und Geschwindigkeit. Es wird sich in den nächsten Monaten zeigen, ob dieses Konzept aufgeht oder nicht.

Links & Literatur

[1] http://www.dartlang.org

[2] http://bit.ly/syvyQ5

[3] http://bit.ly/v5nNUb

[4] http://www.dartlang.org/docs/getting-started/editor/index-macos.html

[5] Factory und Fabrik: http://de.wikipedia.org/wiki/Fabrikmethode

[6] http://try.dartlang.org/s/Iqkk

[7] http://dartvader.grobmeier.de/dart-isolates-08112011.html

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -