Framework összehasonlítás

Ha ezt az oldalt olvasod, valószínűleg már használtál más keretrendszereket alkalmazások építéséhez, és szeretnéd tudni, hogy a Mithril.js hatékonyabban segítene-e a problémáid megoldásában.

Miért ne [a kedvenc keretrendszered]?

A valóság az, hogy a legtöbb modern keretrendszer gyors, jól alkalmazható komplex alkalmazások építésére, és karbantartható, ha tudod, hogyan kell őket hatékonyan használni. Vannak példák rendkívül komplex alkalmazásokra, amelyek szinte minden népszerű keretrendszert használnak: az Udemy az Angular-t, az AirBnB a React-et, a Gitlab a Vue-t, a Guild Wars 2 a Mithril.js-t használja (igen, a játékon belül!). Nyilvánvaló, hogy ezek mindegyike éles környezetben is használható keretrendszer.

Általános szabályként, ha a csapatod már erősen befektetett egy másik keretrendszerbe/könyvtárba/technológiai verembe, akkor érdemesebb ragaszkodni hozzá, hacsak a csapatod nem ért egyet abban, hogy nagyon nyomós ok van egy költséges átírás igazolására.

Azonban, ha valami újat kezdesz, fontold meg a Mithril.js kipróbálását, hogy lásd, mennyi értéket kaptak a Mithril.js alkalmazói kevesebb mint 10kb (gzip-elve) kódból. A Mithril.js-t számos jól ismert vállalat használja (pl. Vimeo, Nike, Fitbit), és nagy nyílt forráskódú platformokat is működtet, mint például a Lichess és a Flarum.

Miért használj Mithril.js-t?

Egy mondatban: mert a Mithril.js pragmatikus. Ez a 10 perces útmutató jó példa: ennyi időbe telik megtanulni a komponenseket, az XHR-t és a routingot - és ez éppen a megfelelő mennyiségű tudás ahhoz, hogy hasznos alkalmazásokat építsünk.

A Mithril.js célja, hogy hatékonyan végezzünk érdemi munkát. Fájlfeltöltés? A dokumentáció megmutatja, hogyan. Hitelesítés? Szintén dokumentálva. Kilépési animációk? Megvan. Nincs extra könyvtár, nincs varázslat.

Összehasonlítások

React

A React egy nézetkönyvtár, amelyet a Facebook tart karban.

A React és a Mithril.js között sok hasonlóság van. Ha már megtanultad a React-et, szinte mindent tudsz, ami az alkalmazások Mithril-lel való építéséhez szükséges.

• Mindkettő virtuális DOM-ot, lifecycle metódusokat és kulcsalapú összehangolást használ
• Mindkettő komponenseken keresztül szervezi a nézeteket
• Mindkettő JavaScriptet használ vezérlési mechanizmusként a nézeteken belül

A legszembetűnőbb különbség a React és a Mithril.js között a hatókörükben rejlik. A React egy nézetkönyvtár, így egy tipikus React-alapú alkalmazás harmadik féltől származó könyvtárakra támaszkodik a routinghoz, az XHR-hez és az állapotkezeléshez. A könyvtárorientált megközelítés lehetővé teszi a fejlesztők számára, hogy a stack-jüket pontosan az igényeikhez igazítsák. Ezt kevésbé szépen úgy is mondhatjuk, hogy a React-alapú architektúrák projektenként nagyon eltérőek lehetnek. Emiatt ezek a projektek nagyobb valószínűséggel lépik át az 1 MB-os méretkorlátot.

A Mithril.js beépített modulokkal rendelkezik a gyakori szükségletekhez, mint például a routing és az XHR; az útmutató pedig bemutatja az idiómatikus használatot. Ez a megközelítés előnyösebb azoknak a csapatoknak, amelyek értékelik a következetességet és a könnyű betanulást.

Teljesítmény

Mind a React, mind a Mithril.js nagy hangsúlyt fektet a renderelési teljesítményre, de ezt különböző módokon teszik. A múltban a React-nek két DOM renderelési implementációja volt (egy a DOM API-t használva, egy pedig az innerHTML-t). A készülő fiber architektúrája ütemezést és a munkaegységek prioritásának meghatározását vezeti be. A React emellett kifinomult build rendszerrel is rendelkezik, amely letiltja a különböző ellenőrzéseket és hibaüzeneteket a gyártási telepítésekhez, valamint különböző böngészőspecifikus optimalizálásokat. Ezenkívül számos teljesítményorientált könyvtár is létezik, amelyek kihasználják a React shouldComponentUpdate hook-ját és a megváltoztathatatlan adatstruktúra könyvtárak gyors objektumegyenlőség-ellenőrzési tulajdonságait a virtuális DOM egyeztetési idő csökkentése érdekében. Általánosságban elmondható, hogy a React teljesítményhez való hozzáállása viszonylag komplex megoldások tervezése.

A Mithril.js a kevesebb több elvét követi. Jelentősen kisebb, agresszíven optimalizált kódbázissal rendelkezik. Az indoklás az, hogy egy kis kódbázist könnyebb auditálni és optimalizálni, és végső soron kevesebb kód futtatását eredményezi.

Íme egy összehasonlítás a könyvtár betöltési idejéről, azaz az egyes keretrendszerek JavaScript kódjának elemzéséhez és futtatásához szükséges időről, úgy, hogy egy console.time() hívást adunk az első sorhoz, és egy console.timeEnd() hívást egy olyan szkript utolsó sorához, amely kizárólag keretrendszerkódból áll. Az olvasás megkönnyítése érdekében itt vannak a legjobb 20 eredmények, a naplózó kóddal manuálisan hozzáadva a csomagolt szkriptekhez, a fájlrendszerről futtatva, egy szerény 2010-es PC asztali gépen a Chrome-ban:

React	Mithril.js
55.8 ms	4.5 ms

A könyvtár betöltési ideje fontos azokban az alkalmazásokban, amelyek nem maradnak nyitva hosszú ideig (például bármi a mobilon), és nem javíthatók gyorsítótárazással vagy más optimalizálási technikákkal.

Mivel ez egy mikro-benchmark, javasoljuk, hogy magad is ismételd meg ezeket a teszteket, mivel a hardver nagymértékben befolyásolhatja a számokat. Vedd figyelembe, hogy a bundler keretrendszerek, mint a Webpack, a függőségeket a timer hívások elé helyezhetik a statikus modul feloldásának emulálása érdekében, ezért vagy másold ki a kódot a lefordított CDN fájlokból, vagy nyisd meg a bundler könyvtár kimeneti fájlját, és manuálisan add hozzá a nagy felbontású timer hívásokat (console.time és console.timeEnd) a csomagolt szkripthez. Kerüld a new Date és a performance.now használatát, mivel ezek a mechanizmusok nem annyira statisztikailag pontosak.

Az olvasás megkönnyítése érdekében itt van a benchmark egy verziója, amely a CDN-eket használja a weben: a React benchmarkja itt található, a Mithril.js benchmarkja pedig itt található. Vedd figyelembe, hogy a Mithril.js egészét benchmarkoljuk, nem pedig csak a renderelő modult (amely a React-tel azonos hatókörű lenne). Azt is vedd figyelembe, hogy ez a CDN-vezérelt beállítás némi többletköltséget okoz az erőforrások lemezgyorsítótárból való betöltése miatt (~2ms erőforrásonként). Ezen okok miatt a számok itt nem teljesen pontosak, de elegendőnek kell lenniük ahhoz, hogy megfigyeljük, hogy a Mithril.js inicializálási sebessége érezhetően jobb, mint a React.

Íme egy kicsit értelmesebb benchmark: 10 000 div (és 10 000 szöveges csomópont) létrehozásának szkriptelési idejének mérése. Ismét itt van a benchmark kódja a React és a Mithril.js számára. A legjobb eredményeik az alábbiakban láthatók:

React	Mithril.js
99.7 ms	42.8 ms

Ezek a számok azt mutatják, hogy a Mithril.js nemcsak jelentősen gyorsabban inicializálódik, hanem akár 20 000 virtuális DOM csomópontot is fel tud dolgozni, mielőtt a React használatra kész lenne.

Frissítési teljesítmény

A frissítési teljesítmény még fontosabb lehet, mint az első renderelés teljesítménye, mivel a frissítések sokszor megtörténhetnek egy Single Page Application futása közben.

A frissítési teljesítmény benchmarkolásához hasznos eszköz az Ember csapata által kifejlesztett DbMonster nevű eszköz. Olyan gyorsan frissít egy táblázatot, amennyire csak tud, és méri a képkockák számát másodpercenként (FPS) és a JavaScript időket (min, max és átlag). Az FPS számot nehéz értékelni, mivel az a böngésző újrarajzolási idejét és a setTimeout clamping késleltetését is tartalmazza, így a legértelmesebb szám, amit érdemes megnézni, az az átlagos renderelési idő. Összehasonlíthatod a React implementációt és a Mithril.js implementációt. A minták eredményei az alábbiakban láthatók:

React	Mithril.js
12.1 ms	6.4 ms

Fejlesztési teljesítmény

Azt is szem előtt kell tartani, hogy mivel a React extra ellenőrzéseket és hasznos hibaüzeneteket ad hozzá fejlesztői módban, lassabb a fejlesztés során, mint a fenti benchmarkokhoz használt éles verzió. Ennek illusztrálására itt van a fenti 10 000 csomópontos benchmark a React fejlesztői verziójával.

Drop-in helyettesítők

Számos projekt állítja azt hogy API paritást mutat a React-tel (némelyik kompatibilitási réteg könyvtárakon keresztül), de nem teljesen kompatibilisek (pl. a PropType támogatás általában csonkolt, a szintetikus események néha nem támogatottak, és néhány API-nak eltérő a szemantikája). Vedd figyelembe, hogy ezek a könyvtárak általában olyan funkciókat is tartalmaznak, amelyek nem részei a hivatalos React API-nak, ami problémássá válhat a jövőben, ha valaki úgy dönt, hogy visszavált a React Fiber-re.

A kis letöltési méretre vonatkozó állítások (a React-hez képest) pontosak, de a legtöbb ilyen könyvtár valamivel nagyobb, mint a Mithril.js renderelő modulja. A Preact az egyetlen kivétel.

Légy óvatos az agresszív teljesítményre vonatkozó állításokkal, mivel néhány ilyen projekt által használt benchmarkról ismert, hogy elavult és hibás (abban az értelemben, hogy kihasználható - és ki is használják). Boris Kaul (néhány benchmark szerzője) részletesen írt arról, hogyan manipulálják a benchmarkokat. Azt is fontos megjegyezni, hogy egyes benchmarkok agresszíven alkalmaznak fejlett optimalizálási technikákat. Ezáltal potenciális teljesítményt mutatnak, ami bizonyos feltételek mellett elérhető, de valójában nem valószínű. Ehhez aktívan át kellene vizsgálnod a teljes kódbázisodat, azonosítva az optimalizálási lehetőségeket és felmérve az optimalizálási feltételekkel járó regressziós kockázatokat.

A tipikus teljesítményjellemzők bemutatásának szellemében az ezen az összehasonlító oldalon bemutatott benchmarkok alma-alma, naiv, idiómatikus módon vannak implementálva (azaz ahogyan a kódod 99%-át normálisan írnád), és nem alkalmaznak trükköket vagy fejlett optimalizálásokat, hogy az egyik vagy másik keretrendszer mesterségesen jobban nézzen ki. Javasoljuk, hogy küldj be egy PR-t, ha úgy érzed, hogy bármelyik DbMonster implementáció itt idiómatikusabban is megírható lenne.

Komplexitás

Mind a React, mind a Mithril.js viszonylag kis API felülettel rendelkezik a többi keretrendszerhez képest, ami segít enyhíteni a tanulási görbét. Azonban, míg az idiómatikus Mithril.js olvashatóságának elvesztése nélkül írható egyszerű ES5-tel és más függőségek nélkül, az idiómatikus React nagymértékben támaszkodik komplex eszközökre (pl. Babel, JSX plugin, stb.), és ez a komplexitási szint gyakran kiterjed az ökoszisztémájának népszerű részeire is, legyen az szintaxis kiterjesztések formájában (pl. nem szabványos objektum spread szintaxis a Redux-ban), architektúrák (pl. megváltoztathatatlan adatkönyvtárakat használók), vagy csengők és sípok (pl. hot module reloading).

Bár a komplex toolchainek a Mithril.js-szel és más keretrendszerekkel is lehetségesek, erősen ajánlott, hogy kövesd a KISS és a YAGNI elveket a Mithril használatakor.

Tanulási görbe

Mind a React, mind a Mithril.js viszonylag kis tanulási görbével rendelkezik. A React tanulási görbéje leginkább a komponensek és azok lifecycle-jének megértését foglalja magában. A Mithril.js komponensek tanulási görbéje szinte azonos. Nyilvánvalóan több API-t kell megtanulni a Mithril.js-ben, mivel a Mithril.js routingot és XHR-t is tartalmaz, de a tanulási görbe meglehetősen hasonló lenne a React, a React Router és egy XHR könyvtár, például a superagent vagy az axios megtanulásához.

Az idiómatikus React megköveteli a JSX és annak buktatóinak működő ismeretét, ezért a Babelhez kapcsolódóan is van egy kis tanulási görbe.

Dokumentáció

A React dokumentációja világos és jól megírt, és tartalmaz egy jó API referenciát, oktatóanyagokat a kezdéshez, valamint oldalakat a különböző haladó fogalmakról. Sajnos, mivel a React csak egy nézetkönyvtárra korlátozódik, a dokumentációja nem vizsgálja, hogyan kell a React-et idiómatikusan használni egy valós alkalmazás kontextusában. Ennek eredményeként sok népszerű állapotkezelő könyvtár létezik, és így a React-et használó architektúrák drasztikusan eltérhetnek vállalatonként (vagy akár projektek között is).

A Mithril.js dokumentációja bevezető oktatóanyagokat, oldalakat a haladó fogalmakról és egy kiterjedt API referencia szekciót is tartalmaz, amely tartalmaz bemeneti/kimeneti típusinformációkat, példákat a különböző gyakori használati esetekre, valamint tanácsokat a helytelen használat és az anti-patternek ellen. Tartalmaz egy gyorsreferenciát is a gyors referenciához.

A Mithril.js dokumentációja egyszerű, közvetlen megoldásokat is bemutat a valós alkalmazásokban előforduló gyakori használati esetekre, ahol helyénvaló tájékoztatni a fejlesztőt arról, hogy a webes szabványok mostanra felérhetnek a nagyobb, bejáratott könyvtárakkal.

Angular

Az Angular egy webalkalmazás-keretrendszer, amelyet a Google tart karban.

Az Angular és a Mithril.js meglehetősen eltérőek, de van néhány hasonlóságuk:

• Mindkettő támogatja a komponensalapúságot
• Mindkettő rendelkezik egy sor eszközzel a webalkalmazások különböző aspektusaihoz (pl. routing, XHR)

A legszembetűnőbb különbség az Angular és a Mithril.js között a komplexitásukban van. Ez legkönnyebben abban látható, ahogyan a nézetek implementálva vannak. A Mithril.js nézetek egyszerű JavaScriptek, és a folyamatszabályozás a JavaScript beépített mechanizmusaival történik, mint például a ternary operátorok vagy az Array.prototype.map. Az Angular viszont egy direktíva rendszert implementál a HTML nézetek kiterjesztésére, hogy lehetővé tegye a JavaScript-szerű kifejezések kiértékelését a HTML attribútumokon és interpolációkon belül. Az Angular valójában egy JavaScriptben írt parsert és egy compilert is szállít ennek eléréséhez. Ha ez nem tűnik elég komplexnek, akkor valójában két fordítási mód létezik (egy alapértelmezett mód, amely dinamikusan generál JavaScript függvényeket a teljesítmény érdekében, és egy lassabb mód a Content Security Policy korlátozások kezelésére).

Teljesítmény

Az Angular az évek során sokat fejlődött a teljesítmény terén. Az Angular 1 egy dirty checking néven ismert mechanizmust használt, amely hajlamos volt lelassulni, mivel folyamatosan diffelni kellett a nagy $scope struktúrákat. Az Angular 2 egy sablonváltozás-észlelési mechanizmust használ, amely sokkal jobban teljesít. Azonban még az Angular fejlesztései ellenére is a Mithril.js gyakran gyorsabb, mint az Angular, a Mithril.js kis kódbázisának köszönhetően, amelyet könnyebb auditálni.

Nehéz összehasonlítani az Angular és a Mithril.js betöltési idejét néhány okból. Az első az, hogy az Angular 1 és 2 valójában teljesen különböző kódbázisok, és mindkét verziót hivatalosan támogatják és karbantartják (és a vadonban lévő Angular kódbázisok túlnyomó többsége jelenleg is az 1-es verziót használja). A második ok az, hogy mind az Angular, mind a Mithril.js moduláris. Mindkét esetben lehetséges eltávolítani a keretrendszer jelentős részét, amelyet egy adott alkalmazás nem használ.

Mindezek ellenére a legkisebb ismert Angular 2 bundle egy 29kb-os hello world szabványos gzip használatával tömörítve (ez 35kb a standard gzip használatával), és az Angular legtöbb hasznos funkciójának eltávolításával. Összehasonlításképpen, egy Mithril.js hello world - beleértve a teljes Mithril.js core-t minden szükséges funkcióval - körülbelül 10kb lenne gzip-elve.

Ne feledd azt is, hogy az olyan keretrendszereket, mint az Angular és a Mithril.js, nem triviális alkalmazásokhoz tervezték, így egy olyan alkalmazásnak, amelynek sikerült az Angular összes API felületét használnia, több száz kb keretrendszerkódot kellene letöltenie, nem pedig csupán 29kb-ot.

Frissítési teljesítmény

A frissítési teljesítmény benchmarkolásához hasznos eszköz az Ember csapata által kifejlesztett DbMonster nevű eszköz. Olyan gyorsan frissít egy táblázatot, amennyire csak tud, és méri a képkockák számát másodpercenként (FPS) és a JavaScript időket (min, max és átlag). Az FPS számot nehéz értékelni, mivel az a böngésző újrarajzolási idejét és a setTimeout clamping késleltetését is tartalmazza, így a legértelmesebb szám, amit érdemes megnézni, az az átlagos renderelési idő. Összehasonlíthatod az Angular implementációt és a Mithril.js implementációt. Mindkét implementáció naiv (azaz nincs optimalizálás). A minták eredményei az alábbiakban láthatók:

Angular	Mithril.js
11.5 ms	6.4 ms

Komplexitás

Az Angular felülmúlja a Mithril.js-t az általa kínált eszközök mennyiségében (különböző direktívák és szolgáltatások formájában), de sokkal komplexebb is. Hasonlítsd össze az Angular API felületét a Mithril.js API felületével. Saját magad ítélheted meg, hogy melyik API önleíróbb és relevánsabb az igényeidhez.

Az Angular 2-ben sokkal több fogalmat kell megérteni: nyelvi szinten a Typescript az ajánlott nyelv, és ezen felül van még Angular-specifikus sablonszintaxis, mint például a kötések, a pipe-ok, a "safe navigator operator". Meg kell tanulnod az olyan architekturális fogalmakat is, mint a modulok, a komponensek, a szolgáltatások, a direktívák stb., és hogy mikor mit érdemes használni.

Tanulási görbe

Ha almát almával hasonlítunk össze, az Angular 2 és a Mithril.js hasonló tanulási görbével rendelkezik: mindkettőben a komponensek az architektúra központi elemei, és mindkettő rendelkezik megfelelő routing és XHR eszközökkel.

Mindezek ellenére az Angularban sokkal több fogalmat kell megtanulni, mint a Mithrilben. Sok dologhoz Angular-specifikus API-kat kínál, amelyek gyakran triviálisan implementálhatók (pl. a pluralizáció lényegében egy switch utasítás, a "kötelező" validáció egyszerűen egy egyenlőségvizsgálat stb.). Az Angular sablonok emellett több absztrakciós réteggel is rendelkeznek, hogy emulálják azt, amit a JavaScript natívan csinál a Mithrilben - az Angular ng-if/ngIf egy direktíva, amely egy egyedi parsert és compilert használ egy kifejezés string kiértékelésére és a lexikális hatókör emulálására... és így tovább. A Mithril.js általában sokkal átláthatóbb, és ezért könnyebb következtetni rá.

Dokumentáció

Az Angular 2 dokumentációja egy kiterjedt bevezető oktatóanyagot és egy másik oktatóanyagot is tartalmaz, amely egy alkalmazást implementál. Emellett különböző útmutatókat is tartalmaz a haladó fogalmakhoz, egy cheat sheet-et és egy stílus útmutatót. Sajnos jelenleg az API referencia sok kívánnivalót hagy maga után. Számos API vagy dokumentálatlan, vagy nem ad kontextust ahhoz, hogy mire lehet az API-t használni.

A Mithril.js dokumentációja bevezető oktatóanyagokat, oldalakat a haladó fogalmakról és egy kiterjedt API referencia szekciót is tartalmaz, amely tartalmaz bemeneti/kimeneti típusinformációkat, példákat a különböző gyakori használati esetekre, valamint tanácsokat a helytelen használat és az anti-patternek ellen. Tartalmaz egy gyorsreferenciát is a gyors referenciához.

A Mithril.js dokumentációja egyszerű, közvetlen megoldásokat is bemutat a valós alkalmazásokban előforduló gyakori használati esetekre, ahol helyénvaló tájékoztatni a fejlesztőt arról, hogy a webes szabványok mostanra felérhetnek a nagyobb, bejáratott könyvtárakkal.

Vue

A Vue egy az Angularhoz hasonló nézetkönyvtár.

A Vue és a Mithril.js között sok különbség van, de van néhány hasonlóságuk is:

• Mindkettő virtuális DOM-ot és lifecycle metódusokat használ
• Mindkettő komponenseken keresztül szervezi a nézeteket

A Vue 2 a Snabbdom egy forkját használja virtuális DOM rendszerként. Ezenkívül a Vue külön modulként eszközöket is biztosít a routinghoz és az állapotkezeléshez. A Vue nagyon hasonlít az Angularhoz, és hasonló direktíva rendszert, HTML-alapú sablonokat és logikai folyamat direktívákat biztosít. Abban különbözik az Angular-tól, hogy egy monkeypatching reaktív rendszert implementál, amely felülírja a natív metódusokat egy komponens adatfájában (míg az Angular 1 dirty checking-et és digest/apply ciklusokat használ hasonló eredmények eléréséhez). Az Angular 2-hez hasonlóan a Vue is függvényekké fordítja a HTML sablonokat, de a lefordított függvények inkább a Mithril.js vagy a React nézetekhez hasonlítanak, mint az Angular lefordított renderelő függvényeihez.

A Vue jelentősen kisebb, mint az Angular, ha almát almával hasonlítunk össze, de nem olyan kicsi, mint a Mithril.js (a Vue core körülbelül 23kb gzip-elve, míg a Mithril.js-ben az ezzel egyenértékű renderelő modul körülbelül 4kb gzip-elve). Mindkettő hasonló teljesítményjellemzőkkel rendelkezik, de a benchmarkok általában azt sugallják, hogy a Mithril.js valamivel gyorsabb.

Teljesítmény

Íme egy összehasonlítás a könyvtár betöltési idejéről, azaz az egyes keretrendszerek JavaScript kódjának elemzéséhez és futtatásához szükséges időről, úgy, hogy egy console.time() hívást adunk az első sorhoz, és egy console.timeEnd() hívást egy olyan szkript utolsó sorához, amely kizárólag keretrendszerkódból áll. Az olvasás megkönnyítése érdekében itt vannak a legjobb 20 eredmények, a naplózó kóddal manuálisan hozzáadva a csomagolt szkriptekhez, a fájlrendszerről futtatva, egy szerény 2010-es PC asztali gépen a Chrome-ban:

Vue	Mithril.js
21.8 ms	4.5 ms

A könyvtár betöltési ideje fontos azokban az alkalmazásokban, amelyek nem maradnak nyitva hosszú ideig (például bármi a mobilon), és nem javíthatók gyorsítótárazással vagy más optimalizálási technikákkal.

Frissítési teljesítmény

A frissítési teljesítmény benchmarkolásához hasznos eszköz az Ember csapata által kifejlesztett DbMonster nevű eszköz. Olyan gyorsan frissít egy táblázatot, amennyire csak tud, és méri a képkockák számát másodpercenként (FPS) és a JavaScript időket (min, max és átlag). Az FPS számot nehéz értékelni, mivel az a böngésző újrarajzolási idejét és a setTimeout clamping késleltetését is tartalmazza, így a legértelmesebb szám, amit érdemes megnézni, az az átlagos renderelési idő. Összehasonlíthatod a Vue implementációt és a Mithril.js implementációt. Mindkét implementáció naiv (azaz nincs optimalizálás). A minták eredményei az alábbiakban láthatók:

Vue	Mithril.js
9.8 ms	6.4 ms

Komplexitás

A Vue-t nagymértékben az Angular inspirálta, és sok Angular-hez hasonló funkciót tartalmaz (pl. direktívák, szűrők, kétirányú kötések, v-cloak). Emellett a React is hatással volt rá (pl. komponensek). A Vue 2.0-tól kezdve a sablonokat hyperscript/JSX szintaxissal is lehet írni (a single-file komponensek és a különböző webpack-alapú nyelvi transzpilációs pluginok mellett). A Vue kétirányú adatkötést és egy opcionális Redux-szerű állapotkezelő könyvtárat is biztosít, de az Angular-ral ellentétben nem biztosít stílus útmutatót. Az egy dolog sokféleképpen való megközelítése architekturális töredezettséget okozhat a hosszú élettartamú projektekben.

A Mithril.js sokkal kevesebb fogalmat tartalmaz, és általában komponensek és egy adatszint szempontjából szervezi az alkalmazásokat. A Mithril.js-ben minden komponens létrehozási stílus ugyanazt a vnode struktúrát adja ki, kizárólag natív JavaScript funkciók használatával. A nyelv használatának közvetlen következménye a kevesebb eszköz és az egyszerűbb projektbeállítás.

Dokumentáció

Mind a Vue, mind a Mithril.js jó dokumentációval rendelkezik. Mindkettő tartalmaz egy jó API referenciát példákkal, oktatóanyagokat a kezdéshez, valamint oldalakat a különböző haladó fogalmakról.

Azonban a Vue sokféleképpen való megközelítésének köszönhetően néhány dolog nem feltétlenül van megfelelően dokumentálva. Például a hyperscriptjüket nagymértékben elhallgatják.

A Mithril.js dokumentációja általában túlzottan alapos, ha egy téma a Mithril hatókörén kívül eső dolgokat érint. Például, ha egy téma egy harmadik féltől származó könyvtárat érint, a Mithril.js dokumentációja végigvezeti a harmadik féltől származó könyvtár telepítési folyamatán. A Mithril.js dokumentációja egyszerű, közvetlen megoldásokat is bemutat a valós alkalmazásokban előforduló gyakori használati esetekre, ahol helyénvaló tájékoztatni a fejlesztőt arról, hogy a webes szabványok mostanra felérhetnek a nagyobb, bejáratott könyvtárakkal.

A Mithril.js oktatóanyagai is sokkal több területet fednek le, mint a Vue oktatóanyagai: a Vue oktatóanyag egy egyszerű helyi todo listával fejeződik be, miután több oldalon keresztül bemutatta a nagy core API-ját. A Mithril.js 10 perces útmutatója az API-jának nagy részét lefedi, és még a valós alkalmazások kulcsfontosságú aspektusait is áttekinti, mint például az adatok lekérése egy szerverről és a routing. Ha ez nem lenne elég, van egy hosszabb, alaposabb oktatóanyag is.