# Desarrollo de aplicaciones con WebAssembly

**Categoría:** Programación · **Nivel:** Intermedio · **Lectura:** 13 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/programacion/desarrollo-con-webassembly/

No es un lenguaje ni un reemplazo de JavaScript: es un destino de compilación. Qué resuelve de verdad, en qué estado está como estándar, y la pregunta que decide si te sirve o no.

## Respuesta rápida

**WebAssembly** —abreviado **Wasm**— es, según su definición oficial, «un formato binario de instrucciones para una máquina virtual basada en pila», diseñado «como destino de compilación portable para lenguajes de programación». Es decir: **no se escribe a mano, se compila hacia él**. Sus cuatro objetivos declarados son ser eficiente y rápido, seguro —con un entorno «aislado y seguro con la memoria»—, abierto y depurable, y parte de la plataforma web abierta, lo que incluye **interactuar con JavaScript**. La versión 1 es **Recomendación del W3C desde el 5 de diciembre de 2019**; la 2 sigue en proceso. Conviene para cálculo intensivo, y no para manipular la interfaz.

## Qué es, con precisión

La definición oficial cabe en una línea, y conviene empezar por ella porque desarma la mayoría de los malentendidos: «**WebAssembly** (abreviado *Wasm*) es un formato binario de instrucciones para una máquina virtual basada en pila».

Y la segunda frase es la que aclara para qué existe: está diseñado «como **destino de compilación portable** para lenguajes de programación».

> **Lo que se sigue de esas dos frases.** **No es un lenguaje que se escriba a mano** —aunque exista un formato textual para leerlo—, **no compite con JavaScript** y **no es un marco de trabajo**. Es un formato al que otros lenguajes apuntan al compilar, para poder ejecutarse en el navegador y en otros entornos. La pregunta «¿aprendo WebAssembly?» está mal planteada: lo que se aprende es a compilar hacia Wasm desde un lenguaje que ya sabés.

## Los cuatro objetivos de diseño

![Diagrama de WebAssembly con sus cuatro objetivos de diseño: eficiente y rápido, seguro, abierto y depurable, y parte de la plataforma web abierta. Después, el estado como estándar del W3C: versión 1 como Recomendación de diciembre de 2019 y versión 2 como Borrador de Recomendación Candidata. Luego, cuándo conviene frente a JavaScript y cuándo no. Al final, WASI como interfaz de sistema fuera del navegador.](../../assets/img/guias/desarrollo-con-webassembly-cuando.svg)

El sitio oficial declara cuatro, y cada uno explica una decisión concreta del diseño:

- **Eficiente y rápido.** «La máquina de pila de Wasm está diseñada para codificarse en un formato binario eficiente en tamaño y en tiempo de carga», y apunta a ejecutar a velocidad nativa aprovechando capacidades de hardware comunes. Las dos partes importan: no solo ejecuta rápido, también *carga* rápido, que en la web pesa igual.
- **Seguro.** Provee «un entorno de ejecución aislado y seguro con la memoria», y cuando está embebido en la web respeta las políticas de seguridad del navegador. Un módulo no puede salirse de su caja de arena por su cuenta.
- **Abierto y depurable.** Está diseñado para poder representarse «en un formato textual para depurar, probar, experimentar, optimizar, aprender, enseñar y escribir programas a mano». No es una caja negra binaria.
- **Parte de la plataforma web abierta.** Mantiene «la naturaleza sin versiones y compatible hacia atrás de la web», y permite que los módulos **interactúen con JavaScript y con las APIs web**.

Ese último objetivo es la respuesta oficial a la pregunta del reemplazo: la interoperabilidad con JavaScript no es un parche, es un objetivo de diseño.

## En qué estado está como estándar

Este punto conviene verificarlo antes de tomar decisiones técnicas, porque circulan afirmaciones imprecisas en las dos direcciones:

| Especificación | Estado en el W3C | Qué significa en la práctica |
|---|---|---|
| Núcleo, versión 1 | **Recomendación**, 5 de diciembre de 2019 | Estándar cerrado, el máximo grado del proceso. Soporte universal en navegadores actuales |
| Núcleo, versión 2 | Borrador de Recomendación Candidata | Etapa anterior del proceso; conviene verificar el soporte de cada función antes de depender de ella |
| WASI | Especificaciones «en vía de estandarización» | En desarrollo activo; se usa en producción pero con más movimiento |

La conclusión operativa: **lo básico se puede usar con total confianza** —tiene seis años de estándar cerrado y soporte en todos los navegadores—, y para las funciones más nuevas conviene comprobar el soporte real en lugar de asumirlo. El propio proyecto publica un informe de implementación de funciones para eso.

## Cuándo conviene frente a JavaScript

Acá está la decisión que importa, y tiene una regla clara: **Wasm rinde cuando el trabajo es cálculo puro y suficientemente grande**.

| Caso | ¿Conviene? | Por qué |
|---|---|---|
| Procesamiento de imágenes, audio o video | **Sí** | Cálculo intensivo sobre datos en memoria: el caso ideal |
| Criptografía y compresión | Sí | Mismo perfil: mucho cómputo, poca interacción |
| Simulaciones y cálculo científico | Sí | El trabajo es numérico y largo |
| Motores de juego y renderizado | Sí | Rendimiento predecible y control de memoria |
| Reutilizar una biblioteca ya escrita en otro lenguaje | **Sí, y es el caso más subestimado** | Evita reescribir y volver a validar código que ya funcionaba |
| Manipular la interfaz y el DOM | No | Cada operación cruza a JavaScript, y el cruce cuesta |
| Lógica de aplicación común | No | JavaScript es suficientemente rápido y mucho más simple de mantener |
| Reemplazar JavaScript entero | No | No es para lo que está diseñado |

La quinta fila merece atención porque es la que más se pasa por alto: cuando ya existe una biblioteca probada en C, C++ o Rust, compilarla a Wasm suele ser **mucho más barato y más seguro que reescribirla** en JavaScript, porque una reescritura implica volver a validar lógica que ya estaba correcta.

## El costo del cruce

Este es el concepto que separa una integración que mejora el rendimiento de una que lo empeora, y casi nunca aparece en los tutoriales introductorios.

**Llamar de JavaScript a Wasm y volver tiene un costo**, y también lo tiene mover datos entre los dos mundos. Un módulo de Wasm trabaja sobre su propia memoria lineal, así que pasarle un objeto de JavaScript implica traducirlo.

> **La consecuencia práctica, en una regla.** **Pocas llamadas con mucho trabajo cada una**, en lugar de muchas llamadas con poco trabajo. Enviar a Wasm una imagen completa para procesarla y recibir el resultado es el patrón correcto; llamar a una función de Wasm dentro de un bucle que se ejecuta miles de veces es el patrón que hace que la versión con Wasm salga *más lenta* que la de JavaScript. Si el trabajo es chico, la travesía se come la ganancia.

Y de ahí sale también la razón técnica por la que no conviene mover una interfaz a Wasm: manipular el DOM son muchísimas operaciones chicas, cada una de las cuales tendría que cruzar el límite. Un módulo de Wasm **no accede al DOM directamente**: pasa por JavaScript.

## Qué lenguajes compilan a Wasm

Al ser un destino de compilación portable, la lista es amplia y se mueve, así que conviene verificarla en cada caso en lugar de confiar en una enumeración que envejece. Lo que sí se puede afirmar es un criterio estructural que no cambia:

- **Los lenguajes de sistemas sin recolector de basura** —como [Rust](../introduccion-a-rust/index.md), C y C++— tienen el mejor soporte y las herramientas más maduras, porque su modelo de memoria encaja naturalmente con el de Wasm.
- **Los lenguajes con recolector de basura** también pueden apuntar a Wasm, con una salvedad concreta: el módulo resultante suele ser **más grande**, porque tiene que incluir su propio entorno de ejecución. En la web, donde el tamaño de descarga importa, eso pesa en la decisión.

Ese criterio explica por qué Rust aparece tan asociado a WebAssembly: no es moda, es que un lenguaje que ya administra la memoria sin recolector produce módulos chicos y predecibles.

## Cómo se usa desde una página

Del lado del navegador, el patrón es siempre el mismo: se carga el módulo, se instancia y se llaman sus funciones exportadas.

```javascript
// Cargar e instanciar el módulo mientras se descarga
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('procesador.wasm')
);

// Llamar a una función exportada por el módulo
const resultado = instance.exports.procesar(ancho, alto);

// Para datos grandes se comparte la memoria lineal del módulo,
// en lugar de pasar los valores uno por uno
const memoria = new Uint8Array(instance.exports.memory.buffer);
memoria.set(pixeles, offset);   // escribir la entrada
instance.exports.procesar(offset, pixeles.length);
```

En la práctica, casi nadie escribe este código a mano: las cadenas de herramientas de cada lenguaje generan una capa de unión que se encarga de la traducción de tipos y de la gestión de memoria. Pero vale entender el mecanismo, porque explica de dónde viene el costo del cruce y por qué los datos grandes se comparten por memoria en lugar de pasarse como argumentos.

## Fuera del navegador: WASI

Wasm empezó en el navegador y hoy se usa bastante fuera de él, y para eso hizo falta resolver un problema concreto: dentro del navegador, un módulo tiene las APIs web disponibles; fuera, no tenía forma estándar de leer un archivo o abrir una conexión.

Ahí entra **WASI**, la Interfaz de Sistema de WebAssembly. Su documentación la define como «un grupo de especificaciones de API **en vía de estandarización** para software compilado al estándar WebAssembly del W3C», diseñada «para proveer una interfaz estándar **segura** a aplicaciones que puedan compilarse a Wasm desde cualquier lenguaje, y que puedan correr en cualquier parte, **desde navegadores hasta nubes y dispositivos embebidos**».

Y su documentación señala el beneficio que persigue: «al estandarizar APIs para WebAssembly, WASI provee una manera de **componer software escrito en distintos lenguajes**» sin recurrir a sistemas de interfaz costosos y engorrosos como los microservicios basados en HTTP.

Eso explica el interés en Wasm del lado del servidor y en el borde: un módulo chico, aislado por diseño, que arranca rápido y corre en cualquier plataforma es un formato atractivo para funciones y complementos. Conviene tener presente que WASI está en desarrollo activo, así que ahí el terreno se mueve más que en el navegador.

## Seguridad: qué garantiza y qué no

El aislamiento es un objetivo de diseño declarado, y eso da garantías reales: un módulo corre en un entorno «aislado y seguro con la memoria», no puede acceder a lo que no se le entregó explícitamente, y en la web respeta las políticas de seguridad del navegador.

Lo que **no** garantiza, y conviene tener claro:

- **Que el código dentro del módulo sea correcto.** Un error de lógica sigue siendo un error de lógica, y una vulnerabilidad de la biblioteca que compilaste viaja con ella.
- **Que sea seguro darle datos sensibles.** Un módulo hace lo que su código dice; el aislamiento limita qué puede alcanzar, no qué hace con lo que le diste.
- **Que el binario sea auditable a simple vista.** Es un formato binario. Existe la representación textual, pero revisar un módulo de terceros es tan trabajoso como revisar cualquier dependencia compilada, y valen las mismas precauciones de cadena de suministro que están en [riesgos y uso responsable](../../inteligencia-artificial/riesgos-etica-y-uso-responsable-de-la-ia/index.md).

## Errores frecuentes

- **Tratarlo como reemplazo de JavaScript.** Está diseñado para convivir con él: la interoperabilidad es un objetivo declarado.
- **Llamar a Wasm dentro de un bucle apretado.** El costo del cruce puede hacer que la versión con Wasm salga más lenta.
- **Mover la interfaz a Wasm.** Cada operación sobre el DOM tiene que pasar por JavaScript.
- **Adoptarlo sin medir primero.** Si no sabés dónde se va el tiempo, no sabés si Wasm va a mejorar algo.
- **Ignorar el tamaño del módulo.** En la web, un binario grande puede costar más en descarga de lo que ahorra en ejecución.
- **Suponer que todas las funciones tienen soporte.** La versión 1 sí; para lo posterior conviene verificar.
- **Confiar en un módulo de terceros porque «está aislado».** El aislamiento limita el alcance, no la intención del código.

## Preguntas frecuentes

### ¿Qué es WebAssembly exactamente?

Su sitio oficial lo define en una línea: WebAssembly, abreviado Wasm, es un formato binario de instrucciones para una máquina virtual basada en pila. Está diseñado como destino de compilación portable para lenguajes de programación, y esa es la parte que más aclara qué es: no se escribe Wasm a mano, se compila código de otro lenguaje hacia Wasm. Por eso no es un lenguaje que compita con JavaScript sino un formato al que otros lenguajes pueden apuntar para correr en el navegador y en otros entornos.

### ¿WebAssembly reemplaza a JavaScript?

No, y el propio diseño lo desmiente: uno de sus cuatro objetivos declarados es ser parte de la plataforma web abierta, y eso incluye explícitamente que los módulos puedan interactuar con JavaScript y con las APIs web. La forma habitual de usarlo es complementaria: JavaScript maneja la interfaz, la lógica de aplicación y la coordinación, y Wasm se encarga de la parte que es cálculo intensivo. Además, cruzar el límite entre los dos tiene un costo, así que enviar trabajo chico a Wasm puede salir más lento.

### ¿Es un estándar terminado?

La versión 1 sí: la Especificación Central de WebAssembly es Recomendación del W3C desde el 5 de diciembre de 2019, que es el máximo grado de madurez del proceso, y tiene soporte en todos los navegadores actuales. La versión 2 está publicada como Borrador de Recomendación Candidata, es decir en una etapa anterior del proceso. La consecuencia práctica es que lo básico se puede usar con total confianza, y para las funciones más nuevas conviene verificar el soporte antes de depender de ellas.

### ¿Puede acceder al DOM directamente?

No de forma directa: para tocar el DOM, un módulo de Wasm pasa por JavaScript. Esa es la razón técnica por la que no conviene reescribir una interfaz en Wasm, porque cada operación sobre la página cruzaría el límite entre los dos mundos y ese cruce tiene costo. La consecuencia de diseño es clara: Wasm rinde cuando recibe datos, hace un trabajo grande de cálculo y devuelve un resultado, no cuando tiene que interactuar constantemente con la página.

### ¿Qué lenguajes se pueden compilar a WebAssembly?

Al ser un destino de compilación portable, la lista es amplia y cambia con el tiempo, así que conviene verificarla en cada caso. Los que tienen mejor soporte y más herramientas son los lenguajes de sistemas sin recolector de basura, como Rust y C o C++, porque su modelo de memoria encaja naturalmente con el de Wasm. Los lenguajes con recolector de basura también pueden apuntar ahí, con la salvedad de que el módulo resultante suele ser más grande, porque tiene que incluir su propio entorno de ejecución.

### ¿Qué es WASI y para qué sirve?

Es la Interfaz de Sistema de WebAssembly, y su documentación la define como un grupo de especificaciones de API en vía de estandarización para software compilado al estándar WebAssembly del W3C. El problema que resuelve es concreto: dentro del navegador, Wasm tiene las APIs web; fuera de él no tenía forma estándar de leer un archivo o abrir una conexión. WASI provee una interfaz estándar y segura para aplicaciones que puedan correr en cualquier parte, desde navegadores hasta la nube y dispositivos embebidos.

## Fuentes

Especificaciones, documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Programación Web](https://underc0de.org/foro/programacion-web-247/). Hilos de la comunidad sobre desarrollo web y rendimiento.
2. **Underc0de, foro.** [Sección Programación General](https://underc0de.org/foro/programacion-general/). Material sobre lenguajes compilados, que son los que mejor apuntan a este destino.

### Especificaciones y documentación oficial

3. **WebAssembly.** [Sitio oficial](https://webassembly.org/). Definición de WebAssembly y los cuatro objetivos de diseño, citados textualmente.
4. **W3C.** [WebAssembly Core Specification, versión 1](https://www.w3.org/TR/wasm-core-1/). Recomendación del W3C del 5 de diciembre de 2019.
5. **W3C.** [WebAssembly Core Specification, versión 2](https://www.w3.org/TR/wasm-core-2/). Publicada como Borrador de Recomendación Candidata.
6. **WebAssembly.** [Feature extensions](https://webassembly.org/features/). Informe de implementación por función, para verificar soporte antes de depender de una capacidad nueva.
7. **WASI.** [WebAssembly System Interface](https://wasi.dev/). Definición de WASI, su estado de estandarización y su objetivo de componer software escrito en distintos lenguajes, citados textualmente.

---

Esta guía forma parte de un proyecto de la comunidad Underc0de para organizar conocimiento técnico en español. Fuente canónica: https://underc0de.org/guias/programacion/desarrollo-con-webassembly/