akwa – unser hausinternes Frontend-Framework
Entweder benutzt man ein (Frontend-)Framework oder man entwickelt ein eigenes. Wir haben uns für letzteres entschieden und möchten es nun einmal vorstellen.
Es heißt: Entweder benutzt man ein (Frontend-)Framework oder man entwickelt sich sein eigenes. Wir haben uns für letzteres entschieden und möchten es nun einmal vorstellen.
Bereits in einem unserer ersten Blog-Beiträge verwiesen wir auf unser hausinternes Frontend-Framework "akwa". In dem Framework versuchen wir alles zu vereinen, das als Komponente gebündelt werden kann und auf den Seiten von heise online mehrfach Verwendung findet. Außerdem ist es unser Bestreben, dort auch Layout-Grundsätze festzuzurren, so beispielsweise einheitliche Abstände, Farben, Schriftgrößen und das Aussehen von Kästen. Über die Jahre ist akwa allerdings über diesen Anspruch hinausgewachsen, und teils hat auch Code seinen Weg dorthin gefunden, der für das Framework nie vorgesehen war. Vor der Entwicklung von akwa gab es auch einige Versuche mit fertigen Frameworks wie Bootstrap. Jedoch machten wir die Erfahrung, dass wir zu viel an unsere Bedürfnisse anpassen mussten und die fertigen Komponenten nie so hundertprozentig passten.
Die Anfänge
akwa hat bei uns mit der Zeit einiges an Wandel mitgemacht. Angefangen hatten wir mit den Ansatz, dass jede Komponente ein eigenes Repository mit eigener Versionsverwaltung war. Doch hatten einige Komponenten Abhängigkeiten zueinander (z.B. hatten viele die Typographie-Komponente als Abhängigkeit) und schnell befanden wir uns in der Abhängigkeitenhölle. Immerzu waren wir mit dem Aktualisieren von Paketen (alles als NPM-Pakete in einer hausinternen Registry) beschäftigt und besonders zu Anfang gab es natürlich diverse Breaking Changes. Das ganze Projekt war und ist nach SemVer versioniert. Dieses Konstrukt kam nicht über das erste Jahr hinaus. Der Gedanke war zwar schön, dass einige Projekte auch nur einzelne akwa-Komponenten hätten verwenden können, aber das lösten wir später anders.
akwa united
Die Grundsteine von akwa lagen bereits im Jahr 2016 und die Anfänge im produktiven Code von heise online fanden sich dann 2017. Das war auch das Jahr in dem wir uns zum Reboot entschlossen. Alle Komponenten wanderten in ein gemeinsames "akwa"-Projekt, teilten sich ein Changelog und diverse Bibliotheken. Das ganze Projekt wurde etwas ruhiger und wir hatten erneut eine Version 1 – ein Blick ins Changelog verrät den 10.08.2017 als initiales Release der zweiten 1.0.0-Version.
Neben der besseren Wartbarkeit gab es nun auch zum ersten Mal eine gemeinsame, komplette akwa-Dokumentation jeder einzelnen Komponente. Damit ist akwa bisher eines unser am besten dokumentierten und am saubersten versionierten Projekte.
Architektur von akwa
Im Framework lebt CSS (in Form von Sass) und JavaScript (vanilla). Jede Komponente gibt pauschal kein CSS aus außer wenige Ausnahmen. Die CSS-Ausgabe wird per Sass-Variable in der akwa-Config gesteuert. Viele Komponenten stellen ihre Funktionalität auch als Mixin zur Verfügung. Der Vorteil davon lässt sich gut am Grid zeigen. Unser Grid ist prinzipiell in zwölf Spalten eingeteilt, aber so granular benötigt heise online das eigentlich gar nicht. Die komplette Ausgabe des Grid-CSS für zwölf Spalten wäre unnötiger Ballast. Daher haben wir eine Layout-Komponente, die lediglich eine Aufteilung in Viertel ermöglicht (via CSS-Klassen).
Falls eine Komponente ausnahmsweise doch einmal ein anderes Grid benötigt, kann sie die Grid-Mixins benutzen, um beispielsweise ein Fünf-Spalten-Grid einzusetzen. Um unseren Code sauber und einheitlich zu halten, benutzen wir Stylelint und ESLint in Zusammenarbeit mit Prettier. Mittlerweile haben wir um die 60 Komponenten, die regen Einsatz auf den Seiten von heise online finden.
Liebgewonnene Fremdkörper
Die ersten Custom Elements bei heise online waren auch akwa-Komponenten. So geschah es, dass sich mit der Zeit ein Ökosystem an Helferlein, Polyfills und sonstigem Syntactic Sugar in akwa aufbaute, um entspannt Custom Elements zu entwickeln. Irgendwann fiel uns auf, dass sich nach und nach ein paar Fremdkörper eingeschlichen hatten, die eigentlich in einem Framework nichts zu suchen hatten. Wegen der Custom-Element-freundlichen Infrastruktur wurden nämlich alle Custom Elements in akwa entwickelt – auch wenn diese nur einen Einsatzzweck hatten und daher eigentlich nicht allgemeingültig waren, um im Framework zu landen.
Eine Unsauberkeit, die bis heute besteht, weil es eigentlich auch nicht wirklich stört. Vielleicht ändert sich irgendwann auch einfach nur die Beschreibung von akwa zu "Das Frontend-Framework von heise online". Spaß beseite, wir entwickeln akwa stets als Framework weiter.
Die Zukunft
akwa ist weiter im Wandel. Neben der angesprochenen Trennung, um es wieder zu einem reinen Framework zu machen, haben wir auch noch Pläne, es insgesamt freundlicher für unsere Fellow-Devs zu gestalten. Aktuell ist akwa ein NPM-Repository, das man in einem Projekt als Abhängigkeit einbinden und mittels eines Build-Prozesses (in unserem Fall derzeit Webpack) bauen muss, damit irgendwann hinten CSS und JavaScript herausfallen. Für Kolleginnen und Kollegen, die im Frontend-Dschungel nicht ganz so firm sind, ist so kein schnelles Setup möglich, um "mal kurz" etwas mit akwa auszuprobieren.
Eine Veröffentlichung des Frameworks ist übrigens nicht geplant. Anfangs hatten wir angedacht, dass man das eventuell irgendwann einmal machen könnte, jedoch ist uns inzwischen klar, dass es viel zu sehr auf unsere Bedürfnisse zugeschnitten ist. Je nachdem wie sich akwa weiter entwickelt, kann es gut sein, dass wir hier im Blog nochmal ein Update geben, was so mit der Zeit noch weiter aus akwa geworden ist.
Wie sind denn so die Erfahrungen unserer Leserinnen und Leser mit Frontend-Frameworks? Habt ihr auch eigene entwickelt oder habt ihr das perfekte Open-Source-Frontend-Framework gefunden, dass ihr bei jedem Projekt mit Freuden wieder einsetzt? Teilt gerne eure Erfahrungen und Gedanken dazu mit uns im Forum dieses Beitrags. (hih)
