Angenommen, man entscheidet sich für eine JavaScript basierte Frontend-Lösung, endet man oft bei der Wahl: Angular vs React. Natürlich gibt es noch andere bekannte Technologien, wie beispielsweise Vue.js, auf die ich in diesem Beitrag jedoch nicht eingehen werde. React ist eine JavaScript Library, mit welcher man komplexe Frontend-Lösungen realisieren kann. Dasselbe kann man auch mit dem Angular-Framework erreichen. React stammt von Meta (früher Facebook), Angular kommt aus dem Hause Google. Viele entscheiden sich für React, weil es flexibler, schlanker und schneller ist. Was bietet Angular um gegen diese Argumente dagegen zu halten?
Dieser Beitrag ist absichtlich provokativ geschrieben, um Diskussionen anzuregen und Überlegungen aufzuzeigen, die vielleicht nicht auf den ersten Vergleich ersichtlich wären.
Tooling: Projekterstellung
Angular bietet ein CLI (Command Line Interface), um das Projekt aufzusetzen. Darin inbegriffen ist:
- Testing
- Typescript
- serve (eine Funktion für die Entwickler das Frontend einfach zu starten)
- Environment Configuration Files
- Routing
- Production Build Scripts
Angular Projekt Erstellung
Das sieht auf den ersten Blick überwältigend aus, ist aber bei einem mittelgrossen Projekt notwendig, wenn es nicht nur aus einer Landing-Page besteht. Stell dir vor, man müsste alles selber machen!
Oh, stimmt. Bei React muss man dies selber machen … Nun ja, nicht ganz. Inzwischen gibt es eine Möglichkeit, eine React App mit dem Terminal zu erstellen. Dies beinhaltet auch Testing, Serving und Build Scripts. Typescript einzustellen ist ebenfalls möglich, wenn man dies als Parameter mitgibt.
React Projekt Erstellung
Einiges, das generiert wird, aber fehlt da nicht etwas? Einige Konfigurationsfiles werden mit der create-react-app Methode versteckt. Ob zum Guten oder zum Schlechten? Das kommt auf die Umstände an. Sicher ist es hilfreich, nur das direkt zu sehen, was man auch wirklich braucht. Wie beispielsweise Routing (damit man auf der Webseite navigieren kann) ist essentiell. Oh stimmt, das ist bei create-react-app nicht dabei …
Dafür gibt es weitere Templates (hier zu finden: https://www.npmjs.com/search?q=cra-template-* ), welche viele Funktionalitäten direkt in das Projekt einbinden. Nur braucht man die wirklich?
Zusammengefasst wirkt es tatsächlich so, dass React, wie oft behauptet, viel schlanker daher kommt als ein Angular Projekt. Wenn jedoch etwas wie ein Router nicht im Standardprojekt enthalten ist, das praktisch IMMER gebraucht wird, wirkt das nicht sehr ehrlich. Ebenfalls gibt es mehr Aufwand für den Entwickler, diese Funktionalität nachträglich hinzuzufügen. Egal, ob dies nur eine Zeile in der Konsole ist: Aufwand = Zeit & Geld.
Tooling: Effizient entwickeln
Möglichst wenig Aufwand zu haben ist umso wichtiger bei Tätigkeiten, die häufig durchgeführt werden. Den Begriff “Automation” trifft man häufig beim Testing an. Aber auch beim Erstellen von neuen Komponenten spart eine Automatisierung Zeit.
Dies kann in React mit dem Tool react-boilerplate erreichen werden, wie in diesem Blogpost beschrieben:
Damit wird nicht nur die Projekterstellung einfacher, sondern es hilft, eine einheitliche Codebasis zu erstellen oder zu erhalten. Neue Entwickler können schneller eingearbeitet werden, wenn alles etwa gleich gestaltet ist und aufwändige Refactorings werden seltener. Zugegeben, anfangs steckt Arbeit drin, alle Templates zu erstellen, aber es zahlt sich aus.
Es stört mich, dass dies eine Third-Party-App ist, welche evtl. nicht richtig gewartet wird. Was passiert, wenn der Support eingestellt wird? Bei einer neuen Version von React? Oder bei einem Bug? Da muss man wohl selber diese App anpassen … Somit hat man plötzlich zwei Apps, um die man sich kümmern muss. Beachtet man die kurzen Updatezeiten (Angular bietet alle 6 Monate ein Major Update), die Sicherheitsstandards, die eingehalten und ebenfalls geupdated werden müssen, so ist dies ein grösseres Unterfangen, das im Budget eingeplant werden muss.
Ist es nicht Luxus, dass die Angular CLI diesen Service bereits standardmässig mitliefert? Man kann praktisch alles mit der Angular CLI generieren lassen, was benötigt wird: Router, Klassen, Components, Guards, und Vieles mehr. Dies bedeutet: Weniger Zeit für Coding Guidelines, mehr Zeit für die effektive Arbeit. Man kann die Definitionen und Dokumentationen weglassen in React, bezahlt aber dann das X-Fache im Verlaufe des Projektes, wegen uneinheitlicher Architektur, welche die Entwickler verlangsamt, Bugs die dadurch entstehen, die verschiedenen eingesetzten Lösungen usw.
Standard: Typescript
Manche sagen, wenn man keinen Clean Code hat mit reinem JavaScript, dann kann man nicht programmieren. Auch wenn ich dem ansatzweise zwar zustimme, will ich mir mein Leben nicht schwerer machen, als es ist. Warum soll ich mir bei jedem Objekt Gedanken machen müssen, ob ich den richtigen Typ verwende? Anstatt sicher zu sein, dass der Compiler mich warnt, wenn ich einen falschen Typ verwende.
Mit Typescript erreicht man bei JavaScript basierten Projekten diese Typsicherheit, die jedes Mal beim Compilieren überprüft wird und von vielen Frontend IDE’s unterstützt wird. Weniger potentielle Bugs, schnellere Entwicklungszeiten und Strukturen, die man von anderen Programmiersprachen wie C# kennt.
Bei React kann man dies ohne Probleme nachinstallieren (oder nutzt eines der Templates beim Erstellen des Projekts, die Typescript unterstützen). Angular arbeitet direkt damit, beziehungsweise kann man Angular fast nicht ohne Typescript nutzen. Es werden Möglichkeiten existieren, aber zu empfehlen ist es nicht.
Architektur
Die Softwarearchitektur definiert die Struktur des Projekts. Meistens werden die verschiedenen Module auf dem Server, die Datenbank, manchmal auch die API in der Architektur vorgesehen. Aber auch das Frontend sollte nicht nur ein grosser schwarzer Block sein. Gerade bei grösseren Projekten mit einem komplexeren Benutzerinterface ist es wichtig, die Frontend-Architektur ebenfalls zu definieren und zu dokumentieren. Ohne Architektur herrscht Chaos, was zu langen Entwicklungszeiten und Bugs führt oder sogar im Neuschreiben des Frontends endet.
Fügt man sich den Guidelines von Angular, so hat man bereits eine Architektur, die einem kleinen bis mittelgrossem Projekt standhält. Definiert man nur schon, wo der Applikations State gespeichert wird, welche Verantwortung das Routing hat und wie der Datenfluss zum Server funktioniert, so hat man eine solide Basis.
React ist auch in diesem Fall frei. Zu Beginn muss man sich gut überlegen, wie das Team die Files organisiert, welche Regeln für die Datenflüsse gelten, ob mit Premises oder RxJs gearbeitet wird, ob Typescript verwendet wird und einige weitere wichtige Entscheidungen treffen.
Angular vs React: Was nun?
Um ein stabiles Frontend zu implementieren braucht man gewisse Tools. Dass React von sich aus behauptet “schlank” zu sein, mag stimmen, allerdings wächst es zu einer gewissen Grösse an, sobald man eine professionelle Umgebung aufbaut.
Mit der Flexibilität, die React bietet, kommt auch die Verantwortung, die Struktur zu definieren und zu dokumentieren, für die man sich entscheidet. Nur weil React flexibel ist, heisst dies nicht, dass man einfach machen kann, was man will. Die Flexibilität kommt mit den Kosten, diese Zeit zu investieren, ansonsten bezahlt man dies mit hoher Wartung, Bugs und langen Entwicklungszeiten. Schlank bedeutet in diesem Fall, dass Zeit und Budget in die Definition, Dokumentation und Setup eines Projekts gesteckt werden muss und das Team all die Probleme, die bspw. bei Angular gelöst worden sind, selbst implementieren muss.
Wie zu Beginn angemerkt, ist es meine Absicht, Diskussionen anzuregen und Überlegungen zu starten. Es geht in einem Projekt nicht darum, immer das einzusetzen, was gerade “in” ist (React ist aktuell populärer als Angular), sondern auch abzuwägen, ob der Aufwand von eigenen Coding Guidelines, eigener spezifischer Architektur und eigenen Toolings Sinn macht und dies entscheidend für den Erfolg sein kann.
