Ciao, e benvenuto nella terza puntata della sessantesima stagione. Oggi torniamo dove WebAssembly è nato, il browser, e chiariamo un equivoco che ha accompagnato questa tecnologia fin dall'inizio. Molti pensano che sia arrivato per uccidere JavaScript. È esattamente il contrario. Oggi parliamo della corsia veloce del browser, e del perché WebAssembly è nato accanto a JavaScript.
Partiamo dal contesto, perché spiega il bisogno. Per più di vent'anni, il browser ha saputo eseguire un linguaggio solo: JavaScript. E JavaScript è un linguaggio straordinario, flessibile, adatto a costruire quasi qualunque cosa dentro una pagina. Ma ha una natura precisa: è fatto per essere scritto in fretta e interpretato al volo, e questo, per certi lavori, gli mette un tetto. Quando devi fare calcoli pesantissimi, come far girare un gioco complesso, montare un video, elaborare immagini in tempo reale, far girare una simulazione scientifica, quel tetto si sente. Non è colpa di JavaScript: è che nessuno strumento è nato per fare tutto.
Voglio dirti quale bisogno è emerso, perché è concreto. Serviva un modo, dentro il browser, per eseguire anche codice compilato e velocissimo, il tipo di codice che scrivi in linguaggi pensati per la prestazione pura. Fino a quel momento, se volevi quella potenza, dovevi uscire dal browser, installare un programma vero. Ma il web voleva portare quelle esperienze pesanti dentro la pagina, senza installare niente. Da qui nasce WebAssembly: come un modo per dare al browser una seconda marcia, una corsia veloce dedicata ai lavori che JavaScript, da solo, faticava a reggere.
Voglio chiarire subito la relazione, perché è il punto centrale. E qui sfatiamo l'equivoco. WebAssembly non è nato per sostituire JavaScript, ma per affiancarlo, e i due lavorano insieme, ognuno per ciò che sa fare meglio. JavaScript resta il direttore d'orchestra della pagina: gestisce l'interfaccia, risponde ai clic, orchestra il tutto, con la sua flessibilità impareggiabile. WebAssembly fa il lavoro sporco e pesante quando serve: prende il compito che richiede muscoli, lo esegue a gran velocità, e restituisce il risultato a JavaScript, che lo usa nella pagina. Non è una gara: è una divisione dei compiti.
Voglio darti l'immagine che rende chiara questa idea, perché la fissa. Pensa a una bottega artigiana. C'è l'artigiano generalista, abilissimo e versatile, che sa fare un po' di tutto: accoglie il cliente, prende le misure, monta i pezzi, rifinisce, gestisce l'intero lavoro. È indispensabile, ed è lui che tiene in mano la bottega. Ma quando arriva un blocco di marmo durissimo da tagliare con precisione millimetrica, l'artigiano non lo fa a mano: accende la macchina specializzata, quella potente e precisa che serve solo per quel taglio. Poi spegne la macchina e torna al suo lavoro versatile. JavaScript è l'artigiano generalista, WebAssembly è la macchina specializzata: nessuno dei due sostituisce l'altro, e insieme fanno cose che da soli non potrebbero.
Voglio essere onesto sul quando ha senso, perché non è sempre. Ma attenzione: questa corsia veloce non serve per tutto, anzi. Per la stragrande maggioranza di ciò che fa una pagina web, mostrare testi, gestire un modulo, rispondere a un pulsante, JavaScript da solo è perfetto, ed è anche più semplice. Tirare in ballo WebAssembly avrebbe senso solo per quei lavori davvero pesanti in calcolo, dove il muscolo in più ripaga la complessità in più. Usarlo per un compito leggero è come accendere quella macchina industriale per tagliare un foglio di carta: uno spreco, non un vantaggio. La corsia veloce è preziosa proprio perché la usi solo quando serve correre. E c'è un costo aggiuntivo, che vedremo meglio nella puntata sul confine: far dialogare i due mondi, quello di JavaScript e quello di WebAssembly, non è gratis, e per un compito minuto quel dialogo può costare più del tempo che ti fa risparmiare. Un motivo in più per riservare la corsia veloce ai lavori che pesano davvero.
Voglio darti la lezione generale, perché va oltre il browser. La lezione è che l'aggiunta di uno strumento potente non deve cancellare quello che c'era: spesso il valore sta nella collaborazione, non nella sostituzione. Il mondo della tecnologia ama le narrazioni da scontro, il nuovo che uccide il vecchio. Ma la realtà, quasi sempre, è più matura e più noiosa: il nuovo strumento trova il suo posto accanto agli altri, prendendosi la fetta di lavoro per cui è fatto, e lasciando il resto a chi lo faceva già bene. Chi capisce questo sceglie meglio, e non butta via strumenti validi inseguendo una moda.
Per oggi ci fermiamo qui. Abbiamo visto perché WebAssembly è nato nel browser, accanto a JavaScript. Per vent'anni il browser eseguiva un linguaggio solo, JavaScript: straordinario, ma con un tetto per i lavori pesantissimi, come giochi, video, simulazioni. Serviva una corsia veloce per il codice compilato, senza uscire dal browser né installare nulla. E la relazione è di collaborazione, non di scontro: JavaScript resta il direttore d'orchestra della pagina, WebAssembly fa il lavoro pesante quando serve e restituisce il risultato. Come l'artigiano generalista e la macchina specializzata. Con l'onestà del quando: per i lavori leggeri, JavaScript da solo basta e avanza. La lezione: spesso il valore è nella collaborazione, non nella sostituzione. Nella prossima puntata: il recinto, eseguire codice di cui non ti fidi. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.