HeyPuter

Firefox che gira dentro Chrome non è più solo un esperimento mentale per addetti ai lavori. A luglio 2026 gli sviluppatori di HeyPuter, già conosciuti per aver trasformato il browser in una specie di sistema operativo con tanto di interfaccia grafica, hanno completato un progetto open source chiamato firefox-wasm. In sostanza hanno preso il motore Gecko, quello che Firefox usa per disegnare le pagine, e lo hanno portato dentro WebAssembly. Il risultato è che un Firefox vero e proprio può aprirsi dentro una scheda di un altro browser, come se fosse una qualsiasi pagina web. WebAssembly non è nato ieri. Ha debuttato nei principali browser nel 2017 come formato binario portabile, pensato soprattutto per far girare sul web software scritto in C, C++ e altri linguaggi compilati. Da allora sono arrivate parecchie estensioni, dal supporto SIMD alla memoria condivisa, dalle operazioni atomiche alla garbage collection. Roba che ha reso possibili applicazioni sempre più complesse. Portare Gecko dentro il browser però resta un salto di livello notevole. Parliamo di milioni di righe di codice, un motore JavaScript, librerie grafiche, gestione dei font, rete, thread e una montagna di componenti che di solito si appoggiano direttamente al sistema operativo. Firefox dentro Chrome, Edge o qualsiasi altro browser La demo di Puter Labs mostra la vera interfaccia di Firefox racchiusa in una normale pagina. Chi la usa può avviare il browser, digitare un indirizzo e caricare i contenuti senza far partire alcun eseguibile tradizionale. Il rendering avviene direttamente nella scheda che ospita tutto, con la possibilità di attivare l'accelerazione grafica basata su WebGL. Qui c'è una differenza che conta e va spiegata bene. Nei classici servizi di browser isolation, Firefox o Chromium girano su un server e mandano al client immagini, video o comandi grafici. In questo caso invece Gecko gira in locale, come modulo WebAssembly. Il server entra in gioco quasi solo per la connettività, dato che una pagina web non può aprire liberamente socket TCP e UDP verso qualsiasi indirizzo Internet. Si crea così una situazione un po' curiosa. Il browser esterno mette a disposizione il runtime WebAssembly, i Web Worker, la superficie grafica e le API permesse dalla piattaforma web. Al suo interno Gecko interpreta HTML, CSS e JavaScript delle pagine visitate. Come Gecko diventa WebAssembly Il porting si basa su Emscripten, una toolchain costruita su LLVM che converte programmi C e C++ in WebAssembly e genera anche il codice JavaScript necessario per farli funzionare nel browser. Il repository su GitHub non contiene una copia completa del sorgente di Firefox, e la scelta è voluta. In questo modo la build resta riproducibile e un aggiornamento improvviso del ramo principale di Mozilla non rischia di rompere tutto. Per compilare servono Linux, Node.js, pnpm, Python e Rust con il target wasm32-unknown-emscripten, più le dipendenze audio di PulseAudio. macOS, almeno nelle prime istruzioni, non è supportato come ambiente di compilazione. Un Firefox normale accelera JavaScript passando attraverso più livelli. SpiderMonkey parte da interpreti abbastanza semplici, raccoglie dati mentre gira e alla fine può generare codice macchina ottimizzato. Dentro WebAssembly però Gecko non può scrivere liberamente istruzioni native in memoria per poi eseguirle. Le tecniche di JIT compilation vanno insomma a scontrarsi con il modello di sicurezza del browser ospitante. Per questo la configurazione standard disattiva il JIT di SpiderMonkey e attiva il Portable Baseline Interpreter, più veloce dell'interprete bytecode di base ma lontano dalle prestazioni della versione desktop. HeyPuter sta pure provando una strada diversa, un JIT che trasforma JavaScript in nuove funzioni WebAssembly invece di produrre istruzioni x86-64 o ARM. L'idea funziona perché il browser ospitante può validare e compilare il modulo, ma generare e sostituire funzioni Wasm al volo richiede meccanismi diversi da quelli pensati per SpiderMonkey. Perché conta anche se ancora imperfetto Firefox si aspetta file di configurazione, font, librerie, profili, cache e chi più ne ha più ne metta. Nel browser non trova un file system POSIX tradizionale, quindi Emscripten offre WasmFS, uno strato che presenta al codice compilato operazioni come open, read, write e stat, traducendole in strutture tenute nella memoria del runtime. Il progetto abilita anche le istruzioni WebAssembly SIMD a 128 bit, così Gecko può accelerare i percorsi usati da Skia, la decodifica delle immagini, la conversione dei colori, Stylo e WebRender. Le applicazioni possibili vanno ben oltre la curiosità di aprire Firefox dentro Chrome. Test di compatibilità senza installazioni, ambienti didattici, editor web con rendering Gecko integrato, laboratori di sicurezza isolati, piattaforme cloud e strumenti capaci di confrontare più motori nella stessa sessione. Potrebbero nascere anche servizi di automazione eseguiti quasi tutti sul client, senza tenere un'istanza browser per ogni utente sul server. Gli ostacoli restano concreti però, tra dimensione degli asset, tempi di avvio, consumo di memoria, compatibilità dei siti e prestazioni JavaScript. Firefox in WebAssembly non sostituirà il browser installato sul computer, ma la demo di HeyPuter gira abbastanza bene da rendere reale un'idea che pochi anni fa sarebbe sembrata poco credibile, distribuire non una pagina o un'app, ma un intero browser con il suo vero motore attraverso una semplice pagina web.

HeyPuter

Firefox gira dentro Chrome grazie a WebAssembly: la demo di HeyPuter