© Liashko/Shutterstock.com
Entwickler Magazin
Ember.js - das JavaScript-Framework für Frontends

MVC im Client

In der Java-Webentwicklung hat sich das Lager sehr früh zwischen Backend- und Frontend-Entwicklern geteilt. Als ehemaliger Backend-Entwickler muss ich auch gestehen, dass wir ein wenig auf die „anderen“ herabgeschaut haben: Wir nutzten Patterns, Standards und Methoden, um aus Granit gemeißelte Module zu bauen. Die „anderen“ waren froh, wenn deren Spaghetti-JS-Code unter IE4 und Firefox lief. Doch dann haben sie aufgeholt: Browser standardisierten sich, die Performance hat sich um Lichtjahre verbessert, TDD und BDD funktionieren auch für das Frontend beeindruckend gut, und neue Programmiersprachen und Frameworks haben dem Frontend die Layer näher gebracht als je zuvor.

Stefan Siprell


Bevor wir weitermachen, möchte ich mich vor den Front­end-Entwicklern verbeugen: die fragmentierte HTML-/CSS-/JavaScript-Landschaft hat viel zu viel Erfahrung und Expertise benötigt, als dass ich als „Backendler“ da mitreden könnte. Aber da sich alles standardisiert, trau ich mich wieder ran …

Heute möchten wir uns Ember.js als JS-Framework für Browseranwendungen anschauen. Im Gegensatz zu jQuery, Backbone und Co. ist Ember.js ein One-Stop-Shop für die gesamte App-Entwicklung. Die Geschäftslogik läuft zum Großteil im Browser, man springt nicht zwischen Seiten, und es wird lediglich das Model vom Server geholt bzw. auf dem Server gespeichert. Man verfolgt ausschließlich das Model-View-Controller-Pattern – es ist fast so, als würde man mit JPA, JSF und Session Beans im Browser arbeiten.

Geschichte

Ember.js erblickte 2007 im MIT unter dem Namen ­Sproutit das Licht der Welt. 2008 wurde das Framework zu SproutCore umbenannt und war das Herzstück der MobileMe- und iWork-Plattform der Firma Apple. Nach einem Intermezzo mit einer eigenen Firma und Face­book entstand 2011 aus SproutCore die Open-Source-­Plattform Ember.js.

Mittlerweile liegt der fünfte Releasekandidat vor, und das API hat sich stabilisiert. Bis vor Kurzem war es sehr nervenaufreibend, dass sich Dokumentation oder Stack Overflow immer auf obsolete API-Versionen bezogen.

Die wichtigste Erweiterung der Plattform ist eindeutig Ember Data, die aber noch nicht so weit in der Entwicklung ist. Zwar hat sich das API hier weitestgehend stabilisiert, man rät aber offiziell von einem produktiven Einsatz ab. Allerdings ist absehbar, dass man sich hier in großen Schritten der Version 1.0 nähert.

Die Anwendung und das Model

Für den Einsatz von Ember.js benötigt man jQuery, Handlebars und in der Regel auch Ember Data. jQuery sollte bekannt sein, Ember Data wurde schon erwähnt, Handlebars (wie auch Mustache) ist eine JS-basierte Templatesprache, die analog zu Velocity den Einsatz von Logik in der View Tier fast unmöglich macht. Um eine Anwendung mit Ember.js zu erstellen, genügt folgender Aufruf:

RezeptSammlung = Ember.Application.create();

RezeptSammlung ist nun eine Ember.js-Anwendung, allerdings versuche ich das Objekt eher als Namespace zu sehen denn als vollständige Anwendung. Alle weiteren Einstellungen oder Erweiterungen der Anwendung werden nun als Eigenschaften des Namespaces konfiguriert.

Da Ember.js das Model-View-Controller-Pattern verfolgt, schauen wir uns zunächst ein einfaches Model mit einer Eigenschaft an:

...

Entwickler Magazin
Ember.js - das JavaScript-Framework für Frontends

MVC im Client

In der Java-Webentwicklung hat sich das Lager sehr früh zwischen Backend- und Frontend-Entwicklern geteilt. Als ehemaliger Backend-Entwickler muss ich auch gestehen, dass wir ein wenig auf die „anderen“ herabgeschaut haben: Wir nutzten Patterns, Standards und Methoden, um aus Granit gemeißelte Module zu bauen. Die „anderen“ waren froh, wenn deren Spaghetti-JS-Code unter IE4 und Firefox lief. Doch dann haben sie aufgeholt: Browser standardisierten sich, die Performance hat sich um Lichtjahre verbessert, TDD und BDD funktionieren auch für das Frontend beeindruckend gut, und neue Programmiersprachen und Frameworks haben dem Frontend die Layer näher gebracht als je zuvor.

Stefan Siprell


Bevor wir weitermachen, möchte ich mich vor den Front­end-Entwicklern verbeugen: die fragmentierte HTML-/CSS-/JavaScript-Landschaft hat viel zu viel Erfahrung und Expertise benötigt, als dass ich als „Backendler“ da mitreden könnte. Aber da sich alles standardisiert, trau ich mich wieder ran …

Heute möchten wir uns Ember.js als JS-Framework für Browseranwendungen anschauen. Im Gegensatz zu jQuery, Backbone und Co. ist Ember.js ein One-Stop-Shop für die gesamte App-Entwicklung. Die Geschäftslogik läuft zum Großteil im Browser, man springt nicht zwischen Seiten, und es wird lediglich das Model vom Server geholt bzw. auf dem Server gespeichert. Man verfolgt ausschließlich das Model-View-Controller-Pattern – es ist fast so, als würde man mit JPA, JSF und Session Beans im Browser arbeiten.

Geschichte

Ember.js erblickte 2007 im MIT unter dem Namen ­Sproutit das Licht der Welt. 2008 wurde das Framework zu SproutCore umbenannt und war das Herzstück der MobileMe- und iWork-Plattform der Firma Apple. Nach einem Intermezzo mit einer eigenen Firma und Face­book entstand 2011 aus SproutCore die Open-Source-­Plattform Ember.js.

Mittlerweile liegt der fünfte Releasekandidat vor, und das API hat sich stabilisiert. Bis vor Kurzem war es sehr nervenaufreibend, dass sich Dokumentation oder Stack Overflow immer auf obsolete API-Versionen bezogen.

Die wichtigste Erweiterung der Plattform ist eindeutig Ember Data, die aber noch nicht so weit in der Entwicklung ist. Zwar hat sich das API hier weitestgehend stabilisiert, man rät aber offiziell von einem produktiven Einsatz ab. Allerdings ist absehbar, dass man sich hier in großen Schritten der Version 1.0 nähert.

Die Anwendung und das Model

Für den Einsatz von Ember.js benötigt man jQuery, Handlebars und in der Regel auch Ember Data. jQuery sollte bekannt sein, Ember Data wurde schon erwähnt, Handlebars (wie auch Mustache) ist eine JS-basierte Templatesprache, die analog zu Velocity den Einsatz von Logik in der View Tier fast unmöglich macht. Um eine Anwendung mit Ember.js zu erstellen, genügt folgender Aufruf:

RezeptSammlung = Ember.Application.create();

RezeptSammlung ist nun eine Ember.js-Anwendung, allerdings versuche ich das Objekt eher als Namespace zu sehen denn als vollständige Anwendung. Alle weiteren Einstellungen oder Erweiterungen der Anwendung werden nun als Eigenschaften des Namespaces konfiguriert.

Da Ember.js das Model-View-Controller-Pattern verfolgt, schauen wir uns zunächst ein einfaches Model mit einer Eigenschaft an:

...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang