WebAssembly: por qué el navegador ya hace cosas que antes exigían instalar un programa
Editar vídeo o comprimir un PDF dentro de una pestaña dejó de ser imposible hace pocos años. La razón tiene nombre, y entenderla explica por qué muchas webs cambiaron de arquitectura al mismo tiempo.
En 2015, si querías recortar un vídeo tenías dos opciones: instalar un programa, o subir el archivo a una web que lo hiciera por ti en su servidor. No había una tercera.
Hoy la hay. Puedes recortar ese vídeo dentro de una pestaña del navegador, sin instalar nada y sin que el archivo salga de tu ordenador. El cambio no fue gradual ni fue una mejora de JavaScript. Fue la llegada de una pieza nueva: WebAssembly.
El problema que JavaScript no podía resolver
JavaScript nació en 1995 para pequeñas tareas: validar un formulario, mostrar un menú. Nadie lo diseñó pensando en decodificar vídeo.
Con los años se volvió sorprendentemente rápido. Los motores modernos hacen compilación justo a tiempo y optimizaciones que en su momento parecían imposibles. Pero arrastra dos características que no se pueden quitar sin romper la web entera:
Es un lenguaje dinámico. Una variable puede contener un número y un instante después un texto. El motor tiene que comprobarlo continuamente en tiempo de ejecución, y esas comprobaciones cuestan. Un lenguaje donde los tipos se conocen de antemano se salta ese trabajo.
No controla la memoria. JavaScript tiene recolector de basura: decide solo cuándo liberar memoria. Es cómodo para programar, pero introduce pausas impredecibles. Procesando un vídeo cuadro a cuadro, esas pausas se acumulan.
El resultado era un techo. Podías escribir un decodificador de vídeo en JavaScript —hubo quien lo hizo— pero iba entre cinco y veinte veces más lento que el mismo algoritmo compilado. Suficiente para que no fuera utilizable.
Qué es WebAssembly exactamente
WebAssembly no es un lenguaje de programación. Es un formato de instrucciones binarias que los navegadores saben ejecutar, pensado como destino de compilación para otros lenguajes.
Tú escribes en C, C++ o Rust. El compilador produce un archivo .wasm. El navegador lo ejecuta a velocidad cercana a la nativa.
Tres decisiones de diseño explican por qué funciona:
Es binario y compacto. No hay que analizar texto: el navegador puede empezar a compilarlo mientras aún se está descargando.
Tiene tipos estáticos. Cada operación sabe con qué está trabajando antes de ejecutarse. No hay comprobaciones en tiempo de ejecución.
La memoria es un bloque plano. El programa recibe un array de bytes y lo gestiona él mismo, exactamente como haría un programa nativo. No hay recolector de basura interfiriendo.
La consecuencia práctica es enorme: el código que ya existía se podía reutilizar. Bibliotecas escritas hace veinte años, depuradas por miles de personas, se recompilaron a WebAssembly sin reescribirse. FFmpeg, que mueve prácticamente todo el vídeo del mundo, funciona hoy dentro de una pestaña siendo el mismo código de siempre.
Lo que cambió en la práctica
Antes de WebAssembly, cualquier tarea pesada obligaba a esta arquitectura:
Tu archivo → red → servidor → procesamiento → red → tu archivo
Eso implica servidores que alguien paga, tiempos de subida y bajada, límites de tamaño, colas cuando hay mucha gente, y una copia de tu archivo en un ordenador ajeno.
Con WebAssembly la arquitectura se reduce a:
Tu archivo → memoria del navegador → procesamiento → tu carpeta de descargas
Desaparecen los servidores de procesamiento, los tiempos de transferencia y la copia remota. Y aparece algo que antes no existía: la herramienta sigue funcionando sin conexión una vez cargada la página.
Dónde está WebAssembly hoy
Puede que ya lo hayas usado sin saberlo:
| Aplicación | Qué hace con WebAssembly |
|---|---|
| Figma | El motor de renderizado del lienzo |
| Photoshop y Lightroom web | El núcleo de edición de imagen, portado desde C++ |
| Google Earth | El renderizado 3D en el navegador |
| AutoCAD web | El motor de dibujo, con décadas de código C++ detrás |
| Herramientas de conversión | FFmpeg, libvips y bibliotecas de PDF compiladas |
El patrón se repite: aplicaciones con mucho código nativo maduro que querían llegar al navegador sin reescribirlo desde cero.
Los límites, que son reales
WebAssembly no es magia, y conviene saber qué no hace.
No tiene acceso directo al navegador. No puede tocar el DOM, ni hacer una petición de red, ni leer un archivo por su cuenta. Todo eso pasa por JavaScript, que actúa de intermediario. Ese cruce tiene un coste, así que la arquitectura sensata es entregar un bloque grande de trabajo y recoger el resultado, no llamar mil veces seguidas.
No es automáticamente más rápido. Para lógica de interfaz y manipulación de páginas, JavaScript suele ganar: está optimizadísimo para eso y no paga el peaje del cruce. WebAssembly brilla en cálculo intensivo sostenido.
Los módulos pesan. Un FFmpeg compilado ronda las decenas de megabytes. Se descarga una vez y queda en caché, pero la primera visita lo nota. Por eso las herramientas bien hechas cargan el motor solo cuando vas a usarlo, no al abrir la página.
Está dentro de la misma caja de arena. No puede leer tus documentos ni acceder al sistema. Solo ve lo que tú le entregas explícitamente. Esto es una limitación de diseño, y también la razón por la que es seguro ejecutarlo.
Multihilo: la parte incómoda
WebAssembly puede usar varios núcleos, lo que multiplica la velocidad en tareas paralelizables. Pero necesita SharedArrayBuffer, y ese objeto quedó restringido tras las vulnerabilidades Spectre de 2018.
Para habilitarlo, la web debe enviar dos cabeceras que activan el aislamiento de origen cruzado. Y ese aislamiento bloquea cualquier recurso externo que no declare permiso explícito: fuentes, imágenes de otros dominios, vídeos incrustados y —muy notablemente— los iframes de publicidad.
Es una disyuntiva incómoda y poco conocida: una web puede tener WebAssembly multihilo o publicidad, pero no ambas cosas en la misma página. La mayoría de herramientas online elige el modo de un solo hilo, que es más lento pero no rompe nada del resto del sitio.
Hacia dónde va
Hay tres piezas en camino que importan:
WASI, para ejecutar módulos WebAssembly fuera del navegador, en servidores, con arranques de milisegundos.
Recolección de basura, que permitirá compilar cómodamente lenguajes como Java, C# o Kotlin sin arrastrar su propio gestor de memoria.
Interfaz de componentes, para que módulos escritos en lenguajes distintos se llamen entre sí con tipos de alto nivel en vez de bytes crudos.
Lo que conviene retener
WebAssembly no vino a sustituir a JavaScript, y no lo hará. Vino a cubrir el hueco que JavaScript nunca podría llenar: cálculo intensivo a velocidad de programa nativo.
Su efecto más visible para el usuario corriente es simple. Tareas que exigían instalar software o subir archivos a un servidor ahora caben en una pestaña. No es un detalle técnico menor: cambia quién tiene tus archivos y qué necesitas instalar para trabajar con ellos.