Webframework Ember.js bewegt sich in eine modulare Zukunft

Im Rahmen der EmberConf hat Ember.js-Mitschöpfer Tom Dale gemeinsam mit Yehuda Katz und Godfrey Chan die Entwicklung des clientseitigen Webframeworks Revue passieren lassen und einen Ausblick auf zukünftige Arbeiten gegeben. Zwar seien in den letzten Jahren so viele JavaScript-Frameworks auf dem Markt erschienen, dass sich mittlerweile die Frage stellen ließe, ob es nicht einfacher sei, Ember.js in den Maintenance-Mode zu versetzen und sich einzig auf die bestehende Nutzergemeinschaft zu konzentrieren, doch sieht Dale darin derzeit keine Option. Vielmehr wolle sich das Team darum bemühen, innovativ zu bleiben, ohne dabei alte Anwendungen zu zerstören und Projekte des letzten Jahres wie FastBoot, Engines und die Einführung der Rendering Engine Glimmer 2 hätten einen passenden Weg dazu aufgezeigt.

Bei den beiden erstgenannten war für den Erfolg wohl ausschlaggebend, dass es sich nur um die Ergänzung kleiner Primitiven gehandelt habe, während sich beim Rewrite der Engine die vorangegangenen Infrastrukturarbeiten ausgezahlt hätten. Fortan wolle das Ember.js-Team daher experimentierfreudiger zeigen und den Fokus auf die Implementierung fehlender Funktionen und Primitiven legen. Sollten bestehende Features Erneuerung bedürfen, wolle man dem bei Glimmer bewährten Muster folgen, und die neu geschriebene Version parallel zur alten laufen lassen, bis alle Tests ohne Anpassungen durchliefen.

Ember.js' Position stärken

Als Hauptgründe, sich nicht für Ember zu entscheiden, werden laut Dale wohl häufig die monolithische Struktur des Frameworks, seine Größe und das Custom Object Model genannt. Um die Verbreitung von Ember.js voranzutreiben, will sich das Team deshalb in nächster Zeit vor allem diesen Punkten widmen. Ein erster Schritt in die Richtung ist die Auskopplung der Rendering Engine als Glimmer.js, die sich nun als UI-Komponentenbibliothek unabhängig von Ember einsetzen lässt. Dabei wurde auch die API überarbeitet, sodass etwa das Wurzelelement von Glimmer im Template definiert ist und Glimmer-Komponenten ES6-Klassen sowie Decorators nutzen.

Die Glimmer-Komponenten sollen auch ein großer Teil der nächsten Entwicklungsschritte sein, da eines der Ziele ist, dass Entwickler sie durch das Installieren von Add-ons auch in Ember-Anwendungen einsetzen können. Dazu wurde vor Kurzem der RFC "Custom Component API" vorgestellt und die Arbeiten an der Module Unification für Ember-Anwendungen vorangetrieben. Ziel ist es, die zur Implementierung nötigen Primitiven in einem Add-on verfügbar zu machen. Darüber hinaus haben die Entwickler mit der Implementierung eines Routing Service begonnen, da bisher damit zusammenhängende Funktionen auf eine private API zurückgreifen mussten und der neue Ansatz die Möglichkeit öffnet, selbst entsprechende Helfer zu implementieren.

Auf lange Sicht soll Ember in kleinere Module aufgeteilt werden, die sich nach Bedarf nutzen lassen. Damit möchte das Team vom großen Gesamtpaket abrücken und andersherum auch die Möglichkeit bieten, dass Glimmer-Nutzer schrittweise auf Ember umsteigen können. Dabei ist es den Entwicklern wichtig, dass alle Module problemlos miteinander arbeiten können und sie Anwendungsprogrammierern durch die Umstrukturierung keine Integrationsarbeit auferlegen. (jul)