WebAssembly · compilazione · macchine virtuali
Che cos’è WebAssembly, esattamente?
L’equivoco più diffuso su WebAssembly è credere che sia un linguaggio da scrivere. Non lo è. La definizione ufficiale è precisa, e leggerla alla lettera risponde alla maggior parte delle domande che ci si pone.
La definizione, parola per parola
WebAssembly, abbreviato in Wasm, è un formato di istruzioni binario per una macchina virtuale basata su stack. È progettato come un target di compilazione portabile per i linguaggi di programmazione, che abilita il deployment sul web per applicazioni client e server.
Ne discendono subito due cose. È un target, il che significa che qualcos’altro compila verso di esso, come il C compila in codice macchina. Ed è basato su stack, che è una decisione di progetto su come la macchina virtuale conserva gli operandi, non un dettaglio con cui interagisci direttamente.
Non ci si aspetta che qualcuno scriva Wasm a mano per la produzione, non più di quanto qualcuno scriva x86 a mano. Tu scrivi Rust, C, Go o un altro linguaggio, e il compilatore emette Wasm.
I quattro obiettivi di progetto, e quanto costa ciascuno
Il progetto dichiara quattro obiettivi, e vale la pena leggerli come compromessi anziché come un elenco di funzionalità.
Efficienza. La macchina a stack è progettata per essere eseguita a velocità nativa sfruttando le capacità hardware comuni disponibili su un’ampia gamma di piattaforme. Si noti la precisazione: capacità comuni, su un’ampia gamma. Qui la velocità nasce dal puntare a ciò che ogni piattaforma possiede, non dallo sfruttare ciò che una sola fa meglio.
Sicurezza. Wasm descrive un ambiente di esecuzione sicuro dal punto di vista della memoria e isolato in una sandbox, che per di più può essere implementato all’interno delle macchine virtuali JavaScript esistenti. Il modulo non può arrivare oltre ciò che l’host gli consegna.
Apertura. È progettato per essere stampato in modo leggibile in un formato testuale per il debug, i test, la sperimentazione, l’ottimizzazione, l’apprendimento, l’insegnamento e la scrittura di programmi a mano. Un formato binario che distribuisce una controparte leggibile compie una scelta deliberata contro l’opacità.
Portabilità. Lo scopo dichiarato è preservare la natura priva di versioni, verificata per funzionalità e retrocompatibile del web. Quella sola formula spiega perché Wasm non ha numeri di versione da negoziare: si verifica la presenza di una funzionalità, non si chiede con quale release si stia parlando.
Il rapporto con JavaScript
Wasm non sostituisce JavaScript, e la formulazione ufficiale sulla loro interazione è prudente in un modo che vale la pena notare. I moduli potranno chiamare dentro e fuori dal contesto JavaScript e accedere alle funzionalità del browser attraverso le stesse Web APIs accessibili da JavaScript.
Quel tempo futuro, potranno, compare nella descrizione ufficiale. È un promemoria del fatto che il confine tra i due è stato un bersaglio mobile, e che qualunque cosa si legga su Wasm e il DOM andrebbe verificata rispetto alla versione che si sta effettivamente rilasciando e non rispetto a un post di blog.
La forma pratica oggi: Wasm calcola, JavaScript orchestra. Il lavoro numerico pesante, i codec, la compressione, la simulazione e la crittografia rientrano tutti nel primo ruolo. Raggiungere la pagina, gestire gli eventi e chiamare le API del browser rientrano nel secondo.
Non è mai stato solo per i browser
Il nome trae in inganno, e il sito lo dice chiaramente: WebAssembly supporta anche incorporamenti non web. La definizione stessa menziona applicazioni client e server.
È per questo che Wasm compare in posti dove non c’è alcun browser: sistemi di plugin che devono eseguire codice non fidato in sicurezza, runtime di edge, scripting incorporato dentro applicazioni più grandi. In tutti l’attrattiva è la stessa coppia di proprietà, una sandbox con un formato binario portabile, e il browser è semplicemente l’host più visibile anziché l’unico.
Quando è lo strumento sbagliato
Se il tuo collo di bottiglia è la rete, Wasm non aiuta. Un modulo deve comunque essere scaricato, e un calcolo veloce dietro un trasferimento lento resta lento.
Se il tuo lavoro è soprattutto manipolazione del DOM, attraversare il confine per farlo costa più di quanto faccia risparmiare. È proprio ciò in cui JavaScript è già bravo.
Se dovessi riscrivere del codice funzionante, valutalo onestamente. Wasm dà il meglio quando un linguaggio compilato è già la scelta naturale, o quando hai una base di codice C o Rust esistente da portarti dietro.
La versione breve
WebAssembly è un formato di istruzioni binario per una macchina virtuale basata su stack, e un target di compilazione portabile più che un linguaggio da scrivere. I suoi quattro obiettivi sono l’efficienza a velocità nativa su hardware comune, una sandbox sicura dal punto di vista della memoria, un formato testuale leggibile accanto al binario, e la portabilità priva di versioni e verificata per funzionalità del web.
Completa JavaScript invece di sostituirlo, e supporta incorporamenti non web, ed è per questo che appare nei sistemi di plugin e nei runtime lato server con la stessa naturalezza con cui appare nei browser. Leggi la definizione alla lettera e gran parte della confusione che la circonda svanisce.
Se stai iniziando a capire come i linguaggi compilati raggiungano un target in generale, la nostra nota su che cos’è un algoritmo parte un livello più sotto.
La definizione, i quattro obiettivi di progetto e la loro formulazione, l’affermazione sul chiamare dentro e fuori dal contesto JavaScript e la nota sugli incorporamenti non web sono tratte dal sito ufficiale di WebAssembly, verificato al momento della stesura. La specifica evolve; verifica sulla documentazione attuale prima di fare affidamento su una capacità specifica.