Simon Willison calificó de "absurdamente genial" un nuevo experimento de ingeniería web: el equipo de Puter compiló Firefox a WebAssembly de tal forma que el navegador completo se ejecuta dentro de otro navegador. En su demostración, Willison mostró su propio blog corriendo en Firefox, sobre WebAssembly, sobre Chrome, con el panel de red de Chrome revelando que la página cargó recursos que incluyen un gecko.wasm de 233 MB y un archivo de recursos de 18 MB.
¿Por qué eligieron Firefox y no Chrome?
El equipo eligió Firefox y su motor Gecko porque tiene un soporte sólido para funcionar en un único proceso, algo clave para que la compilación a WebAssembly resulte manejable. El proyecto tomó un costo estimado de 25.000 dólares en tokens de Claude Opus y Fable, aprovechando un plan de suscripción Claude Max.
¿Cómo accede a la red desde dentro del navegador?
La demostración canaliza todo el tráfico a través de un protocolo sobre WebSocket, usando el protocolo Wisp, a través del servidor de Puter. Es un requisito para lograr algo así, porque el código que corre en los navegadores no puede abrir conexiones de red arbitrarias. Ese esquema de proxy resulta costoso: el equipo tuvo que escalar sus servidores para manejar el tráfico durante la conversación sobre el proyecto en Hacker News.
Puter afirma que esto admite cifrado de extremo a extremo, y las pruebas lo respaldan. Willison inspeccionó los mensajes de WebSocket y comprobó que el tráfico hacia su propio sitio HTTPS estaba cifrado, mientras que las solicitudes y respuestas hacia sitios sin HTTPS viajaban en texto plano.
Un patrón que empieza a repetirse
El repositorio de firefox-wasm está disponible públicamente. Existe además un proyecto similar, WebkitWasm, que compila WebKit a WebAssembly, aunque por ahora no tiene una demostración accesible en línea.
El experimento se suma a una tendencia creciente: usar WebAssembly como capa de compatibilidad universal para ejecutar software pesado, antes impensable, dentro de la pestaña de un navegador. El detalle de que un motor completo como Gecko quepa en un paquete de 233 MB y arranque en Chrome muestra hasta dónde llegó WebAssembly como objetivo de compilación. Para desarrolladores en LatAm que trabajan con entornos restringidos, donde no siempre se puede instalar software nativo, la idea de correr un navegador aislado dentro de otro abre posibilidades concretas de sandboxing y compatibilidad.
