Un confronto reale tra frame front-end e benchmark

Foto di delfi de la Rua su Unsplash
AGGIORNAMENTO: esiste una versione più recente di questo articolo

Negli ultimi due anni abbiamo assistito a un'esplosione di framework front-end. Ognuno di loro è più che in grado di creare fantastiche applicazioni Web. Quindi, come confrontare e decidere quale utilizzare per il tuo prossimo progetto?

Prima di tutto, per fare un confronto significativo abbiamo bisogno di alcune cose:

  1. Real World App - Qualcosa di più di un "todo". Di solito i "todos" non trasmettono conoscenza e prospettiva per costruire effettivamente applicazioni reali.
  2. Standardizzato: un progetto conforme a determinate regole. Ospitato nello stesso posto, fornisce un'API back-end, markup statico, stili e specifiche.
  3. Scritto da un esperto - Un progetto coerente e reale, che idealmente un esperto in quella tecnologia avrebbe costruito. Questo è vero, almeno per la maggior parte del tempo (vedi sotto).

Quindi, come possiamo ottenere un tale progetto? La buona notizia è che Eric Simons ha già creato un progetto RealWorld. È un clone della piattaforma di blog media. Ogni implementazione di questo progetto utilizza la stessa struttura HTML, CSS e specifiche API, ma una libreria / struttura diversa. Quando si tratta di conoscenze specialistiche, è vero per la maggior parte del tempo. Ho scritto un'implementazione in ClojureScript e ri-frame e non mi considero un esperto. A mia difesa, un esperto ha esaminato il mio codice, grazie Daniel Compton.

Ora abbiamo una specifica di base, abbiamo bisogno di un set standard di test / metriche per confrontarli.

  1. Prestazione. Quanto tempo impiega questa App per mostrare i contenuti e diventare utilizzabili?
  2. Taglia. Quanto è grande l'app? Confronteremo solo le dimensioni del JavaScript compilato. Il CSS è comune a tutte le varianti e viene scaricato da una rete CDN (Content Delivery Network). L'HTML è comune anche a tutte le varianti. Tutte le tecnologie vengono compilate o traspilate in JavaScript, pertanto dimensioniamo solo questo file.
  3. Linee di codice. Di quante righe di codice aveva bisogno l'autore per creare l'app RealWorld in base alle specifiche? Ad essere onesti alcune app hanno un po 'più di campane e fischietti, ma non dovrebbero avere un impatto significativo. L'unica cartella che quantificiamo è src / in ogni app.

Al momento della stesura (dicembre 2017) il progetto RealWorld è disponibile nei seguenti framework:

  • Reagire / Redux
  • Olmo
  • Angolare 4+
  • Angolare 1.5+
  • React / MobX
  • Crizmas MVC
  • CLSJ Keechma
  • AppRun
  • Ri-frame CLJS (Questo è quello che ho fatto. Non è ancora elencato al RealWorld Project).

Metrica n. 1: prestazioni

Primo test di verniciatura significativo con Lighthouse Audit fornito con Chrome.

Prima dipingi, migliore è l'esperienza per la persona che utilizza l'app. Lighthouse misura anche First interattivo, ma era quasi identico per la maggior parte delle app.

Prima vernice significativa (ms) - inferiore è meglio

Metrica n. 2: dimensioni

Le dimensioni del trasferimento provengono dalla scheda Rete Chrome. Intestazioni di risposta GZIPed più il corpo di risposta, come fornito dal server.

File più piccolo = download più veloce e meno da analizzare.

Ciò dipende dalle dimensioni del framework, da eventuali dipendenze extra aggiunte e dalla capacità dello strumento di creazione di creare un piccolo pacchetto.

Dimensione di trasferimento (KB): inferiore è meglio

Metrica n. 3: righe di codice

Usando cloc contiamo le righe di codice nella cartella src di ogni repository. Le righe vuote e di commento non fanno parte di questo calcolo. Perché è significativo?

Se il debug è il processo di rimozione dei bug del software, la programmazione deve essere il processo per inserirli - Edsger Dijkstra

Meno righe di codice hai la probabilità minore di un errore e una base di codice più piccola da mantenere.

# Linee di codice: meno è meglio

Conclusione

Prestazione

Questo è un confronto RealWorld e non un punto di riferimento nel vuoto. I test sono stati effettuati fuori dall'Europa (Svizzera). Tutte le app sono state ospitate su Github. I valori possono differire per te, il che va bene. I test sono stati eseguiti un paio di volte per ogni app, quindi mediati e arrotondati. I risultati sono stati piuttosto lineari se confrontati durante il giorno. La maggior parte delle librerie / framework sono nella gamma di eccellente e buono. Non vedrai molte differenze quando si tratta di prestazioni.

Taglia

Le dimensioni del pacchetto per ogni app sono sempre le stesse. Stiamo confrontando implementazioni simili e osserviamo come differiscono le dimensioni del pacchetto. AppRun è pazzo! Ho guardato un paio di volte perché non ci potevo credere. Elm sta facendo un ottimo lavoro quando si tratta di dimensioni del bundle e soprattutto quando si guardano le righe di codice.

Dimensione del bundle AppRun 18,7 KB

Linee di codice

Questo ha il maggiore impatto su di te come sviluppatore di software. Più righe di codice, più è necessario digitare e più da mantenere. Ci sono alcuni compromessi qui. Soprattutto quando si tratta di linguaggi tipizzati vs. linguaggi dinamici. I tipi ti offrono più sicurezza e hanno un costo, più cose da scrivere.

Digitato vs. dinamico

Digitato: Elm, Angular 4+ e AppRun.

Dinamica: Reagisci | Redux, Angular 1.5, React | Ri-frame di MobX, Crizmas MVC, CLJS Keechma e CLJS.

Quindi qual è la migliore? Non è meglio o peggio, è diverso. Come TDD (Test Driven Development), alcune persone lo adorano, altri lo odiano. Puoi sviluppare un software eccezionale con o senza di esso: scegli quello che fa per te.

Dove sono Vue, Preact, Ember, Svelte, Aurelia e altri?

Sembra che siano in ritardo alla festa, ma non preoccuparti. Farò un altro giro quando li avremo. Ci sono già problemi aperti: considera di contribuire! Oppure inizia da zero e apri un nuovo numero.

Parola finale

Questo confronto è esattamente quello che dice. Confronta diverse implementazioni di applicazioni Web simili nel mondo reale. Lo so, non è perfetto. Si differenzia in base al carico del server, al traffico di rete e a molte altre cose che accadono nel mondo reale.

Grazie a Daniel Compton per la correzione di bozze.

Se ti è piaciuto questo articolo e vuoi essere informato quando rilascerò un articolo simile, considera di seguirmi su Medium e Twitter.