Entwicklung einer guten Frontend-Architektur: Grundlegende Prinzipien und bewährte Verfahren

Dieser Artikel befasst sich mit den wichtigsten Prinzipien, Vorteilen und praktischen Schritten zum Aufbau und zur Pflege einer guten Frontend-Architektur, darunter Modularität, Wiederverwendbarkeit und die Bedeutung eines gemeinsamen mentalen Modells unter den Teammitgliedern. Bleiben Sie in der Webentwicklung immer einen Schritt voraus, indem Sie Best Practices und Tools für automatisierte Prüfungen nutzen, angeleitet von Melanie Bucher – einer begeisterten Architektur-Enthusiastin.

Wir alle wollen gute, moderne Frontend-Anwendungen. In unserem digitalen Alltag als Nutzer möchten wir benutzerfreundliche, schnelle, stabile und verfügbare Anwendungen verwenden. Die Anbieter dieser Apps möchten langfristig profitable, leistungsfähige und sichere Apps besitzen. Und als Entwickler möchten wir gut funktionierende, wartbare und erweiterbare Apps entwickeln, die durch eine klare Codestruktur und eine gute Architektur erreicht werden.

Eine „gute“ Frontend-Architektur ist zwar der Schlüssel zum Aufbau einer Anwendung, die den Zielen und Anforderungen von Nutzern, Unternehmen und Entwicklern gleichermaßen gerecht wird, aber der Begriff selbst ist weit gefasst und vage. Sein Verständnis ist subjektiv und in der Praxis stark kontextabhängig.

Um einen tieferen Einblick zu erhalten, was eine gute Frontend-Architektur für uns bei MaibornWolff ausmacht und wie wir sie gemeinsam mit unseren Kunden in unseren Softwareentwicklungsprojekten umsetzen, habe ich mit fünf meiner erfahrenen Kollegen aus dem Bereich Webentwicklung darüber gesprochen, wie sie Frontend-Architektur in ihren agilen Entwicklungsteams persönlich konzipieren und anwenden.

Die Erkenntnisse meiner Kollegen bieten einen Überblick über das Thema – die Ziele, die wir mit einer guten Frontend-Architektur erreichen möchten, welche Aspekte entscheidend sind, wie man eine Architektur zu Beginn eines Projekts aufbaut und wie man eine gute Architektur in späteren Entwicklungsphasen aufrechterhält. Die allgemeinen Prinzipien sollten zwar für jede Entwicklungsplattform sowie für die mobile Entwicklung gelten, die in dieser Artikelserie diskutierten Beispiele und Erkenntnisse basieren jedoch hauptsächlich auf den persönlichen Erfahrungen meiner Kollegen im Bereich der Webentwicklung.

Wir beginnen mit einem Blick darauf, was Frontend-Architektur ist, welche Ziele wir damit erreichen wollen und welche Grundprinzipien im Entwicklungsprozess entscheidend sind.

Architektur befasst sich mit der Art und Weise, wie Software, insbesondere ihr Code, in Bausteine strukturiert und unterteilt wird. Ein Frontend-Architekt konzentriert sich auf das Gesamtbild der Struktur einer Anwendung – aus welchen Teilen eine Software besteht und wie diese verschiedenen Softwareteile miteinander interagieren. Der Fokus liegt also auf der allgemeinen strukturellen Anordnung einer Anwendung und nicht auf der spezifischen Implementierung der verschiedenen Teile. Im Idealfall ist die Implementierung der Bausteine der Software austauschbar, d. h. einzelne Bausteine sind voneinander unabhängig. Dadurch sind sie auch wiederverwendbar.

Mit Blick auf die technische Umgebung einer Anwendung umfasst die Architektur auch den Tech-Stack der Anwendung und die Struktur um sie herum, z. B. ob sie in mehrere Frontend-Systeme eingebettet ist und wie sie mit einem oder mehreren Backend-Systemen zusammenarbeitet. Auf der Client-Seite kann die Architektur durch Leistungsanforderungen, Browser-Einschränkungen hinsichtlich Bandbreite oder Speicher sowie Geräteabhängigkeiten beeinflusst werden. Dazu gehören auch nicht-funktionale Anforderungen wie die HTML-Struktur für Suchmaschinenoptimierung und Barrierefreiheit.

Das Aufstellen einer Architektur ist wie das Errichten eines Fundaments auf einer grünen Wiese, und wir müssen sicherstellen, dass dieses Fundament stabil ist und uns ermöglicht, die Anwendung weiter auszubauen und zu erweitern. Entscheidungen über das Framework, die Bibliotheken und die Codierungspraktiken geben hilfreiche Richtungen vor und schränken möglicherweise die Architektur ein. Folglich hängt die zukünftige Entwicklung in hohem Maße von der anfänglichen Einrichtung ab.

Bei der projektbasierten Entwicklung ist es unser Ziel, die technischen Funktionen und Anforderungen der App innerhalb eines bestimmten Zeitrahmens und unter Berücksichtigung der Fähigkeiten des Teams mit den bestmöglichen qualitativen Eigenschaften umzusetzen. Mit einer guten Architektur stellen wir sicher, dass die Anwendung:

Bestimmte Architekturmuster können auch dabei helfen, nicht-funktionale Anforderungen wie die Performance zu erfüllen, da es Tools wie Lighthouse gibt, die die Seitengeschwindigkeit während der Entwicklung berücksichtigen, wenn die Architektur die Anforderungen der Tools erfüllt. Darüber hinaus reduziert eine saubere und klare Architekturstruktur die mentale Belastung der Entwickler, fördert ein gemeinsames Verständnis im Team und erleichtert die Einarbeitung neuer Entwickler, was wiederum den Geschäftszielen zugute kommt.

Aus den Interviews mit meinen Kollegen haben sich bestimmte Schlüsselbereiche herauskristallisiert, auf die sie bei der Frontend-Architektur besonders achten. Dazu gehören die Auswahl des Frameworks, die Modularisierung, der Datenfluss, die Trennung der Komponenten und eine ausgewogene Dateistruktur.

1. Auswahl eines Frameworks

Da zu Beginn eines Projekts in der Regel nicht alle Informationen verfügbar sind, ist es wichtig, so viele Erkenntnisse wie möglich vom Kunden einzuholen, indem man beispielsweise folgende Fragen stellt:

• Wie lange wird das Projekt laufen?
• Wie viele Entwickler daran arbeiten werden
• Wie oft die Entwickler wechseln werden
• Wie groß das Projekt werden könnte
• Welche geschäftliche Relevanz es hat

Die Antworten auf diese Fragen können Ihnen einen guten Eindruck vom Umfang der Anwendung und der Produktvision vermitteln, in welche Richtung sie sich entwickelt und welche geschäftlichen Ziele ihre Entwicklung vorantreiben. Überlegen Sie, ob der Kunde möglicherweise bereits eine Präferenz für bestimmte Technologien hat, ob das Team bereits steht und über welche Kenntnisse es verfügt. Beginnen Sie dann mit einer bestmöglichen Einschätzung, wobei Sie den Grad der Interaktivität der Anwendung berücksichtigen und prüfen, ob das in Betracht gezogene Framework es Ihnen ermöglicht, einen kleinen Basisprototyp zu erstellen, damit Sie zu Beginn keine zu hohen Hürden oder Einschränkungen haben.

Darüber hinaus ist es wichtig zu evaluieren, wie der Prozess für Design und UX im Projekt gehandhabt wird, da dieser sehr früh integriert werden muss und seine Bedeutung für die Geschäftsziele zunimmt. Sie können auch prüfen, ob Meta-Frameworks wie Next.js, Remix oder Nuxt.js, die bestimmte Architekturmuster festlegen, für Ihren Anwendungsfall geeignet sind. Schließlich empfiehlt es sich, geeignete Bibliotheken zu verwenden, da es im Ökosystem des Frameworks oft viele gute Lösungen gibt, wobei darauf zu achten ist, dass diese gut zusammenarbeiten. Es ist weniger empfehlenswert, alles selbst zu entwickeln, da Sie dann auch allen anderen alles erklären müssen.

2. Modularisierung

Modularisierung bedeutet, Grenzen im System zu ziehen, um Module sauber voneinander zu trennen und sie so unabhängig wie möglich zu halten. Um geeignete Grenzen zu finden, überlegen Sie, welches Modul zu welcher Funktion gehört, und überlegen Sie, wie Funktionen in Geschäftsbereiche gruppiert werden können. Jedes Modul benötigt bestimmte Daten und sollte idealerweise nur das erhalten, was es benötigt. Um Überschneidungen zu minimieren und Module getrennt zu halten, analysieren Sie, wo sich die Abhängigkeiten in Ihrem System befinden. Es sollte auch so wenige technische Komponenten wie möglich geben, mit Ausnahme globaler Elemente wie Protokollierung und Authentifizierung, die an einem zentralen Ort gespeichert werden sollten.

Da die Modularisierung trotz ihrer Vorteile jedoch die Komplexität von Apps erhöhen kann, sollten Sie andere Auswirkungen wie eine mögliche Verringerung der Seitengeschwindigkeit berücksichtigen. Es ist auch vorteilhaft, über die Auswirkungen nachzudenken, die die Modularisierung Ihrer Funktionen auf die zukünftige Aufteilung des Teams haben kann.

3. Komponententrennung

Ähnlich wie bei der Modularisierung, jedoch auf einer detaillierteren Ebene, sind in modernen Frontends Code-Blöcke in der Regel in Komponenten enthalten, was als komponentenbasierte Architektur bezeichnet wird. Komponenten sollten nur eine einzige Aufgabe haben, sodass sie eigenständige Elemente sind, die über ihre Schnittstelle mit anderen Elementen kommunizieren. Sie sollen in Ihrer Anwendung oder sogar in verschiedenen Anwendungen wiederverwendbar sein, wodurch ihre Verwendung modular und flexibel wird. Die Anwendung wird insgesamt aus diesen unabhängigen Komponenten zusammengesetzt, wobei kleinere untergeordnete Komponenten flexibel in größeren, stärker angepassten übergeordneten Komponenten verwendet werden können.

Es ist wichtig, kleine, wiederverwendbare und möglichst fein abgestimmte Komponenten zu erstellen. Dies kann beispielsweise durch folgende Maßnahmen erreicht werden:

• Unterscheidung zwischen repräsentativen und logischen Komponenten durch klare Trennung
• Kapselung von Daten in eine Abstraktion, um Daten über einen einzigen Punkt in der Anwendung zugänglich zu machen (z. B. in React mit der Context API)
• Schaffung von Einheitlichkeit bei der Komponentenimplementierung und Erwägung der Einführung einer gemeinsamen Komponentenbibliothek

Der Vorteil der Erstellung zusammenhängender, aber unabhängiger Komponenten besteht zum einen darin, dass ihre Wiederverwendbarkeit eine schnellere Entwicklung ermöglicht. Sie können auch an einem zentralen Ort aktualisiert oder erweitert werden, was die Wartung erleichtert. Bei großen Projekten kann die Unabhängigkeit der Komponenten es Teams auch ermöglichen, in kleineren Teams zu arbeiten, da die Schnittstellen bei Änderungen der internen Implementierungen stabil bleiben.

4. Datenfluss und Schnittstelle

Da jede Anwendung eine Komponentenstruktur hat, die mit der Wurzel beginnt, ist es wichtig, einen logischen, konsistenten und leicht verständlichen Datenfluss einzuführen. Dadurch lässt sich leichter nachvollziehen, woher Daten stammen und wohin sie geleitet werden, was die Fehlersuche erleichtert.

Bei einer Eltern-Kind-Komponentenstruktur ist darauf zu achten, dass Informationen in den Komponenten nur in eine Richtung fließen – nur von Eltern- zu Kindkomponenten – und dass die Elternkomponente die Kindkomponente steuert. Es ist jedoch entscheidend, die Komponenten entkoppelt zu halten, was durch andere Formen der Datenbereitstellung für Komponenten, wie z. B. Dateninjektion, ermöglicht wird. Insgesamt ist ein Gleichgewicht zwischen einem klaren und gerichteten Datenfluss und der Isolierung der Komponenten erforderlich. Dazu ist ein zentrales Statusmanagement erforderlich, das die erforderlichen Daten speichert und aktualisiert und den Komponenten nur das zur Verfügung stellt, was sie benötigen.

Das Statusmanagement ist eine Besonderheit der Frontend-Entwicklung, da die vom Benutzer im Browser eingegebenen Daten, also der Frontend-Status, mit dem Backend synchronisiert werden müssen. Da diese Tools nicht so einfach zu erstellen sind, gibt es viele davon auf dem Markt. Die Einrichtung ist zwar mit einem gewissen Aufwand verbunden, aber die Wahl einer geeigneten Technologie für die Statusverwaltung ist von entscheidender Bedeutung. Dies ist letztlich eine architektonische Entscheidung, die vom jeweiligen Projektkontext abhängt, da sie Ihren Anforderungen entsprechen und sich gut in das gewählte Framework und die Bibliotheken integrieren lassen sollte. Wenn Sie Stores oder Bibliotheken für die Statusverwaltung verwenden, achten Sie darauf, dass Sie das Dependency-Inversion-Muster verwenden, um eine enge Bindung Ihrer App an eine bestimmte Store-Implementierung oder Store-Technologie zu vermeiden.

Beachten Sie beim Entwerfen von Schnittstellen das Inversionsprinzip und legen Sie im Voraus fest, wer die Schnittstelle bestimmt – der Verbraucher oder der Produzent. Im Allgemeinen ist es sehr nützlich, Ihren Code an den SOLID-, DRY- und YAGNI-Prinzipien auszurichten, aber manchmal lohnt es sich, diese zu hinterfragen oder zu brechen. Achten Sie also darauf, wo sie eher hinderlich als hilfreich sind. Einer meiner Kollegen, der als Webarchitekt tätig ist, hat beispielsweise sein eigenes „Prinzip der minimalen Schnittstelle“ entwickelt, wonach eine Schnittstelle (oder jede andere Sache) nur das Nötigste tun sollte, um die vorgegebene Anforderung zu erfüllen. Dadurch werden die Gründe für eine Änderung der Schnittstelle minimiert und diese wird robuster und stabiler. Er testet Schnittstellen und anderen Code anhand der folgenden Fragen:

• Was ist das Minimum, das ich einfügen und herausholen muss?
• Steht die minimale Lösung in einem guten Verhältnis zur Leistungsfähigkeit der Lösung? Mit anderen Worten: Wie leistungsfähig ist die kleinste Lösung? Im Idealfall finden Sie die kleinste Lösung mit der größten Leistungsfähigkeit.

Vermeiden Sie außerdem, etwas zu erstellen, das nicht in dem von Ihnen verwendeten Framework berücksichtigt ist, sondern halten Sie sich an dessen Regeln.

5. Ausgewogene Dateistruktur

Einerseits kann es schwierig sein, den Überblick zu behalten, wenn sich viele Dateien in einem Ordner befinden, und es kann chaotisch wirken. Andererseits kann eine zu tiefe Hierarchie mit vielen verschachtelten Ordnern den Inhalt unübersichtlich machen, sodass es schwierig ist, das Gesuchte zu finden. Eine ausgewogene Struktur, die für Ihren Anwendungsfall geeignet ist, z. B. mehrere übergeordnete Ordner, in denen eine kleine Anzahl von Unterordnern gruppiert sind, kann beide Probleme mit zunehmender Größe der Codebasis mindern. Mit einer relativ flachen Hierarchie, also durch die Verwendung einer Reihe kleiner Ordner und Dateien, wird jede Komponente oder unabhängige Funktion in einer eigenen Datei abgelegt. Auch wenn dies die Komplexität einer großen Codebasis nicht vollständig beseitigt, sondern nur horizontal verlagert, ermöglicht die Verwendung vieler kleiner Elemente auf wenigen Ebenen in der Regel einen besseren Überblick.

Wenn das von Ihnen gewählte Framework eine vorgegebene Struktur hat, ist es am sinnvollsten, sich daran zu halten. Innerhalb dieser Struktur können Ordner beispielsweise funktional oder logisch nach Domänen geordnet werden. Sie können die Ordnerstruktur auch danach ausrichten, wie die App verwendet wird, indem Sie beispielsweise eine Web-App so aufbauen, als hätte sie Seiten, selbst wenn es sich um eine Single-Page-Anwendung handelt, da ein Browser seitenbasiert ist. Eine Webanwendung, die im Browser landet, könnte beispielsweise in Ordnern für jede Seite strukturiert sein, mit den dazugehörigen Komponenten daneben.

Zusammenfassend lässt sich sagen, dass die Berücksichtigung dieser allgemeinen Grundsätze und der Ziele einer guten Frontend-Architektur dabei helfen kann, einen konsistenten Ansatz zu finden, der ein langfristiges Wachstum der Anwendung ermöglicht.

Wir werden uns zu Beginn eines Projekts genauer mit dem Prozess der Entwicklung einer Architektur für Ihre Frontend-Anwendung befassen. Bleiben Sie dran!

Es gibt kein perfektes Referenzprojekt, das alle architektonischen Probleme löst. Die Entwicklung einer guten Architektur für Ihr spezifisches Projekt ist daher eine Frage der Einrichtung einer Architektur, die für das Projekt geeignet ist, gut angewendet wird, allgemein bekannt ist und als Verpflichtung im Team geteilt wird.

Architektur ist nicht nur ein technisches Gerüst. Sie ist auch etwas, das wir als Entwickler nutzen, um das System auf abstrakte Weise zu verstehen, wie ein mentales Modell davon, wie wir über die Anwendung denken. Wenn alle im Team dasselbe mentale Modell teilen, können wir ein gemeinsames Verständnis erreichen und effektiv mit anderen Entwicklern kommunizieren.

Wann entsteht also eine Architektur? Man könnte argumentieren, dass ein einzelner Mensch gar keine Architektur benötigt, solange er sich im Projekt auskennt und den Überblick behält. Aber selbst wenn nur eine Person eine Anwendung programmiert, hat der Code immer eine implizite Architektur, auch wenn diese inkonsistent oder schwer nachvollziehbar ist. Daher geht es insbesondere in einem Team darum, die Architektur einerseits explizit und andererseits konsistent zu gestalten. Je besser Sie sich Ihrer Architektur und des Gesamtbildes bewusst sind, desto bewusster können Sie sie aufbauen und explizite Regeln in Ihrem Team bekannt machen. Dieses gemeinsame Verständnis ermöglicht es Ihrem Team, Probleme konsistent zu lösen.

Darüber hinaus ist es für das gesamte Team hilfreich, einen guten Einblick in die Vision des Product Owners zu erhalten, wie er die Anwendung in der Zukunft sieht und welchen Zweck sie erfüllen soll. Die Kommunikation dieser Informationen innerhalb des Entwicklerteams ermöglicht es allen, einen realen Kontext und Anwendungsfälle zu haben, mit denen sie ihr eher abstraktes, gemeinsames mentales Modell verknüpfen können. Wenn Sie zusätzlich zur anfänglichen Anforderungsanalyse die Rahmenbedingungen kennen und wissen, wie die Anwendung in zwei Jahren idealerweise aussehen soll, können Sie entsprechend planen, auch wenn Ihr Unternehmen vielleicht nur ein Jahr lang an dem Projekt arbeitet, bis es an die interne Entwicklung übergeben wird.

Die genauen Details Ihrer Umsetzung hängen zwar von Ihrem Projekt und dessen Kontext ab, aber die Interviews mit meinen Kollegen ergaben einige Punkte, die Sie in der Anfangsphase des Projekts beachten sollten, um langfristig eine gute und stabile Frontend-Architektur zu erreichen.

1. Klein anfangen und Veränderungen begrüßen

Wie richten Sie Ihre App zu Beginn so ein, dass Sie darauf vorbereitet sind, dass sie von einer kleinen Anwendung zu einer großen Anwendung mit vielen Features und Funktionen wird? Die meisten waren der Meinung, dass es hilfreich ist, klein anzufangen und iterativ vorzugehen, um in Gang zu kommen und sich auf die Probleme zu konzentrieren, die gerade gelöst werden müssen. Mit jeder Iteration passt sich die Komplexität der Anwendung dann an die Projektphase an, und Sie vermeiden, etwas zu entwickeln, das Sie später nicht mehr brauchen (YAGNI).

Vielleicht möchten Sie zu Beginn ein kleines Wasserfallmodell verwenden, damit Sie keine wesentlichen Elemente und Hilfsmittel wie Linting und automatisierte Qualitätsprüfungen vergessen, aber auch nur das lösen, was in dieser Phase gelöst werden muss. Fügen Sie dann auf agile Weise nach und nach weitere Elemente hinzu und überarbeiten Sie das Ganze im Laufe der Zeit. Sie könnten auch mit einem ersten Beispiel-Setup beginnen und sehen, wie es sich nach einer Weile bewährt. Nachdem die ersten User Stories fertig sind, bewerten Sie sie, schreiben Sie sie zur Bereinigung um und behalten Sie sie ab diesem Zeitpunkt so bei. Sie können dies auch als Proof-of-Concept durchführen, den Sie nach kurzer Zeit verwerfen und auf dessen Grundlage Sie dann mit dem, was Sie gelernt haben, von vorne beginnen.

Berücksichtigen Sie auch die Erfahrung Ihrer Teammitglieder, da diese täglich mit der Architektur arbeiten müssen. Eine festgelegte Struktur, die Sie zu Beginn bereitstellen und kommunizieren, kann Junior-Entwicklern mehr Sicherheit geben.

Es ist zwar wichtig, die langfristige Produktvision zu kennen, aber wenn Sie zu Beginn zu groß denken, kann dies zu Überengineering und unnötiger Komplexität in der Anwendung führen. Hier ist es wichtig, die Dinge einfach zu halten (KISS): Finden Sie etwas, das vorerst funktioniert und mit dem Wachstum der Anwendung leicht umgestaltet werden kann. Versuchen Sie, potenzielle Hindernisse im Voraus zu erkennen, aber bleiben Sie auch auf dem Komplexitätsniveau, das zum aktuellen Zeitpunkt erforderlich ist. Am wichtigsten ist eine hohe Flexibilität und Erweiterbarkeit der Anwendung, damit sie auch dann für Wachstum gerüstet ist, wenn in Zukunft ein großes Entwicklerteam daran arbeitet.

2. Verwendung projektspezifischer Konventionen für Konsistenz

Während Sie klein anfangen und wie oben beschrieben iterativ arbeiten, sollten Sie so früh wie möglich versuchen, bewährte Vorgehensweisen zu etablieren. Eine gute Architektur soll Ihnen im Laufe der Projektentwicklung immer helfen und Ihnen Arbeit abnehmen. Dies kann sie leisten, indem sie einen konsistenten und klaren Rahmen mit expliziten Regeln für die Entwicklung bereitstellt.

Zu Beginn eines Projekts wird der Rahmen wahrscheinlich recht schnell festgelegt, und nachdem Sie evaluiert haben, welche weiteren Tools Sie verwenden möchten, erstellen Sie eine erste Struktur, die als Ausgangspunkt für alles Weitere dient. In dieser Projektphase ist es entscheidend, zu Beginn erste Entscheidungen zu treffen, um sicherzustellen, dass die Anwendung eine leicht verständliche Struktur und einen klaren Datenfluss aufweist. Explizite Konventionen können festgelegt werden für:

• Benennung: logisch konsistente Benennung von Variablen, Funktionen, Klassen und Komponenten sowie Groß-/Kleinschreibungsregeln für verschiedene Elemente und Dateien
• Dateiorganisation: Verwendung konsistenter Ordner- und Dateistrukturen
• Komponentenstruktur: Die Organisation des Codes in logische Komponenten und die Art und Weise, wie eine Komponente aufgebaut ist, ihren Zustand beibehält oder Daten bezieht
• Importe: Festlegung der zulässigen Importtypen und der Module, die aus welchen Modulen oder Bibliotheken importieren dürfen, d. h. wie Abhängigkeiten zwischen verschiedenen Teilen der Codebasis verwaltet werden
• Best Practices und Designmuster: Gemeinsame Verwendung von Designmustern für das Schreiben von effizientem und skalierbarem Code und für die effektive Nutzung von Bibliotheken von Drittanbietern
• Kommentierung: Konsistente Verwendung von Kommentaren und ein klarer Kommentierungsstil
• Fehlerbehandlung und Protokollierung: Konsistente Vorgehensweisen für die Fehler- und Ausnahmebehandlung und Richtlinien für die Protokollierung
• Testen: Abdeckung der Codebasis mit konsistenten Mustern in Unit- und Integrationstests
• Formatierung: Einrückungen, Abstände und Zeilenumbrüche für bessere Lesbarkeit

Es ist wichtig, sich an diese bewussten Entscheidungen zu halten, sobald sie festgelegt wurden, damit sie klar bleiben und durchgängig umgesetzt werden können. Die Bemühungen aller, sich so weit wie möglich an die Architektur zu halten, führen auch zu nützlichen Codierungsbeispielen, die neuen Entwicklern im Team als Orientierung dienen.

Langfristig helfen Konventionen, indem sie die kognitive Belastung reduzieren und Einheitlichkeit gewährleisten. Es ist einfacher, neue Dinge umzusetzen, wenn man dem bereits etablierten Muster folgt, was auch das Wachstum in späteren Phasen erleichtert.

Wir haben gesehen, dass man sich, sobald man sich für einen Ansatz entschieden hat, daran halten sollte, um die Konsistenz in der Zukunft zu gewährleisten. Man muss aber auch offen für Veränderungen und hinterfragen, wenn nötig. Frontend-Anwendungen sind „lebende“ Strukturen, die sich im Laufe der Zeit verändern und wachsen. Einige Dinge, die Sie in der Vergangenheit entwickelt haben, sind möglicherweise irgendwann nicht mehr geeignet, um die aktuellen Anforderungen zu erfüllen, und leisten einfach keine gute Arbeit mehr, sodass eine Umgestaltung erforderlich wird. Eine Umgestaltung kann neue Möglichkeiten eröffnen und aus diesem Grund begrüßt werden. Nach Abschluss der Umgestaltungsänderungen ist es entscheidend, die Konsistenz wiederherzustellen. Lösungen und neue Best Practices müssen gut kommuniziert und Änderungen explizit gemacht werden, damit neue Muster wieder konsistent befolgt werden können.

Zusammenfassend lässt sich sagen, dass Sie mit kleinen Schritten und der Bereitschaft zu Veränderungen bei gleichzeitiger Einhaltung klar festgelegter Konventionen eine gute Grundlage für Ihr Frontend schaffen. Konsistenz ist entscheidend und ermöglicht außerdem die Entwicklung eines gemeinsamen mentalen Modells in Ihrem Team, was die Kommunikation verbessert.

Bleibt die Frage, wie wir diese architektonische Grundlage, die wir geschaffen haben, langfristig aufrechterhalten können, um unser Frontend über den gesamten Projektlebenszyklus hinweg skalierbar, leistungsfähig und wartbar zu halten. Wir werden daher näher darauf eingehen, wie ein Team zusammenarbeiten kann, um eine gute Frontend-Architektur aufrechtzuerhalten. Außerdem werden wir Tools und Techniken untersuchen, mit denen automatisierte Prüfungen dies unterstützen können.

Im Laufe der Zeit hängt die Architektur davon ab, wie Entwickler mit ihr interagieren und Änderungen daran vornehmen. Die Frontend-Architektur unterliegt in der Regel wenigen Einschränkungen und ist flexibel, insbesondere bei komponentenbasierten Architekturen, die auf Bibliotheken und Frameworks wie React oder Vue.js basieren, mehr noch als beispielsweise bei Angular-Anwendungen. Flexibilität ist zwar gut, da sie die Erweiterung der Anwendung erleichtert, aber sie macht sie auch anfälliger für divergierende Strukturen oder Chaos. Deshalb ist es entscheidend, sicherzustellen, dass neuer Code in die bestehende Architektur passt. Dies kann erreicht werden, indem jemand im Team für die architektonische Übersicht verantwortlich ist und eine Reihe geeigneter automatisierter Prüfungen und Tools eingesetzt werden.

Wie im vorherigen Artikel erläutert, trägt die Einrichtung einer ersten Architekturstruktur in Ihrem Frontend, einschließlich einiger Konventionen darüber, wie Dinge in Ihrer gesamten Anwendung auf die gleiche Weise funktionieren, dazu bei, die Entwicklung eines gemeinsamen mentalen Modells in Ihrem Team zu fördern. In der weiteren Folge geht es darum, die ursprüngliche Struktur bei Bedarf an den richtigen Stellen anzupassen und sie mit dem Wachstum der Anwendung zu pflegen. Mindestens eine Person sollte dafür verantwortlich sein: die Übersicht über die architektonischen Aspekte während des gesamten Projekts zu behalten. Je nach Größe und Erfahrung des Teams und den Anforderungen des Projekts kann die Rolle des Architekten etwas variieren. Die Verantwortung kann hauptsächlich von einem Architekturleiter übernommen werden, auf das gesamte Team verteilt werden oder in großen Projekten einem speziellen Team obliegen.

1. Leitender Architekt in einem Team

In Teams mit wenigen erfahrenen und vielen unerfahrenen Entwicklern kann es sinnvoll sein, ein bis zwei Personen zu haben, die für die Frontend-Architektur der Anwendung verantwortlich sind. Sie können als „Sprecher“ betrachtet werden. Sie nehmen das Thema ernst und verfügen über fundierte Kenntnisse und ein tiefes Verständnis dafür. Idealerweise haben sie den Beginn des Projekts miterlebt und vor allem eine Vision für die Zukunft sowie Pläne, wie diese umgesetzt werden kann. Sie setzen sich innerhalb und außerhalb des Teams für die Architektur ein, beispielsweise in Bezug auf neue Anforderungen, sei es durch notwendige Anpassungen oder durch die Wahrung der Konsistenz. Sie übernehmen auch Verantwortung für übergreifende Themen wie Barrierefreiheit, Internationalisierung und Performance.

Anstatt nur Top-Down-Anweisungen zu geben, sollte das Ziel des Sprechers darin bestehen, Kompetenzen an alle Teammitglieder weiterzugeben. Im Idealfall sollte jeder im Team in der Lage sein, die Architektur selbst aufrechtzuerhalten – die Rolle des Architekten besteht dann darin, „sich selbst theoretisch überflüssig zu machen“, wie es einer meiner Kollegen formuliert hat. Sprecher können andere Entwickler aktiv in die Entwicklung von Verbesserungen für neuen Code einbeziehen. Sie können auch die Leitprinzipien bekannt machen und für alle zugänglich machen, beispielsweise durch schriftliche oder visuelle Dokumentation oder durch eine gute Kommunikation. Dennoch sollte neben kompetenten Teammitgliedern mindestens eine Person die Rolle übernehmen, dafür zu sorgen, dass neuer Code den vereinbarten Prinzipien entspricht, und die Verantwortung dafür übernehmen.

Darüber hinaus sind Einblicke und Weitsicht hinsichtlich der weiteren Entwicklung der Anwendung für die Rolle eines Architekten von unschätzbarem Wert, und „Denken ist billiger als Entwickeln“, wie einer meiner Kollegen sagte. Wenn er mit neuen Herausforderungen konfrontiert ist, für die es in der Regel keine einzige Lösung gibt, versucht er beispielsweise immer, mehrere Lösungen zu finden, die das Problem mit dem geringsten Aufwand lösen. Eine hilfreiche Frage zum Vergleich potenzieller Lösungen könnte lauten: Wenn man das vorliegende Problem betrachtet, welche Lösung erfüllt alle aktuellen Anforderungen, ist robust gegenüber Änderungen und verursacht gleichzeitig weniger oder vergleichbare Kosten wie andere potenzielle Lösungen?

Ähnliche Leitfragen können für das Refactoring gelten. Da Architektur etwas Lebendiges ist, das sich weiterentwickeln kann und muss, ist Refactoring Teil des Prozesses. Die Bewertung, welche Teile im Zuge des Wachstums der Anwendung von einem Refactoring profitieren könnten, und die anschließende Umsetzung dieser Änderungen in angemessenen Abständen führen ebenfalls zu einer kontinuierlichen Auseinandersetzung mit der Frontend-Architektur.

2. Geteilte Verantwortung in einem großen Team

In größeren Teams mit einer größeren Anzahl von erfahrenen Entwicklern können mehrere Personen als Architektur-Sprecher fungieren und die Verantwortung dafür teilen. Sie können Probleme und mögliche Lösungen diskutieren und gemeinsam Entscheidungen treffen, die dann im gesamten Team geteilt und kommuniziert werden.

3. Architektur-Lead-Team für mehrere große Teams

In sehr großen Projekten, in denen mehrere große, unabhängige Teams an einer Anwendung arbeiten, kann jedes Team mindestens ein Teammitglied haben, das die Rolle des Architekturleiters übernimmt. Diese Personen treffen sich dann regelmäßig. In dem Team eines meiner Kollegen beispielsweise treffen sich alle Architekturleiter einmal pro Woche zu einem festen Termin, um aktuelle Themen zu besprechen und bei Bedarf über das Architekturdesign zu entscheiden. Die Struktur ist nicht sehr hierarchisch, sodass die Entwickler gemeinsam über Architekturregeln und -richtlinien diskutieren und Entscheidungen treffen. Die Meetings sind für alle Teammitglieder offen, sodass jeder, der sich für das Thema interessiert, jederzeit teilnehmen und wichtige Themen ansprechen kann. Dieser häufige Informationsaustausch mit mehreren Teammitgliedern ist besonders bei größeren Teams notwendig, um die Umsetzung einheitlicher Lösungen im gesamten Code zu gewährleisten.

In hierarchischeren Teams kann es je nach Teamkultur auch einen übergeordneten Lead-Architekten geben, dessen Aufgabe es ist, Architekturentscheidungen eher von oben nach unten zu treffen.

Unabhängig von der genauen Teamzusammensetzung ist es für eine gute Frontend-Architektur entscheidend, dass das gesamte Team hinter dem Architekturansatz steht und ihn aktiv unterstützt. Die Frontend-Architektur kann durch andere tägliche Arbeitsaufgaben und Termine leicht vernachlässigt werden. Wenn dies geschieht, kann es schnell zu großen Inkonsistenzen in der Codebasis, zu Ineffizienzen in der Entwicklung und zu Leistungsproblemen kommen, die umfangreiche Refactoring-Aufgaben nach sich ziehen. Daher muss die Aufrechterhaltung einer guten Frontend-Architektur vom Team priorisiert und von allen „gelebt“ werden. Dann kann sie eine wesentliche Rolle für das Wachstum der Anwendung spielen.

Zusätzlich dazu, dass alle Teammitglieder aktiv Verantwortung für die Aufrechterhaltung einer guten Frontend-Architektur übernehmen, können bestimmte Team-Praktiken sowie der Einsatz automatisierter Tools die architektonische Qualität weiter verbessern.

1. Code-Reviews und Pull-Anfragen

Code-Reviews durch andere Entwickler gehören zu den nützlichsten Praktiken, um die Einheitlichkeit der Codebasis zu gewährleisten. Die Teammitglieder überprüfen gegenseitig ihre Pull-Anfragen, bevor sie in die Codebasis übernommen werden, und können so Probleme im neuen Code erkennen, die während der Entwicklung möglicherweise übersehen wurden, beispielsweise Abweichungen von Best Practices. Diese Konsistenz kann die Pflege der Architektur im Laufe der Zeit erleichtern.

Durch die Überprüfung des Codes anderer mit Blick auf das Gesamtbild können Teammitglieder auch Bereiche der Codebasis identifizieren, die generell von einer Refaktorisierung profitieren könnten. Probleme sollten frühzeitig überarbeitet werden, da sie sonst später viel schwieriger und zeitaufwändiger zu beheben sind.

Darüber hinaus erleichtern Code-Reviews die Kommunikation und Zusammenarbeit zwischen den Teammitgliedern, was zu besseren Ergebnissen führen und zum Aufbau eines gemeinsamen mentalen Modells der Architektur beitragen kann.

2. Dokumentation der Frontend-Architektur

Die frühzeitige Dokumentation von Architekturentscheidungen sowie späterer Refactoring-Entscheidungen und deren Begründungen kann eine gemeinsame Grundlage für alle Teammitglieder schaffen. Sie kann auch eine wertvolle Ressource für die Einarbeitung neuer Teammitglieder sein. Grafiken und Diagramme können dies unterstützen. Beispielsweise kann ein Übersichtsdiagramm der Frontend-Architektur die Gesamtstruktur und die Beziehungen zwischen ihren Teilen oder Komponenten visuell vermitteln.

Wenn Sie bestimmte Architekturmuster oder Lösungen aus anderen Projekten verwenden, kann es für andere hilfreich sein, die Quellen selbst einsehen zu können. Daher kann es auch sinnvoll sein, Links zu Referenzen in einer Readme-Datei anzugeben.

Die Dokumentation muss auf dem neuesten Stand gehalten werden, um mit aktuellen Änderungen Schritt zu halten und fehlerhafte und verwirrende Informationen zu vermeiden.

3. Beispielkomponenten und vorgefertigte Vorlagen

Es kann nützlich sein, verschiedene „Go-to“-Komponenten oder -Module zu haben, die als besonders gute Beispiele für diese Art von Komponente bzw. Modul dienen. Dies kann Entwicklern helfen, konsistente Implementierungen beizubehalten und die Entwicklung effizienter zu gestalten. Sie können auch vorgefertigte Vorlagen für verschiedene Anwendungsfälle erstellen und diese in einem Komponenten- oder Modul-Startercode zusammenfassen. Alles, was Ihre Best Practices aus bestimmten Implementierungen abstrahiert, kann hilfreich sein.

4. Linting

Technische Tools können die Entwicklung erheblich unterstützen, indem sie Warnungen und Fehlermeldungen ausgeben, wenn neuer Code nicht den definierten Codierungsstandards und Best Practices entspricht.

Linting-Tools können so konfiguriert werden, dass sie beispielsweise konsistente Namenskonventionen, die Vermeidung problematischer Codemuster oder veralteter Funktionen sowie die Codeformatierung durchsetzen. Für die Frontend-Architektur sind jedoch Linting-Regeln relevant, die sich auf Import- und Exportanweisungen konzentrieren. Die Einschränkung von Modulimporten trägt dazu bei, Module voneinander unabhängig zu halten, indem beispielsweise Module aus einer Bibliothek nicht in eine andere importiert werden können. Import- und Export-Linting sollte auch verwendet werden, um die Entstehung von zirkulären Abhängigkeiten zu vermeiden, die sonst zu Fehlern führen können.

Es ist ratsam, so viele automatisierte Prüfungen gegen Architekturregeln wie möglich durchzuführen, wenn die Regeln gut definiert, transparent und leicht verständlich sind. Jeder sollte diese Regeln verstehen und wissen, wie sie anzuwenden sind, da die automatisierten Prüfungen sonst für Entwickler frustrierend sein können. Eine gute Anzahl klar definierter, automatischer Prüfungen kann den Aufwand für manuelle Überprüfungsaufgaben für alle Entwickler in Ihrem Team erheblich reduzieren.

5. Tools zur Analyse der Codequalität

Ähnlich wie Linter, jedoch mit höherer Funktionalität, können automatisierte Tools zur Codequalitätsanalyse verwendet werden, um die Qualität der Codebasis zu messen und Verstöße gegen Codierungsstandards und schlechte Muster zu erkennen. SonarQube ist beispielsweise ein weit verbreitetes Tool, das bestimmte Codemetriken verfolgen und analysieren kann, die für eine gute Frontend-Architektur relevant sind, wie z. B. Wartbarkeit, Komplexität und Zuverlässigkeit. Schwellenwerte für diese Metriken können verwendet werden, um die Qualität der Codebasis aufrechtzuerhalten und Bereiche der Codebasis zu identifizieren, in denen Verbesserungen vorgenommen werden können. Hierfür stehen vordefinierte Regelsätze zur Verfügung, es können jedoch auch benutzerdefinierte Regeln definiert werden. SonarQube bietet außerdem eine Reihe von Tools zur Erkennung von Sicherheitslücken, Leistungsengpässen und anderen potenziellen Leistungsproblemen wie unnötigem Neurendern oder aufwändigen DOM-Operationen.

Andere Tools zur Architekturvalidierung und Abhängigkeitsvisualisierung, wie Dependency Cruiser oder das Nx Dependency Graph-Tool in Nx-Monorepos, bieten ebenfalls eine visuelle Grafik, die den Abhängigkeitsfluss zwischen Modulen in Ihrem Frontend anzeigt. Die Visualisierung des Datenflusses auf diese Weise kann dabei helfen, unerwünschte Abhängigkeiten aufzudecken.

Viele Linting- und Codequalitätsanalyse-Tools können in den Entwicklungsworkflow integriert werden, beispielsweise über Pre-Commit-Hooks oder Continuous-Integration-Pipelines (CI), um sicherzustellen, dass der Code bei jedem Commit oder Pull-Request automatisch analysiert wird.

Zusammenfassend lässt sich sagen, dass durch hilfreiche Team-Praktiken wie Code-Reviews, aktuelle Dokumentation und vorgefertigte Vorlagen alle Mitglieder des Entwicklungsteams auf dem Laufenden gehalten werden und Funktionen implementieren können, die der festgelegten Architektur entsprechen. Darüber hinaus werden durch die Konfiguration von Tools zur Codequalitätsanalyse mit Fokus auf architektonische Probleme neue Codes konsequent anhand Ihrer definierten Regeln überprüft und Probleme sofort behoben. Dies kann zu einer besser wartbaren, skalierbaren und robusten Codebasis führen, die weniger anfällig für Probleme und Fehler ist. Außerdem kann es die Entwicklererfahrung verbessern, indem klare architektonische Prinzipien für Ihre Frontend-Anwendung bereitgestellt werden.

Im letzten Teil werden wir uns mit den aktuellen Trends in der Frontend-Entwicklung befassen und Möglichkeiten aufzeigen, wie Sie mit den neuesten Innovationen in diesem Bereich Schritt halten können. Wohin führt uns die Zukunft als Frontend-Architekten?

Dieser Teil befasst sich mit relevanten Trends in der Frontend-Entwicklung, die sich auf unterschiedliche Weise auf die Architektur unserer Anwendungen auswirken können. Da ständig neue Tools und Frameworks auf den Markt kommen, werden wir auch einige Möglichkeiten vorstellen, wie Sie sich über aktuelle Entwicklungen auf dem Laufenden halten können.

1. Verwischung der Grenze zwischen Client-Rendering und Server-Rendering

Die klassische Architektur von Single-Page-Anwendungen (SPAs) mit einer strikten Trennung zwischen Backend und Frontend wird zunehmend durch Server-Side-Rendering (SSR) und statische Seitengenerierung (SSG) ersetzt. Meta-Frameworks wie Next.js, Nuxt.js und Remix haben in den letzten Jahren den Weg für eine Rückkehr zu den Vorteilen des statischen Ladens von Inhalten geebnet: Das Rendern einer Seite auf dem Server und das Bereitstellen des generierten statischen HTML-Codes an den Browser, um ihn anschließend mit JavaScript zu hydrieren. Diese Rückkehr zu statischen Inhalten löst die strikte Trennung zwischen Frontend und Backend auf. Sie ermöglicht schnellere Ladezeiten von UI-Elementen auf der Seite und verbessert damit die Performance, die User Experience und die Möglichkeiten für eine bessere Suchmaschinenoptimierung.

Ein weiteres Beispiel ist das neuere Framework Remix, das eine noch effizientere Datenbereitstellung ermöglicht, da die Daten nicht auf dem Browser des Nutzers, sondern auf dem Server abgerufen werden. Dadurch werden Ladezeiten auf der Client-Seite vermieden, da Anfragen sofort gesendet werden. Auf andere Weise, aber mit ähnlicher Wirkung, hat die Einführung von React Server Components in React es möglich gemacht, Komponenten zu rendern und die benötigten Daten auf dem Frontend-Server abzurufen. Dadurch entfällt die sequentielle Datenabfrage in Komponentenhierarchien aus dem Browser des Benutzers. React Server Components können auch Bibliotheken von Drittanbietern verwenden, und da sie auf dem Server kompiliert werden, kann die Bundle-Größe der an den Client gesendeten Daten erheblich reduziert werden. Moderne Meta-Frameworks bieten auch andere Vorteile wie integriertes Caching, wodurch die Antwortzeiten weiter verkürzt werden. Beispielsweise verbessert Next.js in Verbindung mit React Server Components die Website-Performance durch integriertes Caching von Abrufanfragen und Routing. Für das Routing werden die Serverkomponenten der besuchten Routensegmente und vorab abgerufene Routensegmente vorübergehend im sogenannten Router-Cache zwischengespeichert.

2. Trend zu weiterer Frontend-Modularisierung

Microfrontends

Die Bedeutung der Modularisierung haben wir bereits in Teil 1 dieser Serie gesehen. Um noch mehr Flexibilität und die Möglichkeit zum Aufbau modularer, skalierbarer und unabhängiger Apps zu erreichen, hat sich in den letzten Jahren das Architekturmodell der Microfrontends durchgesetzt. Die Microfrontend-Architektur besteht aus einer Sammlung kleiner, in sich geschlossener Anwendungen, die zusammen die Gesamtanwendung bilden. Jedes Microfrontend ist für eine bestimmte Funktion oder Funktionalität verantwortlich und kann mit einem eigenen Framework oder Technologie-Stack erstellt werden.

Zu den Vorteilen gehört eine größere Flexibilität bei der Entwicklung, da Teams unabhängig voneinander an einzelnen Funktionen arbeiten können, ohne durch die allgemeine Technologieauswahl eingeschränkt zu sein. Da Microfrontends unabhängig voneinander bereitgestellt werden können, können sie CI/CD-Pipelines insgesamt beschleunigen und vereinfachen. Außerdem können sie verhindern, dass sich Single-Page-Anwendungen zu großen Monolithen entwickeln. Monolithische Anwendungen sind mit der Zeit schwerer zu warten, da die Verteilung der Verantwortlichkeiten mit zunehmender Größe der Anwendung unklar und unübersichtlich werden kann. Mikrofrontends können eine architektonische Alternative bieten.

Dieses Muster kann jedoch auch Herausforderungen mit sich bringen. Die Aufteilung einer Anwendung in unabhängige Teams kann Risiken für das Unternehmen mit sich bringen, da fragmentierte Teams möglicherweise Schwierigkeiten haben, effektiv zu kommunizieren. Dies kann die Aufrechterhaltung der Kohärenz und Konsistenz der Codebasis erschweren, insbesondere im Hinblick auf die Architektur des Frontends. Weitere Herausforderungen sind die erhöhte Komplexität der Kommunikation zwischen den verschiedenen Teilen von Mikrofrontends, wodurch eine klar definierte Architektur und API-Verträge noch wichtiger werden. Angesichts dieser Nachteile argumentierten die meisten meiner Kollegen, dass die Möglichkeiten bestehender Frameworks für die meisten Projekte in der Praxis ausreichend sind und dass die Mikrofrontend-Architektur einen klar definierten Anwendungsfall benötigt, um effektiv zu funktionieren.

Eine Alternative zu Mikrofrontends könnte darin bestehen, Apps parallel in einem Mono-Repository zu entwickeln, wobei die Unabhängigkeit zwischen den Anwendungen erhalten bleibt, aber auch die Kohärenz in Bezug auf die Implementierung und die Teamorganisation gewahrt wird. Wie bei jedem Architekturmuster ist es wichtig, die Vorteile und Nachteile von Mikrofrontends in Bezug auf verschiedene Aspekte Ihres Projekts, einschließlich der Teamorganisation und der Architekturentwicklung, zu berücksichtigen, bevor Sie sich für die Einführung des Mikrofrontend-Musters entscheiden.

Web Komponenten

Darüber hinaus werden Webkomponenten in der Frontend-Entwicklung immer beliebter. Viele meiner Kollegen haben sich für ihre verschiedenen Vorteile ausgesprochen und würden es begrüßen, wenn sie sich als Architekturmuster und sogar als Standardmuster für Frontends etablieren würden. Webkomponenten basieren auf bestehenden Webstandards und sind wiederverwendbare Komponenten, deren Funktionalität von ihrer Umgebung gekapselt ist. Sie können über verschiedene Frameworks und Bibliotheken hinweg eingesetzt werden, insbesondere in jeder JavaScript-Bibliothek oder jedem JavaScript-Framework, das mit HTML arbeitet, und können somit in verschiedenen Projekten und Webanwendungen wiederverwendet werden. Durch die Erstellung benutzerdefinierter HTML-Elemente, die vollständig separat sind, aber innerhalb Ihrer Webanwendung betrieben werden können, sind Webkomponenten hochgradig modular und sehr flexibel einsetzbar. Dies kann insbesondere für die Architektur großer und komplexer Webanwendungen von Vorteil sein. Bei der Verwendung von Webkomponenten ist jedoch zu beachten, dass sie viele Schnittstellen mit ihrer externen Umgebung teilen müssen, sodass Sie auf die Leistung achten sollten.

3. Moderne, leichtgewichtige Web-Frameworks

Neuere Web-Frameworks enthalten Funktionen, die immer beliebter werden und einen erheblichen Einfluss auf die architektonische Gestaltung einer Anwendung haben können. Mit neueren Frameworks wie Svelte, SolidJS, Qwik oder Astro sehen wir neue Möglichkeiten, sowohl die Benutzererfahrung als auch die Entwicklererfahrung zu verbessern. Sie alle sind bestrebt, die Leistung zu steigern, beispielsweise durch effizientere Wege, Daten dem Benutzer zu präsentieren oder Benutzerinteraktionen zu empfangen. Sie sind in der Regel leichtgewichtig mit kleinen Bundle-Größen und haben sehr schnelle Laufzeiten, wodurch sie große Frameworks wie React oder Angular in Bezug auf Laufzeiten und Geschwindigkeit weit übertreffen. Astro beispielsweise gehört zu den Frameworks, die eine sehr schnelle Seitenladeperformance bieten, insbesondere bei großen Mengen statisch generierter oder serverseitig gerenderter Inhalte.

Ein weiteres Beispiel ist Svelte, das optimierten, kompilierten JavaScript-Code an den Browser liefert, ohne dass dieser zur Laufzeit geparst und kompiliert werden muss, was zu schnelleren Ladezeiten führt. Es unterstützt auch Reaktivität, was eine verbesserte Rendering-Performance ohne virtuelles DOM ermöglicht, was auch andere neue Frameworks wie SolidJS bieten. In reaktiven Frameworks wie SolidJS müssen Komponenten bei Datenänderungen nicht neu gerendert werden. Dies funktioniert auf der Grundlage von Signalen, die das Framework beobachtet, und aktualisiert dann nur die Daten an ihrer genauen Position im DOM.

Qwik hingegen verfolgt einen Ansatz, der darauf basiert, dem Browser möglichst kleine Bundles zu liefern, indem JavaScript in das HTML-Dokument serialisiert und sehr fein granulierte JavaScript-Module nur dann an den Browser gesendet werden, wenn sie aufgrund von Benutzerinteraktionen benötigt werden. Anstelle der typischen SSR-Hydration verwendet Qwik daher progressive Hydration, d. h., es verzögert das Laden und Ausführen von JavaScript so lange wie möglich. Qwik implementiert auch die Wiederaufnimmbarkeit, die den Status basierend auf der Stelle lädt, an der er auf dem Server unterbrochen wurde, ohne dass Komponenten erneut ausgeführt werden müssen.

Obwohl die meisten dieser Frameworks noch wenig verbreitet sind und möglicherweise einige Nachteile haben, weniger Community-Support bieten oder für sich allein genommen zu leichtgewichtig sind, können sie bestehende Technologien für bestimmte Anwendungsfälle hervorragend ergänzen. Ihre zunehmende Beliebtheit könnte neue Wege für zukünftige Fortschritte in der Webentwicklung eröffnen.

4. Designsysteme

Da das Design und Branding von Anwendungen für Unternehmen immer wichtiger wird, um ihre Geschäftsziele zu erreichen, werden Frontend-Designsysteme zu entscheidenden Faktoren für die Designkonsistenz innerhalb der Unternehmensumgebung. Ein benutzerdefiniertes Designsystem, das in einen benutzerdefinierten Frontend-Stil und eine Komponentenbibliothek übersetzt wird, wird in der Regel von verschiedenen Anwendungen innerhalb eines Unternehmens gemeinsam genutzt. Die Einrichtung einheitlicher, konsistenter Designsysteme für Frontend-Anwendungen ist daher nicht nur eine Frage des Designs, sondern auch ein wichtiger Aspekt der Frontend-Architektur.

Während die Organisation und das Design in den Aufgabenbereich der Designer fallen, ist es eine architektonische Entscheidung, wie das System in Code umgesetzt wird, damit es effizient über Anwendungen hinweg gemeinsam genutzt werden kann. Stil- und Komponentenbibliotheken müssen gut in bestehende oder geplante Frontend-Anwendungen integrierbar sein und mit den darin verwendeten Technologien gut zusammenarbeiten. Daher ist es entscheidend, ihre Architektur und Schnittstellen so früh wie möglich zu berücksichtigen. Eine frühzeitige Kommunikation mit den Stakeholdern ist entscheidend. Die Bibliotheken müssen außerdem zum richtigen Zeitpunkt entwickelt werden, damit die verschiedenen Frontend-Anwendungen sie von Anfang an optimal nutzen können. Insgesamt lohnt es sich bei der Integration eines Designsystems in Ihr Frontend, es für alle Personen, die damit arbeiten, einfach zu bedienen und zu warten zu halten, unabhängig davon, ob sie in der Entwicklung, im Design oder im Business tätig sind.

Die Frontend-Welt ist schnelllebig. Es entstehen neue Technologien und es gibt viele Diskussionen im Internet. Hier sind einige Möglichkeiten, wie Sie sich über neue Trends in der Frontend-Entwicklung auf dem Laufenden halten können:

• Werfen Sie einen Blick auf das Projekt JavaScript Risings Stars, das einen Überblick über die trendigen Projekte auf GitHub im JavaScript-Ökosystem der letzten 12 Monate bietet.
• Folgen Sie Frontend-Experten und Diskussionen in sozialen Medien.
• Besuchen Sie Konferenzen.
• Lesen Sie die Ergebnisse jährlicher Entwicklerumfragen wie State of JavaScript und State of CSS.
• Lesen Sie regelmäßig Blogs auf Websites wie Medium oder Feeds wie daily.dev.
• Verfolgen Sie neue Projekte auf GitHub.
• Hören Sie sich Web- und Frontend-Podcasts an.
• Folgen Sie Kanälen auf Reddit, wie dem JavaScript-Kanal oder framework-spezifischen Kanälen.
• Gehen Sie offline und schauen Sie sich die Bildschirme Ihrer Kollegen an und fragen Sie sie, an welchen tollen Projekten sie gerade arbeiten.

Ob es darum geht, die Leistungsfähigkeit komponentenbasierter Architekturen zu erkunden oder alternative Frontend-Architekturmuster und -Technologien wie Microfrontends und Webkomponenten einzusetzen – für Frontend-Architekten ist es unerlässlich, sich über die neuesten Trends und Best Practices auf dem Laufenden zu halten. Am Ende dieser Artikelserie hoffe ich, deutlich gemacht zu haben, dass die Frontend-Architektur eine entscheidende Rolle für den Erfolg jeder Webanwendung spielt. Durch die Einführung einer gut durchdachten und wartbaren Architektur können wir skalierbare, effiziente und robuste Anwendungen entwickeln, die die Nutzer begeistern und die Geschäftsziele erfüllen. Das Frontend ist das Aushängeschild Ihrer Anwendung, und die Investition in eine durchdachte Architektur zahlt sich aus und sichert den langfristigen Erfolg Ihres Projekts. Vielen Dank für Ihre Aufmerksamkeit!