Netzgeflüster: JS-Frameworks im Vergleich (Vue, React, Angular)

Ich mag Web-Development. Wie es aber der Zufall so will, war ich zuletzt auf Arbeit hauptsächlich in Backend-Aufgaben involviert oder Projekte, die gar keinen Gebrauch von Web-Frontends machen. Umso mehr hat es mich gefreut, als ich neulich die Gelegenheit bekam für Kunden eine Gegenüberstellung dreier Web-Frontends zu machen. Dabei handelt es sich um die großen Drei Javascript-Frameworks VueJS, Angular und ReactJS. Da ich bis dato nur mit Angular gearbeitet habe, war das für mich umso spannender und erschien mir teilenswert.

Bestandsaufnahme

Tatsächlich sind also meine Web-Zeiten schon etwas her. Klar, es gibt die Blogs, die Wartung benötigen und hier und da kleinere Spielereien. Aber bei den JS-Frameworks war ich nicht mehr unbedingt fit. Die letzte Angular-Version mit der ich exzessiver gearbeitet habe, war Angular 2. Dazu gesellt sich der übliche Stack an Web-Frontend-Themen, die man vernachlässigen kann (CSS, HTML, Javascript – plain vanilla, jQuery zu früheren Zeiten, etc). Ziel dieser Gegenüberstellung ist nun nicht den Code bereitzustellen oder die blanken Spezifikationen der Frameworks – es gibt schon genug Webseiten, die das tun (siehe hierzu Links am Ende des Beitrags), sondern die Ergebnisse und Erkenntnisse zu präsentieren. Und wo fängt man da an? Am besten am Anfang.

Vorgehen, oder: CLI sind dein Freund

Aufgabe war ja die Gegenüberstellung der Frameworks. Specs lesen können wir alle, aber was bedeuten die schnöden Fakten? So war relativ schnell klar, dass kes nützlich sein könnte einen Eindruck der Frameworks vom Doing und Handling her zu bekommen. Und Demo-Anwendungen zu bauen! Als Tools of Choice sollte die jeweilige CLI benutzt werden. Also die Command Line Interfaces der jeweiligen Frameworks, die ja inzwischen flächendeckend von Paketmanagern unterstützt werden. Mit der CLI kann man sehr angenehm Projekte anlegen und Abhängigkeiten hinzufügen, sowie die Apps kompilieren und in einer Demo-Umgebung zum Laufen bringen. Neben den jeweiligen CLIs nutzte ich dann auch Material-Design, um bei allen Demo-Apps ein ähnliches Look-and-Feel zu erzeugen und nicht das (optische) Rad neu erfinden zu müssen. Material-Design ist „[…] a design system created by Google to help teams build high-quality digital experiences for Android, iOS, Flutter, and the web.“ Also im Grunde sowas wie Bootstrap und Primefaces mit dem von Google her bekannten Look and Feel. Material Design beinhaltet Icons genauso wie UI-Komponenten und -Widgets.

Der Vorteil der Verwendung von Material-Design neben der (zumindest erhofften Einheitlichkeit): man lernt nebenbei einige Besonderheiten der jeweiligen Frameworks kennen in punkto Ressourcen managen. Bei den Frameworks entschied ich mich für die jeweils aktuellste, stabile, veröffentlichte Version, für die es unterstützte Material-Design-Libs gibt. Das waren Stand Ende letzten Jahres Angular v10, React v17 und Vue v2. (Ich verzichte im Folgenden auf die Bezeichnungen VueJs, ReactJS, etc.) Wie sich während des MOCKens, POCens und Ausprobierens herausgestellt hat, ist ein Custom-CSS trotzdem notwendig (zumindest für meinen Geschmack) und auch spannend, um zu sehen wie flexibel die Frameworks und Material-Design-Libs damit arbeiten. So findet in allen Beispielen ein kleines Custom-CSS Verwendung und auch, klar, Mockdaten ziemlich simpler Natur. Was sollte die Demo beinhalten? Im Grunde immer dasselbe: einen Abriss einiger populärer UI-Elemente (hier kommt Material-Design ins Spiel) und eine Datentabelle. Erstellt habe ich die Demo-Apps meist nach/während des Anschauens von ein bis zwei Online-Tutorials bzw. Youtube-Videos à la „Create Your First VueJS Material Design App“ etc.

Vue & Vuetify

Vue gilt als eine Art Shootingstar unter den JS-Frameworks, was sicherlich daran liegt, dass es verhältnismäßig leichtgewichtig und einfach zu erlernen ist, was sich auch bestätigt hat. Die Vue-App stand am schnellsten. Vue hat keine Firma im Hintergrund (wir erinnern uns: React ist das Baby von Facebook und Angular das von Google). Ob das nun gut oder schlecht ist, darüber lässt sich streiten. Womit es sich einen gewissen Nerd-Bonus verdient ist, dass die Releases nach populären Anime benannt sind. 🙂 Die Syntax von Vue ist intuitiv bedienbar, aber erfordert zumindest etwas Gewöhnung. Sie ist HTML-basiert und sieht etwas fragmentarisch und rudimentär aus. Schon gewöhnungsbedürftiger ist, dass man CSS bzw. Styling auf mindestens drei verschiedene Weisen unterbringen kann. Das populärste Material-Design-Package für Vue ist offenbar Vuetify. Die Community mag noch nicht riesengroß sein, aber Vuetify ist definitiv die am simpelsten und wohlsortiert dokumentierte aller Material-Design-Frameworks. So entstand die Vue-App ohne Vorkenntnisse in weniger Zeit als alle anderen und hatte sogar bereits einen Router um zwischen mehreren Seiten zu wechseln … einfach weil ich gerade einen Lauf hatte. (Das Routing-Menü habe ich in den anderen Apps aus Zeitgründen nicht verbaut.)

React & Material UI

Was mir bei React am stärksten aufgefallen ist und mich sehr erstaunt hat: die so wie ich es kenne einst langläufige Meinung man müsse Markup, Funktion und Styling trennen, ist offenbar längst nicht mehr so. Und das finde ich schade. Wann gab es diesen Paradigmenwechsel? Gerade bei React wird das doch ziemlich gewürfelt. Vielleicht ist es auch eine Frage der Freiheitsgrade. Wo viel geht, kann man viel auf unterschiedliche Weise machen. Und Getting-Started-Tutorials vermitteln nicht unbedingt guten Stil. Bei React fiel mir auf wie schnell man gut wiederverwendbare Komponenten bauen kann und dass offenbar im React-Core bereits ein Mini-Testframework enthalten ist. Ähnlich wie Vue kommt React mit einer eigenen „Sprache“ daher: JSX ist aber relativ erlernbar.

Der Nachteil: React ist sehr verbose, d.h. langatmig und wortreich. Hier ist in der kürzesten Zeit der meiste Code entstanden. Und wie ich finde der unübersichtlichste. Shame on me oder feature? Nach dem was ich so lese feature. React selber ist von der Kernkomponente her eher rudimentär und eher weniger ein vollständiges Framework. Daher kracht es auch nicht in der Verbindung mit anderen JS-Frameworks und kann gar mit jQuery kombiniert werden. Im Umkehrschluss braucht man für einige Aufgaben extra Libs und Pakete. Für Data & State Flow empfiehlt sich als Best Practice offenbar Redux – auf den ersten Blick wirkt das für mich allerdings unnötig kompliziert. Hier bin ich besonders gespannt auf eure Erfahrungen in den Kommentaren. Immer gern her damit.

Angular & Angular-Material

Das war überraschend. Oder auch nicht! Obwohl ich Angular-Vorkenntnisse habe, brauchte ich für die Angular-App doppelt solange wie für React und etwas mehr als doppelt so lang als für die Vue-App. Der Hauptgrund ist derselbe wie schon immer: Versionsunterschiede und keine Abwärtskompatibilität. Was ich in Anleitung A gelernt habe, war für eine neuere Version; der gefundene Fix für eine ältere, blablabla. Derselbe Krampf wie schon damals beim Wechsel von AngularJS zu Angular2+ erschwert offenbar immer noch den Umgang mit dem ansonsten sehr coolen Framework. V.A. das reibungslose Databinding habe ich immer sehr genossen, so auch hier. Aus sprach-designtechnischen Aspekten hat Angular in der jüngeren Vergangenheit viele Kritiker geweckt, u.a. wegen der vielen Konfiguration (in Hinblick auf die Angabe und Benamung „offensichtlicher“ Details wie templates, provider etc). Ansonsten hat Angular eine angenehm große Community und man findet viel Support und Hilfestellungen bei Problemen. Ich erinnere gern an Seiten wie die RxJSMarbles – auch wenn ich sie für meine Minimalapp nicht gebraucht habe. Trotzdem leider ein K(r)ampf.

Das Ergebnis

Man hört es schon raus, dass für eine kleine Anwendung Vue den besten Eindruck bei mir hinterlassen hat. Sowohl von der Syntax her als auch von Erlernbarkeit. Der Zeitfaktor kann irreführend sein. Sicher, es hat am wenigsten lange gedauert die Vue-App zu schreiben. Kaum signifikant länger die React-App. Trotz Vorkenntnissen in AngularJS und Angular2 hat es doppelt so lange gedauert die Angular-Demo zu schreiben. Also Vue als Testsieger? Das ist ja schön für eine kleine App, aber wenn man skaliert? Wie ist dann die Arbeit mit Vue? Trotzdem kann ich mich gegen den Ersteindruck nicht wehren. React war mir persönlich zu verbose und dass das Arbeiten mit Angular so ein Krampf ist, erscheint mir für Kolleg*innen, die das eventuell noch gar nicht kennen sogar wie eine noch größere Einstiegshürde. Hat Angular Entwickler durch Modernisierung abgehängt? Oder wäre das auch für mich alles halb so wild, wenn ich nicht sechs Versionen plus übersprungen, sondern stetig mit Angular gearbeitet hätte?

Was mich verwundert hat: trotz Material-Design habe ich nicht den vollkommen gleichen Look, aber immerhin dasselbe Feel. Zur Erklärung: alle Material Design Libs bieten verschiedene Standard-Templates an. In allen Fällen habe ich mich für „irgendwas mit dunkel und rot“ entschieden. Alle Apps haben eine unterschiedliche Responsiveness wie man unschwer an der Tabelle erkennt – siehe Screenshot unten. Das liegt wahrscheinlich daran, dass nicht jedes Framework/nicht jede Material Design Lib von Haus aus ein Datentabelle anbietet und ich experimentieren musste. Was ich natürlich auch zugeben muss: ich habe mich eben mit dem Ergebnis zufrieden gegeben. Analyse kann man so exzessiv betreiben wie man möchte. Für Kennzahlen und Fakten habe ich unten in die Linkliste ein paar Quellen gepackt. Mein „gefühltes Fazit“ hier sagt, wenn ich mir heute was aussuchen könnte, wäre es Vue. Womit arbeitet ihr?

Zum weiterlesen

Framework-Vergleich auf slant.co
Vergleich auf entwickler.de
Vergleich auf academind

Kamt ihr auch schon mal in die Verlegenheit zwischen mehreren Alternativen zu wählen oder zumindest einen Vorschlag abzugeben? Was war euer Ansatz? Wie habt ihr euch der Entscheidungsfindung genähert? Und welches Framework ist eure Weapon of Choice?

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen aus IT, Forschung, Netzwelt und Internet widme genauso wie Spaß rund um die Arbeit mit Bits und Bytes. 🙂

4 Antworten

  1. Avatar von voidpointer
    voidpointer

    Bei der Technologiewahl ist denke ich immer auch der Kenntnisstand des Entwickler-Teams ein wichtiger Punkt, was natürlich nicht heißen soll, dass man an ineffizienten Technologien festhalten sollte. Am besten man hat schon einen Entwickler der die Technologie schon lange verwendet, was natürlich nicht immer der Fall ist. Sollte die Technologie auch von anderen genutzt werden, kann es sinnvoll sein die mit einzubeziehen.
    Was UI angeht, denke ich das eine strikte Trennung von Deklaration und Code das Ziel sein muss, so dass ein Designer möglichst leicht am UI arbeiten kann.

    Generell bin ich ein großer Fan von statisch typisierten, kompilierten Sprachen was ein wenig meine Euphorie für Java-Script Frameworks bremst. Auch bin ich kaum im Web-Umfeld unterwegs gewesen, so dass ich da nur sehr wenig sagen kann. Ohne TypeScript würde ich es glaube ich auf lange Sicht nicht nutzen wollen. 😉 Tooling ist sicherlich generell ein wichtiger Punkt, ebenso wie ein stabiles, konsistentes Software-Ökosystem.

    1. Avatar von Miss Booleana
      Miss Booleana

      Ja auf jeden Fall spielen die Kenntnisse innerhalb des Teams eine Rolle – da hast du Recht. Das habe ich auch betrachtet, aber hier vergessen zu erwähnen. Vermutlich, weil ich zumindest die Kenntnisstände des Teams hier nicht veröffentlichen möchte. Aber so oder so ist das sehr hilfreich, wenn man jemanden in der Runde sitzen hat, der das schon kennt und über idealerweise mehr als die Grundlagen beherrscht.

      Tatsächlich bin ich auch kein besonders großer Fan von Javascript oder plain vanilla javascript. Typescript ist von daher ein Bonus.

  2. […] Hausaufgabe hatten wir zu HTML, CSS und Javascript. Über Angular, geschweigedenn React und andere Frontends hat damals noch keiner geredet. Aber ich war neugierig und habe das einerseits als Übung […]

  3. […] für Nicht-ITler? Habe ich jetzt Lust über die Arbeit zu schreiben?“), aber der Beitrag JS-Frameworks im Vergleich (Vue, React, Angular) war für mich im Vorfeld spannend und gibt wieder was man als Softwareentwicklerin halt so tut. Die […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert