Framework-Vergleich
Wenn Sie diese Seite lesen, haben Sie wahrscheinlich bereits Erfahrungen mit anderen Frameworks zur Erstellung von Anwendungen gesammelt und möchten wissen, ob Mithril.js Ihnen helfen könnte, Ihre Herausforderungen besser zu meistern.
Warum nicht [hier Ihr Lieblingsframework einfügen]?
Die meisten modernen Frameworks sind schnell und gut geeignet, um komplexe Anwendungen zu erstellen und wartungsfreundlich zu gestalten, vorausgesetzt, man weiß, wie man sie effektiv einsetzt. Es gibt zahlreiche Beispiele für hochkomplexe Anwendungen, die mit nahezu jedem gängigen Framework realisiert wurden: Udemy verwendet Angular, AirBnB verwendet React, Gitlab verwendet Vue, Guild Wars 2 verwendet Mithril.js (sogar innerhalb des Spiels!). Dies sind alles Frameworks, die sich in der Produktion bewährt haben.
Als Faustregel gilt: Wenn Ihr Team bereits stark in ein anderes Framework/eine andere Bibliothek/einen anderen Stack investiert hat, ist es in der Regel sinnvoller, dabei zu bleiben, es sei denn, es gibt einen überzeugenden Grund für eine kostspielige Neuentwicklung.
Wenn Sie jedoch ein neues Projekt starten, sollten Sie Mithril.js in Betracht ziehen, allein schon um zu sehen, welchen Mehrwert Anwender aus weniger als 10 KB (gezipptem) Code ziehen können. Mithril.js wird von vielen namhaften Unternehmen (z. B. Vimeo, Nike, Fitbit) eingesetzt und betreibt auch große Open-Source-Plattformen (z. B. Lichess, Flarum).
Warum Mithril.js verwenden?
Kurz gesagt: weil Mithril.js pragmatisch ist. Die 10-Minuten-Anleitung ist ein gutes Beispiel: In dieser Zeit können Sie Komponenten, XHR und Routing erlernen – und das ist genau das Wissen, das Sie benötigen, um nützliche Anwendungen zu erstellen.
Mithril.js konzentriert sich darauf, effizient sinnvolle Arbeit zu leisten. Datei-Uploads? Die Dokumentation zeigt Ihnen, wie es geht. Authentifizierung? Ebenfalls dokumentiert. Exit-Animationen? Vorhanden. Keine zusätzlichen Bibliotheken, kein Hokuspokus.
Vergleiche
React
React ist eine View-Bibliothek, die von Facebook gepflegt wird.
React und Mithril.js haben viele Gemeinsamkeiten. Wenn Sie bereits mit React vertraut sind, wissen Sie bereits fast alles, was Sie zum Erstellen von Anwendungen mit Mithril benötigen.
- Beide verwenden Virtual DOM, Lifecycle-Methoden und Key-basierten Abgleich.
- Beide organisieren Views über Komponenten.
- Beide verwenden JavaScript als Flow-Control-Mechanismus innerhalb von Views.
Der offensichtlichste Unterschied zwischen React und Mithril.js liegt in ihrem Umfang. React ist eine View-Bibliothek, daher ist eine typische React-basierte Anwendung auf Bibliotheken von Drittanbietern für Routing, XHR und State Management angewiesen. Dieser bibliotheksbasierte Ansatz ermöglicht es Entwicklern, ihren Stack genau an ihre Bedürfnisse anzupassen. Andererseits bedeutet dies, dass React-basierte Architekturen stark von Projekt zu Projekt abweichen können und dadurch eher die 1-MB-Grenze überschreiten.
Mithril.js verfügt über integrierte Module für gängige Anforderungen wie Routing und XHR, und die Anleitung demonstriert die idiomatische Verwendung. Dieser Ansatz ist für Teams von Vorteil, die Wert auf Konsistenz und einfaches Onboarding legen.
Performance
Sowohl React als auch Mithril.js legen großen Wert auf die Darstellungs-Performance, gehen aber unterschiedlich vor. In der Vergangenheit hatte React zwei DOM-Rendering-Implementierungen (eine mit der DOM-API und eine mit innerHTML
). Die kommende Fiber-Architektur führt die Planung und Priorisierung von Arbeitseinheiten ein. React verfügt außerdem über ein ausgereiftes Build-System, das verschiedene Prüfungen und Fehlermeldungen für Produktionsbereitstellungen deaktiviert, sowie über verschiedene browserspezifische Optimierungen. Darüber hinaus gibt es auch mehrere leistungsorientierte Bibliotheken, die den shouldComponentUpdate
-Hook von React und die schnellen Eigenschaften zur Überprüfung der Objektgleichheit von Immutable-Data-Structure-Bibliotheken nutzen, um die Virtual-DOM-Abgleichszeiten zu reduzieren. Im Allgemeinen verfolgt React bei der Performance den Ansatz, relativ komplexe Lösungen zu entwickeln.
Mithril.js folgt dem Less-is-more-Gedanken. Es hat eine wesentlich kleinere, aggressiv optimierte Codebasis. Die Begründung ist, dass eine kleine Codebasis einfacher zu überprüfen und zu optimieren ist und letztendlich zu weniger auszuführendem Code führt.
Im Folgenden finden Sie einen Vergleich der Bibliotheksladezeiten. Das heißt, die Zeit, die benötigt wird, um den JavaScript-Code jedes Frameworks zu parsen und auszuführen. Dies wird gemessen, indem console.time()
am Anfang und console.timeEnd()
am Ende eines Skripts eingefügt wird, das nur aus Framework-Code besteht. Um die Lesbarkeit zu erhöhen, sind hier die 20 besten Ergebnisse. Der Logging-Code wurde manuell zu gebündelten Skripten hinzugefügt und in Chrome auf einem durchschnittlichen PC-Desktop von 2010 ausgeführt, wobei die Skripte vom Dateisystem geladen wurden.
React | Mithril.js |
---|---|
55.8 ms | 4.5 ms |
Bibliotheksladezeiten sind wichtig in Anwendungen, die nicht lange geöffnet bleiben (z. B. alles im mobilen Bereich) und nicht durch Caching oder andere Optimierungstechniken verbessert werden können.
Da es sich um einen Micro-Benchmark handelt, werden Sie ermutigt, diese Tests selbst zu replizieren, da die Hardware die Ergebnisse stark beeinflussen kann. Beachten Sie, dass Bundler-Frameworks wie Webpack Abhängigkeiten vor den Timer-Aufrufen verschieben können, um die statische Modulauflösung zu emulieren. Sie sollten daher entweder den Code aus den kompilierten CDN-Dateien kopieren oder die Ausgabedatei aus der Bundler-Bibliothek öffnen und die hochauflösenden Timer-Aufrufe console.time
und console.timeEnd
manuell zum gebündelten Skript hinzufügen. Vermeiden Sie die Verwendung von new Date
und performance.now
, da diese Mechanismen statistisch nicht so genau sind.
Zu Ihrer Bequemlichkeit finden Sie hier eine Version dieses Benchmarks, die an die Verwendung von CDNs im Web angepasst ist: Der Benchmark für React ist hier und der Benchmark für Mithril.js ist hier. Beachten Sie, dass wir hier das gesamte Mithril.js testen und nicht nur das Rendering-Modul (das vom Umfang her React entsprechen würde). Beachten Sie auch, dass dieses CDN-gesteuerte Setup einige Overheads verursacht, da Ressourcen aus dem Festplatten-Cache abgerufen werden (~2 ms pro Ressource). Aus diesen Gründen sind die Ergebnisse hier nicht ganz genau, aber sie sollten ausreichen, um zu beobachten, dass die Initialisierungsgeschwindigkeit von Mithril.js spürbar besser ist als die von React.
Hier ist ein etwas aussagekräftigerer Benchmark: Messung der Skriptzeit für das Erstellen von 10.000 Divs (und 10.000 Textknoten). Auch hier ist der Benchmark-Code für React und Mithril.js. Ihre besten Ergebnisse sind unten dargestellt:
React | Mithril.js |
---|---|
99.7 ms | 42.8 ms |
Diese Zahlen zeigen, dass Mithril.js nicht nur deutlich schneller initialisiert wird, sondern auch bis zu 20.000 Virtual-DOM-Knoten verarbeiten kann, bevor React einsatzbereit ist.
Update-Performance
Die Update-Performance kann noch wichtiger sein als die First-Render-Performance, da Updates während der Ausführung einer Single-Page-Anwendung viele Male auftreten können.
Ein nützliches Tool zum Testen der Update-Performance ist ein Tool, das vom Ember-Team entwickelt wurde und DbMonster heißt. Es aktualisiert eine Tabelle so schnell wie möglich und misst Frames pro Sekunde (FPS) und JavaScript-Zeiten (min, max und Mittelwert). Die FPS-Anzahl kann schwierig zu bewerten sein, da sie auch Browser-Repaint-Zeiten und die setTimeout
-Klemmverzögerung enthält. Die aussagekräftigste Zahl ist daher die durchschnittliche Renderzeit. Sie können eine React-Implementierung und eine Mithril.js-Implementierung vergleichen. Beispielergebnisse sind unten dargestellt:
React | Mithril.js |
---|---|
12.1 ms | 6.4 ms |
Development-Performance
Ein weiterer Punkt, den Sie beachten sollten, ist, dass React im Entwicklungsmodus zusätzliche Prüfungen und hilfreiche Fehlermeldungen hinzufügt und daher in der Entwicklung langsamer ist als die Produktionsversion, die für die obigen Benchmarks verwendet wurde. Zur Veranschaulichung hier der bereits erwähnte 10.000-Knoten-Benchmark mit der Entwicklungsversion von React.
Drop-in-Ersatz
Es gibt mehrere Projekte die behaupten, API-Parität mit React zu haben (einige über Kompatibilitätsschichtbibliotheken), aber sie sind nicht vollständig kompatibel (z. B. wird die PropType-Unterstützung normalerweise ausgeblendet, synthetische Ereignisse werden manchmal nicht unterstützt und einige APIs haben unterschiedliche Semantiken). Beachten Sie, dass diese Bibliotheken in der Regel auch eigene Funktionen enthalten, die nicht Teil der offiziellen React-API sind, was sich später als problematisch erweisen kann, wenn man sich entscheidet, zu React Fiber zurückzukehren.
Behauptungen über eine geringe Downloadgröße (im Vergleich zu React) sind zutreffend, aber die meisten dieser Bibliotheken sind etwas größer als das Renderer-Modul von Mithril.js. Preact ist die einzige Ausnahme.
Seien Sie vorsichtig bei aggressiven Leistungsbehauptungen, da Benchmarks, die von einigen dieser Projekte verwendet werden, bekanntermaßen veraltet und fehlerhaft sind (in dem Sinne, dass sie ausgenutzt werden können - und werden). Boris Kaul (Autor einiger der Benchmarks) hat detailliert darüber geschrieben, wie Benchmarks manipuliert werden. Ein weiterer Punkt, den Sie beachten sollten, ist, dass einige Benchmarks aggressiv erweiterte Optimierungsfunktionen verwenden und somit die potenzielle Leistung demonstrieren, d. h. die Leistung, die unter bestimmten Vorbehalten möglich ist, aber realistischerweise unwahrscheinlich ist, es sei denn, Sie verbringen aktiv Zeit damit, Ihre gesamte Codebasis zu überprüfen, Optimierungskandidaten zu identifizieren und die Regressionsrisiken zu bewerten, die durch die Optimierungsvorbehalte entstehen.
Um typische Leistungsmerkmale zu demonstrieren, werden die auf dieser Vergleichsseite dargestellten Benchmarks auf naive, idiomatische Weise (d. h. so, wie Sie normalerweise 99 % Ihres Codes schreiben würden) und ohne Tricks oder erweiterte Optimierungen implementiert, um das eine oder andere Framework künstlich besser aussehen zu lassen. Sie werden ermutigt, einen PR beizutragen, wenn Sie der Meinung sind, dass eine DbMonster-Implementierung hier idiomatischer geschrieben werden könnte.
Komplexität
Sowohl React als auch Mithril.js haben im Vergleich zu anderen Frameworks relativ kleine API-Oberflächen, was dazu beiträgt, die Lernkurve zu erleichtern. Während idiomatische Mithril.js ohne Lesbarkeitsverlust mit einfachem ES5 und ohne andere Abhängigkeiten geschrieben werden kann, ist idiomatische React stark auf komplexe Tools angewiesen (z. B. Babel, JSX-Plugin usw.), und diese Komplexität erstreckt sich häufig auf beliebte Teile seines Ökosystems, beispielsweise in Form von Syntaxerweiterungen (z. B. nicht standardmäßige Objektverteilungssyntax in Redux), Architekturen (z. B. solche, die Immutable-Data-Bibliotheken verwenden) oder zusätzlichen Funktionen (z. B. Hot-Module-Reloading).
Obwohl komplexe Toolchains auch mit Mithril.js und anderen Frameworks möglich sind, wird dringend empfohlen, dass Sie die Prinzipien KISS (Keep It Simple, Stupid) und YAGNI (You Ain't Gonna Need It) bei der Verwendung von Mithril befolgen.
Lernkurve
Sowohl React als auch Mithril.js haben relativ flache Lernkurven. Die Lernkurve von React beinhaltet hauptsächlich das Verständnis von Komponenten und ihrem Lebenszyklus. Die Lernkurve für Mithril.js-Komponenten ist nahezu identisch. Es gibt offensichtlich mehr APIs in Mithril.js zu lernen, da Mithril.js auch Routing und XHR enthält, aber die Lernkurve wäre ziemlich ähnlich wie beim Erlernen von React, React Router und einer XHR-Bibliothek wie Superagent oder Axios.
Idiomatisches React erfordert Kenntnisse über JSX und seine Vorbehalte, und daher gibt es auch eine kleine Lernkurve in Bezug auf Babel.
Dokumentation
Die React-Dokumentation ist klar und gut geschrieben und enthält eine gute API-Referenz, Tutorials für den Einstieg sowie Seiten, die verschiedene fortgeschrittene Konzepte abdecken. Da React jedoch auf eine reine View-Bibliothek beschränkt ist, wird in der Dokumentation nicht untersucht, wie React idiomatisch im Kontext einer realen Anwendung verwendet wird. Infolgedessen gibt es viele beliebte State-Management-Bibliotheken, und daher können sich Architekturen mit React von Unternehmen zu Unternehmen (oder sogar zwischen Projekten) drastisch unterscheiden.
Die Mithril.js-Dokumentation enthält auch Einführungs- Tutorials, Seiten über fortgeschrittene Konzepte und einen umfangreichen API-Referenzabschnitt, der Informationen zu Eingabe-/Ausgabetypen, Beispiele für verschiedene gängige Anwendungsfälle und Ratschläge gegen Missbrauch und Anti-Patterns enthält. Sie enthält auch ein Cheatsheet zur schnellen Referenz.
Die Mithril.js-Dokumentation demonstriert auch einfache, praxisnahe Lösungen für gängige Anwendungsfälle in realen Anwendungen und informiert Entwickler gegebenenfalls darüber, dass Webstandards inzwischen mit größeren, etablierten Bibliotheken gleichziehen könnten.
Angular
Angular ist ein Webanwendungs-Framework, das von Google gepflegt wird.
Angular und Mithril.js sind recht unterschiedlich, aber sie haben einige Gemeinsamkeiten:
- Beide unterstützen die Komponentisierung.
- Beide verfügen über eine Reihe von Tools für verschiedene Aspekte von Webanwendungen (z. B. Routing, XHR).
Der offensichtlichste Unterschied zwischen Angular und Mithril.js liegt in ihrer Komplexität. Dies lässt sich am einfachsten daran erkennen, wie Views implementiert werden. Mithril.js-Views sind einfaches JavaScript, und die Flow-Control erfolgt mit integrierten JavaScript-Mechanismen wie ternären Operatoren oder Array.prototype.map
. Angular hingegen implementiert ein Direktiven-System, um HTML-Views zu erweitern, sodass es möglich ist, JavaScript-ähnliche Ausdrücke innerhalb von HTML-Attributen und Interpolationen auszuwerten. Angular liefert tatsächlich einen Parser und einen Compiler, die in JavaScript geschrieben sind, um dies zu erreichen. Wenn das noch nicht komplex genug erscheint, gibt es tatsächlich zwei Kompilierungsmodi (ein Standardmodus, der dynamisch JavaScript-Funktionen für die Performance generiert, und ein langsamerer Modus für den Umgang mit Content-Security-Policy-Einschränkungen).
Performance
Angular hat im Laufe der Jahre deutliche Leistungsverbesserungen erzielt. Angular 1 verwendete einen Mechanismus, der als Dirty Checking bekannt ist und aufgrund der Notwendigkeit, ständig große $scope
-Strukturen zu vergleichen, langsam wurde. Angular 2 verwendet einen Template-Change-Detection-Mechanismus, der viel performanter ist. Aber selbst trotz der Verbesserungen von Angular ist Mithril.js oft schneller als Angular, da die geringe Größe der Codebasis von Mithril.js die Prüfung erleichtert.
Es ist schwierig, einen Vergleich der Ladezeiten zwischen Angular und Mithril.js anzustellen, und zwar aus mehreren Gründen. Der erste ist, dass Angular 1 und 2 tatsächlich völlig unterschiedliche Codebasen sind und beide Versionen offiziell unterstützt und gepflegt werden (und die überwiegende Mehrheit der Angular-Codebasen derzeit noch Version 1 verwendet). Der zweite Grund ist, dass sowohl Angular als auch Mithril.js modular sind. In beiden Fällen ist es möglich, einen wesentlichen Teil des Frameworks zu entfernen, der in einer bestimmten Anwendung nicht verwendet wird.
Dennoch ist das kleinste bekannte Angular-2-Bundle ein 29 KB Hello World, das mit dem Brotli-Algorithmus komprimiert wurde (mit Standard-Gzip sind es 35 KB), und die meisten nützlichen Funktionen von Angular wurden entfernt. Im Vergleich dazu wäre ein Mithril.js Hello World - einschließlich des gesamten Mithril.js-Kerns mit allem Drum und Dran - etwa 10 KB gezippt.
Denken Sie auch daran, dass Frameworks wie Angular und Mithril.js für nicht triviale Anwendungen entwickelt wurden. Eine Anwendung, die es schafft, die gesamte API-Oberfläche von Angular zu nutzen, müsste also mehrere hundert KB Framework-Code herunterladen, anstatt nur 29 KB.
Update-Performance
Ein nützliches Tool zum Testen der Update-Performance ist ein Tool, das vom Ember-Team entwickelt wurde und DbMonster heißt. Es aktualisiert eine Tabelle so schnell wie möglich und misst Frames pro Sekunde (FPS) und JavaScript-Zeiten (min, max und Mittelwert). Die FPS-Anzahl kann schwierig zu bewerten sein, da sie auch Browser-Repaint-Zeiten und die setTimeout
-Klemmverzögerung enthält. Die aussagekräftigste Zahl ist daher die durchschnittliche Renderzeit. Sie können eine Angular-Implementierung und eine Mithril.js-Implementierung vergleichen. Beide Implementierungen sind naiv (d. h. keine Optimierungen). Beispielergebnisse sind unten dargestellt:
Angular | Mithril.js |
---|---|
11.5 ms | 6.4 ms |
Komplexität
Angular ist Mithril.js in Bezug auf die Anzahl der angebotenen Tools (in Form verschiedener Direktiven und Dienste) überlegen, aber es ist auch weitaus komplexer. Vergleichen Sie die API-Oberfläche von Angular mit der von Mithril.js. Sie können selbst entscheiden, welche API verständlicher und besser auf Ihre Bedürfnisse zugeschnitten ist.
Angular 2 hat viel mehr Konzepte zu verstehen: Auf der Sprachebene ist Typescript die empfohlene Sprache, und darüber hinaus gibt es auch Angular-spezifische Template-Syntax wie Bindungen, Pipes, "Safe Navigator Operator". Sie müssen auch architektonische Konzepte wie Module, Komponenten, Dienste, Direktiven usw. lernen und wo es angebracht ist, was zu verwenden.
Lernkurve
Wenn wir Äpfel mit Äpfeln vergleichen, haben Angular 2 und Mithril.js ähnliche Lernkurven: In beiden sind Komponenten ein zentraler Aspekt der Architektur, und beide verfügen über vernünftige Routing- und XHR-Tools.
Dennoch gibt es in Angular viel mehr Konzepte zu lernen als in Mithril. Es bietet Angular-spezifische APIs für viele Dinge, die oft trivial implementiert werden können (z. B. ist die Pluralisierung im Wesentlichen eine Switch-Anweisung, die "erforderliche" Validierung ist einfach eine Gleichheitsprüfung usw.). Angular-Templates haben auch mehrere Abstraktionsebenen, um zu emulieren, was JavaScript nativ in Mithril.js tut - Angulars ng-if
/ngIf
ist eine Direktive, die einen benutzerdefinierten Parser und Compiler verwendet, um einen Ausdrucksstring auszuwerten und lexikalische Gültigkeitsbereiche zu emulieren... und so weiter. Mithril.js ist in der Regel viel transparenter und daher einfacher zu verstehen.
Dokumentation
Die Angular-2-Dokumentation bietet ein umfangreiches Einführungstutorial und ein weiteres Tutorial, das eine Anwendung implementiert. Sie enthält auch verschiedene Anleitungen für fortgeschrittene Konzepte, ein Cheatsheet und einen Styleguide. Leider lässt die API-Referenz im Moment zu wünschen übrig. Mehrere APIs sind entweder undokumentiert oder bieten keinen Kontext dafür, wofür die API verwendet werden könnte.
Die Mithril.js-Dokumentation enthält Einführungs- Tutorials, Seiten über fortgeschrittene Konzepte und einen umfangreichen API-Referenzabschnitt, der Informationen zu Eingabe-/Ausgabetypen, Beispiele für verschiedene gängige Anwendungsfälle und Ratschläge gegen Missbrauch und Anti-Patterns enthält. Sie enthält auch ein Cheatsheet zur schnellen Referenz.
Die Mithril.js-Dokumentation demonstriert auch einfache, praxisnahe Lösungen für gängige Anwendungsfälle in realen Anwendungen und informiert Entwickler gegebenenfalls darüber, dass Webstandards inzwischen mit größeren, etablierten Bibliotheken gleichziehen könnten.
Vue
Vue ist eine View-Bibliothek, die Angular ähnelt.
Vue und Mithril.js haben viele Unterschiede, aber sie haben auch einige Gemeinsamkeiten:
- Beide verwenden Virtual DOM und Lifecycle-Methoden.
- Beide organisieren Views über Komponenten.
Vue 2 verwendet einen Fork von Snabbdom als Virtual-DOM-System. Darüber hinaus bietet Vue auch Tools für Routing und State Management als separate Module. Vue ähnelt Angular sehr und bietet ein ähnliches Direktiven-System, HTML-basierte Templates und Logik-Flow-Direktiven. Es unterscheidet sich von Angular dadurch, dass es ein Monkeypatching-Reaktivsystem implementiert, das native Methoden in einem Datenbaum einer Komponente überschreibt (während Angular 1 Dirty Checking und Digest/Apply-Zyklen verwendet, um ähnliche Ergebnisse zu erzielen). Ähnlich wie Angular 2 kompiliert Vue HTML-Templates in Funktionen, aber die kompilierten Funktionen sehen eher wie Mithril.js- oder React-Views aus als die kompilierten Rendering-Funktionen von Angular.
Vue ist deutlich kleiner als Angular, wenn man Äpfel mit Äpfeln vergleicht, aber nicht so klein wie Mithril.js (Vue Core ist etwa 23 KB gezippt, während das entsprechende Rendering-Modul in Mithril.js etwa 4 KB gezippt ist). Beide haben ähnliche Leistungsmerkmale, aber Benchmarks deuten in der Regel darauf hin, dass Mithril.js etwas schneller ist.
Performance
Im Folgenden finden Sie einen Vergleich der Bibliotheksladezeiten. Das heißt, die Zeit, die benötigt wird, um den JavaScript-Code jedes Frameworks zu parsen und auszuführen. Dies wird gemessen, indem console.time()
am Anfang und console.timeEnd()
am Ende eines Skripts eingefügt wird, das nur aus Framework-Code besteht. Um die Lesbarkeit zu erhöhen, sind hier die 20 besten Ergebnisse. Der Logging-Code wurde manuell zu gebündelten Skripten hinzugefügt und in Chrome auf einem durchschnittlichen PC-Desktop von 2010 ausgeführt, wobei die Skripte vom Dateisystem geladen wurden.
Vue | Mithril.js |
---|---|
21.8 ms | 4.5 ms |
Bibliotheksladezeiten sind wichtig in Anwendungen, die nicht lange geöffnet bleiben (z. B. alles im mobilen Bereich) und nicht durch Caching oder andere Optimierungstechniken verbessert werden können.
Update-Performance
Ein nützliches Tool zum Testen der Update-Performance ist ein Tool, das vom Ember-Team entwickelt wurde und DbMonster heißt. Es aktualisiert eine Tabelle so schnell wie möglich und misst Frames pro Sekunde (FPS) und JavaScript-Zeiten (min, max und Mittelwert). Die FPS-Anzahl kann schwierig zu bewerten sein, da sie auch Browser-Repaint-Zeiten und die setTimeout
-Klemmverzögerung enthält. Die aussagekräftigste Zahl ist daher die durchschnittliche Renderzeit. Sie können eine Vue-Implementierung und eine Mithril.js-Implementierung vergleichen. Beide Implementierungen sind naiv (d. h. keine Optimierungen). Beispielergebnisse sind unten dargestellt:
Vue | Mithril.js |
---|---|
9.8 ms | 6.4 ms |
Komplexität
Vue ist stark von Angular inspiriert und hat viele Dinge, die Angular tut (z. B. Direktiven, Filter, bidirektionale Bindungen, v-cloak
), hat aber auch Dinge, die von React inspiriert sind (z. B. Komponenten). Ab Vue 2.0 ist es auch möglich, Templates mit Hyperscript/JSX-Syntax zu schreiben (zusätzlich zu Single-File-Komponenten und den verschiedenen Webpack-basierten Sprach-Transpilations-Plugins). Vue bietet sowohl bidirektionale Datenbindung als auch eine optionale Redux-ähnliche State-Management-Bibliothek, aber im Gegensatz zu Angular bietet es keinen Styleguide. Die Vielfalt an Möglichkeiten, eine Aufgabe zu lösen, kann in langfristigen Projekten zu einer Fragmentierung der Architektur führen.
Mithril.js hat weitaus weniger Konzepte und organisiert Anwendungen typischerweise in Bezug auf Komponenten und eine Datenschicht. Alle Komponentenerstellungsstile in Mithril.js geben die gleiche VNode-Struktur nur mit nativen JavaScript-Funktionen aus. Die direkte Folge der Anlehnung an die Sprache ist weniger Tooling und ein einfacheres Projekt-Setup.
Dokumentation
Sowohl Vue als auch Mithril.js haben eine gute Dokumentation. Beide enthalten eine gute API-Referenz mit Beispielen, Tutorials für den Einstieg sowie Seiten, die verschiedene fortgeschrittene Konzepte abdecken.
Aufgrund des Ansatzes von Vue, viele Wege zu haben, um eine Sache zu tun, sind einige Dinge möglicherweise nicht ausreichend dokumentiert. Zum Beispiel wird ihr Hyperscript stark beschönigt.
Die Mithril.js-Dokumentation neigt in der Regel dazu, übermäßig gründlich zu sein, wenn ein Thema Dinge außerhalb des Geltungsbereichs von Mithril betrifft. Wenn ein Thema beispielsweise eine Bibliothek eines Drittanbieters betrifft, führt die Mithril.js-Dokumentation durch den Installationsprozess für die Bibliothek des Drittanbieters. Die Mithril.js-Dokumentation demonstriert auch oft einfache, praxisnahe Lösungen für gängige Anwendungsfälle in realen Anwendungen und informiert Entwickler gegebenenfalls darüber, dass Webstandards inzwischen mit größeren, etablierten Bibliotheken gleichziehen könnten.
Die Tutorials von Mithril.js decken auch viel mehr ab als die von Vue: Das Vue-Tutorial endet mit einer einfachen lokalen To-Do-Liste, nachdem mehrere Seiten durchlaufen wurden, um die umfangreiche Kern-API abzudecken. Die 10-Minuten-Anleitung von Mithril.js deckt den Großteil seiner API ab und geht sogar auf wichtige Aspekte realer Anwendungen ein, wie z. B. das Abrufen von Daten von einem Server und das Routing. Wenn das nicht genug ist, gibt es auch ein längeres, gründlicheres Tutorial.