15. Januar 2020 in Allgemein, code IT

React vs. Angular

Mit dem Aufkommen der großen Webplattformen sind die Anforderungen an dynamische Webapplikationen rasant gestiegen. Daher haben die beiden “Big Player” Google und Facebook jeweils Angular und React entwickelt (oder gesponsort), eigene JavaScript basierte Frameworks, um ihr User Interface dynamisch weiter zu entwickeln.   

Das Thema „Angular vs React“ wurde in Foren, auf Webseiten und auch in der analogen Welt schon viele Male ausführlich besprochen. Bei vielen dieser Artikel werden Vorteile und Nachteile gegenübergestellt. Das hilft jedoch nicht wirklich, wenn jemand ein neues Projekt anfangen möchte und nach entsprechenden Tools sucht. Es wäre besser, sich einfach ein Beispiel anzuschauen und sich daran eine eigene Meinung zu bilden. Denn die Entscheidung für Angular oder React hat Auswirkungen auf die weitere Entwicklung des Projekts. Da die beiden Lösungen von den großen Playern Google und Facebook sind, kann man davon ausgehen, dass beide Möglichkeiten eine ausgereifte Lösung darstellen.  Aus diesem Grund werde ich in diesem Artikel zwei kleine Projekte erstellen, das erste mit Angular und das zweite mit React, um zu zeigen wie bestimmte Konzepte behandelt werden. Dabei nehme ich an, dass ihr bereits gewisse Vorkenntnisse im Angular und React besitzt. 

Eine Beispiel-App, die die Entscheidung für Angular oder React einfacher macht 

Die Beispiel-App wird eine TODO Liste sein. Dazu werden wir die zehn neuesten Post-Titel aus entsprechenden subreddits anzeigen. Damit können wir leicht darstellen, wie die bestimmten Mechanismen dabei behandelt werden. Den Quellcode kann man auf GitHub finden. 

Zuerst lässt man sich den Boilerplate Code generieren. Beide Frameworks, Angular und React, bieten bequeme Tools, um dies schnell zu erledigen. Dazu benutzt man folgende Befehle: 

React: 

npx create-react-app react-todo 

Angular 

ng new angular-todo 

Ein paar Minuten später haben wir bei beiden Apps initiale Zustände erstellt. Diese kann man testen, um sicherzustellen, dass alles gut gelaufen ist.  

React: 

npm start 

Angular: 

ng serve 

Wenn alles funktioniert hat, sollten wir bereits beide Apps sehen können. Diese befinden sich unter folgenden URLS: localhost:3000 für React und localhost:4200 für Angular. Jetzt müssen wir nur die Platzhaltertexte aufräumen und dann können wir anfangen. 

Zuerst generieren wir Komponenten für unsere TODO Liste. 

Angular 

ng g component todo-list 

In React haben wir leider keine Möglichkeit um eine Komponente „out of the box“ automatisch zu generieren. Wir müssen die Dateien manuell erstellen oder uns ein npm Paket holen, das es für uns macht. Ich habe für mich selbst ein Tool geschrieben, das ich in diesem Fall benutze. 

React 

rct g TodoList/TodoList 

Obwohl wir nicht viel gemacht haben, können wir schon einen großen Unterschied bemerken: 

Links leere Angular Komponente, Rechts leere React Komponente
Abbildung 1: Links leere Angular Komponente, Rechts leere React Komponente 

In React lebt unser HTML Template in der Komponente selbst und in Angular ist es meistens als separate .html-Datei eingebunden. Der andere Unterschied ist, wie man mit den Styles umgeht. Angular hat dafür auch eine separate Styling Datei. React erlaubt uns, genauso wie Angular, die html Template und die Styles separat zu speichern, jedoch gehen hier die Meinungen zu diesem Thema auseinander.

Was für Möglichkeiten bieten mir die Frameworks? 

Es gibt viele andere Möglichkeiten, die genutzt werden können. Die Wahl hängt von uns ab. Das ist ein sehr wichtiges Merkmal von React: für alles, was wir machen wollen, gibt es mindestens ein paar Optionen. Ob es ein Vorteil oder Nachteil ist, muss man selbst entscheiden. Es ist auch wichtig zu berücksichtigen, dass Angular-Styles standardmäßig modularisiert sind, d.h. die CSS Klassen sind nur den eigenen Komponenten zugewiesen. Damit müssen wir uns nicht selbst darum kümmern Kollisionen zu vermeiden. Bei React muss man dafür die css file `[name].module.css` nennen und importieren. 

 Wenn die Grundelemente stehen, können wir mit unseren ersten Komponente anfangen. Zuerst fügen wir ein Inputfeld hinzu, sowie einen Button und eine Box, in der wir die TODOs anzeigen lassen. In beiden Fällen wird eine separate Komponente für das Anzeigen der Liste zuständig. 

Das sind die Komponenten. Beiden nehmen eine Liste von Aufgaben als Inputparameter und benutzen sie, um die Informationen anzuzeigen. 

Links Angular Komponente, Rechts React Komponente mit ToDo Einträgen
Abbildung 2: Links Angular Komponente, Rechts React Komponente mit ToDo Einträgen 

Hier gibt es keine großen Unterschiede. Die Komponenten sehen sehr ähnlich aus. Jedoch muss man bemerken, dass wir die Form der React- Komponente geändert haben. Hier wurde eine stateless funktionale Komponente genutzt. Das erlaubt es uns, die ganze Komponente als Funktion zu schreiben. Damit kann man eine bessere Lesbarkeit erreichen, im Vergleich zur Klassenkomponenten. Ein neues Feature sind auch React Hooks, die vor kurzem eingeführt wurden. Diese bieten sogar größere Flexibilität, wenn es sich um Logik darin handelt. 

Auf der anderen Seite haben sich dazu unsere Grundkomponenten geändert. Wir mussten State-Management einführen, um die Liste von Todos zu speichern. Wir haben eine Methode hinzugefügt, die das Inputfeld steuert und eine, die für das Hinzufügen von neuen TODOs zuständig ist.  

Im React-Projekt ist der State in der Komponente selbst platziert. Ein Grund dafür ist, dass unser State sehr klein ist und damit keine separaten Steuerungs-Mechanismen hat. Im Angular-Projekt wollen wir dazu eine Dependency Injection von Angular benutzen.  Deswegen haben wir einen Service erstellt, der das State-Management übernimmt. So müssen wir uns selbst nicht darum kümmern, die Dependencies zu besorgen. Das erlaubt es uns, eine unabhängige Datenquelle zu haben, die wir während Tests leicht mocken können. 

Links Angular Komponente, Rechts Angular Service
Abbildung 3: Links Angular Komponente, Rechts Angular Service 

Daten aus externen Quellen abrufen 

Hier werden die Aufgabendaten asynchron geholt. Das wird sehr bequem sein, wenn man in der Zukunft die Daten beispielsweise aus Onlinequellen holen will. Dann muss man die Änderungen nur im Service machen und trotzdem wird alles ohne Probleme laufen. 

Jetzt werden wir uns damit beschäftigen, die Daten aus externen Servern zu holen. Das wird eine Komponente sein, die die populärsten Artikel in Reddit anzeigen wird. Dafür nutzen wir für Angular das HttpClient Modul, für React nutzen wir in diesem Fall Axios.  

Wenn es sich um Angular handelt, ist meist alles was wir brauchen, schon für uns verfügbar. Ein gutes Beispiel ist das HttpClient Modul, das uns erlaubt, externe Aufrufe zu machen. Bei React müssen/dürfen wir wählen, womit wir arbeiten wollen.  

Die fertigen Komponenten sehen so aus:  

Links Angular Komponente und Service, Rechts React Komponente
Abbildung 4: Links Angular Komponente und Service, Rechts React Komponente 

Bei Angular haben wir wieder einen Service erstellt, den wir injectieren lassen. Nun holen wir fertige, bearbeitete Daten ab. Bei React sieht es ein bisschen anders aus. Auf diesem Feld gibt es auch viele Meinungen, wie man das Data Fetching Problem richtig lösen sollte. Ich habe mich für React Hooks entschieden, weil man die Daten damit ganz sauber beschaffen kann. Die Funktion zum Holen der Daten konnten wir auch in ein separates Javascript Modul verschieben, um diese Logik von der Komponente zu trennen. 

Ein Fazit zu React vs. Angular

Am Ende sieht unsere kleine App so aus: 

Fertige App, geschrieben mit Angular und React

Das Projekt ist sehr einfach, aber wenn man die To-Do-App mit zwei unterschiedlichen Frameworks entwickelt, kann man schon einen ersten Überblick darüber bekommen, wo die Unterschiede zwischen den beiden Frameworks liegen. Man kann sagen, dass bei Angular alles schon vorhanden ist, bei React treffen wir die Entscheidung selbst. Wie gesagt, beides hat Vorteile (wir sind nicht eingeschränkt mit den Tools, die wir benutzen) und Nachteile (man kann sehr viel Zeit damit verbringen, das richtige Tool zu finden). 

Am Ende macht jedoch die Entscheidung, welches Tool wir wählen, keinen Unterschied. Allerdings sprechen wir hier von einer einfachen To-Do-App und nicht von großen Enterprise-Projekten. Wir können einfach nutzen, was uns besser gefällt. Beide vorgestellten Frameworks sind schon sehr gut entwickelt und haben jeweils eine sehr große Community.

Wir dürfen dabei nicht vergessen, dass gute Programmierer Konzepte und keine Tools lernen, weil es in ein paar Jahren wieder etwas Neues geben kann. Deswegen empfehle ich, mindestens ein Projekt mit beiden Frameworks zu schreiben, um einen objektiven Überblick über die Möglichkeiten beider Frameworks zu bekommen. 

Beitrag von Maciej Kawka

Zurück zur Übersicht