Pattern Library mit Astrum

Im März 2016 sprach ich auf dem Webkongress Erlangen über Styleguides und die Tools, die es uns leichter machen (können), Styleguides und Pattern Libraries zu erstellen und zu warten. Mein Fazit damals war, dass es zwar viele Tools gibt, die auch in speziellen Anwendungsfällen funktionieren mögen, dass letztlich jedoch Stand damals PatternLab das Maß aller Dinge sei.

PatternLab all the things?

Inzwischen ist PatternLab in Version 2 erschienen, aber auch da muss ich einen meiner ursprünglichen zarten Vorbehalte dagegen erneuern – PatternLab ist für meinen Geschmack leider nicht leicht in jeden Workflow zu integrieren, zudem ist es für manche Projektgrößen vielleicht ein bisschen zu komplex. Bitte nicht falsch verstehen – PatternLab ist toll, durchdacht, sehr mächtig und ermöglicht bzw. unterstützt Arbeitsabläufe in einem Maße, in dem es andere Tools gar nicht können. Aber es hat dadurch eben auch eine Lernkurve und einen Mindestaufwand, den Zeit und Budget manchmal leider einfach nicht hergeben.

Als mögliche Alternative ist mir neulich Astrum über den Weg gelaufen.

Astrum versteht sich selbst als schlanke Pattern Library, die Komponenten in Gruppen organisiert darstellt, ohne Vorgaben an Markup oder Projektstruktur zu machen. Astrum ist Open Source (MIT-Lizenz) und besteht aus einem Kommandozeilen-Tool auf Node-Basis und einem (Single-Page-)Webinterface, welches das JS-Framework vue.js nutzt.

Eine Demo-Library gibt es übrigens auch.

Soweit ich es verstehe, lädt das Webinterface Komponenten und Assets aus der Ordnerstruktur dynamisch nach und bezieht sonstige Informationen wie Meta-Daten aus einer JSON-Datei, die man – und das ist ziemlich pfiffig – über das Kommandozeilen-Tool verwaltet.

Was Astrum anders macht

Um also z.B. eine neue Komponente blockquote in der Gruppe elements anzulegen, verwendet man den Kommandozeilenbefehl astrum new elements/blockquote. Astrum fragt dann noch ein paar Daten zur neuen Komponente ab, legt ein Verzeichnis und darin Dateien für Markup und Dokumentation der Komponente an und bindet beides in das Webinterface ein – beide muss man von Grund auf selbst schreiben; Astrum gibt nichts vor, setzt aber auch nichts voraus. Ob man also Atomic Design, BEM oder beides machen möchte, ist Astrum herzlich egal; ebenso ist man frei in der Wahl eines CSS-Frameworks, Prä- oder Postprozessors oder Build-Tools. Das ist für mich schon mal ein großer Vorteil.

Externe Assets wie Stylesheets oder Javascripte, aber auch Webfont-Bibliotheken kann man Astrum über die data.json einbinden lassen, ebenso lässt sich das (von Hause aus übrigens bereits responsive!) Theme des Webinterfaces anpassen und branden (sehr wichtig für Kunden – auch in der Pattern Library kann das eigene Logo nicht groß genug sein!) und man kann zusätzlich zu den Komponenten Seiten (z.B. zur Dokumentation) anlegen, die man genau wie die Komponenten-Dokumentation in Markdown schreibt.

Alles, was Astrum erfordert, legt ein astrum init projekt/verzeichnis dort ab, wo man es haben möchte. Das Webinterface benötigt einen einfachen (lokalen) Webserver, das Kommandozeilen-Tool logischerweise Node und man sollte keinen ganz steinalten Browser verwenden. Nichts davon dürfte heutzutage ein Problem sein. Da es Astrum völlig egal ist, wo man es ablegt, so lange seine eigenen Dateien dabei sind und es weiß, wo es externe Assets findet, dürfte es sich völlig unproblematisch in jede Projektstruktur und jeden Buildprozess integrieren lassen. Auch das finde ich überaus praktisch – ich ändere nicht gerne meine gewohnten Abläufe, damit der Styleguide funktioniert.

#wasfehlt

Astrum wird „nebenbei“ von zwei Developern entwickelt, die offen für Community-Beiträge sind. Natürlich hat es Haken, natürlich vermisst man Features; das wird auch individuell unterschiedlich sein. Was mir fehlt bzw. auffällt:

• Es gibt nur zwei Ebenen – Komponenten und Gruppen. Das schränkt die Möglichkeiten, die Patterns zu organisieren, schon sehr ein.
• Da keine Template-Engine wie etwa Handlebars zum Einsatz kommt, gibt es kein „Vererben“ von kleineren Komponenten in größere, wie es PatternLab macht. Hat man also z.B. eine Komponente für ein <input>, verwendet dieses in einer <form>-Komponente und ändert daran etwas, muss man an zwei Stellen ändern.
• Der Einsatz von Inhaltsvariablen ist mangels Template-Engine ebenfalls nicht möglich. Es gibt also keine an mehreren Stellen verwendbaren Platzhaltertexte etc.
• Als dynamisch nachladende Single-Page-WebApp ist Astrum natürlich etwas träger als eine optimierte Seite statisches HTML, und einen Export dorthin gibt es leider nicht. Denkbar, dass es bei sehr großen, fein granulierten Pattern Libraries auch mal langsam wird.
• Im Vergleich zu PatternLab fehlt der letzte Schritt zu Templates und Pages, also die Kombination von Komponenten zu ganzen Seiten bzw. Prototypen.

Ich kann eigentlich alle Punkte verschmerzen, weil die zuvor genannten Vorteile für mich wichtiger sind. Das „Wiederverwenden“ von Bausteinen wie in PatternLab wäre großartig, weil es meines Erachtens die Fehleranfälligkeit reduziert und den schleichenden „Verfall“ der Pattern Library eindämmt, aber es würde wohl Astrum erheblich komplexer machen. (Die Integration einer Art Template-Engine ist allerdings bereits vorgesehen, wie auch etliche andere Features.)