Produktteams von AirBnb und New York Times bis hin zu Shopify und Artsy (und viele andere) konvergieren auf eine neue Reihe von Best Practices und Technologien für den Aufbau von Webanwendungen, von denen ihre Unternehmen abhängen. Dieser Trend spiegelt Kernprinzipien wider und löst zugrundeliegende Probleme, die wir möglicherweise teilen, daher lohnt es sich, tiefer zu graben.
Einiges davon beinhaltet
- Visuelle Konsistenz: Präsentiert als ein Designsystem (nicht zu verwechseln mit einer Pattern-Bibliothek oder Styleguide), oft aufgebaut mit Bibliotheken wie styled-components und Tools wie Storybook.
- Interne Konsistenz: Erstellt mit statischen Typisierungswerkzeugen wie TypeScript.
- Datenmanipulation: Diese arbeiten mit GraphQL-sprechenden Clients wie Apollo.
- Datenrepräsentation: Dargestellt mit einer Bibliothek für wiederverwendbare Komponenten und Verhaltensweisen, wie React.
Das Benennen von Dingen ist schwierig, und unsere Branche hat Schwierigkeiten, dieser neuen Generation von Tooling für Webanwendungen einen Namen zu geben. Der unnachahmliche Orta Theroux nennt es ein Omakase; ich habe es verschlankt und mich für ein einfacheres Backronym entschieden, das aus Buchstaben des oben beschriebenen Toolings stammt: STAR (Design Systems, TypeScript, Apollo und React).
STAR-Apps sind keine „weitere Front-End-Stack“. Sie beinhalten zusätzliche Meinungen und Einschränkungen. Daher sind STAR-Apps auch nicht unbedingt einfach. Sie haben eine Lernkurve. Ein einzelner Entwickler mag STAR-Apps als unnötig wortreich empfinden, da sie den Kommunikationsaufwand vornherein verlagern. STAR-Apps drehen sich mehr um den Workflow von Produktteams als um spezifische Technologien.
Wir stellen jedoch fest, dass Unternehmen über Unternehmen diesen Stack als lohnenswerte Investition betrachten. Wir sollten uns fragen, warum.
Kontext: Von LAMP zu MEAN
Der LAMP-Stack wurde 1998 von Michael Kunze identifiziert, um die Kombination von Linux, Apache, MySQL und PHP als vorherrschende Open-Source-Technologien für einen vollwertigen Webserver zu beschreiben. In diesem Modell wurden alle Rendering- und Logikoperationen auf der Serverseite durchgeführt, und die Rolle von JavaScript war extrem begrenzt. Bis heute ist dies die häufigste Website-Architektur aufgrund der Popularität lang etablierter Frameworks wie WordPress, das 30 % des Internets antreibt.
In den folgenden 20 Jahren führte das Wachstum der Webplattform (insbesondere JavaScript) zu einer Weiterentwicklung der Disziplin „Front-End“ als Ergänzung zu den serverseitigen „Back-End“-Anliegen. Durch eine Kombination aus Atwoods Gesetz und Metcalfe's Vorhersagen über den Triumph des Webs über native Plattformen kulminierten diese Bemühungen in einer Neuerfindung der monolithischen Architektur, um sowohl Front- als auch Backends abzudecken. Eine prominente Verkapselung davon war der MEAN-Stack, der 2013 von Val Karpov geprägt wurde, um „Full-Stack“-JavaScript-Alternativen anzubieten, darunter MongoDB (für die NoSQL-Datenspeicherung), Express und Node (zum Schreiben von Webservern) und Angular (zum Schreiben reaktiver Benutzeroberflächen).
Was sich geändert hat
In den letzten fünf Jahren haben jedoch mehrere Trends den MEAN-Stack und die Vorstellung vom Full-Stack-JavaScript-Monolithen ausgehöhlt
- Anstatt dass jeder Entwickler maßgeschneiderte Endpunkte schreibt, sind APIs zu einer eigenen Wirtschaft geworden, mit Unternehmen wie Stripe, Twilio und Zapier, die rein durch die Stärke ihrer APIs gewachsen sind.
- Die Übernahme von Firebase und die Einführung von AWS Lambda im Jahr 2014 – und die darauffolgende Serverless-Revolution – haben das Konzept der eigenen, undifferenzierten Serververwaltung und Zuverlässigkeitsentwicklung deutlich unattraktiver gemacht.
- Was proprietäre Backends betrifft, so war klar, dass nicht alle Backend-Umgebungen in JavaScript geschrieben sein würden, insbesondere angesichts der anhaltenden Stärke anderer Sprach-Frameworks, darunter Rails, Laravel und .NET, sowie aufkommender Sprachen wie Go. Selbst die Entwickler von Express.js und Node.js gaben die JavaScript-Entwicklung gänzlich auf.
Dies hat dazu geführt, dass der Stack und die Hauptarbeit des Produktentwicklers sich noch stärker auf das Front-End verlagert haben, als es mit dem MEAN-Stack vorgesehen war. Chris hat dies als ein Phänomen beschrieben, das Frontend-Entwicklern außergewöhnliche Kräfte verleiht, aufgrund des Trends zu Front-End-Tooling für Bereiche, die traditionell dem Backend zugeordnet wurden. Auch die Frontend-Entwicklung hat sich weiterentwickelt, hauptsächlich durch die inkrementelle Hinzufügung einer Constraint-Schicht zu dem, was wir bereits verwenden – Hinzufügung einer Designphilosophie, Typen, Schemas und Komponentenstruktur zu unserer App-Entwicklung.
Warum all diese Änderungen? Hört auf, Dinge zu ändern!
Die Wahrheit ist, dass wir jetzt in einer Welt leben, in der Produkt- und Geschäftsanforderungen die Web-App- (einschließlich Mobile Web) Entwicklung auf Augenhöhe mit der nativen Android-, iOS- und Desktop-App-Entwicklung bringen müssen, während unsere unterschiedlichen Webentwicklungs-Tools im Vergleich zu diesen eng gefassten Ökosystemen immer noch stark unzureichend sind. Es ist nicht so, dass ältere Toolsets an sich falsch sind oder dass die neuen perfekt sind. Stattdessen können die Änderungen als Reaktion auf die zugrunde liegenden Bedürfnisse von Produktteams betrachtet werden.
- Stärkere Typen: Typüberprüfung ist keine Allzwecklösung und ersetzt nicht die Notwendigkeit von Tests, aber sie ermöglicht bessere Tooling und erhöht die Code-Zuverlässigkeit. TypeScript und GraphQL tun dies für Clients und APIs, wie Chris Toomey von thoughtbot gezeigt hat. Lauren Tan von Netflix hat diese Idee noch weiter vorangetrieben und einen vollständigen End-to-End Strongly Typed Graph vorgeschlagen.
- Integrierte Designer/Entwickler-Workflows: Die Abhängigkeit von manuellen Code-Tests und Design-Reviews skaliert nicht. Designsysteme sind heute umfassende Dokumentationen über das Wie und Warum wiederverwendbarer Komponenten in einem Unternehmen. Brad Frost hat gezeigt, wie man „Workshop“- und „Storefront“-Umgebungen für einen Styleguide- und Designsystem-Workflow mit Gatsby einrichtet. Design-Tools wie Sketch und Framer haben begonnen, React und Design eng in gestraffte Workflows zu integrieren. TypeScript und GraphQL bieten beide auch eng gekoppelte, selbstdokumentierende Features mit TSDoc, GraphiQL und verwandten IDE-Integrationen.
- Optimiert für Veränderung: Da Produktteams iterative agile Sprints und Split-Tests annehmen, ist es zunehmend wichtig, flexible Paradigmen zu verwenden, die inkrementelle Anpassungen ermöglichen. Dan Abramov vom React-Team nennt dies „Second Order“-API-Design – Robustheit gegenüber sich ändernden Anforderungen. Designsysteme und React erleichtern das schnelle Komponieren wiederverwendbarer Komponenten, wobei TypeScript die Feedback-Schleifen drastisch verkürzt. Adam Neary von Airbnb zeigt ein wunderbares Beispiel für Refactoring und Iteration mit React und Apollo GraphQL in der Produktion.
Beachten Sie, dass sich „Produktteams“ in diesem Artikel hauptsächlich auf Produktentwicklungsteams beziehen, obwohl es oft der Fall ist, dass Produktdesign und Produktmanagement räumlich nah beieinander liegen oder starken, häufigen Input haben. Entwicklungs-Workflows müssen dies als Ergebnis explizit berücksichtigen.
Verbleibende Grenzen
Ob Sie es glauben oder nicht, ich bin beschreibend und nicht vorschreibend; ich empfehle nicht, dass jeder seinen Code wegwirft und STAR-Apps schreibt. Vielmehr beobachte und benenne ich, was ich als Trend sehe, bei dem großartige Produktteams alle auf dieses neue Muster konvergieren. Und sie sind vielleicht auf etwas gestoßen.
Ich glaube jedoch nicht, dass die Entwicklung ihren Abschluss erreicht hat. Es gibt immer noch zu viele wichtige Aspekte der modernen Web-App-Entwicklung, die einen breiteren Konsens erfordern, was zu einem Potpourri aus benutzerdefinierten oder Einzellösungen und Checklisten geführt hat. Ein wichtiger Punkt ist die Leistung. Die durchschnittliche Menge an JavaScript, die auf Desktop und Mobilgeräten ausgeliefert wird, hat sich in den letzten fünf Jahren verdoppelt. All die wunderbare Web-App-Entwicklung der Welt ist nutzlos, wenn der Benutzer wegnavigiert, bevor sie geladen ist. Die traditionelle Lösung war (oft selbst erstelltes) serverseitiges Rendering, das später von Frameworks wie Next.js und After.js verwaltet wird. Dies erfordert jedoch immer noch das Ausführen und Verwalten eines Servers, sodass statische Rendering-Lösungen wie Gatsby und React-Static beliebt geworden sind, um Apps direkt in statisches Markup zu rendern, das später lazy rehydriert wird (das letzte Stück des JAMstack). Progressive Web App-Technologie und Muster helfen, nachfolgende Ladevorgänge noch schneller zu machen und dienen als praktikable Alternative zu nativen Erlebnissen.
Fortsetzung folgt…
Während sich diese Geschichte weiter entfaltet, glaube ich, dass noch viel mehr Erkundung und Experimente erforderlich sind, um die Lernkurve für mehr Teams zu glätten, damit sie STAR-App-Workflows übernehmen können. Tatsächlich lerne ich selbst im offenen bei STAR Labs und lade Sie ein, dabei zu sein. Wenn Sie Erfahrungen teilen oder Fragen stellen möchten, bin ich ganz Ohr.
Guter Beitrag und ein leicht zu merkendes Akronym. Die Teams, mit denen ich arbeite, könnten von Fortschritten in allen vier Bereichen profitieren.
Danke, Joel! Ich hoffe, mehr über diese Themen zu schreiben und zu veröffentlichen.
Ein weiteres großes fehlendes Stück im Vergleich zu nativen Apps: Offline-Funktionalität.
Ja – obwohl wir niemals native App-Parität haben werden. Bin auf eine großartige Liste gestoßen: https://reddit.com/r/webdev/comments/abkggl/_/ed1mxrz/?context=1
Das Beste, was wir hoffen können, ist eine begrenzte PWA-Funktionalität, und wir sollten uns sorgfältig dafür entscheiden, da die Entwicklererfahrung und die Devtools noch nicht für eine Offline-First- oder PWA-by-Default-Erfahrung bereit sind.
Ich denke, Sie haben es mit diesem Satz auf den Punkt gebracht: „STAR-Apps drehen sich mehr um den Workflow von Produktteams als um spezifische Technologien.“
Ich bin ein großer Fan davon, die Dinge auf dem neuesten Stand zu halten, nicht nur wegen der Verwendung der neuesten Technologie, sondern um unseren Benutzern eine bessere Erfahrung zu bieten.
Je mehr Stacks wir haben, desto mehr „validierte“ Muster werden verwendet, um Entwicklern/Teams zu helfen.
Wirklich schöner Artikel, Shawn! :)
Danke! Ich suche immer nach weiteren Mustern wie diesem – und konzentriere mich dann nicht so sehr auf die Muster, sondern auf die zugrunde liegenden Gründe und Probleme dahinter. Es ist ein bisschen so, als wäre man Arzt und schaut sich Symptome an, versucht aber, die zugrunde liegende Ursache zu diagnostizieren.
Schöner Artikel, obwohl ich darauf hinweisen möchte, dass einige der Tools ReactJS-zentriert sind (abgesehen von ReactJS selbst – Beispiel: Styled-Components.
Nun, ich sage nicht, dass das per se falsch ist – das ist es sicherlich nicht –, aber der Titel des Artikels deutet auf einen allgemeineren globalen Ansatz für Front-End-Tooling hin.
Ich stimme zu, obwohl das mehr oder weniger absichtlich war – ich lebe hauptsächlich im React-Ökosystem, daher kann ich nicht mit viel Autorität über andere Frameworks sprechen. Aber ich bin definitiv offen dafür, diese Idee zu erweitern und mit anderen gängigen Setups in anderen Ökosystemen zu vergleichen!