Ember.js 1.1 im Einsatz

Inhaltsverzeichnis

Laut der Projekt-Webseite ist Ember.js das perfekte JavaScript-Framework für ambitionierte Webapplikationen. Ambitioniert sollte allerdings auch jeder Programmierer sein, der mit Ember neu anfängt. Im Gegensatz zu Angular.js ist die Einstiegshürde vergleichsweise hoch.

Wie bei den meisten IT-Themen sind JavaScript-Frameworks und Webapplikationen gewissen Moden unterworfen. Neue Frameworks für die Entwicklung von Webapplikationen schießen gerade wie Pilze aus dem Boden. Eine solche Webanwendung ist aber etwas anderes als eine statische oder auf dem Server gerenderte HTML-Seite. Als Programmierer muss man sich immer fragen, was für den eigenen Anwendungsfall wirklich die optimale Lösung ist. Ember.js, Angular.js und Backbone.js sollten nicht l’art pour l’art eingesetzt werden. Wer online eine echte Applikation mit dynamischen Elementen zur Verfügung stellen will, braucht ein solches Framework. Wer aber nur eine normale Webseite mit Informationen zur eigenen Firma veröffentlichen will, ist mit klassischem HTML und der Programmierung von dynamischen Elementen mit PHP, Python oder Ruby in Kombination mit einem Framework wie Django und Ruby on Rails besser beraten.

Ember ist ein "opinionated" MVC-Framework (Model-View-Controller). Der Zusatz "opinionated" heißt im Klartext: "Sachen werden so gemacht, wie wir uns das vorstellen oder gar nicht." Wer auf der Serverseite mit den erwähnten Frameworks arbeitet, wird an Ember.js Freude haben. Wer mit strikten Konventionen wenig anfangen kann, der sollte lieber in Richtung Angular.js gehen. Um die Wahl etwas zu erleichtern, sind in der folgenden Tabelle die wichtigsten Entscheidungsfaktoren gegenübergestellt.

	Backbone.js	AngularJS	Ember.js
Flexibilität	+	- -	- -
Erlernbarkeit	+	-	- -
Routing Engine	-	+	++
Two Way Bindings	- -	++	++
Abbildung von Datenbank Relationships im Modell	- -	- -	+
Programmierproduktivität	-	+	++
Größe der Entwickler-Community	++	+	+
Geschwindigkeit	+	o	+
Sicherheit vor Speicherlecks	-	++	++
automatisch testbar	+	+	++

(++ sehr gut, + gut, o noch in Ordnung, - schlecht, - - sehr schlecht)

Tipps zum Einstieg

Möchte man sich mit Ember.js beschäftigen, ist es wichtig darauf zu achten, bei der Suche nach Tutorials im Internet nur aktuelle Artikel zu lesen. Allein 2013 hat sich so viel getan, dass ein Artikel vom Januar im November oft völlig unbrauchbar ist. Innerhalb der Community wird darüber diskutiert, ob Ember vielleicht zu früh "sichtbar" geworden ist und sich dadurch – unnötigerweise – zu viele neue Entwickler durch Fehler abschrecken ließen. Das Ember-Core-Team stellt zwar mehr als deutlich klar, welche Version von Ember und der Bibliothek Ember-Data gerade Beta sind und welche nicht, viele Interessierte schätzen eine Beta allerdings schnell als "stabil genug" ein (was nicht der Fall ist) und stehen so bald vor Schwierigkeiten.

Ein guter Start für den Anfänger mit Englisch-Kenntnissen sind die Guides des Ember-Projekts. Auf emberwatch.com findet man aktuelle Vorträge und Tutorials zu Ember. In Deutschland gibt es außerdem Meet-ups von Ember-Entwicklern, die auf der Community-Seite verzeichnet sind.

Die im Folgenden als Beispiel verwendete Nutzerverwaltung besteht aus nur einer Datei ( index.html ). Bei einem großen Ember.js-Projekt würde man die einzelnen Elemente allerdings in eigene Dateien auslagern. Die folgenden Grundbibliotheken sind für das Projekt später notwendig:

<script src="http://code.jquery.com/jquery-1.10.2.min.js"></script>
<script src="http://builds.emberjs.com/handlebars-1.0.0.js"></script>
<script src="http://builds.emberjs.com/tags/v1.1.2/ember.js"></script>
<script src="http://builds.emberjs.com/tags/v1.0.0-beta.3/ember-data.js">
</script>
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups
/md5.js"></script>

jQuery lässt sich in der Version 1.x oder 2.x benutzen, während Ember.js in Version 1.1 Verwendung findet. Sie ist, nach einem für normale Ember.js-Entwickler anstrengendem 2013er-Release-Process, eine stabile und performante Version, die die Kinderkrankheiten der 1.0 vergessen lässt. Ember-Data muss momentan (November 2013) noch als Beta-Version eingebunden werden. Handlebars kommt darüber hinaus zum Einsatz, um die HTML-Templates zu schreiben. Übrigens: In all diesen Open-Source-Projekten arbeitet der Ember-Erfinder Yehuda Katz im Core-Entwicklerteam. Die als Letztes eingebundene Google Crypto-Bibliothek md5.js soll im Beispiel dazu dienen, um aus der E-Mail-Adresse eine MD5-Summe erstellen zu können und damit per Gravatar Fotos der Personen anzuzeigen.

Obwohl Ember-Data eine eigenständige Bibliothek ist, feiern sie viele Entwickler als die eigentliche Revolution des Ember-Frameworks. Mit ihr lässt sich von einer Ember-Applikation aus eine beliebige RESTful Schnittstelle per JSON bedienen. Wer die auf der Projektseite beschriebenen Konventionen auf Serverseite einhält, kann mit Ember-Data Daten aus der JavaScript-Applikation heraus transparent auf dem Server lesen und schreiben. Die Highlights bestehen dabei in Transaktionen, Rollbacks und die von ActiveRecord bekannten Associations has_many und belongs_to. Es gab vor Ember.js schon andere JavaScript-Frameworks, mit denen man gute Webapplikationen programmieren konnte, aber Ember-Data betritt Neuland.

Muster und Modelle

Das User-Model lässt sich mit folgendem Code definieren und per FixtureAdapter lokal im RAM speichern. Mit anderen Adaptern kann man später in der Produktion LocalStorage oder RESTful Server anbinden.

App.ApplicationAdapter = DS.FixtureAdapter;
App.User = DS.Model.extend({
  firstName: DS.attr('string'),
  lastName : DS.attr('string'),
  email : DS.attr('string'),
  phone : DS.attr('string'),
  fullName : function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName'),
});

fullName wird als Computed Property automatisch bei jeder Änderung der Attribute firstName oder lastName neu berechnet und zur Verfügung gestellt. Für den HTML-Inhalt der späteren Webseite kommt ein Handlebar-Template zum Einsatz. Das Erste ohne eine definierte ID bekommt von Ember per Konvention automatisch die ID application und wird damit als Haupt-Template benutzt. Innerhalb des Templates lässt sich per {{outlet}} definieren, an welcher Stelle Unter-Templates Inhalte einfügen können.