Dart vs Motörhead: Das Ergebnis steht fest

April 26th, 2012 by grobmeier

Am Dienstag, den 24.04.2012 war ich Gast der Java User Group Saxony. Ich traf so einige nette Leute und war von der Organisation dieses kleinen Events beeindruckt. Dank der JUG Saxony konnten wir nun endlich das Geheimnis lüften: Wer rockt mehr, Motörhead oder der Newbie Dart? Näheres kann meinen online Folien entnommen werden (pdf).

Die letzte Folie ist die vermutlich wichtigste: die Schlacht zwischen David-Dart und Goliath-Motörhead endet mit einem unentschieden!

Dart macht ein paar Punkte in Bezug auf Offenheit (niemand sagt Lemmy wie der seine Songs zu schreiben hat), Zukunft (Lemmy ist immerhin schon fast 70) und Geschwindigkeit (Motörhead ist schnell, aber diese Bits und Bytes…). Aber Motörhead liegt mit den Punkten Lautstärke, Anzahl der Releases (21!) und einer stabilen API, äh, Bandbesetzung vorne.

Es war ein spaßiger Abend für mich. Und ich hoffe, das Gleiche gilt für meine Gäste.

Entwickler Magazin: Dart und das liebe Web

April 19th, 2012 by grobmeier

Teil 2 meiner kleinen Dart-Serie im Entwickler Magazin ist erschienen. Er heißt “Dart und das liebe Web” und kümmert sich hauptsächlich um DOM-Manipulation mit Dart. Enjoy!

Darts neue Isolate API

April 19th, 2012 by grobmeier

Eines meiner Lieblingsfeatures in Google Dart sind die Isolates (eine Art Multithreading Feature für Dart, falls Sie es noch nicht kennen. Jedoch war die erste Version der API noch sehr komplex. Sie erinnerte sehr stark an das Java Threading und war generell sehr schwer zu erlernen. Die Dart-Entwickler haben jedoch recht bald angekündigt, eine Überarbeitung vorzunehmen, was mittlerweile getan ist.

Mit der alten API musste man noch die Isolate-Klasser erweitern, um ein Isolate zu erstellen. Dabei wurde zwischen “Heavy” und “Light” Isolates unterschieden. Das ist alles Vergangenheit. Die Dart VM entscheidet mittlerweile für den Entwickler, welche Art von Isolate angemessen ist. Außerdem muss nicht mehr von Isolate abgeleitet werden, jetzt arbeitet man mit Funktionen. Das Ergebnis führt zu sehr viel besser lesbaren Code. Ein Beispiel.

Zunächst muss das Isolate-Packet importiert werden. Auch das ist neu, denn vorher haben sich die Isolate Klassen im Core befunden.

#import('dart:isolate');

Dann kann der Spaß beginnen!

Zunächst definiere ich eine Funktion, die als neues Isolate agieren soll.

process() {
  port.receive((var message, SendPort replyTo) {
      print ("Got message: ${message}");
      replyTo.send("close");
      port.close();  
  });
}

Es muss sich hierbei um eine Top-Level Funktion handeln und darf keinen Rückgabewert haben. “Void” würde daher nicht funktionieren. In Zeile 2 sieht man, dass ich auf den “port” zugreife. Es handelt sich hier um eine get-Methode, die den Port dieser Funktion zurückliefert. Über Ports kann man mit anderen Isolates kommunizieren.

Dieser Port kann eien Funktion ausführen, wenn eine Nachricht erhalten wurde. Dessen Argumente sind dann die eigentliche Nachricht. Eine Nachricht kann aus null, num, bool, double oder String bestehen. Auch Listen und Maps, die diese Typen beinhalten, sind erlaubt. Sogar Objekte sind möglich, wenn die Isolates im selben Prozess laufen (vorher auch als “light” Isolate) bekannt. Die Dokumentation sagt dazu, diese ist der Fall wenn das Isolate mit “spawnFunction” erzeugt wurde.

Zusätzlich zur Nachricht erhalten wir auch noch einen SendPort, was eine Art Rückkanal zum sendenden Isolate darstellt.

In meiner Funktion drucke ich eine Nachricht, sende einen “close”-String zurück und schließe im Nachhinein den Port. Das Isolate ist dann bereit in den Müll zu wandern und die VM sollte dies auch erledigen. Es ist wichtig, die Ports zu schließen, da sonst der Code für immer läuft und den Speicher unnötig belastet.

Soweit zur Isolate-Funktion. Sehen wir uns an, wie wir die Funktion dann eigentlich erzeugen (spawn).

main() {
   port.receive((var message, SendPort replyTo) {
     print("Got message: ${message}");
     port.close();  
   });

   SendPort sender = spawnFunction(process);
   sender.send("start", port.toSendPort());
}

Dieser Code läuft in der Main-Methode. Die Main-Methode ist auch nur ein Isolate, deswegen habe ich hier auf einen Port zugriff. Ich lege wieder eine Funktion als Empfänger fest, die abermals eine Nachricht druckt und den Port im Anschluß schließt. Sobald der Main-Port schließt, ist die Anwendung beendet.

Dann rufe ich die “spawnFunction()” Methode auf die die bereits beschriebene Top-Level-Funktion als Argument erhält. Ich verwende keine Klammern. Der Grund ist, dass ich eine Referenz zur Funktion übergeben möchte, und nicht dessen Ergebnis. Die eigentliche Durchführung soll ja im eigenen Isolate erfolgen, und zwar durch die spawnFunction-Methode.

Die spawnFunction-Methode liefert einen SendPort, den ich in der letzten Zeile benutze, um meine erste Nachricht zu senden. Mein zweites Argument ist der Rückkanal für das zweite Isolate. Jetzt kann ich also Antworten meiner “process”-Funktion erhalten.

Das war’s!

Ich habe festgestellt, das die Funktion nicht gespawned wird, when die port.receive() Methode keinen Handler erhält. Zusätzlich darf man nicht vergessen, dass die Funktion die gespawned werden soll, kein “void” als Rückgabewert erhält. Zu guter Letzt habe ich festgestellt, dass der SendPort – obwohl er in der API als optional markiert war – immer vorhanden oder null sein muss.

Fall Sie gerne mit Futures arbeiten möchten: auch dafür gibt es Unterstützung im SendPort. Es ist außerdem möglich einen Isolate von einer URI zu spawnen. Mehr dazu bieten die Docs.

Die API ist meiner Meinung nach ein Schritt in die richtige Richtung. Alles ist einfacher und benötigt weniger Code. Mal sehen, wie das in ein paar Monaten so aussieht. Es soll wohl auch bald Isolates geben, die auf dem gleichen DOM Stück operieren können, was die Geschwindigkeit von Webapps ziemlich steigern dürfte.

Dart vs. Motörhead – Dresden

April 2nd, 2012 by grobmeier

Rock in Dresden – präsentiert von der Java Usergroup Saxony.

Dart ist eine neue Band, die aber schon gewaltig rocken soll. Kann es die Nachwuchsband mit alteingesessenen Rockstars – wie etwa Motörhead – aufnehmen? Motörhead kommt mit einer eingespielten Truppe daher: die Bibliotheken ändern sich quasi niemals und timingprobleme kennt der Drummer nicht. Dart dagegen ist jung und unerfahren. Konnte es von den “Großen” genug abkupfern um selbst auf Tour gehen zu können? Wirkt der Dart-Sänger ohne die charakteristische Motörhead-Warze im Gesicht wie ein Milchbubi? Oder ist es gerade das charmante Äußere, mit dem Dart die Herzen der Entwickler zum Schmelzen bringt?

Der Vortrag zeigt, was Dart musikalisch so drauf hat. Lockere Kleidung, Ohrstöpsel und eine Dose Bier werden für dieses Konzert empfohlen. Ach ja, der Vortrag ist zwar kostenlos, jedoch: you might loose your soul to Gods Rock’n’Roll!

Sprecher: Christian Grobmeier, The Apache Software Foundation

Ort: Fakultät Informatik der TU Dresden, Raum E023

Datum: 24. April 2012, 19:00-22:00

(Google) Dart rockt die Java Usergroup Augsburg!

March 24th, 2012 by grobmeier

Am 22.03.2012 schaute ich mal bei der Java Usergroup Augsburg vorbei um etwas über Dart zu sprechen. Es war ein großartiger Abend, mit vielen interessanten Fragen und einer Menge Spaß! Danke an die Organisatoren! Ich habe die Folien als PDF Datei und als HTML version hochgeladen.

Unten findet sich ein Bild, das mein alter Kumpel Jochen Stricker aufgenommen hat. Hoffentlich sehe ich in Wirklich etwas besser aus :-)


Dart läuft native auf Chromium: Hallo Dartium! #dartlang

February 15th, 2012 by grobmeier

UPDATE: Dartium ist da.

Im heutigen Dart G+ Hangout mit dem Dart Team haben die Google Entwickler bekanntgegeben, das Dartium fertig ist (und in ein paar Stunden auch zum Download angeboten wird. Bitte einfach öfter mal bei Dartlang.org vorbeisehen. Alternativ werde ich auch diesen Post mit einem Update versehen).

Was heißt das nun? Es bedeutet, Dart läuft jetzt auch native im Browser. Also ohne das man es vorher zu JavaScript kompilieren muss.

Es ist ein wichtiger Schritt für das Dart Team denn Dartium ist der erste Browser, der Dart native unterstützt. Dart selbst ist ja noch sehr jung auch recht kompliziert, deswegen hat das Team entschieden die VM erst einen Fork von Chromium namens Dartium einzubauen, bevor es dann in die breite Öffentlichkeit entlassen wird.

Dartium ist im technischen Preview. Der Browser wird nicht zum täglichen Einsatz empfohlen. Es könnte Sicherheitsprobleme und andere Unstimmigkeiten auftreten. Das Dart Team hat um Unterstützung von den Usern gebeten und wünscht sich, dass alle Bugs an die Entwickler herangetragen wird.

Dartium kann gleichzeitig mit JavaScript und Dart umgehen.

Jedes Dart Skript wird als eigenes Isolate laufen. Sogenannte Heavy Isolates in Dart werden sogar einen eigenen Prozess starten, während zu JavaScript generierte Heavy Isolates mit WebWorkern arbeiten.

Um Dart im Dartium Browser zu aktivieren, muss lediglich ein script tag mit dem Typ “application/dart” eingefügt werden, alles zwischen diesem Tag wird als Dart ausgeführt, ähnlich wie bei JavaScript.

Dartium unterstützt auch Debugging, ein Feature was bereits lange vermisst wurde. Sogar eine experimentelle Fassung einer Caching Lösung (Snapshots) ist vorhanden. Experimentell deswegen, weil es besonders sicherheitsbedenklich ist. Das Snapshot-Feature soll die Dart-Startzeit und die Skriptausführzeit deutlich reduzieren.

Das Dart Team freut sich im besonderen über Erfahrungsberichte mit multiplen Skripttags und Isolates.

Viel Spaß beim Darten!

(Google) Dart im Entwickler Magazin

February 10th, 2012 by grobmeier

Heute erschien im Entwickler Magazin ein neuer Artikel über Google Dart. Und er hat es sogar auf das Deckblatt geschafft! Leider ist der Name des Artikels “Google Dart”, wo er doch nur “Dart” heißen sollte. Aber egal – ich denke der Artikel ist recht nett zu lesen. Woher ich das weiß? Immerhin hab ich ihn geschrieben :-) – aber ich gebe zu, ich bin da vielleicht nicht ganz objektiv mit meiner Bewertung.

Feedback dazu ist natürlich willkommen!

Das ist übrigens nicht der einzige Artikel seiner Art. Es werden noch zwei weitere Folgen. #2 beschäftigt sich mit mehr mit dem HTML/DOM Aspekt von Dart, #3 führt uns dann ziemlich direkt in die Welt der Isolates.

10 Punkte, in denen Dart JavaScript übertrifft

January 12th, 2012 by grobmeier

Dart ist eine von Google entwickelte Programmiersprache, die mittlerweile als Open Source Projekt verfügbar ist. Derzeit befindet sich die Sprache im technischen Preview und ist noch nicht produktiv zu verwenden, aber man kann schon prima damit rumspielen.

Aus Dart kann JavaScript generiert werden (ähnlich dem CoffeeScript Ansatz) oder es kann native im Browser laufen. Es gibt bereits Webkit- und Chrome-Branches, die genau jenes unterstützen sollen. Trotzdem: es wird noch einige Zeit vergehen, bis man wirklich von einer weiten “nativen” Unterstützun von Dart in den Browsern sprechen kann. Glücklicherweise kann man aus Dart ja auch JavaScript machen, weswegen die Sprache trotzdem interessant ist.

Aber warum das Ganze? JavaScript ist immerhin weit verbreitet und hat viele Anhänger gefunden.

Vor ca. einem Jahr begann ich mich ernsthaft mit JavaScript beschäftigen. Ich komme von der Java Welt und musste daher einiges lernen, bevor ich wirklich produktiv arbeiten konnte. Die Art zu Denken unterscheidet sich doch sehr zwischen Java und JavaScript.

Manche Leuten sagen, dass man sich besonders tief mit JavaScript beschäftigen muss, ansonsten könne man nicht über die Vor- und Nachteile diskutieren. Ich bin nun wirklich kein JavaScript Ninja. Aber ich glaube fest daran, dass eine Sprache leicht zu erlernen und leicht zu verstehen sein sollte. Zudem sollte eine Sprache konsequent sein, wenn es um Syntax und Konzepte geht.

Auch jetzt, nachdem ich bereits so lange Zeit mit JavaScript gearbeitet habe und dessen Schwächen kenne, muss ich leider sagen dass ich immer noch sehr, sehr, sehr vorsichtig arbeiten muss, wenn es um mein tägliches Brot geht. JavaScript hat ein paar sehr gute Ideen – aber trotzdem, die fehlende Sicherheit beim Entwickeln empfinde ich als sehr nachteilig. Eine Sprache sollte den Entwickler unterstützen – und nicht umgekehrt.

Ich habe im folgenden 10 Punkte aufgelistet, die mich besonders mit meiner täglichen JavaScript Arbeit beschäftigt haben und die jetzt mit Dart gelöst werden (sollen). Wegen ihnen – aber nicht nur – werde ich irgendwann zu Dart wechseln. Dabei darf man aber nicht vergessen, das Dart immer noch “in der Mache” ist, und sich somit noch einiges verändern kann. Ungefragt und jederzeit.

1. Dart kennt nur einen “falsify” Wert

In diesem Post kann man recht schnell sehen was ich meine. Die Werte: false, null, undefined, “”, 0, NaN in JavaScript gelten als “false”. Das heißt, man kann solche Dinge machen:

var a = null;
if(!a) {
   // do
}

In Dart gibt es nur einen Wert der “false” ist, nämlich “false” selbst. Natürlich muss man den Code dann etwas anders schreiben:

var a = null;
if(a != null) {
   // do
}

6 verschiedene Ausdrücke die “false” ergeben – das muss man erstmal wissen.

2. Dart arbeitet mit Typen, wenn man das will

JavaScript Entwickler sagen oft, dass Typen die Flexibilität reduzieren. OK, das mag wahr sein. Aber zu viel Flexibilität reduziert auch die Qualität der Software ;-). Manchmal will man eben mit Typen arbeiten, und Dart erlaubt es einem, wenn man es möchte. Man muss einfach nur den Typechecker anschalten, schon kann man damit loslegen.

3. Man braucht ein weiteres Framework in JS um gut mit dem DOM arbeiten zu können

In JavaScript gibt es unsere alten Freunde:

getElementsById()
getElementsByTagName()
getElementsByName()
getElementsByClassName()
querySelector()
querySelectorAll()
document.links
document.images
document.forms
document.scripts
formElement.elements
selectElement.options

Ganz schön viel. Glücklicherweise haben wir jQuery und Co, die uns aus dieser Geschichte raushelfen. Aber, sollte es heutzutage wirklich noch nötig sein ein extra Framework einzubinden, nur um mit dem DOM zu arbeiten? Eigentlich doch nicht.

Dart hat sich jQuery ansehen und daraus genau zwei Methoden abgeleitet:

elem.query('#foo');
elem.queryAll('.foo');

Besser.

4. Klassen und Interfaces

Wenn Java Entwickler mit JavaScript anfangen, versuchen sie oft JavaScript so zu programmieren, wie sie auch Java schreiben würden. Da gibt es dann Konstruktoren und klassenähnliche Elemente. Das ist aber nicht im Sinne des Erfinders und sollte anders gemacht werden: JavaScript ist eben Prototyp basiert, alles ist ein Objekt. Das ist ziemlich cool. Auf der anderen Seite kann man die Gang of Four Patterns weitgehend ausser Acht lassen und anstelle dessen ein Buch über JavaScript Patterns lesen.

Ich habe in meiner Laufbahn einige Entwickler getroffen, die bereits sehr lange Zeit benötigt haben um die gängigen Patterns zu verstehen. Nicht jeder ist ein Geek. Eine Sprache, die nicht mainstream ist, in einer mainstream-Umgebung zu verwenden führt geradewegs in das Zentrum des absoluten Chaos.

5. Vererbung

Dr. Rauschmayer erklärt in seinem ausgezeichneten Blogpost, warum JavaScript Vererbung einfach ist – und da hat er recht. Es ist wirklich einfach. Aber aufgepasst: dies ist nicht die einzige Art, wie man Vererbung durchführen kann. jQuery und das Prototype-Framework haben sogar eine extra “extend” Methode. Anstelle von dem von Dr. Rauschmayer empfohlenen __proto__ kann man das prototype Keyword verwenden (in diesem Post wird sogar von Klassen gesprochen, auch wenn es gar keine Klassen in JavaScript gibt). Natürlich kann man auch seinen
eigenen Mechanismus entwickeln und jede Eigenschaft einfach selbst kopieren.

Diese Seiten waren Suchergebnisse von Google, wenn man nach den Wörtern “javascript object extends” sucht. Es ist eigentlich ziemlich viel, was man lesen kann, obwohl es eigentlich nur ein recht einfaches Ziel zu erreichen gilt: Erweiterung.

Nicht jeder liest Dr. Rauschmayers Blog. Schade, denn das Leben wäre recht viel einfacher, falls das so wäre.

Dart kennt Klassen und kennt auch das “extends” Schlüsselwort. Ziemlich einfach.

ECMAScript 6 soll das übrigens bereinigen (Spec wird 2013 beendet werden).

6. Globaler Namespace

In JavaScript muss man aufpassen, damit man nicht einfach Zeugs in den globalen Namensraum legt. Das kann ehrlich gesagt ziemlich einfach passieren. Falls man ein “this” oder ein “var” vergisst, hat man Variablen auf globalen Level. Jedes Skript hat dann Zugriff darauf. Das ist eigentlich ziemlich schrecklich und sollte verhindert werden. Dank dem Buch von Stoyan Stefanovs namens JavaScript Patterns habe ich ein Pattern gelernt, wie man den Namensraum sauber halten kann. Jetzt geht es mir besser und ich habe wieder mehr Kontrolle über das, was ich tue. Leider brauche ich dafür ein Pattern. Das sollte eigentlich “out of the Box” geliefert werden.

In Dart entwickelt man im “Library” Scope. Das bedeutet, das Keyword “Library” verschließt ein Dart-”Paket” so, daß nur öffentliche Felder, Methoden und Klassen von außen zugänglich sind. Zusätztlich wird jedes Dart Skript als eigenes Isolate ausgeführt. Das heißt, es hat einen eigenen State und kann nicht auf den State der anderen Skripte zugreifen. Mit Dart muss man zwar immer noch über Sichtbarkeit und Bibliotheken nachdenken, aber es ist sehr viel einfacher und man braucht sicherlich auch kein Buch dafür. Anstelle davon sollte man eigentlich nur über “Separation of concerns” nachdenken müssen.

7. Dart kennt Nebenläufigkeit

Mit JavaScript sind die Dinge nicht wirklich nebenläufig. Sogar wenn man einen asynchronen Zugriff mittels jQuery durchführt befindet man sich immer noch in einem “Thread”. Mit V8 scheinen die Dinge anders zu laufen, aber genaueres weiß ich darüber nicht. Umgehen kann man dieses Problem mit HTML5 und Webworkern.

Dart kennt Isolates. Das ist damit so ähnlich wie in Erlang. Isolates können miteinander kommunizieren. Wenn ein Isolate zusammenbricht, kann es neu gestartet werden. Das ist ziemlich cool. Natürlich machen Isolates Dart auch für die serverseitige Entwicklung interessant. Und ja, ich habe von Node.js gehört. Aber das ist nicht der Punkt: Dart kann das nämlich von sich aus.

8. JavaScript kennt kein foreach.

Aber moment.

Object oder Array.prototype kann erweitert werden. Das ist natürlich nett.

Für Arrays kann man natürlich auch das machen:

for (var i = 0; i < elements.length; i++) {
  // do something
}

Und man kann das für Objekte machen:

for (key in elements) {
  alert(elements[key]);
}

Douglas Crockford empfiehlt dies jedoch nicht. Er sagt, die Ergebnisse sind nicht geordnet und man kann natürlich auch die Eigenschaften der prototyp-Kette sowie Funktionsnamen sehen. Die man wiederrum mit hasOwnProperty ausfiltern könnte.

Letztlich kann man natürlich auch in ein Framework wie jQuery sehen, die sowas wie forEach anbieten.

Zu guter letzt sei gesagt, das ECMAScript 5 foreach für Arrrays kennt. Zumindest alle modernen Browser unterstützen das also. Dazu gehört der Internet Explorer 8 aber offensichtlich nicht und der ist dummerweise noch im Einsatz.

In Dart:

for (element in elements) {
  // do something
}

Das Leben ist damit entspannter. Damit iteriert man über eine Liste mit Elementen.

9. Seltsames initialisieren von Arrays

Das habe ich mir ausgeliehen. Man sehe sich folgendes an:

var a1 = new Array(1,2,3,4,5);
var a2 = new Array(5);

a1 ist ein Array mit 5 Elementen: [1,2,3,4,5]
a2 ist auch ein Array mit 5 Elementen: [undefined,undefined,undefined,undefined,undefined]

Dart ist da sauberer. Ein Array ist hier einfach eine Liste und hat eben ein solches Interface.

List a1 = [1,2,3,4,5];
List a2 = new List(5);

Auch hier enthält a1 fünf verscchiedene Elemente, a2 enthält nur den Platz für 5 Elemente.
Zusätzlich bekommt man Methoden wie “removeRange” oder zur Sortierung, wie man in obigen link von Seth Ladd kann.

10. undefined und null

Es gibt viel zu lernen, wenn man mit JavaScript anfängt. Darunter ist die Weisheit, dass es nicht nur null gibt – sondern auch undefined. Dabei handelt es sich um einen Typ mit nur einem Wert: undefined. Dieser kann überschrieben werden. Und den kann man quasi jederzeit bekommen, zum Beispiel wenn man return aufruft aber keinen Wert zurückgibt. Auf der verlinkten Seite kann man lesen, wie man mit undefined umgeht, wenn man sich vor einem versehentlichen Überschreiben schützen will.

In den meisten Fällen kann wohl null mit undefined ersetzt werden.

Das ist krank.

Dart kennt nur ein null.

Zusammenfassung

JavaScript hat natürlich auch seine guten Seiten. Es gibt einige sehr nette Patterns. Aber derzeit habe ich nichts gefunden, was ich nicht auch mit Dart machen könnte. Dart ist meistens eleganter und lesbarer (meiner Meinung nach). Natürlich werden einigen Hardcore-JavaScript Entwickler dem nicht zustimmen. Aber das ist OK. Man muß JavaScript mögen, wenn man damit arbeiten will. Dart dagegen ist Mainstream. Es gibt kaum böse Überraschungen.

PS: In meiner Liste habe ich die EventHandler vergessen, die in Dart sehr gelungen sind.

PPS: Außerdem habe ich die Verwirrung, die das this-Schlüsselwort in JavaScript bietet, vergessen. Vielleicht findet sich ja noch was für eine zweite Liste.

Dart erreicht Chromium – und begegnet Scala

December 17th, 2011 by grobmeier

Heute waren gleich zwei gute Nachrichten in meine Mailbox. Zunächst wurde ein Chromium branch eingerichtet, der die auf der WebKit diskutierten Multi-VM integriert hat. Das war natürlich nur eine Frage der Zeit. Derzeit muss man den browser allerdings noch selbst bauen. Dieser Build ist auch nur für Mac OSX und Linux getestet. Und Achtung: der Augenmerk  wurde nicht auf Sicherheit und Konsorten gelegt – Chromium ist also noch nicht für den Alltagsgebrauch geeignet.

Um was geht es da nun eigentlich? Es ist ein Browser, der natives Dart unterstützt und daher auch den neuen script type” application/dart” unterstützt, so wie hier:

<script type="application/dart">
      #import('dart:dom');
      void main() {
         final element = window.document.createElement('div');
         element.innerHTML = 'Hello from Dart';
         window.document.body.appendChild(element);
      }
</script>

Das Skript erstellt ein neues Div-Element, schreibt etwas Text hinein und hängt es dann an den Body des Dokuments an. Native- also ohne JavaScript.

Dart trifft Scala

In einer zweiten Notiz hat Amin Shali ein Framework angekündigt, dass so ähnlich ist wie die Actors in Scala. Im Moment funktioniert das nicht mit den JavaScript Compilern und ist nur zur Verwendung mit der VM (also Kommandozeile) gedacht. Es sind auch Beispiele verfügbar.

Das Framework arbeitet auf Basis der Darts Isolates – eine Möglichkeit der parallelen Verarbeitung in Dart. Wenn man sich, das so ansieht, wird klar: das Framework bietet sich an Isolates ohne “Low Level”-Schmerz zu verwenden :-)

class HelloWorld extends Actor {
  HelloWorld() : super() {
    on["say hello"] = (var who) {
      ui.print("Hello ${who}!");
      halt();
    };
  }
}

Wie man sich vorstellen kann: wenn der Actor das Kommando “say hello” bekommt, wir der Parameter gedruckt. Es braucht noch ein wenig mehr um das zum laufen zu bringen, wie den ActorManager, der die Actor Objekte erzeugt. In diesem Blog wird es sicherlich einen Post zu diesem Thema geben.

Dart Editor in Version 2380

December 14th, 2011 by grobmeier

Google hat soeben die neueste Version des Dart Editors freigegeben. Er kann sich hier heruntergeladen werden. Die neue Version bringt vor allem Verbesserungen in der Stabilität mit sich sowie Bugfixes. Zum ersten Mal geht es auch in Richtung VM: JavaScript soll jetzt nur noch für Browser-Anwendungen generiert werden – wenn die Anwendung über den “Server-Launch” Button ausgeführt wird. Der ist aber zumindest bei mir noch nicht bedienbar. :-)