Confronto tra i Framework
Se stai leggendo questa pagina, probabilmente hai già utilizzato altri framework per creare applicazioni e vuoi sapere se Mithril.js può aiutarti a risolvere i tuoi problemi in modo più efficace.
Perché non [inserisci il tuo framework preferito qui]?
In realtà, la maggior parte dei framework moderni sono veloci, adatti per creare applicazioni complesse e manutenibili se sai come usarli efficacemente. Esistono esempi di applicazioni altamente complesse che utilizzano praticamente ogni framework popolare: Udemy utilizza Angular, AirBnB utilizza React, GitLab utilizza Vue, Guild Wars 2 utilizza Mithril.js (sì, all'interno del gioco!). Chiaramente, questi sono tutti framework di qualità adatti alla produzione.
Come regola generale, se il tuo team ha già investito molto in un altro framework/libreria/stack, conviene attenersi a esso, a meno che il team non concordi che ci sia una ragione molto forte per giustificare una riscrittura costosa.
Tuttavia, se stai iniziando un nuovo progetto, considera di provare Mithril.js, almeno per capire quanto valore gli utenti di Mithril.js hanno ricevuto da meno di 10kb (compressi con gzip) di codice. Mithril.js è utilizzato da molte aziende ben note (ad esempio Vimeo, Nike, Fitbit) e alimenta anche grandi piattaforme open source (ad esempio Lichess, Flarum).
Perché usare Mithril.js?
In una frase: perché Mithril.js è pragmatico. Questa guida di 10 minuti ne è un buon esempio: è il tempo necessario per imparare componenti, XHR e routing - e questa è la quantità di conoscenza necessaria per creare applicazioni utili.
Mithril.js punta a svolgere un lavoro significativo in modo efficiente. Caricare file? La documentazione ti mostra come. Autenticazione? Documentata anche quella. Animazioni di uscita? Le trovi qui. Niente librerie aggiuntive, niente magia.
Confronti
React
React è una libreria per la visualizzazione mantenuta da Facebook.
React e Mithril.js condividono molte somiglianze. Se hai già imparato React, sai già quasi tutto ciò che ti serve per creare app con Mithril.
- Entrambi utilizzano il DOM virtuale, i metodi del ciclo di vita e la riconciliazione basata su chiavi.
- Entrambi organizzano le visualizzazioni tramite componenti.
- Entrambi utilizzano JavaScript come meccanismo di controllo del flusso all'interno delle visualizzazioni.
La differenza più ovvia tra React e Mithril.js è nella loro portata. React è una libreria di visualizzazione, quindi una tipica applicazione basata su React si affida a librerie di terze parti per il routing, XHR e la gestione dello stato. L'utilizzo di un approccio orientato alla libreria consente agli sviluppatori di personalizzare il proprio stack per soddisfare precisamente le proprie esigenze. Per dirla in modo meno elegante, le architetture basate su React possono variare enormemente da progetto a progetto e tali progetti hanno molte più probabilità di superare la dimensione di 1 MB.
Mithril.js ha moduli integrati per le necessità comuni come il routing e XHR, e la guida dimostra l'uso idiomatico corretto. Questo approccio è preferibile per i team che apprezzano la coerenza e la facilità di onboarding.
Performance
Sia React che Mithril.js danno molta importanza alle prestazioni di rendering, ma le affrontano in modi diversi. In passato React aveva due implementazioni di rendering DOM (una che utilizzava l'API DOM e una che utilizzava innerHTML). La sua imminente architettura Fiber introduce la pianificazione e la definizione delle priorità delle unità di lavoro. React ha anche un sofisticato sistema di build che disabilita vari controlli e messaggi di errore per le distribuzioni di produzione e varie ottimizzazioni per browser specifici. Inoltre, ci sono anche diverse librerie orientate alle prestazioni che sfruttano l'hook shouldComponentUpdate di React e le proprietà di controllo rapido dell'uguaglianza degli oggetti delle librerie di strutture dati immutabili per ridurre i tempi di riconciliazione del DOM virtuale. In generale, l'approccio di React alle prestazioni è quello di progettare soluzioni relativamente complesse.
Mithril.js segue la filosofia del "less-is-more" (meno è meglio). Ha un codebase sostanzialmente più piccolo e ottimizzato in modo aggressivo. La logica è che un codebase piccolo è più facile da controllare e ottimizzare, con conseguente riduzione del codice da eseguire.
Per facilitare la lettura, ecco i migliori risultati su 20 test, con codice di logging aggiunto manualmente agli script in bundle, eseguiti da filesystem su Chrome, su un PC desktop del 2010:
| React | Mithril.js |
|---|---|
| 55.8 ms | 4.5 ms |
I tempi di caricamento della libreria sono importanti nelle applicazioni che non rimangono aperte per lunghi periodi di tempo (ad esempio, qualsiasi cosa in ambito mobile) e non possono essere migliorati tramite la memorizzazione nella cache o altre tecniche di ottimizzazione.
Poiché questo è un micro-benchmark, ti invitiamo a replicare tu stesso questi test poiché l'hardware può influire notevolmente sui numeri. Tieni presente che i framework di bundling come Webpack possono spostare le dipendenze prima delle chiamate del timer per emulare la risoluzione statica dei moduli, quindi dovresti copiare il codice dai file CDN compilati o aprire il file di output dalla libreria del bundler e aggiungere manualmente le chiamate del timer ad alta risoluzione console.time e console.timeEnd allo script in bundle. Evita di utilizzare new Date e performance.now, poiché questi meccanismi non sono statisticamente accurati.
Per tua comodità, ecco una versione di quel benchmark adattata per utilizzare i CDN sul web: il benchmark per React è qui, e il benchmark per Mithril.js è qui. Si noti che stiamo confrontando l'intero Mithril.js piuttosto che confrontare solo il modulo di rendering (che sarebbe equivalente in ambito a React). Si noti inoltre che questa configurazione basata su CDN comporta alcuni overhead dovuti al recupero di risorse dalla cache del disco (~2ms per risorsa). Per questi motivi, i numeri qui non sono del tutto accurati, ma dovrebbero essere sufficienti per osservare che la velocità di inizializzazione di Mithril.js è notevolmente migliore di React.
Ecco un benchmark leggermente più significativo: misurare il tempo di scripting per la creazione di 10.000 div (e 10.000 nodi di testo). Ancora una volta, ecco il codice benchmark per React e Mithril.js. I loro migliori risultati sono mostrati di seguito:
| React | Mithril.js |
|---|---|
| 99.7 ms | 42.8 ms |
Questi numeri mostrano che Mithril.js non solo si inizializza più velocemente, ma può elaborare oltre 20.000 nodi DOM virtuali prima che React sia pronto.
Update performance
Le prestazioni di aggiornamento possono essere ancora più importanti delle prestazioni di primo rendering, poiché gli aggiornamenti possono verificarsi molte volte durante l'esecuzione di una Single Page Application.
Uno strumento utile per confrontare le prestazioni di aggiornamento è uno strumento sviluppato dal team di Ember chiamato DbMonster. Aggiorna una tabella il più velocemente possibile e misura i frame al secondo (FPS) e i tempi JavaScript (min, max e media). Il conteggio degli FPS può essere difficile da valutare poiché include anche i tempi di ridisegno del browser e il ritardo di clamping setTimeout, quindi il numero più significativo da esaminare è il tempo di rendering medio. Puoi confrontare un' implementazione React e un' implementazione Mithril.js. I risultati di esempio sono mostrati di seguito:
| React | Mithril.js |
|---|---|
| 12.1 ms | 6.4 ms |
Development performance
Inoltre, React è più lento in fase di sviluppo rispetto alla versione di produzione usata nei benchmark, perché aggiunge controlli extra e messaggi di errore utili. Per illustrare, ecco il benchmark di 10.000 nodi di cui sopra utilizzando la versione di sviluppo di React.
Drop-in replacements
Ci sono diversi progetti che affermano la parità API con React (alcuni tramite librerie di livello di compatibilità), ma non sono completamente compatibili (ad esempio, il supporto PropType è solitamente omesso, gli eventi sintetici a volte non sono supportati e alcune API hanno semantiche diverse). Si noti che queste librerie in genere includono anche funzionalità proprie che non fanno parte dell'API ufficiale di React, il che potrebbe diventare problematico in futuro se si decidesse di tornare a React Fiber.
Le affermazioni sulle dimensioni ridotte del download (rispetto a React) sono accurate, ma la maggior parte di queste librerie sono leggermente più grandi del modulo renderer di Mithril.js. Preact è l'unica eccezione.
Presta attenzione alle affermazioni eccessive sulle prestazioni, perché alcuni benchmark sono obsoleti o difettosi e quindi manipolabili. Boris Kaul (autore di alcuni dei benchmark) ha scritto in dettaglio su come i benchmark vengono manipolati. Un'altra cosa da tenere a mente è che alcuni benchmark utilizzano in modo aggressivo funzionalità di ottimizzazione avanzate e quindi dimostrano le prestazioni potenziali, ovvero le prestazioni che sono possibili date alcune avvertenze, ma realisticamente improbabili a meno che tu non dedichi attivamente del tempo a rivedere l'intero codebase identificando i candidati all'ottimizzazione e valutando i rischi di regressione portati dalle avvertenze di ottimizzazione.
Per mostrare le prestazioni tipiche, i benchmark sono implementati in modo semplice e idiomatico (come si scriverebbe normalmente il 99% del codice), senza trucchi o ottimizzazioni per favorire un framework rispetto all'altro. Ti invitiamo a contribuire con una PR se ritieni che qualsiasi implementazione di DbMonster qui possa essere scritta in modo più idiomatico.
Complexity
Sia React che Mithril.js hanno superfici API relativamente piccole rispetto ad altri framework, il che aiuta a facilitare la curva di apprendimento. Tuttavia, mentre Mithril.js idiomatico può essere scritto senza perdita di leggibilità utilizzando ES5 semplice e nessuna altra dipendenza, React idiomatico si affida fortemente a strumenti complessi (ad esempio Babel, plugin JSX, ecc.) e questo livello di complessità si estende frequentemente alle parti popolari del suo ecosistema, sia sotto forma di estensioni di sintassi (ad esempio, sintassi di spread di oggetti non standard in Redux), architetture (ad esempio, quelle che utilizzano librerie di dati immutabili) o campanelli e fischietti (ad esempio, hot module reloading).
Sebbene toolchain complesse siano possibili anche con Mithril.js e altri framework, è fortemente raccomandato seguire i principi KISS e YAGNI quando si utilizza Mithril.
Learning curve
Sia React che Mithril.js hanno curve di apprendimento relativamente brevi. La curva di apprendimento di React implica principalmente la comprensione dei componenti e del loro ciclo di vita. La curva di apprendimento per i componenti Mithril.js è quasi identica. Ci sono ovviamente più API da imparare in Mithril.js, poiché Mithril.js include anche routing e XHR, ma la curva di apprendimento sarebbe abbastanza simile all'apprendimento di React, React Router e una libreria XHR come superagent o axios.
React idiomatico richiede la conoscenza pratica di JSX e delle sue avvertenze, e quindi anche di Babel.
Documentation
La documentazione di React è chiara e ben scritta e include un buon riferimento API, tutorial per iniziare, nonché pagine che trattano vari concetti avanzati. Sfortunatamente, poiché React è limitato a essere solo una libreria di visualizzazione, la sua documentazione non esplora come utilizzare React in modo idiomatico nel contesto di un'applicazione reale. Di conseguenza, ci sono molte librerie di gestione dello stato popolari e quindi le architetture che utilizzano React possono differire drasticamente da azienda ad azienda (o anche tra progetti).
La documentazione di Mithril.js include tutorial introduttivi, tutorial, pagine su concetti avanzati e un'ampia sezione di riferimento API, che include informazioni sul tipo di input/output, esempi per vari casi d'uso comuni e consigli contro l'uso improprio e gli anti-pattern. Include anche un promemoria per una rapida consultazione.
La documentazione di Mithril.js mostra anche soluzioni semplici e dirette per casi d'uso comuni, evidenziando come gli standard web moderni possano competere con librerie più consolidate.
Angular
Angular è un framework per applicazioni web mantenuto da Google.
Angular e Mithril.js sono abbastanza diversi, ma condividono alcune somiglianze:
- Entrambi supportano la componentizzazione.
- Entrambi hanno una serie di strumenti per vari aspetti delle applicazioni web (ad esempio, routing, XHR).
La differenza più ovvia tra Angular e Mithril.js è nella loro complessità. Questo può essere visto più facilmente in come vengono implementate le visualizzazioni. Le visualizzazioni Mithril.js sono JavaScript semplice e il controllo del flusso viene eseguito con meccanismi integrati di JavaScript come operatori ternari o Array.prototype.map. Angular, d'altra parte, implementa un sistema di direttive per estendere le visualizzazioni HTML in modo che sia possibile valutare espressioni simili a JavaScript all'interno di attributi HTML e interpolazioni. Angular include un parser e un compilatore scritti in JavaScript proprio per questo scopo. Se ciò non sembra abbastanza complesso, ci sono in realtà due modalità di compilazione (una modalità predefinita che genera dinamicamente funzioni JavaScript per le prestazioni e una modalità più lenta per affrontare le restrizioni della Content Security Policy).
Performance
Angular ha fatto molti progressi in termini di prestazioni nel corso degli anni. Angular 1 utilizzava un meccanismo noto come dirty checking che tendeva a rallentare a causa della necessità di differenziare costantemente grandi strutture $scope. Angular 2 utilizza un meccanismo di rilevamento delle modifiche del modello che è molto più performante. Tuttavia, anche nonostante i miglioramenti di Angular, Mithril.js è spesso più veloce di Angular, a causa della facilità di controllo che le piccole dimensioni del codebase di Mithril.js offrono.
È difficile fare un confronto dei tempi di caricamento tra Angular e Mithril.js per un paio di motivi. Il primo è che Angular 1 e 2 sono in realtà codebase completamente diversi ed entrambe le versioni sono ufficialmente supportate e mantenute (e la stragrande maggioranza dei codebase Angular in circolazione attualmente utilizza ancora la versione 1). Il secondo motivo è che sia Angular che Mithril.js sono modulari. In entrambi i casi, è possibile rimuovere una parte significativa del framework che non viene utilizzata in una determinata applicazione.
Detto questo, il più piccolo bundle Angular 2 conosciuto è un hello world da 29kb compresso con l'algoritmo Brotli (sono 35kb utilizzando la compressione gzip standard) e con la maggior parte delle funzionalità utili di Angular rimosse. In confronto, un hello world di Mithril.js - incluso l'intero core di Mithril.js con batterie e tutto il resto - sarebbe di circa 10kb compresso con gzip.
Inoltre, ricorda che framework come Angular e Mithril.js sono progettati per applicazioni non banali, quindi un'applicazione che è riuscita a utilizzare tutta la superficie API di Angular dovrebbe scaricare diverse centinaia di kb di codice framework, piuttosto che semplicemente 29kb.
Update performance
Uno strumento utile per confrontare le prestazioni di aggiornamento è uno strumento sviluppato dal team di Ember chiamato DbMonster. Aggiorna una tabella il più velocemente possibile e misura i frame al secondo (FPS) e i tempi JavaScript (min, max e media). Il conteggio degli FPS può essere difficile da valutare poiché include anche i tempi di ridisegno del browser e il ritardo di clamping setTimeout, quindi il numero più significativo da esaminare è il tempo di rendering medio. Puoi confrontare un' implementazione Angular e un' implementazione Mithril.js. Entrambe le implementazioni sono semplici (ovvero, nessuna ottimizzazione). I risultati di esempio sono mostrati di seguito:
| Angular | Mithril.js |
|---|---|
| 11.5 ms | 6.4 ms |
Complexity
Angular è superiore a Mithril.js nella quantità di strumenti che offre (sotto forma di varie direttive e servizi), ma è anche molto più complesso. Confronta la superficie API di Angular con quella di Mithril.js. Valuta tu stesso quale API è più auto-descrittiva e adatta alle tue esigenze.
Angular 2 ha molti più concetti da capire: a livello di linguaggio, TypeScript è il linguaggio raccomandato e, inoltre, c'è anche la sintassi del modello specifica di Angular come binding, pipe, "safe navigator operator". Devi anche imparare concetti architetturali come moduli, componenti, servizi, direttive, ecc. e dove è appropriato usare cosa.
Learning curve
Se confrontiamo mele con mele, Angular 2 e Mithril.js hanno curve di apprendimento simili: in entrambi, i componenti sono un aspetto centrale dell'architettura ed entrambi hanno strumenti di routing e XHR ragionevoli.
Detto questo, Angular ha molti più concetti da imparare rispetto a Mithril. Offre API specifiche di Angular per molte cose che spesso possono essere implementate banalmente (ad esempio, la pluralizzazione è essenzialmente un'istruzione switch, la convalida "richiesta" è semplicemente un controllo di uguaglianza, ecc.). I modelli Angular hanno anche diversi livelli di astrazioni per emulare ciò che JavaScript fa nativamente in Mithril.js - ng-if/ngIf di Angular è una direttiva, che utilizza un parser e un compilatore personalizzati per valutare una stringa di espressione ed emulare lo scoping lessicale... e così via. Mithril.js tende ad essere molto più trasparente e quindi più facile da comprendere.
Documentation
La documentazione di Angular 2 fornisce un ampio tutorial introduttivo e un altro tutorial che implementa un'applicazione. Ha anche varie guide per concetti avanzati, un promemoria e una guida di stile. Sfortunatamente, al momento, il riferimento API lascia molto a desiderare. Diverse API non sono documentate o non forniscono alcun contesto per cosa potrebbe essere utilizzata l'API.
La documentazione di Mithril.js include tutorial introduttivi, tutorial, pagine su concetti avanzati e un'ampia sezione di riferimento API, che include informazioni sul tipo di input/output, esempi per vari casi d'uso comuni e consigli contro l'uso improprio e gli anti-pattern. Include anche un promemoria per una rapida consultazione.
La documentazione di Mithril.js mostra anche soluzioni semplici e dirette per casi d'uso comuni, evidenziando come gli standard web moderni possano competere con librerie più consolidate.
Vue
Vue è una libreria di visualizzazione simile ad Angular.
Vue e Mithril.js hanno molte differenze, ma condividono anche alcune somiglianze:
- Entrambi utilizzano il DOM virtuale e i metodi del ciclo di vita.
- Entrambi organizzano le visualizzazioni tramite componenti.
Vue 2 utilizza un fork di Snabbdom come sistema DOM virtuale. Inoltre, Vue fornisce anche strumenti per il routing e la gestione dello stato come moduli separati. Vue sembra molto simile ad Angular e fornisce un sistema di direttive simile, modelli basati su HTML e direttive di flusso logico. Si differenzia da Angular in quanto implementa un sistema reattivo di monkeypatching che sovrascrive i metodi nativi nell'albero dei dati di un componente (mentre Angular 1 utilizza il dirty checking e i cicli di digest/apply per ottenere risultati simili). Simile ad Angular 2, Vue compila i modelli HTML in funzioni, ma le funzioni compilate assomigliano più alle visualizzazioni Mithril.js o React, piuttosto che alle funzioni di rendering compilate di Angular.
Vue è significativamente più piccolo di Angular quando si confrontano mele con mele, ma non così piccolo come Mithril.js (il core di Vue è di circa 23kb compresso con gzip, mentre il modulo di rendering equivalente in Mithril.js è di circa 4kb compresso con gzip). Entrambi hanno caratteristiche di prestazioni simili, ma i benchmark di solito suggeriscono che Mithril.js è leggermente più veloce.
Performance
Per facilitare la lettura, ecco i migliori risultati su 20 test, con codice di logging aggiunto manualmente agli script in bundle, eseguiti da filesystem su Chrome, su un PC desktop del 2010:
| Vue | Mithril.js |
|---|---|
| 21.8 ms | 4.5 ms |
I tempi di caricamento della libreria sono importanti nelle applicazioni che non rimangono aperte per lunghi periodi di tempo (ad esempio, qualsiasi cosa in ambito mobile) e non possono essere migliorati tramite la memorizzazione nella cache o altre tecniche di ottimizzazione.
Update performance
Uno strumento utile per confrontare le prestazioni di aggiornamento è uno strumento sviluppato dal team di Ember chiamato DbMonster. Aggiorna una tabella il più velocemente possibile e misura i frame al secondo (FPS) e i tempi JavaScript (min, max e media). Il conteggio degli FPS può essere difficile da valutare poiché include anche i tempi di ridisegno del browser e il ritardo di clamping setTimeout, quindi il numero più significativo da esaminare è il tempo di rendering medio. Puoi confrontare un' implementazione Vue e un' implementazione Mithril.js. Entrambe le implementazioni sono semplici (ovvero, nessuna ottimizzazione). I risultati di esempio sono mostrati di seguito:
| Vue | Mithril.js |
|---|---|
| 9.8 ms | 6.4 ms |
Complexity
Vue è fortemente ispirato ad Angular e ha molte cose che Angular fa (ad esempio, direttive, filtri, binding bidirezionali, v-cloak), ma ha anche cose ispirate a React (ad esempio, componenti). A partire da Vue 2.0, è anche possibile scrivere modelli utilizzando la sintassi hyperscript/JSX (oltre ai componenti in file singoli e ai vari plugin di transpilazione del linguaggio basati su webpack). Vue fornisce sia il data binding bidirezionale sia una libreria di gestione dello stato opzionale simile a Redux, ma a differenza di Angular, non fornisce alcuna guida di stile. Questa flessibilità può portare a frammentazione architetturale in progetti a lungo termine.
Mithril.js ha molti meno concetti e in genere organizza le applicazioni in termini di componenti e un livello di dati. Tutti gli stili di creazione dei componenti in Mithril.js producono la stessa struttura vnode utilizzando solo funzionalità JavaScript native. La conseguenza diretta dell'appoggiarsi al linguaggio è meno strumenti e una configurazione del progetto più semplice.
Documentation
Sia Vue che Mithril.js hanno una buona documentazione. Entrambi includono un buon riferimento API con esempi, tutorial per iniziare, nonché pagine che trattano vari concetti avanzati.
Tuttavia, a causa dell'approccio "molti modi di fare una cosa" di Vue, alcune cose potrebbero non essere adeguatamente documentate. Ad esempio, il loro hyperscript è pesantemente glossato.
La documentazione di Mithril.js tende ad essere molto dettagliata, anche quando un argomento esula dall'ambito del framework. Ad esempio, quando un argomento coinvolge una libreria di terze parti, la documentazione di Mithril.js illustra il processo di installazione per la libreria di terze parti. La documentazione di Mithril.js mostra anche soluzioni semplici e dirette per casi d'uso comuni, evidenziando come gli standard web moderni possano competere con librerie più consolidate.
I tutorial di Mithril.js coprono anche molti più argomenti di quelli di Vue: il tutorial di Vue termina con una semplice todo list locale, dopo aver esaminato diverse pagine per coprire la sua ampia API principale. La guida di 10 minuti di Mithril.js copre la maggior parte della sua API e analizza anche gli aspetti chiave delle applicazioni reali, come il recupero di dati da un server e il routing. Se ciò non bastasse, c'è anche un tutorial più lungo e approfondito.