Die Disziplin der Frontend-Entwicklung hat in den letzten Jahren eine rasante Veränderung erlebt. Vor dem Hintergrund steigender Komplexität wurden Technologien und Werkzeuge entwickelt, die die Arbeit von Frontend-Entwicklern unterstützen. Und die dynamische Entwicklung geht weiter: Es stecken noch viele Neuerungen in der Pipeline, die versuchen, Benutzer- und Kundenbedürfnisse sowie Technologie und Infrastruktur in Einklang zu bringen.Als Senior Frontend Engineer bei Unic nehme ich Sie mit auf eine Zeitreise durch die Ära der Webentwicklung und teile meine ganz persönliche Sicht über die Bedeutung und die Perspektiven der Frontend-Entwicklung mit Ihnen.
Die Vergangenheit
Als ich vor 25 Jahren angefangen habe, Websites zu gestalten, war diese Aufgabe noch relativ einfach: Das World Wide Web steckte in den Kinderschuhen und als Entwickler konnte man mit einfachen Mitteln in ein paar Tagen für fast jeden Kunden eine Website zum Leben erwecken. Im Laufe der Jahre wurden die Ansprüche auf Kunden-, Benutzer- und Entwicklerseite aber immer grösser. Dadurch wurde alles komplexer. Entwickler haben vor diesem Hintergrund angefangen, sich auf bestimmte Bereiche zu spezialisieren. Frontend- und Backend-Entwicklung haben sich zu eigenständigen Disziplinen entwickelt.
Ich glaube zwar nicht, dass es irgendwann wieder so einfach wird, Weblösungen zu entwickeln wie in den Anfangszeiten des WWW. Dennoch denke ich, dass wir aktuell auf dem richtigen Weg sind, indem wieder mehr Entwickler die Fähigkeiten eines Fullstack-Entwicklers haben. Dies hat mich angetrieben, im August 2018 auf der Frontend Conference einen Vortrag zu halten. Ich möchte Entwickler motivieren, den Fokus auf das Frontend zu legen und ganz nach dem Prinzip «Frontend First» zu leben, ohne die Fullstack-Perspektive aus den Augen zu verlieren.
Ich will euch in diesem Beitrag Schlüsseltechnologien und Patterns näherbringen, die uns auf diesem Weg unterstützen. Diese Technologien schliessen die Kluft zwischen Design, Frontend- und Backend-Entwicklung. Sie vereinen getrennte Bereiche wieder miteinander. Sie fördern die Kommunikation und den Abgleich zwischen unterschiedlichen Teams und führen Entwicklungsteams wieder zusammen. Zu guter Letzt reduzieren und verbergen diese Technologien die Komplexität jedes einzelnen Bereichs, sodass Zeit und mentale Kapazitäten freigesetzt werden, um unsere Lösungen besser und unsere Kunden zufriedener zu machen.
Dieser Beitrag reflektiert meine ganz persönliche Einschätzung als Frontend-Entwickler und wagt einen Blick in die Zukunft, zumal einige der erwähnten Technologien noch nicht vollständig ausgereift sind.
Die Gegenwart
Komponenten
Für einen Frontend-Entwickler war wohl die wichtigste Entwicklung der letzten Jahre, dass React komponentenbasierte Layouts populär machte. jQuery, die zuvor von allen verwendete bedeutende Bibliothek, war für kleinere Projekte grossartig. Aber als Vorhaben komplexer wurden und sich immer mehr Business-Logik vom Backend ins Frontend verlagerte, war die Notwendigkeit für ein neues Paradigma reif: Backbone.js war eine Art Zwischenschritt – hilfreich aber alles andere als perfekt. Mit React und dessen Komponenten wurde es schliesslich möglich, grosse komplexe Anwendungen aus einfachen kleinen Teilen zu konstruieren. Andere Frameworks wie Angular und Vue folgten dem Beispiel. Mittlerweile haben wir viele grossartige Optionen zur Auswahl. jQuery hat immer noch seine Berechtigung für kleinere Projekte. Aber sobald man neue Elemente auf einer Seite erstellt, die miteinander interagieren und reibungslos funktionieren müssen, führt heutzutage kein Weg an komponentenbasierten Layouts vorbei.
Flux
Der nächste Schritt war, Probleme mit dem Architekturmuster MVC (Model, View, Controller) zu überwinden. Mit MVC wurde das Debugging schwieriger, je grösser die Anwendungen wurden, weil mehrere Controller untereinander gleichzeitig und schwierig überwachbar Events senden und empfangen können. Gerade bei grösseren Projekten mit mehreren Entwicklern ist es fast unmöglich zu wissen, wie alles zusammenhängt. Dies führt dazu, dass die Codebasis nur schwer auf Fehler zu analysieren und zu optimieren ist. Flux und insbesondere die Redux-Bibliothek, die das Konzept noch verbessert hat, lösen diese Herausforderung, indem Daten nur in eine einzige Richtung durch die Anwendung fliessen können. Zusätzlich hat Redux das Konzept der «Unveränderlichkeit» hinzugefügt. So weiss man immer, welcher Zustand welchem Zustand folgt und welche Aktionen welche Änderungen verursachen. Diese Prinzipien machen das Debugging wieder einfach und reduzieren die Komplexität. Spannend ist, dass wir diese neuen Möglichkeiten nur bekommen haben, indem der Entwickler in dem, was er tun kann, eingeschränkt wird.
GraphQL
Die selben Entwickler, die Komponenten und Flux in der Frontend-Entwicklergemeinde populär gemacht haben, haben eine Lösung für die Herausforderung bei der Kommunikation mit Backend-Services erarbeitet. Während viele REST damals noch für seine Einfachheit lobten und dankbar waren, endlich unnötig komplizierte API-Protokolle wie Soap losgeworden zu sein, adressierten diese Experten die Probleme mit REST insbesondere bei mobilen Verbindungen. Sie läuteten die nächste Entwicklungsstufe ein: Sie lösten nicht nur die meisten der Probleme mit REST, die entstanden, weil die Endpunkte komplexer wurden, sondern sie schufen auch die Werkzeuge für weitere Verbesserungen, die wir später betrachten werden.Die Lösung war ziemlich einfach: Mit GraphQL gibt es nur noch einen Endpunkt. Sämtliche Abfragen laufen darüber. Damit entfällt die Notwendigkeit von Mehrfachabfragen und das Problem des Under- und Over-Fetching mit standardkonformen REST-APIs wird gelöst. Dies wiederum behebt das Performance-Problem, den Server mehrmals abfragen zu müssen, um alle benötigten Daten zu erhalten. Und weil ein GraphQL-Endpunkt sich selber automatisch dokumentiert, erkennt man nicht nur die Möglichkeiten einer API, indem man sie benutzt, sondern es ermöglichte auch die Entwicklung vieler erstaunlicher Tools wie bspw. für intelligenteres Caching, die Visualisierung einer API, oder durchgehende Typsicherheit zwischen Frontend und Backend, um nur drei von ihnen zu nennen.
Mocking von APIs
GraphQL ermöglicht das realistische Mocking von APIs. Dies ist der Bereich, in dem ich mich hauptsächlich in der globalen Open-Source-Community engagiere. Weil GraphQL die Bereitstellung von Werkzeugen fördert und man nun über einen einzigen, super flexiblen Endpunkt verfügt, eröffnet es die Möglichkeit, eine API perfekt und superrealistisch zu simulieren. Dies war mit REST so unmöglich. GraphQL-Engines wie Prisma und Hasura können voll funktionale, realistische APIs basierend auf einer Schemadefinition nachahmen. Im Falle von Hasura und meiner eigenen Bibliothek Blowson müssen wir nicht einmal mehr manuell Beispieldaten eingeben. Wir können mit minimalem Aufwand sehr einfach Beispieldaten generieren. Dies ermöglicht es, super schnell auf unseren APIs und Frontends zu iterieren, ohne jemals eine einzige Zeile Backend-Code schreiben zu müssen. Wer versucht hat, APIs zu migrieren, weiss, wie schwierig und zeitaufwändig es sein kann, wenn man mit echten benutzergenerierten Daten arbeiten muss. Aber wenn man mit realistischen Beispieldaten arbeitet, stellen Änderungen fast kein Problem mehr dar. Ich persönlich bin sehr begeistert von dieser Entwicklung, da sie zu schnelleren Iterationen und letztendlich zu glücklicheren Kunden führt.Smarte CDNs.
Ein weiteres sehr schwieriges Problem, das derzeit ebenfalls dank GraphQL gelöst wird, ist das Caching. Während wir in der Vergangenheit hauptsächlich CDNs (Content Delivery Networks) für Media-Dateien eingesetzt haben, werden aktuell viele neue Dienste dank GraphQL flexibler und leistungsfähiger. Es gibt heute beispielsweise mehrere Dienste, die GraphQL-API-Anfragen am Rande des Netzwerks zwischenspeichern können. Dies tun diese Services, indem sie die GraphQL-Abfragen analysieren, die wir darüber senden. Durch die Kenntnis der Möglichkeiten eines Endpunkts und weil GraphQL schemenbasiert ist, kann ein CDN genau wissen, wann es den Server nach neuen Daten fragen muss und wann es diese von seinem Service am Rande des Netzwerks liefern kann. Diese Art von Caching kann auch Daten cachen, die früher nur sehr aufwändig oder gar unmöglich zu cachen waren wie beispielsweise Benutzerdaten oder einen Warenkorb.
CSS in JS
Ein weiteres Problem, das derzeit gelöst wird, ist die Kapselung von Styling-Regeln in unseren Frontend-Komponenten. Entwickler versuchen seit einer Weile, dieses Problem mit Namenskonventionen wie BEM zu lösen. Aber jeder Entwickler weiss, dass das Finden von passenden Namen eine der grössten Herausforderungen in der Softwareentwicklung (neben der Cache-Invalidierung) ist. CSS in JS beseitigt dieses Problem mit automatisch generierten Namen und macht so das Leben der Entwickler viel einfacher. Da bei komponentenbasierten Layouts sowieso alles in JavaScript geschrieben wird, fühlt sich das Schreiben von CSS in JS nicht mehr so seltsam an. Die Definition von Styles hat neben der Vermeidung von Überschreibungen weitere Vorteile: Da alles «Code» ist, können wir Code-Splitting-Techniken verwenden, um die Ladezeiten zu verbessern. Wenn wir unsere Komponenten vom Server rendern, sind Styles sofort verfügbar, sobald eine Komponente verfügbar ist. Es werden nur Daten an den Browser ausgeliefert, die tatsächlich auf einer bestimmten Seite verwendet werden.
Serverless
Parallel zu der rasanten Entwicklung im Frontend haben Backend-Entwickler Serverless-Funktionen eingeführt, die direkt in der Cloud bereitgestellt werden können. Damit entfällt die aufwändige Konfiguration von Backend-Servern (Dev-Ops). Der Code skaliert bei steigendem Traffic automatisch. Serverless kann nicht für alle Anwendungsszenarien eingesetzt werden, aber es ist perfekt für die Abbildung einer zustandslosen Business-Logik. Damit ist eine Business-Logik gemeint, die aus dem gleichen Input immer den gleichen Output generiert. Aus Sicht eines Frontend-Entwicklers sind diese Serverless-Funktionen sehr interessant, da sie in der gleichen Sprache geschrieben werden können, die wir bereits auf dem Frontend verwenden, nämlich JavaScript. Dies öffnet den Backend-Bereich für viele Frontend-Entwickler. Einer der Vorträge auf der diesjährigen Frontend Conference illustrierte das Projekt Codepen. Daran sind nur Frontend-Entwickler beteiligt. Codepen bietet Millionen von Nutzern einen einwandfrei funktionierenden Service, der skaliert. Ein solches Projekt hätte man reinen Frontend-Entwicklern noch vor wenigen Jahren nicht zugetraut.
Headless
Der Serverless-Ansatz ist nicht für jede Backend-Technologie geeignet. Es ist beispielsweise nach wie vor sinnvoll, über ein dediziertes Content-Management-System oder eine zentrale Datenbank zu verfügen. Heute ist es allerdings immer weniger der Fall, dass ein CMS notwendigerweise Markup rendert. Eine grosse Anzahl von Neueinsteigern im CMS-Bereich macht das Prinzip Headless populär, welches Frontend und Backend vollständig entkoppelt. Dies bringt mehrere Vorteile und nur sehr wenige Nachteile (wie ich das hier erläutere). Mittlerweile gehen auch etablierte Content-Management-Systeme wie Drupal in diese Richtung. Aus Frontend-Perspektive war es nie wirklich sinnvoll, dass ein Markup durch das CMS gerendert wird, vor allem seit das Frontend immer komplexer geworden ist. Änderungen in der Art und Weise, wie wir heutzutage Layouts erstellen, zum Beispiel mit Flexbox, und Themen wie Barrierefreiheit und HTML 5, erzwingen ein viel strikteres Markup als die Default-Ausgabe der meisten CMS bietet. Mit einem Headless-CMS wird Frontend-Entwicklern kein Markup mehr aufgedrängt, sondern er kann perfektes, HTML5-kompatibles und barrierefreies Markup selber schreiben.
Design-Tools integrieren Komponenten
Jüngst kommt eine neue Generation von Design-Tools auf den Markt, die versucht, die Lücke zwischen Design und Frontend-Code zu schliessen. Die wichtigsten sind: FramerX, Alva, BuilderX und mit einem etwas anderen Fokus: Figma. Im Grunde genommen stellen diese Tools, Frontend-Komponenten (Code) innerhalb von Design-Tools zur Verfügung. Dies unterstützt den Entwicklungsprozess massgeblich: Auf diese Weise können Designer Seiten und Module mit realen Komponenten gestalten. Dies stellt sicher, dass alles im Design genauso aussieht und funktioniert wie in der endgültigen Implementierung. Einige Unternehmen wie z. B. Dropbox haben bereits damit begonnen, FramerX zur Optimierung der Kommunikation zwischen Designern und Frontend-Entwicklern einzusetzen.
Die Zukunft
Zukunftsprognosen sind sehr schwierig und meist nicht genau, aber sie sind ein hervorragendes Instrument, um die Entwicklung in die richtige Richtung zu lenken. Mit meiner sehr frühen Vorhersage, dass React, GraphQL und Flux populär werden würden, lag ich richtig. Vielleicht treffe ich auch mit den folgenden Vorhersagen ins Schwarze. Wünscht mir Glück!
Datenbank agnostisches CMS
Derzeit verwalten alle Enterprise-Content-Management-Systeme und sogar die meisten Headless-Systeme ihre eigenen Datenbanken und APIs. Ich denke, das wird sich drastisch ändern. GraphQL-Engines sind viel flexibler und besser für Cloud-Infrastrukturen optimiert als die traditionellen Datenbankimplementierungen, die Content-Management-Systeme heutzutage verwenden. Ich bin überzeugt, der nächste logische Schritt ist die vollständige Entkopplung der Datenbank vom Content-Management-System ähnlich der oben beschriebenen Entkopplung des Markup vom CMS. GraphQL-Engines werden das ORM zukünftiger Content-Management-Systeme sein und die Lücke zwischen einem CMS und einer GraphQL-API schliessen.
Frontend-First-Entwicklung
Alle oben genannten Technologien erlauben es, länger an einem Frontend-Prototypen zu arbeiten als in der Vergangenheit. Wir wissen, dass Kunden Lösungen besser verstehen, wenn sie sie sehen und damit interagieren können. Indem wir einfach Backend-API-Implementierungen simulieren können, werden Prototypen realistischer. Dies ermöglicht es Kunden, während des Entwicklungsprozesses schneller Neuerungen einzubringen, ohne dass aufwändige Änderungen im Backend sowie Anpassungen der CMS-Inhalte notwendig sind.
Microservices überall
Mit der neuen Generation der komponentenbasierten Frontend-Frameworks zerlegen wir visuell und im Markup alles in winzige Komponenten. Ich denke, das Gleiche geschieht auch im Backend. Serverless-Funktionen und Microservices werden immer mehr Aufgaben übernehmen, die in der Vergangenheit von einem CMS erledigt wurden, und dieser Trend wird nicht abbrechen.
CMS mit Fokus auf den Content-Editor
Viele der derzeit populären Enterprise-Content-Management-Systeme werden Verantwortlichkeiten an Microservices abgeben müssen. Damit können sich die Entwicklungsteams des CMS-Herstellers auf das Benutzererlebnis der Inhaltsredakteure konzentrieren und weniger auf die Implementierung von Backend-Services. Dies wird die Usability der Produkte drastisch verbessern.
Spezifische Benutzeroberflächen
Die Admin-Schnittstellen werden sehr individuell. Wir werden nicht nur allgemeine Admin-Interfaces für Kunden gestalten, sondern die Admin-Oberfläche für jeden Content-Editor individuell definieren können. Dies wird die Technologie viel zugänglicher machen. Das Drupal-Team arbeitet beispielsweise bereits in diese Richtung.
Design-Systeme werden in allen Projekten zum zentralen Thema
Da Design-Tools und Frontend-Technologien immer enger zusammenrücken, werden Design-Systeme immer mehr zur Grundlage für alles. Dadurch ist es möglich, Grössen, Leerzeichen, Farben, Schriften und vieles mehr während der Entwicklung eines Projekts jederzeit schnell und einfach anzupassen, ohne dabei immer wieder von vorne anfangen zu müssen.
Kontakt für Ihre digitale Lösung mit Unic
Termin buchenSie möchten Ihre digitalen Aufgaben mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus: Jörg Nölke und Gerrit Taaks (von links nach rechts).
Wir sind da für Sie!
Termin buchenSie möchten Ihr nächstes Projekt mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus: Melanie Klühe, Stefanie Berger, Stephan Handschin und Philippe Surber (im Uhrzeigersinn).
