Angular, React und Vue - die Qual der Wahl

Ein Kommentar von Andreas Krings-Stern

Wer dieses Jahr ein Web-Projekt startet, hat die Qual der Wahl. Es existieren unzählige Möglichkeiten, das Frontend zu entwickeln. Klammert man PHP, ASP.NET und GWT aus und beschränkt sich nur auf JavaScript als Programmiersprache, ist die Auswahl an Technologien immer noch riesig. Wobei sich hier drei Technologien als beliebteste und bekannteste Möglichkeit herauskristallisiert haben: Angular, React und Vue.  

Ausgereift, stabil und ready for production 

Diese drei Technologien sind mittlerweile im Schnitt vier Jahre alt. Die älteste ist React, entwickelt von Facebook und veröffentlicht 2013. Die jüngste ist Angular, von Google entwickelt und 2016 veröffentlicht. Zählt man den Vorgänger AngularJS hinzu, dann wäre Angular(JS) mit einem Veröffentlichungsjahr von 2010 die älteste Technologie dieser Liste. Angular ist eine komplette Neuentwicklung und unterscheidet sich daher so stark von AngularJS, dass man diese beiden – trotz ähnlichen Namens - getrennt betrachten sollte. Vue.js, von Evan You entwickelt, wurde im Jahre 2014 veröffentlicht und rangiert daher zeitlich gesehen zwischen React und Angular. Alle drei Technologien sind mittlerweile sehr ausgereift, stabil, "battle-tested" und bereit, in der Produktion eingesetzt zu werden. Es kommt eigentlich "nur" noch auf die eigene Präferenz und Vorliebe an. 

Wenn man versuchen wollte, die drei Technologien über Zahlen zu vergleichen, könnte man zum Beispiel die Anzahl der Downloads hinzuziehen: 

Dabei weist Laurie Voss (ehemals Chief Data Manager bei NPM) in seinem Talk auf der JSConf EU: "JavaScript: Who, What, Where, Why and Next" darauf hin, dass alle Technologien in absoluten Zahlen wachsen. Angular fällt allerdings seit 2017 in seiner relativen Popularität, während Vue und React in der relativen Popularität weiterhin steigen. Mit dem Ergebnis, dass heutzutage ca. 3 Millionen Leute sowohl Angular, als auch Vue nutzen. Etwa die Hälfte aller JavaScript Entwickler geben dagegen auf NPM an, mit React zu arbeiten.  

Für ein Beliebtheits-Ranking könnte man auch versuchen, anhand der GitHub-Sterne die Popularität zu bemessen. Mit folgendem Ergebnis (am 22.07.2019): 

  • Vue 144.255 Sterne 
  • React 133.020 Sterne 
  • Angular 49.774Sterne 

Seit kurzer Zeit zeigt GitHub zusätzlich an, von wie vielen Repositories die Technologie benutzt wird, bzw. eine Abhängigkeit ist (am 22.07.2019): 

  • React 2.243.249 
  • Vue 946.909 
  • Angular (keine Angabe) 

Einen weiteren Anhaltspunkt zur Beliebtheit könnte eine Suche nach offenen Jobs (bei monster.de und stepstone.de) in Deutschland liefern. Hier sieht das Ergebnis folgendermaßen aus (am 22.07.2019): 

Oder man bezieht sich auf die letzte State Of Js-Umfrage

All diese Zahlen lassen sich recht einfach vergleichen und zeigen die hohe Popularität von React weltweit. Nimmt man die Job-Angebote hinzu, könnte man sagen, dass Angular in Deutschland ebenfalls sehr beliebt ist. Als weitere Anhaltspunkte ließen sich zum Beispiel auch die Anzahl an Tutorials oder Artikeln zu den Technologien heranziehen. Oder die zur Verfügung stehenden 3rd Party Libraries. Diese Zahlen lassen sich allerdings schwer vergleichen. Vor allem, wenn man zudem die Qualität dieser Artikel, Tutorials und 3rd Party Libraries berücksichtigen möchte, wird es schnell subjektiv. 

Auswahl Schritt für Schritt

Meine Empfehlung zur Auswahl-Methode lautet, sich zuerst kurz mit den Technologien auseinander zu setzen, um ein Gefühl für diese zu bekommen. Am besten, man schaut sich die Dokumentation an und versucht, die jeweiligen Tutorials durchzuarbeiten. Eventuell kann man auf diese Weise schon sehr schnell eine der Technologien aussortieren. Danach empfehle ich, sich noch einmal zu überlegen, was das Endprodukt sein soll. Ein zusätzlicher Schritt dabei könnte es sein, "Komponenten shoppen zugehen", um zu analysieren, welche 3rd Party Libraries zur Verfügung stehen, und ob man komplizierte Use Cases eventuell schon über diese abdecken kann, ohne selber Zeit in die Entwicklung dieser Komponenten stecken zu müssen. Ist man zum Beispiel auf kompliziertere Komponenten wie Pivot-Tabellen, Graphen, Scheduler oder anderes angewiesen, kann es passieren, dass es hierfür bei der ein oder anderen Technologie auf dem freien Markt keine 3rd-Party-Lösung gibt. 

Findet man auf dem freien Markt nicht die benötigte Komponente, empfehle ich, bei Anbietern wie Kendo, DevExtreme, PrimeFaces oder entsprechenden Alternativen vorbei zu schauen. Diese bieten eine große Auswahl an kostenpflichtigen Komponenten an. Die meisten dieser Anbieter stellen ihre Komponenten zudem in allen drei Technologien zur Verfügung. Allerdings sollte man sich hier auch noch einmal über die Art der Integration informieren. Stellen die Anbieter die Komponenten in nativer Form oder nur als Wrapper zur Verfügung? In den meisten Fällen ist die native Form der Wrapper-Form vorzuziehen. 

Bevor ich mich nachfolgend im Detail mit den einzelnen Technologien befasse, sei erwähnt, dass ich mich als Entwickler bei tangro und wir uns im Entwickler-Team für React entschieden haben. In meinem täglichen Gebrauch komme ich daher nur mit React in Berührung und habe folglich auch nur in dieser Technologie echte Hand On Experience erlangt. Allerdings versuche ich - so gut es geht - die Fortentwicklung der beiden anderen Technologien zu verfolgen. Und ich bin der Meinung, dass man keine falsche Entscheidung trifft, wenn man sich nicht für React, sondern für eine andere Technologie entscheidet. 

Angular - klare Strukturen 

Aus meiner Sicht könnte Angular die richtige Wahl für Entwickler sein, die aus der .NET- oder JEE- Ecke kommen. Die Entwicklung mit Angular ist primär objektorientiert, getrieben von Decorators, komplett in TypeScript und bietet neben Dependency Injection auch eine sehr klare Struktur und Linie, wie Komponenten und die gesamte Anwendung aufgebaut und entwickelt werden sollen. Angular liefert bereits von Haus aus sehr viele Utilities und Komponenten mit. Etwa einen Router oder Wrapper für HTTP-Aufrufe. Ersterer ist zum Beispiel bei React erst über 3rd-Party-Bibliotheken erhältlich. Die wohldefinierte Struktur und der dadurch entstehende rote Faden bei der Entwicklung von Angular-Anwendungen kann vor allem bei größeren Teams sehr hilfreich sein. Umgekehrt kann er aber auch zu einer großen Menge an Boilerplate und Inflexibilität führen. 

Ich persönlich fühle mich durch die starren Strukturen zu sehr eingeschränkt und schätze die Flexibilität der beiden anderen Technologien. Des Weiteren missfällt mir der Boilerplate und die Notwendigkeit zu Decorators. Dadurch ist Angular mir zu weit entfernt von “normalem” JavaScript bzw. TypeScript. Außerdem wird Angular nachgesagt, kompliziert zu sein und eine sehr steile Lernkurve zu haben. Ein positiver Aspekt an der Technologie ist für mich jedoch, dass diese nativ auf TypeScript aufsetzt. Dies ist allerdings kein Alleinstellungsmerkmal mehr: Vue.js in Version 2 wurde ebenfalls nativ in TypeScript entwickelt, und auch React verfügt mittlerweile über einen sehr guten TypeScript-Support. Wobei generell die TypeScript-Eigenschaft für Entwickler, die "nur" JavaScript einsetzen wollten, durchaus auch ein Hindernis darstellen könnte. Manchmal vermisse ich bei React die Vielfalt an dem, was Out-Of-The-Box zur Verfügung steht und die erstklassige Angular CLI (Command Line Interface). Auch das Handling von Formularen scheint in Angular sehr gut und komfortabel zu funktionieren - ein Punkt, den ich bei React zum Beispiel ohne 3rd Party Libraries für kompliziert und nervig halte.  

Vue - einfach zu erlernen 

Meiner Meinung nach ordnet sich Vue zwischen Angular und React ein. In seinem Ansatz erinnert Vue stark an AngularJS: Komponenten werden (nach best practice) in einer einzelnen Datei entwickelt, in der sowohl der HTML-Code (getrennt in einem <template>), das Styling (in einem <style>) und der JavaScript-Code (in einem <script>) stehen. Dabei müssen verschiedene Meta-Informationen - wie bei Angular und AngularJS - in der Komponente veröffentlicht werden. Der dazu nötige Code-Aufwand (Boilerplate) ist hier geringer als bei Angular, aber höher als bei React. Ähnlich wie bei Angular werden Router und weitere nützliche Komponenten/Funktionen direkt mitgeliefert. 

Meine Kritikpunkte an Vue sind unter anderem die Template-Sprachen (die Directives), wie sie auch bei Angular existieren. Des Weiteren fehlt mir auch hier die Flexibilität von React. Komponenten lassen sich meiner Meinung nach in React noch schneller entwickeln als in Vue. Vielleicht erinnert mich Vue aber auch einfach zu sehr an AngularJS. Ein echter Nachteil von Vue ist aber die Tatsache, dass verschiedene 3rd Party Bibliotheken hauptsächlich in chinesischer Sprache zur Verfügung stehen, da Vue seine große Beliebtheit vor allem in China erfährt. 

Sehr gut gefällt mir an Vue dagegen, dass template, style und script in derselben Datei geschrieben werden. Die sehr starke CLI und ein gutes Tooling führen dazu, dass der Einstieg in Vue recht schnell erfolgen kann. Vue wird daher nachgesagt, dass es einfach zu erlernen sei. 

React - primär JavaScript 

React ist meiner Meinung nach sehr gut für Entwickler geeignet, die primär mit JavaScript arbeiten. Anders als in den anderen Technologien ist fast alles, was man benutzt, "nur" JavaScript. So können Komponenten zwar über Klassen erstellt werden, aber besser ist es, dies über kompakte Funktionen zu realisieren. Der HTML-Code der Komponenten wird dabei direkt in der Funktion/Klasse in Form von JSX geschrieben und benötigt keine extra HTML-Datei (wie bei Angular). JSX ist sehr nah an HTML gehalten und anders als bei den anderen beiden Technologien wird keine spezielle Syntax für eine Template-Sprache benötigt. Zum Beispiel nutzt man für Loops Array.map anstatt der Direktiven [ng-for] oder v-for. 

Allerdings ist JSX leider nicht einfach "nur" HTML mit JavaScript. Für JSX gibt es hier eine Handvoll Einschränkungen. Um diese besser nachvollziehen zu können, macht es Sinn, sich mit dem Thema React.createElement zu beschäftigen (nachdem man sich mit den Basics sicher fühlt), da es sich hier bei JSX im Grunde genommen um eine Abstraktionssicht über den Aufruf React.createElement handelt. Damit lassen sich dann auch die Einschränkungen von JSX nachvollziehen: So sind zum Beispiel keine komplizierteren Bedingungs-Strukturen möglich, mit Ausnahme von ternary-Strukturen. Außerdem erklärt das auch, wieso man keine reservierten Schlüsselwörter wie zum Beispiel class (stattdessen className) oder for beim label (stattdessen htmlFor) nutzen kann. 

Beim Durchlesen von Kritiken an React habe ich das Gefühl, dass den meisten Leuten, denen React nicht gefällt, JSX nicht gefällt. Ich behaupte, dass die Wenigsten, die diese Kritikpunkte äußern, sich mit React.createElement auseinandergesetzt haben. Allerdings zeigt dies auch, wie sehr es letztendlich auf die persönliche Vorliebe ankommt. So wie mir die Template-Syntaxen von Angular und Vue nicht so gut gefallen und ich JSX bevorzuge, mögen anderen Entwickler die JSX-Syntax nicht.  

React - hohe Flexibilität 

Unabhängig von der Syntax gefällt mir an React aber auch die Flexibilität und die Geschwindigkeit, in der man einzelne Komponenten entwickeln kann. Wiederverwendbare Komponenten auszulagern ist ähnlich einfach, wie eine Funktion aus seinem Code herauszuziehen. Auch dadurch, dass dieser Schritt so einfach und unkompliziert ist, wird man quasi animiert, wiederverwendbare Komponenten zu erstellen. Dieser Prozess wird weiter dadurch verstärkt, dass Komponenten in React nur Funktionen sind. 

Auch die Auswahl an zur Verfügung stehenden 3rd-Party-Komponenten ist durch die hohe Popularität von React größer, als bei den anderen beiden Technologien. Zu fast allen Themen findet man mindestens eine 3rd-Party-Komponente, meistens sogar mehrere. Hinweis: Bei der Auswahl der korrekten 3rd-Part-Komponente sollte man allerdings ähnlich gründlich vorgehen wie bei der Auswahl der richtigen Technologie.  

In punkto Lernkurve ordnet sich React meiner Meinung nach zwischen Angular und Vue ein. Der Einstieg in React ist, finde ich, zwar recht einfach, aber komplexere Themen können durch die große Auswahl an Möglichkeiten oder durch zuerst nicht offensichtlich scheinende Lösungswege komplizierter werden. Um React komfortabel lernen und einsetzen zu können, sollte man allerdings ein gutes Wissen über moderne JavaScript Entwicklung haben. Wichtige Features, die die React Entwicklung einfacher gestalten, wurden mit EcmaScript 2015 eingeführt.  

Was den Einstieg in die Sprachen anbetrifft, ist Vue meiner Meinung nach einfacher, wenn man kein solides JavaScript Grundwissen hat. Bei Vue reicht ein Verständnis der Vue-spezifischen Syntax und ein Grundverständnis in JavaScript. Angular gestaltet sich am Kompliziertesten, da man neben einem guten Verständnis von JavaScript noch TypeScript und Angular spezifisches Wissen benötigt. 

Was mir an React am meisten gefällt, ist die Einfachheit, mit der man die Abstraktionsschichten verwalten kann: Sowohl "simple" Felder zur Texteingabe, als auch komplexere Eingabefelder mit vielen Features können als Komponenten umgesetzt werden. Dabei lässt sich die Komplexität der Feature-reichen Felder gut hinter einer Abstraktionsschicht verstecken, sodass der Benutzer einer Komponente (in diesem Fall ein Entwickler) von der eigentlichen Komplexität nicht betroffen ist. 

React weist jedoch auch Nachteile auf: Meiner Meinung nach wurde React erst durch die Einführung von create-react-app Mainstream-tauglich. Vorher musste man erst noch Webpack und dessen Konfiguration verstehen, bevor man dann React anwenden konnte. Hat man andere Anforderungen an sein Projekt, als die durch create-react-app abgedeckt werden können, ist man gezwungen, sich mit all dem, was create-react-app einem abnimmt, näher auseinander zu setzen. Randnotiz: create-react-app ist mittlerweile so ausgereift, dass es schon lange nicht mehr vorgekommen ist, dass wir eine eigene Webpack Konfiguration benötigt haben.  

Ein weiterer Kritikpunkt an React ist meiner Meinung nach die übergroße Menge an Möglichkeiten. Beim Schreiben dieses Artikels bin ich auf einen Tweet gestoßen, der es passender nicht ausdrücken könnte: 

"React’s refusal to have an opinion on things like styling and routing are the biggest source of frustration for users and also its biggest reason for success. There isnt 1 framework called React, there are 1000s of artisanally handrolled fw’s. React gets credit for ALL of them." Shawn Wang auf twitter 

Die große Auswahl ist Vorteil und Nachteil zugleich. So ist es durchaus von Vorteil, dass beim Einsatz einer 3rd Party Library immer noch weitere Alternativen zur Verfügung stehen, die man ebenfalls ausprobieren kann. Die Behandlung von komplexeren Formularen ist für mich beispielsweise ein größerer Pain Point von React, der erst durch den Einsatz von 3rd Party Libraries ertragbar wurde.  

Gleichzeitig steht man jedoch durch die Vielzahl an Möglichkeiten immer vor der Qual der Wahl. React deckt in erster Linie (vereinfacht gesprochen) das Rendern des View Layers ab. Für vieles Weitere bietet React APIs und Möglichkeiten, die aber selten ohne den Einsatz von 3rd-Part-Bibliotheken oder eigene Abstraktionsschichten auskommen. Wenn es zum Beispiel darum geht, den Zustand (state) zu verwalten, bietet React hierfür von Haus aus mehrere Möglichkeiten. Ist die Anwendung klein, kommt man damit auch gut aus. Wächst die Anwendung, entwickelt man entweder seine eigene Abstraktionsschicht, oder man wählt eine der vielen 3rd Party Libraries. Hier die richtige Wahl zu treffen ist allerdings nicht einfach.* 

React im Use Case 

Meiner Meinung nach sollte man in Artikeln oder Diskussionen, die Technologien vergleichen, immer darauf achten, für welchen Use Case der Autor die Technologie eingesetzt hat. Leider wird diese Information bei den wenigsten Diskussionen mitgeliefert. 

Unsere Anforderungen an die Technologie waren recht simpel: Die Anwendung besteht hauptsächlich aus einem Router vieler Formular-Komponenten, (komplexen) Tabellen und Listen. Diese Anforderungen hätten von allen drei Technologien abgedeckt werden können. Wichtig für uns war daher vor allem die Developer Experience (DX). Für uns war diese mit React am meisten gegeben. Bei dem Einsatz konzentrieren wir uns darauf, wiederwendbare Komponenten zu erschaffen und diese in einer Komponenten-Bibliothek zu sammeln. Als kleines Team (3 Entwickler, die zum Teil an unterschiedlichen Projekten arbeiten) haben wir nicht die Ressourcen, viel Zeit für die Entwicklung eigener Komponenten zu investieren. Aber dank der großen Auswahl an 3rd Party Libraries können wir uns für fast jeden Use Case für eine bereits zur Verfügung stehende Lösung entscheiden und müssen diese lediglich an unseren exakten Use Case anpassen. 

*Wenn Sie mehr zur Entscheidungsfindung bei 3rd Party Libraries erfahren möchten, schauen Sie in der nächsten Zeit noch einmal vorbei. Demnächst veröffentlichen wir eine Artikelreihe zu dem Thema 3rd Party Libraries für React. 

Zum Seitenanfang