I risultati del benchmark per Next.js 12 sono convincenti. Ma vale la pena cambiare?

Al nostro recente evento di team building, ho tenuto un discorso sul motivo per cui gli sviluppatori JavaScript stanno spostando i loro strumenti su Rust. È stato un discorso molto ben accolto e abbiamo deciso che sarebbe stato bello condividerlo con il mondo. Quindi eccolo qui. Questa è la versione modificata del discorso, scritta per la lettura e ci sarà uno screencast sul nostro canale Podcast. Quindi tuffiamoci direttamente dentro.

Sfondo

Una tendenza comune nel software è quella di scrivere gli strumenti che noi sviluppatori utilizziamo per creare le nostre applicazioni nello stesso linguaggio che utilizziamo per creare le applicazioni. Ad esempio, pip è scritto in Python, Composer è scritto in PHP, Maven in Java, ecc. Questo ha senso perché la maggior parte delle volte le persone che creano gli strumenti sono anche quelle che li usano. Quindi è più facile lavorare solo nella loro lingua preferita.

JavaScript non fa eccezione. Da Gulp e Bower a babel e Webpack abbiamo scritto tutto in JavaScript. Questo ha funzionato bene per noi, ma ci sono stati alcuni problemi.

Il problema con JavaScript

Per vedere il problema dobbiamo guardare le proprietà di JavaScript. JavaScript è un linguaggio di scripting leggero per le pagine Web. Sicuramente ora lo usiamo ovunque, dai back-end ai database, ma originariamente è stato creato per rendere prima le pagine brillanti e poi tutto il resto, il che dimostra.

È un linguaggio interpretato che può essere compilato just-in-time ed è a thread singolo. Sì, sì, conosco la creazione di più istanze e la comunicazione con i web worker... ma secondo me non è multi-threading, è una strana soluzione voodoo che cerca di distrarci dal fatto che non abbiamo il multi-threading nativo .

Un problema più grande è che è piuttosto lento sulla console, rispetto ad altre lingue.

Mentre JavaScript è fantastico su una pagina, fa schifo su una console.

Quindi un giorno un gruppo di sviluppatori JavaScript si è riunito in una stanza buia e dopo aver bevuto troppo qualcuno ha detto:

"Ehi ragazzi, e se... ascoltatemi... e se non scrivessimo gli strumenti che costruiscono il nostro JavaScript, in JavaScript?"

C'è stato un sussulto collettivo, sono state lanciate sedie, sono scoppiate risse e dopo che la polvere si è calmata, tutti hanno accettato di provarlo.

Ok, potrei averlo inventato ma il risultato è sempre lo stesso, ora stiamo realizzando strumenti di compilazione JavaScript in linguaggi diversi da JavaScript.

Ma perché ruggine?

In una parola... velocità e overflow del buffer .

Rust è un linguaggio di programmazione multi-paradigma e generico progettato per prestazioni e sicurezza. È come C++ ma per millennial e zoomer. È un linguaggio di sistema che impone la sicurezza della memoria e ha una concorrenza "sicura". È sintatticamente simile al C++ e, cosa più importante, è veloce quasi quanto il C++.

Reclami promettenti

Ci sono un certo numero di progetti ora che cercano di sostituire gli strumenti JavaScript con quelli basati su Rust. Alcuni esempi sono ParcelJS, Deno, ESBuild e Speedy Web Compiler (SWC). Tutti affermano di funzionare più velocemente di qualunque cosa stiano cercando di sostituire e se vuoi una risatina dai un'occhiata al confronto esbuild .

Per questo post, non li esaminerò tutti, ma darò un'occhiata più da vicino a SWC tramite Next.js.

Compilatore Web veloce (SWC)

SWC è una piattaforma estendibile basata su Rust per la prossima generazione di strumenti di sviluppo veloci. Ciò significa che è un framework per costruire costruttori. Puoi utilizzare SWC sia per la compilazione che per il raggruppamento. Richiederà file JavaScript / TypeScript utilizzando le moderne funzionalità JavaScript e sputerà codice valido supportato da tutti i principali browser.

Gli ultimi strumenti di Next.js Rusty

Next.js ha introdotto un compilatore Rust nella versione 12 basato su SWC. Sul sito Next.js hanno affermato di aggiornare localmente ~ 3 volte più velocemente e build di produzione ~ 5 volte più veloci.

Mi sembra un'affermazione verificabile. Quindi l'ho testato.

Ho creato esattamente lo stesso progetto nelle versioni 11 e 12 e ho aggiunto gli stessi 400 componenti generati. Ho usato React Benchmark Generator per questo. L'unica differenza tra i progetti era la versione di Next.js, tutto il resto era identico.

I risultati sono stati piuttosto convincenti. Ecco per Next.js 11:

E per Next.js 12, ecco qua:

Next.js 12, ha impiegato 12 secondi per fare ciò che Next.js 11 ha fatto in 1 minuto e 40 secondi. È circa 8 volte più veloce. Quindi chiaramente non stavano esagerando.

Inoltre, non mi aspettavo che Next.js 12 impiegasse 12 secondi. Immagino sia stata una felice coincidenza.

Vale la pena l'hype?

Ora la domanda ovvia è: ne vale la pena?

L'applicazione che stiamo costruendo alla fine della giornata è la stessa, giusto? Questo non cambia l'esperienza dell'utente finale ma solo l'esperienza dello sviluppatore, quindi perché preoccuparsi? Perché aggiustare qualcosa che stava già funzionando bene?

Perché non funzionava bene. Come ho detto prima, JavaScript è fantastico su una pagina ma fa schifo su una console. Le macchine degli sviluppatori sono bestie potenti e non utilizzare questo potere è un terribile spreco. È anche uno spreco costoso.

Immagina di essere in un team di 20 sviluppatori che lavorano su un grande progetto che viene distribuito e testato su un CI basato su cloud. Ogni giorno ogni membro del tuo team distribuisce più correzioni e funzionalità, ecco cosa è probabile che accada.

Se il tuo CI offre build simultanee illimitate ma si addebita in base al minuto di build o ai secondi del tempo del processore, Next.js ti costerà letteralmente 8 volte di più rispetto a Next.js 12.

D'altra parte, se fornisce un prezzo fisso e un numero fisso di build simultanee, dovrai aspettare un po' se la tua coda di build cresce o dovrai pagare per aumentare il numero di build simultanee che puoi eseguire.

Ad ogni modo, le build lente ti costano di più in tempo o denaro, o entrambi.

Conclusione

JavaScript è un linguaggio straordinario e Internet non sarebbe dov'è senza di esso. Ma non dobbiamo usarlo per costruire i nostri strumenti perché ci sono linguaggi più difficili, migliori, più veloci e più forti per questo, come Rust, e va bene così. Non toglie nulla a JavaScript e non è un tradimento abbandonare gli strumenti costruiti basati su JavaScript per quelli più veloci basati su Rust. E ammettiamolo, non soffrirò di più istanze JavaScript solo per ottenere il multi-threading voodoo.