Welches Front-End Framework darf’s denn sein: Angular (www.angular.io), React.js (www.reactjs.org), Vue.js, Svelte oder Ember? – Und welches Designsystem: Material Design (www.material.angular.io), PrimeNG (www.primefaces.org/primeng), Clarity (www.clarity.design), Carbon Design System oder Fluent UI (www.microsoft.com/design/fluent)?

Softwareprojekte (und die Entwicklung von Softwareprodukten) sind von einer Vielzahl an Entscheidungen zum Tech Stack gekennzeichnet: Programmiersprache / Framework (Java, C#.NET, …), Datenbanken (PostGreSQL, MS SQL, Oracle, Mongo DB, …) und natürlich auch der Front-End Technology Stack. Die wichtigsten Front-End Frameworks sind Angular und React, wobei Letzteres eigentlich nur eine Bibliothek ist – hier treten also „Ökosysteme“ in weitestem Sinne gegeneinander an.

Nachfolgend stelle ich einige praxiserprobte, gängige Kriterien für den Auswahlprozess vor. Und zwar nicht nur für eine Auswahl der Frameworks, sondern auch für Designsysteme.

React vs Angular: Ein umfangreicher Kriterienkatalog

Bei einem solchen Entscheidungsprozess gibt es „universale“ Kriterien, aber auch „unternehmenspezifische“ Kriterien. Die „unternehmensspezifischen“ Kriterien stellen etwa ab auf entscheidungsrelevante Faktoren wie:

  • Welches Know-How ist im unternehmenseigenen Entwicklerteam bereits vorhanden? Welcher Trainingsbedarf besteht ggf. bei einem Wechsel des Tech Stacks? Welche Bereitschaft zum „Umlernen“ besteht überhaupt generell?
  • Mit welchen Technologien wurden bislang Produkte (oder auch: Projekte mit Referenzcode) entwickelt? Wie hoch würde die Migration von Produkten auf einen neuen Tech Stack ausfallen (also etwa von React auf Angular?

In der Praxis werden für alle zur Auswahl stehenden Front-End Frameworks Bewertungen zu den einzelnen Kriterien entwickelt (z.B. 1 bis 5). Entweder wird schlussendlich die Summe der erzielten Bewertungen je Technologie miteinander verglichen, oder aber die Kriterien werden noch unterschiedlich gewichtet (z.B. Investitionssicherheit höher als Aufwand für Migrationsbedarf).

Nachfolgend ein knapper Überblick zu den Kriterien:

Wie zukunftsfähig ist eine Technologie bzw. wie hoch ist die Investitionssicherheit? Hierfür betrachtet man zum einen, welcher Konzern hinter einem OpenSource Projekt steht. In unserem Fall gilt: Angular ist ein OpenSource-Projekt, angeführt durch Google. React wird von Facebook entwickelt. Beide Technologien können damit als „zukunftssicher“ hinsichtlich Konzern-BackUp betrachtet werden.

Zum anderen ist hinsichtlich Zukunftsfähigkeit entscheidend, wie die Popularität einer Technologie ausfällt. Dafür kann man zahlreiche Indikatoren heranziehen. Auf Statista beispielsweise findet sich eine Auswertung zur Nutzungshäufigkeit von Angular und React: Most used web frameworks among developers worldwide, as of 2021:

Als Indikator für die Popularität lassen sich auch heranziehen die Rankings auf der Seite stateofjs.com:

Und natürlich umfangreiche statistische Daten zu Downloads, Beiträgen in Diskussionsforen, sogenannten „forks“ und derlei mehr auf github.com:

Es lässt sich unschwer erkennen, dass React hinsichtlich Popularität klar die Nase vorn hat.

Betrachtet man die Verfügbarkeit von Entwicklerressourcen ist das Bild wiederum gemischt, hier gibt es keinen klaren Favoriten. Einen solchen Indikator entwickelt man etwas durch einschlägige Artikel (z.B. Hacker News Hiring Trends), verfügbaren Entwicklern auf www.freelancermap.de , www.gulp.de oder www.freelancer.de. Klar ist, dass in dieser Betrachtungsdimension insbesondere die Frage relevant ist, welche unternehmensinternen Ressourcen zur Verfügung stehen.

[Exkurs] Die Auswertung von insgesamt verfügbaren Qualifikationsprofilen ist übrigens ein gänzlich anderer (und womöglich umgekehrt proportionaler Indikator): Die Verfügbarkeit von (buchbaren) Freelancern kann darauf hindeuten, dass bestimmte Skills nicht (mehr) gefragt sind, während niedrige Zahlen darauf hindeuten, dass Entwickler mit bestimmten Kompetenzen gerade hoch-ausgelastet und eben nicht mehr verfügbar sind. Hier kommt es folglich darauf an, welche Frage / welches Suchkriterium man heranzieht. [Exkurs Ende]

Kommen wir nun zu einem weiteren, sehr relevanten Kriterium: Dem Aufwand für die unternehmensweite Governance-Administrierung; damit wird sichergestellt, dass alle Entwickler über verschiedene Produkte hinweg auch tatsächlich einen „Standard“ nutzen, der Vorteile wie einheitliches Repository, hohe Wartbarkeit und flexibler Einsatz von Entwicklern über verschiedene Produkte/Projekte hinweg ermöglicht.

Eben hier zeigt sich ein entscheidender Unterschied zwischen Angular und React: Angular ist ein Framework im eigentlichen Sinne, den Entwicklern wird kompletter full-stack für die Frond-End Entwicklung bereitgestellt, keine weiteren zusätzlichen Technologien sind erforderlich. React ist nur eine Front-End-Schicht und erfordert zusätzliche Technologien – wie Redux -, um ein komplettes Front-End-Anwendungs-Framework bzw. einen gut definierten Entwicklungsstapel bereitzustellen. Dabei existiert ein weitläufiges Ökosystem von Technologien, die mit React integriert werden können. Und eben diese Möglichkeit, aus einer großen Anzahl von Projekten/Bibliotheken zu wählen, wird von vielen Entwicklern als großer Vorteil von React angesehen.

Letzteres führt jedoch zu zusätzlichem Governance-Aufwand, da mehrere unabhängige externe Open-Source-Projekte überwacht und Aktionen auf der Grundlage der beobachteten Informationen durchgeführt werden müssen. Es ist folglich nicht überraschend, dass Angular bei diesem Kriterium einen Vorteil hat.

Der Vollständigkeit halber noch der Hinweis darauf, dass alle shortlisted Technologien einige Must-Have Kriterien erfüllen müssen; diese sind eher als Mindest-Anforderungen zu sehen. Diese habe ich hier nicht im Detail erläutert, dazu zählen: Verbreitung in der Industrie (how battle-tested are they), Testbarkeit, Verfügbarkeit von Anbietern mit Support und Wartung, Verfügbarkeit von Dokumentation. Sowohl React als auch Angular erfüllen eben diese Kriterien natürlich.

Ein Kriterienkatalog zur Auswahl von Designsystemen

Die Relevanz eines Designsystems dürfte klar sein: Es handelt sich dabei um eine Reihe von Standards zur Verwaltung von Design in großem Maßstab, so dass (a) Redundanzen reduziert werden und (b) eine visuelle Konsistenz über alle Produkte (oder auch: Softwareprojekte) geschaffen wird. Das Design Repository umfasst in der Regel einen Style Guide, eine Komponentenbibliothek und eine Pattern Library (Pattern umfassen – in Abgrenzung zur Komponentenbibliothek – eine Integration von Komponenten zur Lösung bestimmter UI/UX Anforderungen).

Die Kriterien, die bei der Auswahl eines Designsystems zur Auswahl kommen, sind natürlich vergleichbar den bereits eingeführt Kriterien. So findet sich zu Popularität von Designsystemen auf GitHub etwa eine Bewertung nach den stars: Für Material Design (Google, Angular) liegt dieser Wert bei 16.700, für Carbon Design 5.700 und für MUI Core etwa 79.800.

Schauen wir uns einmal exemplarisch zwei Designsysteme an: Eines für Angular (Material Design), eines für React (MUI Core).

Material Design ist ein OpenSource-Projekt, angeführt durch Google. Es gibt eine hohe Adoptionsrate innerhalb der Angular-Community, auf www.stackoverflow.com gibt es eine große Anwendercommunity. Die Weiterentwicklungsdynamik ist gut (ca. ein neues Release pro Woche), es gibt eine gute Dokumentation je Komponente (inkl. Beispielen), Dokumentation für das Component Development Kit (CDK) und Anleitungen für eine Vielzahl von Themen.

Das Carbon Design System wird von IBM unterstützt (und natürlich auch in IBM Produkten eingesetzt, auch für die IBM Cloud). Mitte 2022 waren ca. 12 Contributors aktiv, was ein Aktivitätslevel auf gutem Niveau entspricht. Die Dokumentation ist gut. Im Übrigen gilt, dass dieses Designsystem sowohl für React als auch für Angular genutzt werden kann.

Zum Weiterlesen

Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.