Ein realistischer Vergleich von Front-End-Frameworks mit Benchmarks (Update 2018)

UPDATE: Es gibt eine neuere Version dieses Artikels

Dieser Artikel ist eine Aktualisierung eines realen Vergleichs von Front-End-Frameworks mit Benchmarks vom Dezember 2017.

In diesem Vergleich zeigen wir, wie unterschiedliche Implementierungen nahezu identischer RealWorld-Beispiel-Apps gegeneinander antreten.

Die RealWorld-Beispiel-App gibt uns:

  1. Real World App - Etwas mehr als eine „Aufgabe“. Normalerweise vermitteln „Aufgaben“ nicht genug Wissen und Perspektive, um echte Anwendungen zu erstellen.
  2. Standardisiert - Ein Projekt, das bestimmten Regeln entspricht. Bietet eine Back-End-API, statische Markups, Stile und Spezifikationen.
  3. Geschrieben oder überprüft von einem Experten - Ein konsistentes, reales Projekt, das im Idealfall von einem Experten für diese Technologie erstellt oder überprüft worden wäre.

Kritik aus der letzten Version (Dez 2017)

️ Angular war nicht in Produktion. Die auf dem RealWorld-Repo aufgelistete Demo-App verwendete eine Entwicklungsversion. Dank Jonathan Faircloth ist sie jetzt in der Produktionsversion!

Vue war nicht im Real World Repo gelistet und somit nicht enthalten. Wie Sie sich vorstellen können, verursachte dies in der Front-End-Welt eine Menge Hitze. Wieso hast du Vue nicht hinzugefügt? Was zum Teufel ist mit dir los? Diesmal ist Vue.js dabei! Vielen Dank, dass Sie Emmanuel Vilsbol.

Welche Bibliotheken / Frameworks vergleichen wir?

Wie im Artikel vom Dezember 2017 haben wir alle Implementierungen aufgenommen, die im RealWorld-Repo aufgeführt sind. Es spielt keine Rolle, ob es eine große Anhängerschaft hat oder nicht. Die einzige Qualifikation ist, dass es auf der RealWorld-Reposeite erscheint.

Frontends unter https://github.com/gothinkster/realworld (April 2018)

Welche Metriken betrachten wir?

  1. Leistung: Wie lange dauert es, bis diese App Inhalte anzeigt und verwendbar ist?
  2. Größe: Wie groß ist die App? Wir werden nur die Größe der kompilierten JavaScript-Datei (en) vergleichen. Das CSS ist allen Varianten gemeinsam und wird von einem CDN (Content Delivery Network) heruntergeladen. Das HTML ist auch allen Varianten gemeinsam. Alle Technologien werden mit JavaScript kompiliert oder transpiliert, daher wird nur die Größe dieser Datei (en) festgelegt.
  3. Codezeilen: Wie viele Codezeilen benötigte der Autor, um die RealWorld-App basierend auf den Spezifikationen zu erstellen? Um fair zu sein, einige Apps haben ein bisschen mehr Schnickschnack, aber es sollte keine signifikanten Auswirkungen haben. Der einzige Ordner, den wir quantifizieren, ist src / in jeder App.

Metrik 1: Leistung

Schauen Sie sich den ersten aussagekräftigen Farbtest mit Lighthouse Audit an, der mit Chrome geliefert wird.

Je früher Sie malen, desto besser ist die Erfahrung für die Person, die die App verwendet. Lighthouse misst auch First Interactive, dies war jedoch für die meisten Apps nahezu identisch und befindet sich in der Beta-Phase.

Erster aussagekräftiger Anstrich (ms) - niedriger ist besser

Sie werden wahrscheinlich keinen großen Unterschied in Bezug auf die Leistung feststellen.

Metrik 2: Größe

Die Übertragungsgröße befindet sich auf der Registerkarte "Chrome-Netzwerk". GZIPed-Antwortheader sowie der vom Server bereitgestellte Antworttext.

Je kleiner die Datei ist, desto schneller ist der Download (und desto weniger muss analysiert werden).

Dies hängt von der Größe Ihres Frameworks sowie von zusätzlichen Abhängigkeiten ab, die Sie hinzugefügt haben, und davon, wie gut Ihr Build-Tool ein kleines Bundle erstellen kann.

Übertragungsgröße (KB) - weniger ist besser

Sie können sehen, dass Svelte, Dojo 2 und AppRun einen ziemlich guten Job machen. Ich kann nicht genug über Elm sagen - vor allem, wenn Sie sich die nächste Tabelle ansehen. Ich würde gerne sehen, wie Hyperapp sich vergleicht ... vielleicht nächstes Mal, Jorge Bucaran?

Metrik 3: Codezeilen

Mit cloc zählen wir die Codezeilen im src-Ordner jedes Repos. Leer- und Kommentarzeilen sind nicht Bestandteil dieser Berechnung. Warum ist dies sinnvoll?

Wenn das Debuggen das Entfernen von Softwarefehlern ist, muss das Programmieren das Einfügen dieser Fehler sein - Edsger Dijkstra
# Codezeilen - weniger ist besser

Je weniger Codezeilen Sie haben, desto geringer ist die Wahrscheinlichkeit, einen Fehler zu finden. Sie müssen auch eine kleinere Codebasis pflegen.

Abschließend

Ich möchte Eric Simons für die Erstellung des RealWorld Example Apps-Repos und zahlreichen Mitwirkenden, die verschiedene Implementierungen geschrieben haben, ein großes Dankeschön aussprechen.

Update: Dank an Jonathan Faircloth für die Bereitstellung der Produktionsversion von Angular.

Und wenn Sie diesen Artikel interessant fanden, sollten Sie mir auf Twitter und Medium folgen.