Porównanie frameworków

Jeśli czytasz tę stronę, prawdopodobnie używałeś już innych frameworków do budowania aplikacji i chcesz się dowiedzieć, czy Mithril.js pomoże Ci efektywniej rozwiązywać problemy.

Dlaczego nie [wstaw ulubiony framework tutaj]?

Prawda jest taka, że większość nowoczesnych frameworków jest szybka, dobrze nadaje się do budowania złożonych aplikacji i jest łatwa w utrzymaniu, jeśli wiesz, jak ich efektywnie używać. Istnieją przykłady bardzo złożonych aplikacji produkcyjnych, które używają niemal każdego popularnego frameworka: Udemy używa Angulara, AirBnB używa Reacta, Gitlab używa Vue, Guild Wars 2 używa Mithril.js (tak, wewnątrz gry!). Oczywiście, wszystkie te frameworki są wysokiej jakości i nadają się do zastosowań produkcyjnych.

Z reguły, jeśli Twój zespół jest już mocno zaangażowany w inny framework/bibliotekę/stos technologii, bardziej sensowne jest, aby się go trzymać, chyba że Twój zespół uzna, że istnieje bardzo silny powód, aby uzasadnić kosztowną przebudowę.

Jeśli jednak zaczynasz coś nowego, rozważ wypróbowanie Mithril.js, choćby po to, aby zobaczyć, ile korzyści czerpią użytkownicy Mithril.js z kodu o rozmiarze poniżej 10 kB (po spakowaniu gzipem). Mithril.js jest używany przez wiele znanych firm (np. Vimeo, Nike, Fitbit) i zasila również duże platformy open-source (np. Lichess, Flarum).

Dlaczego warto używać Mithril.js?

W skrócie: Mithril.js jest pragmatyczny. Ten 10-minutowy przewodnik jest dobrym przykładem: tyle czasu zajmuje nauczenie się komponentów, XHR i routingu – i to jest mniej więcej odpowiednia ilość wiedzy potrzebna do budowania użytecznych aplikacji.

Mithril.js koncentruje się na efektywnym wykonywaniu istotnych zadań. Przesyłanie plików? Dokumentacja pokazuje, jak to zrobić. Uwierzytelnianie? Również udokumentowane. Animacje wyjścia? Proszę bardzo. Bez dodatkowych bibliotek, bez magii.

Porównania

React

React to biblioteka do tworzenia interfejsów użytkownika, utrzymywana przez Facebooka.

React i Mithril.js mają wiele wspólnych cech. Jeśli już nauczyłeś się Reacta, wiesz już prawie wszystko, czego potrzebujesz do budowania aplikacji za pomocą Mithril.

• Oba używają wirtualnego DOM, metod cyklu życia i uzgadniania opartego na kluczach (key-based reconciliation).
• Oba organizują interfejs użytkownika za pomocą komponentów.
• Oba używają JavaScript jako mechanizmu kontroli przepływu w widokach.

Najbardziej oczywistą różnicą między Reactem a Mithril.js jest ich zakres. React jest biblioteką interfejsu użytkownika, więc typowa aplikacja oparta na Reacie polega na bibliotekach firm trzecich do routingu, XHR i zarządzania stanem. Używanie podejścia zorientowanego na biblioteki pozwala programistom dostosować swój stos technologiczny (stack) do precyzyjnego dopasowania do ich potrzeb. Mniej elegancko można to ująć tak, że architektury oparte na Reacie mogą się bardzo różnić w zależności od projektu, a projekty te są o wiele bardziej narażone na przekroczenie rozmiaru 1 MB.

Mithril.js ma wbudowane moduły dla typowych potrzeb, takich jak routing i XHR, a przewodnik ilustruje idiomatyczne użycie. To podejście jest preferowane dla zespołów, które cenią spójność i łatwość wdrażania nowych członków zespołu.

Wydajność

Zarówno React, jak i Mithril.js kładą duży nacisk na wydajność renderowania, ale podchodzą do tego na różne sposoby. W przeszłości React miał dwie implementacje renderowania DOM (jedna używająca API DOM, a druga używająca innerHTML). Jego nadchodząca architektura Fiber wprowadza planowanie i priorytetyzację jednostek pracy. React ma również zaawansowany system kompilacji, który wyłącza różne kontrole i komunikaty o błędach dla wdrożeń produkcyjnych oraz różne optymalizacje specyficzne dla przeglądarek. Ponadto istnieje również kilka bibliotek zorientowanych na wydajność, które wykorzystują hook shouldComponentUpdate Reacta i właściwości szybkiego sprawdzania równości obiektów bibliotek struktur danych niezmienniczych (immutable data structure libraries), aby skrócić czas uzgadniania wirtualnego DOM. Ogólnie rzecz biorąc, podejście Reacta do wydajności polega na projektowaniu stosunkowo złożonych rozwiązań.

Mithril.js kieruje się zasadą "mniej znaczy więcej". Ma znacznie mniejszą, agresywnie zoptymalizowaną bazę kodu. Uzasadnienie jest takie, że mała baza kodu jest łatwiejsza do analizy i optymalizacji, co ostatecznie skutkuje uruchomieniem mniejszej ilości kodu.

Oto porównanie czasów ładowania bibliotek, czyli czasu potrzebnego na przeanalizowanie i uruchomienie kodu JavaScript dla każdego frameworka, poprzez dodanie wywołania console.time() w pierwszej linii i console.timeEnd() w ostatniej linii skryptu, który składa się wyłącznie z kodu frameworka. Dla ułatwienia, przedstawiamy najlepsze wyniki z 20 prób z kodem rejestrującym dodanym ręcznie do spakowanych skryptów, uruchomionych z systemu plików, w Chrome na standardowym komputerze stacjonarnym z 2010 roku:

React	Mithril.js
55.8 ms	4.5 ms

Czasy ładowania bibliotek mają znaczenie w aplikacjach, które nie pozostają otwarte przez długi czas (na przykład w przypadku aplikacji mobilnych) i nie można ich poprawić za pomocą buforowania lub innych technik optymalizacji.

Ponieważ jest to mikro-benchmark, zachęcamy do samodzielnego powtórzenia tych testów, ponieważ wyniki mogą być silnie uzależnione od sprzętu. Zauważ, że frameworki do bundle'owania, takie jak Webpack, mogą przenosić zależności przed wywołaniami timera, aby emulować statyczne rozwiązywanie modułów. Dlatego powinieneś albo skopiować kod ze skompilowanych plików CDN, albo otworzyć plik wyjściowy z biblioteki bundlera. Następnie ręcznie dodaj wywołania timera wysokiej rozdzielczości console.time i console.timeEnd do spakowanego skryptu. Unikaj używania new Date i performance.now, ponieważ te mechanizmy nie są tak dokładne statystycznie.

Dla Twojej wygody, oto wersja tego benchmarku dostosowana do używania CDN w Internecie: benchmark dla Reacta, a benchmark dla Mithril.js. Zauważ, że testujemy cały Mithril.js, a nie tylko moduł renderowania (który odpowiadałby zakresowi Reacta). Zauważ również, że ta konfiguracja oparta na CDN wiąże się z pewnymi obciążeniami związanymi z pobieraniem zasobów z pamięci podręcznej dysku (~2 ms na zasób). Z tych powodów liczby tutaj nie są całkowicie dokładne, ale powinny wystarczyć, aby zaobserwować, że szybkość inicjalizacji Mithril.js jest zauważalnie lepsza niż Reacta.

Oto nieco bardziej znaczący benchmark: pomiar czasu skryptowania dla utworzenia 10 000 divów (i 10 000 węzłów tekstowych). Ponownie, oto kod benchmarku dla Reacta i Mithril.js. Ich najlepsze wyniki są pokazane poniżej:

React	Mithril.js
99.7 ms	42.8 ms

Te liczby pokazują, że Mithril.js nie tylko inicjalizuje się znacznie szybciej, ale także może przetworzyć ponad 20 000 węzłów wirtualnego DOM, zanim React będzie gotowy do użycia.

Wydajność aktualizacji

Wydajność aktualizacji może być nawet ważniejsza niż wydajność pierwszego renderowania, ponieważ aktualizacje mogą występować wielokrotnie podczas działania aplikacji typu Single Page Application.

Przydatnym narzędziem do testowania wydajności aktualizacji jest narzędzie opracowane przez zespół Ember, zwane DbMonster. Aktualizuje ono tabelę tak szybko, jak to możliwe, i mierzy liczbę klatek na sekundę (FPS) i czasy JavaScript (min, max i średni). Liczbę FPS może być trudno ocenić, ponieważ obejmuje ona również czasy odświeżania przeglądarki i opóźnienie zaciskania setTimeout, więc najbardziej znaczącą liczbą do analizy jest średni czas renderowania. Możesz porównać implementację Reacta z implementacją Mithril.js. Obie implementacje są naiwne (tj. nie zawierają optymalizacji). Przykładowe wyniki są pokazane poniżej:

React	Mithril.js
12.1 ms	6.4 ms

Wydajność programowania

Inną rzeczą, o której należy pamiętać, jest to, że ponieważ React dodaje dodatkowe kontrole i pomocne komunikaty o błędach w trybie programowania, jest wolniejszy w programowaniu niż wersja produkcyjna używana do powyższych benchmarków. Aby to zilustrować, oto benchmark 10 000 węzłów z powyższego, używający wersji programistycznej Reacta.

Zamienniki typu drop-in

Istnieje kilka projektów które twierdzą o parzystości API z Reactem (niektóre za pośrednictwem bibliotek warstwy kompatybilności), ale nie są w pełni kompatybilne (np. obsługa PropType jest zwykle wycofywana, zdarzenia syntetyczne czasami nie są obsługiwane, a niektóre API mają inną semantykę). Zauważ, że biblioteki te zazwyczaj zawierają również własne funkcje, które nie są częścią oficjalnego API Reacta, co może stać się problematyczne w przyszłości, jeśli ktoś zdecyduje się wrócić do React Fiber.

Twierdzenia o małym rozmiarze pobierania (w porównaniu z Reactem) są dokładne, ale większość z tych bibliotek jest nieco większa niż moduł renderowania Mithril.js. Preact jest jedynym wyjątkiem.

Należy uważać na agresywne twierdzenia dotyczące wydajności, ponieważ benchmarki używane przez niektóre z tych projektów są znane jako nieaktualne i wadliwe (w tym sensie, że mogą być – i są – wykorzystywane). Boris Kaul (autor niektórych benchmarków) napisał szczegółowo o tym, jak manipuluje się benchmarkami. Inną rzeczą, o której należy pamiętać, jest to, że niektóre benchmarki agresywnie wykorzystują zaawansowane funkcje optymalizacji, a tym samym demonstrują potencjalną wydajność, tj. wydajność, która jest możliwa przy pewnych zastrzeżeniach, ale realistycznie mało prawdopodobna, chyba że aktywnie poświęcisz czas na przejrzenie całej bazy kodu, identyfikując kandydatów do optymalizacji i oceniając ryzyko regresji wynikające z zastrzeżeń dotyczących optymalizacji.

W duchu demonstrowania typowych charakterystyk wydajności, benchmarki przedstawione na tej stronie porównawczej są implementowane w sposób uczciwy i idiomatyczny (tj. tak, jak normalnie napisałbyś 99% swojego kodu) i nie wykorzystują sztuczek ani zaawansowanych optymalizacji, aby jeden lub drugi framework wyglądał sztucznie lepiej. Zachęcamy do wniesienia PR, jeśli uważasz, że jakakolwiek implementacja DbMonster tutaj mogłaby być napisana bardziej idiomatycznie.

Złożoność

Zarówno React, jak i Mithril.js mają stosunkowo małe powierzchnie API w porównaniu z innymi frameworkami, co pomaga złagodzić krzywą uczenia się. Jednak podczas gdy idiomatyczny Mithril.js można pisać bez utraty czytelności przy użyciu zwykłego ES5 i bez żadnych innych zależności, idiomatyczny React w dużym stopniu opiera się na złożonych narzędziach (np. Babel, wtyczka JSX itp.), a ten poziom złożoności często rozciąga się na popularne części jego ekosystemu, czy to w postaci rozszerzeń składni (np. niestandardowa składnia rozszerzania obiektów w Redux), architektur (np. te, które używają bibliotek danych niezmienniczych), czy też dzwonków i gwizdków (np. gorące przeładowanie modułów).

Chociaż złożone łańcuchy narzędzi są również możliwe w Mithril.js i innych frameworkach, zdecydowanie zaleca się przestrzeganie zasad KISS i YAGNI podczas korzystania z Mithril.

Krzywa uczenia się

Zarówno React, jak i Mithril.js mają stosunkowo łagodne krzywe uczenia się. Krzywa uczenia się Reacta polega głównie na zrozumieniu komponentów i ich cyklu życia. Krzywa uczenia się dla komponentów Mithril.js jest prawie identyczna. Oczywiście w Mithril.js jest więcej API do nauczenia się, ponieważ Mithril.js zawiera również routing i XHR, ale krzywa uczenia się byłaby dość podobna do uczenia się Reacta, React Routera i biblioteki XHR, takiej jak superagent lub axios.

Idiomatyczny React wymaga praktycznej znajomości JSX i jego specyfiki, dlatego istnieje również niewielka krzywa uczenia się związana z Babel.

Dokumentacja

Dokumentacja Reacta jest jasna i dobrze napisana i zawiera dobre odniesienie do API, samouczki dla początkujących, a także strony obejmujące różne zaawansowane koncepcje. Niestety, ponieważ React ogranicza się do bycia tylko biblioteką interfejsu użytkownika, jego dokumentacja nie bada, jak używać Reacta idiomatycznie w kontekście rzeczywistej aplikacji. W rezultacie istnieje wiele popularnych bibliotek zarządzania stanem, a zatem architektury używające Reacta mogą się drastycznie różnić w zależności od firmy (lub nawet między projektami).

Dokumentacja Mithril.js zawiera wprowadzające samouczki, strony o zaawansowanych koncepcjach i obszerną sekcję odniesienia do API, która zawiera informacje o typach wejścia/wyjścia, przykłady dla różnych typowych przypadków użycia i porady dotyczące unikania niewłaściwego użycia i antywzorców. Zawiera również arkusz z podpowiedziami do szybkiego odniesienia.

Dokumentacja Mithril.js demonstruje również proste, bliskie metalu rozwiązania dla typowych przypadków użycia w rzeczywistych aplikacjach, informując programistę, że standardy internetowe mogą być teraz na równi z większymi, ugruntowanymi bibliotekami.

Angular

Angular to framework aplikacji internetowych utrzymywany przez Google.

Angular i Mithril.js są dość różne, ale mają kilka podobieństw:

• Oba obsługują komponentyzację.
• Oba mają szereg narzędzi do różnych aspektów aplikacji internetowych (np. routing, XHR).

Najbardziej oczywista różnica między Angularem a Mithril.js polega na ich złożoności. Można to najłatwiej zobaczyć w sposobie implementacji widoków. Widoki Mithril.js to zwykły JavaScript, a kontrola przepływu odbywa się za pomocą wbudowanych mechanizmów JavaScript, takich jak operatory trójskładnikowe lub Array.prototype.map. Z drugiej strony, Angular implementuje system dyrektyw, aby rozszerzyć widoki HTML, tak aby można było oceniać wyrażenia podobne do JavaScript w atrybutach HTML i interpolacjach. Angular faktycznie zawiera parser i kompilator napisany w JavaScript, aby to osiągnąć. Jeśli to nie wydaje się wystarczająco złożone, istnieją w rzeczywistości dwa tryby kompilacji (tryb domyślny, który generuje funkcje JavaScript dynamicznie dla wydajności, oraz wolniejszy tryb do radzenia sobie z ograniczeniami Content Security Policy).

Wydajność

Angular poczynił ogromne postępy pod względem wydajności na przestrzeni lat. Angular 1 używał mechanizmu znanego jako dirty checking, który miał tendencję do spowalniania z powodu konieczności ciągłego porównywania dużych struktur $scope. Angular 2 używa mechanizmu wykrywania zmian szablonu, który jest znacznie wydajniejszy. Jednak nawet pomimo ulepszeń Angulara, Mithril.js jest często szybszy niż Angular, ze względu na łatwość audytu, jaką zapewnia mały rozmiar bazy kodu Mithril.js.

Trudno jest porównać czasy ładowania między Angularem a Mithril.js z kilku powodów. Pierwszym jest to, że Angular 1 i 2 są w rzeczywistości zupełnie różnymi bazami kodu, a obie wersje są oficjalnie obsługiwane i utrzymywane (a zdecydowana większość baz kodu Angulara w środowisku produkcyjnym nadal używa wersji 1). Drugim powodem jest to, że zarówno Angular, jak i Mithril.js są modułowe. W obu przypadkach można usunąć znaczną część frameworka, która nie jest używana w danej aplikacji.

Biorąc to pod uwagę, najmniejszy znany pakiet Angular 2 to 29kb hello world skompresowany algorytmem Brotli (to 35kb przy użyciu standardowego gzip), z usuniętą większością przydatnych funkcji Angulara. Dla porównania, Mithril.js hello world – w tym cały rdzeń Mithril.js z bateriami i wszystkim – miałby około 10kb po spakowaniu gzipem.

Pamiętaj również, że frameworki takie jak Angular i Mithril.js są przeznaczone dla nietrywialnych aplikacji, więc aplikacja, która zdołała użyć całej powierzchni API Angulara, musiałaby pobrać kilkaset kb kodu frameworka, a nie tylko 29kb.

Wydajność aktualizacji

Przydatnym narzędziem do testowania wydajności aktualizacji jest narzędzie opracowane przez zespół Ember, zwane DbMonster. Aktualizuje ono tabelę tak szybko, jak to możliwe, i mierzy liczbę klatek na sekundę (FPS) i czasy JavaScript (min, max i średni). Liczbę FPS może być trudno ocenić, ponieważ obejmuje ona również czasy odświeżania przeglądarki i opóźnienie zaciskania setTimeout, więc najbardziej znaczącą liczbą do analizy jest średni czas renderowania. Możesz porównać implementację Angulara i implementację Mithril.js. Obie implementacje są naiwne (tj. nie zawierają optymalizacji). Przykładowe wyniki są pokazane poniżej:

Angular	Mithril.js
11.5 ms	6.4 ms

Złożoność

Angular oferuje więcej narzędzi (w postaci różnych dyrektyw i usług) niż Mithril.js, ale jest również znacznie bardziej złożony. Porównaj powierzchnię API Angulara z powierzchnią API Mithril.js. Możesz sam ocenić, które API jest bardziej opisowe i bardziej odpowiednie dla Twoich potrzeb.

Angular 2 ma o wiele więcej koncepcji do zrozumienia: na poziomie języka zalecanym językiem jest Typescript, a ponadto istnieje również specyficzna dla Angulara składnia szablonów, taka jak powiązania, potoki, "bezpieczny operator nawigacji". Musisz także dowiedzieć się o koncepcjach architektonicznych, takich jak moduły, komponenty, usługi, dyrektywy itp. oraz o tym, gdzie i co należy użyć.

Krzywa uczenia się

Porównując jabłka z jabłkami, Angular 2 i Mithril.js mają podobne krzywe uczenia się: w obu przypadkach komponenty są centralnym aspektem architektury, a oba mają rozsądne narzędzia do routingu i XHR.

Biorąc to pod uwagę, Angular ma znacznie więcej koncepcji do nauczenia się niż Mithril. Oferuje specyficzne dla Angulara API dla wielu rzeczy, które często można łatwo zaimplementować (np. pluralizacja jest zasadniczo instrukcją switch, walidacja "wymagane" jest po prostu porównaniem równości itp.).

Szablony Angulara mają również kilka warstw abstrakcji, aby emulować to, co JavaScript robi natywnie w Mithril.js – ng-if/ngIf Angulara to dyrektywa, która używa niestandardowego parsera i kompilatora do oceny ciągu wyrażenia i emulacji zakresu leksykalnego... itd. Mithril.js jest zwykle o wiele bardziej przejrzysty, a zatem łatwiejszy do zrozumienia.

Dokumentacja

Dokumentacja Angular 2 zawiera obszerny samouczek wprowadzający oraz kolejny samouczek, który implementuje aplikację. Zawiera również różne przewodniki dotyczące zaawansowanych koncepcji, arkusz z podpowiedziami oraz przewodnik po stylach. Niestety, obecnie odniesienie do API pozostawia wiele do życzenia. Kilka interfejsów API jest albo nieudokumentowanych, albo brakuje im kontekstu, w jakim można by użyć API.

Dokumentacja Mithril.js zawiera wprowadzające samouczki, strony o zaawansowanych koncepcjach oraz obszerną sekcję odniesienia do API, która zawiera informacje o typach wejścia/wyjścia, przykłady dla różnych typowych przypadków użycia oraz porady dotyczące unikania niewłaściwego użycia i antywzorców. Zawiera również arkusz z podpowiedziami do szybkiego odniesienia.

Dokumentacja Mithril.js demonstruje również proste, bliskie metalu rozwiązania dla typowych przypadków użycia w rzeczywistych aplikacjach, informując programistę, że standardy internetowe mogą być teraz na równi z większymi, ugruntowanymi bibliotekami.

Vue

Vue to biblioteka interfejsu użytkownika podobna do Angulara.

Vue i Mithril.js mają wiele różnic, ale mają również pewne podobieństwa:

• Oba używają wirtualnego DOM i metod cyklu życia.
• Oba organizują interfejs użytkownika za pomocą komponentów.

Vue 2 używa forka Snabbdom jako systemu wirtualnego DOM. Ponadto Vue udostępnia również narzędzia do routingu i zarządzania stanem jako oddzielne moduły. Vue wygląda bardzo podobnie do Angulara i zapewnia podobny system dyrektyw, szablony oparte na HTML i dyrektywy przepływu logiki. Różni się od Angulara tym, że implementuje system reaktywny monkeypatching, który nadpisuje natywne metody w drzewie danych komponentu (podczas gdy Angular 1 używa dirty checking i cykli digest/apply, aby osiągnąć podobne wyniki). Podobnie jak Angular 2, Vue kompiluje szablony HTML do funkcji, ale skompilowane funkcje wyglądają bardziej jak widoki Mithril.js lub React, a nie skompilowane funkcje renderowania Angulara.

Vue zajmuje znacznie mniej miejsca niż Angular, porównując jabłka z jabłkami, ale nie tak mało jak Mithril.js (rdzeń Vue ma około 23kb po spakowaniu gzipem, podczas gdy równoważny moduł renderowania w Mithril.js ma około 4kb po spakowaniu gzipem). Oba mają podobne charakterystyki wydajności, ale benchmarki zwykle sugerują, że Mithril.js jest nieco szybszy.

Wydajność

Oto porównanie czasów ładowania bibliotek, czyli czasu potrzebnego na przeanalizowanie i uruchomienie kodu JavaScript dla każdego frameworka, poprzez dodanie wywołania console.time() w pierwszej linii i console.timeEnd() w ostatniej linii skryptu, który składa się wyłącznie z kodu frameworka. Dla ułatwienia, przedstawiamy najlepsze wyniki z 20 prób z kodem rejestrującym dodanym ręcznie do spakowanych skryptów, uruchomionych z systemu plików, w Chrome na standardowym komputerze stacjonarnym z 2010 roku:

Vue	Mithril.js
21.8 ms	4.5 ms

Czasy ładowania bibliotek mają znaczenie w aplikacjach, które nie pozostają otwarte przez długi czas (na przykład w przypadku aplikacji mobilnych) i nie można ich poprawić za pomocą buforowania lub innych technik optymalizacji.

Wydajność aktualizacji

Przydatnym narzędziem do testowania wydajności aktualizacji jest narzędzie opracowane przez zespół Ember, zwane DbMonster. Aktualizuje ono tabelę tak szybko, jak to możliwe, i mierzy liczbę klatek na sekundę (FPS) i czasy JavaScript (min, max i średni). Liczbę FPS może być trudno ocenić, ponieważ obejmuje ona również czasy odświeżania przeglądarki i opóźnienie zaciskania setTimeout, więc najbardziej znaczącą liczbą do analizy jest średni czas renderowania. Możesz porównać implementację Vue i implementację Mithril.js. Obie implementacje są naiwne (tj. nie zawierają optymalizacji). Przykładowe wyniki są pokazane poniżej:

Vue	Mithril.js
9.8 ms	6.4 ms

Złożoność

Vue jest silnie inspirowany Angularem i ma wiele rzeczy, które robi Angular (np. dyrektywy, filtry, powiązania dwukierunkowe, v-cloak), ale ma również rzeczy inspirowane Reactem (np. komponenty). Od Vue 2.0 można również pisać szablony przy użyciu składni hyperscript/JSX (oprócz komponentów jednoplikowych i różnych wtyczek transpilacji języka opartych na webpack). Vue zapewnia zarówno dwukierunkowe powiązanie danych, jak i opcjonalną bibliotekę zarządzania stanem podobną do Redux, ale w przeciwieństwie do Angulara nie zapewnia wytycznych dotyczących stylu. Podejście "wiele sposobów robienia jednej rzeczy" może powodować fragmentację architektury w długotrwałych projektach.

Mithril.js ma znacznie mniej koncepcji i zazwyczaj organizuje aplikacje w kategoriach komponentów i warstwy danych. Wszystkie style tworzenia komponentów w Mithril.js wyprowadzają tę samą strukturę vnode przy użyciu tylko natywnych funkcji JavaScript. Bezpośrednią konsekwencją polegania na języku jest mniejsza ilość narzędzi i prostsza konfiguracja projektu.

Dokumentacja

Zarówno Vue, jak i Mithril.js mają dobrą dokumentację. Oba zawierają dobre odniesienie do API z przykładami, samouczki dla początkujących, a także strony obejmujące różne zaawansowane koncepcje.

Jednak ze względu na podejście Vue "wiele sposobów robienia jednej rzeczy", niektóre rzeczy mogą nie być odpowiednio udokumentowane. Na przykład ich hyperscript jest mocno pomijany.

Dokumentacja Mithril.js jest zazwyczaj bardzo dokładna, nawet jeśli temat dotyczy kwestii spoza zakresu Mithril. Na przykład, gdy temat dotyczy biblioteki innej firmy, dokumentacja Mithril.js przeprowadza użytkownika przez proces instalacji biblioteki innej firmy. Dokumentacja Mithril.js często demonstruje również proste, bliskie metalu rozwiązania dla typowych przypadków użycia w rzeczywistych aplikacjach, informując programistę, że standardy internetowe mogą być teraz na równi z większymi, ugruntowanymi bibliotekami.

Samouczki Mithril.js obejmują również znacznie więcej niż samouczki Vue: samouczek Vue kończy się prostą lokalną listą zadań do wykonania, po przejściu przez kilka stron, aby omówić jego rozbudowane podstawowe API. 10-minutowy przewodnik Mithril.js obejmuje większość jego API, a także omawia kluczowe aspekty rzeczywistych aplikacji, takie jak pobieranie danych z serwera i routing. Jeśli to nie wystarczy, dostępny jest również dłuższy, bardziej szczegółowy samouczek.