Selbst große Firmen in der Industrie können nicht bestreiten, dass es neben klassischen Desktop-Frontend-Technologien, wie WinForms oder WPF, eine bemerkenswerte Bewegung in Richtung Web-Frontend-Technologien gibt. Als UX Dienstleister, der seine Kunden zu großen Teilen auch im Frontend-Engineering unterstützt, werden wir oft gefragt, welche Technologie am besten zu den Bedürfnissen des Kunden passe und welche er demnach wählen solle. Neben vielen relevanten Bibliotheken und Frameworks, sind Angular* und React die zwei vorherrschenden Platzhirsche. Es ist nicht einfach die Frage zu beantworten, für welche der beiden Technologien man sich entscheiden solle. Ein Ansatz ist die Betrachtung verschiedener Kriterien in Bezug auf einen fest definierten Satz von Anforderungen seitens der Entwickler. Im Folgenden werde ich eine Antwort darlegen, die wir für uns bei Centigrade gefunden haben und von der wir denken, dass sie für unsere Kunden am hilfreichsten sein wird.
Warum sollte man Web Technologien nutzen?
Zunächst müssen wir beantworten, warum es sinnvoll sein kann, überhaupt eine Web-Technologie für das Frontend-Engineering auszuwählen. Eine solche Entscheidung aufgrund von populären Schlagworten oder Trends zu treffen ist kein guter Grund, jedoch häufig die initiale Motivation und der Grund warum dieses Thema überhaupt aufkommt. Web-Frontend-Technologien sind eine Chance echte plattformübergreifende Systeme umzusetzen. Dies kann sich nicht nur auf Betriebssysteme (wie Windows oder Unix), sondern auch auf mobile Geräte und grundsätzlich auf alles beziehen, auf dem ein Browser läuft. Moderne clientseitige Web-Frameworks gehen sogar noch einen Schritt weiter, indem sie vom Browser abstrahieren, sodass nativ sogar Desktop-, Mobil- oder komplett andere Systeme adressiert werden können. Im Hinblick auf die heutige Digitalisierung und Industrie 4.0, wobei viele unterschiedlichste Geräte untereinander verbunden sind, kann diese Flexibilität oft eine entscheidende Anforderung sein. Allein aus diesem Grund ist es durchaus berechtigt Web-Technologien in Erwägung zu ziehen. 
Angular und React
Angular wird entwickelt von Google, hinter React steht Facebook; beides sind Großkonzerne. Die Technologien haben eine enorm große Community und (bezogen auf das Web-Engineering) eine eher lange und mittlerweile stabile Entwicklungshistorie. Nachdem wir deren Evolution über einen längeren Zeitraum beobachtet haben, können wir gewissenhaft sagen, dass sowohl Angular als auch React in Produktivumgebungen genutzt werden können und werden.
In ihren Grundkonzepten sind sich Angular und React sehr ähnlich: Beide sind Komponenten-basiert, was bedeutet, dass alle Anwendungen gebaut werden indem man mehrere kleine, in sich geschlossene Komponenten mit einer klaren Zuständigkeit zu einem großen Gesamtsystem zusammenstellt. Da es heutzutage im Web-Engineering als Bad Practice gesehen wird, wenn das sogenannte DOM (Document Object Model des Browsers auf direktem Wege manipuliert wird (siehe jQuery), basieren beide Technologien auf der Idee der DOM-Abstraktion. Deklariert man Angular oder React Komponenten auf der View-Ebene, beschreibt man damit nur wie die Applikation aussehen soll, während die Frameworks mit Hilfe von intelligenten Algorithmen diese Informationen am performantesten verarbeiten. Durch diese Abstraktion von konkreten DOM-Elementen des Browsers ist es möglich, nativ andere Zielsysteme wie zum Beispiel Android oder iOS, Backend-Server oder sogar IoT-Geräte anzusprechen. Die Entwickler hinter Angular und auch React arbeiten auf mehreren Ebenen sehr intensiv daran, die Performanz, Architektur, Flexibilität und die sogenannte Developer Experience zu verbessern. Zusammengefasst erfüllen damit beide Technologien, insofern sie im vorgesehenen Sinne genutzt werden, die oben genannte Multi-Plattform-Anforderung.
Framework und Library
Da die Kerngedanken und eben genannte technischen Schlüsselkriterien ziemlich ähnlich sind, fokussieren wir uns nun auf die Unterschiede zwischen Angular und React, um für oder gegen eines der beiden sprechen zu können. Der Hauptunterschied ist, dass Angular als Framework oder gar Plattform bezeichnet wird, wohingegen man React als Bibliothek auffasst. Wie der englische Begriff schon aussagt, bietet ein Framework (zu Deutsch Rahmenwerk) einen Rahmen, in den sich der Quellcode einer Applikation einfügen kann. Damit einher geht, dass es eine Menge an vordefinierten Beschränkungen wie beispielsweise Programmiersprachen, Werkzeuge oder Muster gibt, die man nutzen und an die man sich halten sollte. Im Gegensatz dazu kann eine Library vom Applikationscode in flexiblerer Art und Weise konsumiert werden. Man kann React wählen und nur punktuell einbinden, während man fehlende Teile ab einem gewissen Punkt selbst hinzufügen muss. Diese Flexibilität hat sowohl Vor- als auch Nachteile.
Angular ist restriktiver, gibt klare Wege und Grenzen vor und macht es einem schwerer aus diesen auszubrechen. Auf der anderen Seite werden dadurch bereits etablierte Best Practices vorgegeben, was dazu führt, dass man ohne lange Entscheidungsprozesse schnell damit starten kann. Existiert bereits eine fest definierte und etablierte Toolchain, kann es wiederum leichter sein, dort React zu integrieren und auf die eigenen Bedürfnisse anzupassen. Man ist jedoch auch gezwungen diese Integrationen selbst durchzuführen und die passenden Werkzeuge auszuwählen, dort wo die Bibliothek keine vorgibt. Insbesondere für Neueinsteiger oder in zeitkritischen Projekten kann dies schnell etwas überfordernd wirken.
Integration in etablierte Werkzeuge und Abläufe mit Angular als Framework gegenüber der freien Adaption von React als eine von mehreren Bibliotheken in der eigenen Codebasis.
Eine Entscheidung basierend auf dem UX-Prozess
Da es unser initiales Ziel war, zwischen den beiden Technologien einen Favoriten auszuwählen, wollen wir nun einen kurzen Blick auf die speziellen Entscheidungskriterien aus dem Blickwinkel des Frontend-Engineerings werfen. Sie sind der Schlüssel in der Domäne der UX Dienstleistungen.
Centigrade Design Engineers arbeiten mit den Backend-Entwicklern auf Kundenseite eng zusammen und sind darauf angewiesen eine enorme Menge an Look-&-Feel-Ressourcen einer Applikation zu verwalten. Bereits in kleineren Projekten entstehen dabei beispielweise viele CSS Stile und Klassen. Es ist essentiell, dass diese Style-Informationen modularisiert, wiederverwendet und in einer gut wartbaren Art und Weise strukturiert werden können. Darüber hinaus darf der architektonische Aufbau dieser Ressourcen die Performanz einer Anwendung in keinem Fall negativ beeinflussen. Zusätzlich zur Erstellung statischer Stilinformationen (der Look), ist es wichtig, dass die Interaktionen und das Layout-Verhalten (das Feel) exakt so umgesetzt werden können, wie es in vorangegangen Schritten des konzeptionellen und visuellen Designs definiert wurde. Beide Aspekte, das Aussehen sowie das Verhalten der Anwendungen, müssen gut in Zusammenarbeit mit den Backend-Entwicklern unserer Kunden implementiert werden können. Aus diesem Grund möchte man die Schnittstellen, an denen das Frontend auf das Backend trifft, klar definieren, sodass beide Team Mitglieder parallel arbeiten können, ohne sich gegenseitig zu behindern.
Das Styling von Angular Applikationen kann gut strukturiert durch SASS und eine Kombination aus dem Anlegen von globalen und Komponenten-basierten Style-Informationen durchgeführt werden. Es gibt noch keine eindeutige Vorgabe oder eine klare Best Practice wie das Styling in React Anwendungen durchzuführen ist. Styled Components, CSS Modules und weitere Techniken treten hier in Konkurrenz zueinander.
Viele unserer eigenen, als auch die Entwickler unserer Kunden kommen aus der Entwicklung mit C# und WPF. Angular Anwendungen in einem eher klassischen MVVM/MVC-Stil umzusetzen, fühlt sich daher etwas natürlicher an als die funktionale Art der Programmierung in React mit einem starken Fokus auf dem Konzept der Unveränderbarkeit. Beide Entwicklungsmuster haben ihre Vor- und Nachteile, jedoch werden insbesondere Neueinsteiger (mit einem .NET Hintergrund) im Web-Bereich womöglich bei React eine steile Lernkurve vernehmen.
Die Angular Plattform hat nicht nur TypeScript (was wir im Besonderen schätzen gelernt haben, da es eine gute Zusammenarbeit im Team ermöglicht und die Vorhersehbarkeit im Code fördert), die Angular CLI und viele weitere nützliche Entwicklerwerkzeuge integriert. Es liefert auch eine großartige Dokumentation und einen gut geschriebenen Styleguide, der sich automatisiert in die praktische Arbeit mit Angular integrieren lässt. Wenn wir mit React arbeiten, müssen wir eine Menge von kleinen Entscheidungen treffen, wenn es darum geht, die verschiedenen Bestandteile unserer Toolchain zu definieren. Beispielsweise erfordert die Nutzung von TypeScript in React zusätzliche Schritte, da hier für gewöhnlich Babel als Transpiler zu JavaScript genutzt wird.
Die Auswahl von React bedingt die Evaluation, Entscheidung und Einigung in Bezug auf einen ganzen Satz an Technologieentscheidungen, welche in der Zusammenarbeit mit unseren Kunden in jedem einzelnen Schritt der Arbeitsabläufe getroffen werden müssen. Das benötigt initial zusätzlichen Aufwand, bevor man sich auf die Entwicklung der tatsächlichen Anwendungslogik fokussieren kann. Besteht das Bedürfnis – das dann zumeist von unseren Kunden ausgeht – eine sehr feingranulare Kontrolle über die Einzelbestandteile zu haben, würde man dafür eher React wählen, wo man genau diesen Weg dann aber auch beschreiten muss. Eine solche Feingranularität ist in Angular durchaus möglich, jedoch in der Form nicht empfohlen.
Zusammenfassung
Um nun mit unseren speziellen Entscheidungskriterien im Hinterkopf zu einem Schluss zu kommen, haben wir bei Centigrade aufgrund seiner reibungslosen Integration und dem hohen Level der Produktivität eine Präferenz zu Angular als unsere primäre Technologie im Frontend-Web-Engineering. Angular als Framework wird eine gute Wahl sein, wenn Sie nach einer stabilen Lösung mit einer Menge von vor- aber gut definierten Bestandteilen suchen. Es gibt außerordentlichen Toolsupport und eine großartige Community. React als Library mag passender sein, falls Sie von Beginn an die vollständige Kontrolle über jegliche Teilbereiche haben möchten. Eine solche Entscheidung ist immer kontextabhängig, weshalb wir uns aus diesem Grund im Allgemeinen nicht gegen React aussprechen. Wir haben einfach sehr gute Erfahrungen mit der Angular Plattform gemacht und so gut wie keine Hindernisse bei der Realisierung selbst komplexer und großer Projekte angetroffen. Jeglichen neuen Technologien, wie Angular und React, treten wir offen entgegen, solange sie uns dazu befähigen, Produkte zu entwickeln, die eine großartige UX bieten und die Nutzer am Ende glücklich machen.
Sind Sie interessiert an tiefgehenden Technologiebesprechungen oder haben Sie weitere Fragen, wie man eine gute UX durch das Zusammenspiel von Design und Implementierung zu Tage bringt? Dann werfen Sie doch einen Blick auf unsere Engineering-Dienstleistungen.
*Wenn wir von Angular sprechen, beziehen wir uns auf Angular ab Version 2 (momentan 5). Angular vor diesen Versionen, Angular 1.x, wird auch AngularJS genannt. Damit folgen wir der offiziellen Nomenklatur von Google.
