Trascina una foto HEIC in un convertitore nel browser. Il file è un contenitore con dati immagine codificati in HEVC — la stessa compressione H.265 usata per i video 4K. Il browser non ha un decodificatore HEVC integrato, e scriverne uno da zero in JavaScript sarebbe lento, fragile e enorme. Il decodificatore che serve davvero è libheif, una libreria C++ mantenuta da strukturag. WebAssembly è ciò che permette a quel decodificatore C++ di essere eseguito nel browser.
Questo esempio da solo riassume il concetto. WebAssembly non è un nuovo linguaggio di programmazione e non sostituisce JavaScript. È un formato binario portatile di istruzioni e un ambiente di esecuzione sandbox che gira nel browser affiancato a JavaScript.
Cos'è davvero WebAssembly
WebAssembly (Wasm) è uno standard W3C. Definisce un formato binario compatto di istruzioni e una macchina virtuale stack-based. Di solito non si scrive Wasm a mano; lo si compila da C, C++, Rust, Go, Zig, C# o da un elenco crescente di altri linguaggi. Il risultato è un modulo .wasm che il browser scarica, valida ed esegue dentro una sandbox memory-safe.
Tutti i principali browser supportano WebAssembly dal 2017. Il formato del modulo è pensato per essere:
- Compatto: binario, quindi viene analizzato più velocemente del codice JavaScript equivalente.
- Veloce: compilato ahead-of-time in codice macchina dal browser.
- Sicuro: ogni modulo ottiene una memoria lineare isolata con controlli sui limiti.
- Indipendente dal linguaggio: qualsiasi linguaggio che possa generare il set di istruzioni Wasm può girare sul web.
I limiti del web tradizionale
JavaScript è un buon linguaggio per interfacce utente, richieste di rete e codice di raccordo. È dinamicamente tipizzato, garbage-collected e JIT-compilato. Queste proprietà lo rendono flessibile, ma anche imprevedibile per carichi di calcolo pesanti.
Una pausa del garbage collector può bloccare un thread UI nel mezzo di un'animazione. Il warm-up JIT significa che lo stesso codice può girare a velocità diverse in momenti diversi. Per lavori numerici o bitwise — decodifica immagini, codifica video, crittografia, simulazioni fisiche, grandi operazioni su matrici — JavaScript è spesso un ordine di grandezza più lento della stessa logica compilata da C o Rust.
L'altra limitazione è il lock-in dell'ecosistema. Decenni di librerie per immagini, audio, video e scientifiche sono scritte in C e C++. Riscriverle in JavaScript non è un modo realistico per portare quelle capacità sul web.
Perché esiste WebAssembly
Wasm è stato creato per risolvere due problemi contemporaneamente:
- Eseguire codice nativo esistente nel browser senza riscriverlo in JavaScript.
- Dare alle web app un livello di esecuzione ad alte prestazioni e prevedibile per compiti per cui JavaScript non è mai stato progettato.
È esplicitamente un compagno di JavaScript, non un successore. Il DOM, lo stack di rete e la maggior parte delle API sono ancora gestiti da JavaScript. Wasm gestisce il calcolo isolato; JavaScript gestisce l'orchestrazione.
Cosa risolve WebAssembly
- Carichi CPU-bound: decodifica immagini, transcodifica video, fisica, crittografia dati.
- Prestazioni prevedibili: nessun garbage collector, nessuna curva di warm-up JIT.
- Riutilizzo del codice: portare librerie collaudate come libheif, FFmpeg, SQLite e OpenCV nel browser.
- Privacy: dati sensibili possono essere elaborati localmente invece di essere caricati su un server.
- Esecuzione offline: una volta scaricato il modulo
.wasm, gira senza un round-trip di rete.
Pro e contro
| Aspetto | Vantaggio | Limite |
|---|---|---|
| Prestazioni | Velocità quasi nativa per task numerici e memory-bound | Non è più veloce del nativo; resta limitato dal browser e dal dispositivo |
| Portabilità | Un modulo gira su qualsiasi browser e sistema operativo | Richiede un host JavaScript per DOM e la maggior parte delle API browser |
| Sicurezza | Memoria lineare sandbox con controlli sui limiti | Vulnerabile a canali laterali in stile Spectre come qualsiasi codice browser |
| Ecosistema | Riutilizza basi di codice C/C++/Rust esistenti | L'interoperabilità con JavaScript aggiunge complessità e overhead |
| Avvio | Il formato binario viene analizzato rapidamente | Download e istanziazione del modulo possono essere pesanti al primo caricamento |
Il punto onesto: Wasm rende il browser capace di lavori che prima non poteva fare, ma non elimina i vincoli di girare sul dispositivo di un utente.
Casi d'uso comuni
WebAssembly è diventato la risposta predefinita quando una web app deve fare il lavoro pesante localmente:
- Editing di immagini e video: Figma, Photopea e strumenti simili usano Wasm per rendering ed effetti.
- Transcodifica video: FFmpeg.wasm esegue FFmpeg dentro il browser per la conversione di formato.
- Riconoscimento ottico dei caratteri: Tesseract.js porta il motore OCR Tesseract su Wasm.
- Gaming: Unity, Godot e Unreal Engine possono esportare su Wasm per giochi basati su browser.
- Analisi dati: Pyodide porta Python e pacchetti scientifici; sql.js esegue SQLite nel browser.
- Inferenza di machine learning: ONNX Runtime Web usa un backend Wasm per l'inferenza CPU.
- CAD e visualizzatori 3D: kernel geometrici complessi che prima erano solo desktop.
- Crittografia: hashing, crittografia e zero-knowledge proof eseguiti lato client.
Librerie comuni basate su WebAssembly
| Libreria | Origine | Cosa fa |
|---|---|---|
| heic-to | libheif via Emscripten | Decodifica immagini HEIC/HEIF e le converte in JPEG, PNG o bitmap nel browser. |
| FFmpeg.wasm | FFmpeg via Emscripten | Transcodifica, remuxing e filtraggio audio/video interamente lato client. |
| Tesseract.js | Tesseract OCR via Emscripten | Riconosce testo da immagini nel browser. |
| sql.js | SQLite via Emscripten | Esegue un motore di database SQLite completo nel browser usando un file in-memory. |
| Pyodide | CPython via Emscripten | Esegue Python e pacchetti come NumPy, Pandas e SciPy senza un backend. |
| ONNX Runtime Web | ONNX Runtime via Emscripten | Esegue modelli ONNX di machine learning su CPU (Wasm) o GPU (WebGL/WebGPU). |
Dietro ogni voce c'è lo stesso schema: prendere un progetto nativo consolidato, compilarlo in Wasm ed esporlo tramite un'API JavaScript. È questo il valore concreto di WebAssembly.
Perché la conversione online da HEIC a JPG/PNG/WebP ha bisogno di WebAssembly
HEIC è un contenitore, non un codec. I dati immagine effettivi sono codificati in HEVC, che è computazionalmente costoso e vincolato da brevetti. Nessun browser include un decodificatore HEVC nativo che le pagine web possano usare. La conversione lato server è l'ovvia alternativa, ma richiede di caricare le foto dell'utente.
L'alternativa è usare libheif — lo stesso decodificatore usato dagli strumenti desktop — compilato in WebAssembly. Quando usi il nostro convertitore da HEIC a JPG, la decodifica avviene nel tuo browser:
- Il file viene validato leggendo la firma del box
ftyp. - Il modulo Wasm di libheif decodifica il bitstream HEVC localmente.
- La bitmap decodificata viene scritta su un canvas ed esportata come JPEG.
Lo stesso modulo serve anche per HEIC to PNG, per output lossless con trasparenza, e per HEIC to WebP, per dimensioni ottimizzate per il web. Nessun caricamento, nessuna elaborazione server e nessun terzo vede l'immagine.
Quel flusso di lavoro funziona solo perché WebAssembly può eseguire un vero decodificatore di immagini. JavaScript da solo non può analizzare HEVC in tempi ragionevoli; un caricamento sul server vanificherebbe la promessa di privacy. È qui che entra in gioco Wasm.
Il futuro di WebAssembly
Wasm si sta espandendo oltre il browser. Il WebAssembly System Interface (WASI) definisce un'interfaccia di sistema portatile che permette ai moduli Wasm di girare su server, edge worker e dispositivi IoT. Runtime come Wasmtime, Wasmer e WasmEdge sono già distribuiti in produzione al di fuori del browser.
La proposta del Component Model permetterà ai moduli Wasm di esporre interfacce tipizzate e comporsi come librerie, facilitando l'integrazione di un modulo Rust in un host Python o un servizio Go. WebAssembly GC aggiunge un supporto migliore per linguaggi gestiti come Java e Kotlin. Nulla di tutto questo riguarda la sostituzione di JavaScript nel browser — si tratta di fare di Wasm un target di runtime universale e leggero.
Anche nel browser si osserva la stessa tendenza: più capacità native spostate lato client, più strumenti che preservano la privacy e più librerie un tempo riservate al desktop che ora girano in una scheda. WebAssembly non è una funzionalità che salta all'occhio degli utenti, ma è sempre più ciò che permette di eseguire compiti complessi sul web.
