Aurelia 2 im Monorepo: Konvention statt Konfiguration, Stand rc.2

Das Aurelia-2-Monorepo und der Beta-Hinweis unter rc.2

Das Repository aurelia/aurelia ist das Monorepo von Aurelia 2. Es bündelt Kern- und Plugin-Pakete, Beispiele, Maßzahlen und Dokumentation für die kommende Hauptversion. Die Metadaten beschreiben das Vorhaben als standardbasiertes Frontend-Framework in TypeScript für anspruchsvolle Anwendungen. Die README nennt drei Leitlinien: enge Ausrichtung an den Spezifikationen der Webplattform, Konvention statt Konfiguration und möglichst wenig Einmischung des Frameworks in den eigenen Code.

Ein Hinweis in der README wiegt schwerer als die Leitlinien: Aurelia 2 befinde sich noch in der Beta-Phase, etliche Funktionen und Anwendungsfälle der öffentlichen Schnittstelle seien ungetestet, und es werde noch einige einschneidende Änderungen geben. Zugleich tragen die letzten drei Ausgaben die Kennungen v2.0.0-rc.2 vom 4. August 2026, v2.0.0-rc.1 vom 13. März 2026 und v2.0.0-rc.0 vom 14. Januar 2026. Wer Text und Ausgaben nebeneinander legt, sieht ein Projekt kurz vor der ersten Hauptversion, das die eigene Reife zurückhaltender einschätzt als die Versionsnummern.

app.js und app.html: Klasse plus Template als Konvention

Eine Aurelia-Komponente besteht der Konvention nach aus zwei Teilen: einer gewöhnlichen JavaScript- oder TypeScript-Klasse und einem zugehörigen HTML-Template. Das Beispiel im README zeigt eine Klasse App mit der Eigenschaft welcome und einem Feld quests, das drei Zeichenketten hält. Das Template greift auf beides zu, ohne dass Bindungen deklariert oder Dekorateure gesetzt werden müssen. Genau diese Selbstverständlichkeit ist der Kern der Konvention: Wer die Namensregel einhält, muss nichts registrieren.

Was das README hier nicht erklärt, ist mindestens so wichtig wie das Gezeigte. Es fehlen Angaben zur Dateiorganisation, zu den Namensregeln, zu verschachtelten Komponenten und zur Weitergabe von Werten zwischen ihnen. Für einen ersten Eindruck reicht das Beispiel vollkommen. Für ein Projekt mit mehr als einer Handvoll Ansichten führt der Weg in die Dokumentation unter docs.aurelia.io, die laut README selbst noch in Arbeit ist und deren Einstiegsteil als am vollständigsten gilt.

value.bind, repeat.for, if.bind und debounce:500 im Template-Beispiel

Das gezeigte Template enthält vier Bestandteile der Bindungssyntax. value.bind verbindet den Wert eines Eingabefeldes mit einer Eigenschaft, hier mit dem Zusatz debounce:500, der die Übernahme verzögert. repeat.for läuft über das Feld quests und erzeugt für jedes Element eine Auswahloption. if.bind schaltet einen Absatz ein oder aus, und eine Interpolation mit Dollarzeichen und geschweiften Klammern setzt einen Wert als Text ein.

Interessanter als die Liste ist, was offen bleibt. Das README sagt nichts über die zeitliche Steuerung von debounce, nichts über die Erneuerungsstrategie von repeat.for bei geänderten Feldern und nichts darüber, ob if.bind den Knoten aus dem Dokument entfernt oder nur verbirgt. Bei Formularen mit Gültigkeitsprüfung im unsichtbaren Zustand ist das ein Unterschied, der über das Verhalten beim Absenden entscheidet. Auch bleibt ungesagt, ob Bindungen von sich aus in beide Richtungen laufen oder nur vom Modell in die Ansicht. Diese Fragen beantwortet das Repository nicht.

npx makes aurelia gegen den examples-Ordner mit JIT-Aufbauten

Für ein neues Projekt nennt die README einen Weg: Nach der Installation von Node.js führt npx makes aurelia das Gerüstwerkzeug makes samt dem Aurelia-Generator herunter und leitet durch die Einrichtung. Einzelheiten zum Generator liegen in einem eigenen Repository unter github.com/aurelia/new. Weitere Befehle, Schalter oder eine nicht-interaktive Ausführung nennt das README nicht, was bei einer automatisierten Erzeugung in einer Pipeline ein Hindernis sein kann.

Wer diesen Weg nicht gehen will, findet im Ordner examples des Monorepos eine zweite Möglichkeit: reine JIT-Aufbauten ohne Konventionen, mit unterschiedlichen Ladern und Bündlern. Der Unterschied ist deutlich. Der Generator liefert ein Projekt nach den Vorstellungen der Maintainer, die Beispiele zeigen, wie Aurelia 2 ohne diese Vorgaben aussieht, und genau das hilft, wenn das Framework in eine bestehende Buildkette eingehängt werden muss. Welche Bundler dort abgedeckt sind, sagt das README nicht; nachsehen muss man im Ordner selbst.

Node.js v8.9.0 als genannte Untergrenze und die Abstände zwischen rc.0 und rc.2

Die genannte Untergrenze für die Laufzeitumgebung ist Node.js v8.9.0 oder höher. Diese Zahl stammt erkennbar aus der Entstehungszeit des Textes und liegt weit unter dem, was heutige Werkzeugketten voraussetzen. Ob sie noch gilt oder nur nicht nachgezogen wurde, lässt sich dem README nicht entnehmen. Bei einem Framework, dessen Gerüst über npx kommt, ist das die Stelle, an der ein Setup scheitert, bevor es richtig anfängt.

Aufschlussreich sind auch die Abstände zwischen den Ausgaben. Zwischen v2.0.0-rc.0 im Januar 2026 und v2.0.0-rc.1 im März 2026 lagen zwei Monate, zwischen rc.1 und rc.2 im August 2026 fünf Monate. Für ein Vorhaben, das laut eigener Aussage kurz vor der ersten Hauptversion steht, ist das eine lange Pause. Sie mag bedeuten, dass die verbleibenden Änderungen gründlich vorbereitet werden, und sie mag andere Gründe haben. Das Material gibt darauf keine Antwort.

SECURITY.md, MIT mit Blue Spire und was die README offen lässt

Zwei Punkte verdienen einen eigenen Blick. Für Sicherheitsfunde verweist das README auf eine Richtlinie in der Datei SECURITY.md und bittet ausdrücklich darum, einen Verdacht nicht als öffentliche Meldung einzustellen, sondern privat zu berichten. In einem Monorepo mit vielen Paketen ist das die vernünftige Regelung, und sie ist hier klar formuliert.

Die Lizenz ist MIT, und der zugrunde liegende Text nennt Blue Spire Inc. als Rechteinhaber. Nutzung, Veränderung, Zusammenführung, Veröffentlichung, Verbreitung, Unterlizenzierung und Verkauf sind erlaubt, solange Urheberrechtshinweis und Lizenztext in allen Kopien oder wesentlichen Teilen enthalten bleiben; eine Gewährleistung wird ausgeschlossen. Für den Einsatz in einem geschlossenen Produkt ist das die unkomplizierteste Variante, weil abgeleitete Werke nicht offengelegt werden müssen. Was darüber hinaus fehlt, betrifft den Betrieb: keine Wartungszusagen, kein Zeitplan für das Verlassen der Beta und keine Messwerte aus dem im Repository angekündigten Ordner für Benchmarks. Die Beschreibung im Vorspann, die von hoher Leistungsfähigkeit spricht, bleibt damit eine Behauptung des Projekts.

Redaktionelles Fazit

Passend ist Aurelia 2 für Teams, die ein konventionsgeführtes Framework mit Vorlagen in reinem HTML suchen und mit einer Schnittstelle leben können, die laut README teils noch ungetestet ist. Weniger passend ist es für Vorhaben mit festem Termin und ohne Bereitschaft zu einschneidenden Änderungen, weil zwischen rc.1 und rc.2 fünf Monate lagen und die Dokumentation als unfertig beschrieben wird. Vor dem Einstieg prüfen: ob der eigene Bundler im Ordner examples vorkommt, ob die genannte Node.js-Untergrenze von v8.9.0 zur eigenen Umgebung passt und ob die Fragen zu debounce und if.bind in docs.aurelia.io geklärt sind.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes