# Qué es WU
Entiende qué problema resuelve WU, cómo encajan una app y su shell y cuándo tiene sentido utilizarlo.
Consulta las versiones, cambios y requisitos en [Framework 4.0 y CLI 1.2](/es/docs/guides/releases/).
WU permite reunir aplicaciones web independientes en una misma página. Cada aplicación conserva su interfaz y su framework; WU coordina cuándo aparece, cuándo se retira y cómo se comunica con las demás.
El paquete incluye adapters para **React, Vue, Angular, Svelte, Preact, Solid, Lit, Vanilla, Alpine, Qwik, Stencil, HTMX y Stimulus**. Consulta sus contratos en la [referencia de adapters](/es/docs/framework/api-adapters/).
Para otra tecnología, registra `mount` y `unmount` con `wu.define`, o construye un adapter con [`createWuAdapter`](/es/docs/framework/api-adapters/#createwuadapter). El contrato común permite conectar aplicaciones con el mismo framework o con frameworks diferentes.
## El problema que resuelve
Imagina una tienda con un catálogo en React y un carrito en Vue. Sus equipos necesitan cambiar y publicar cada parte por separado, pero el usuario espera una sola experiencia: elegir un producto en el catálogo y verlo en el carrito.
WU carga ambas aplicaciones, entrega a cada una un contenedor y ofrece canales para compartir datos. El catálogo puede avisar de una selección sin importar componentes ni código del carrito. Las dos aplicaciones también podrían usar React: **la independencia entre aplicaciones es lo esencial; mezclar frameworks es una posibilidad**.
## Tres piezas para entenderlo
### 1. La app aporta una parte de la interfaz
El catálogo y el carrito son **microapps**, también llamadas microfrontends o MFE. Cada una registra cómo dibujarse en un contenedor y cómo retirar los recursos que creó al salir. En WU esas operaciones se llaman `mount` y `unmount`: su ciclo de vida.
Puedes escribirlas con JavaScript o utilizar un **adapter**, que conecta el ciclo de vida de React, Vue u otro framework con WU. [Los adapters](/es/docs/framework/api-adapters/) evitan repetir esa conexión en cada aplicación.
### 2. El shell decide dónde aparece cada app
El **shell** o **host** es la página que las reúne. Define sus URLs, reserva los espacios para mostrarlas y coordina navegación, permisos y errores visibles. Puede construirse con Astro, otro framework o HTML y JavaScript.
En la tienda, el shell puede reservar una zona para el catálogo y otra para el carrito. No necesita conocer los componentes internos de cada uno.
### 3. El runtime las conecta durante la ejecución
El **runtime** es el paquete JavaScript `wu-framework` ejecutándose en la página. Carga y monta las apps y proporciona eventos, estado compartido y llamadas con respuesta.
Por ejemplo, el catálogo puede emitir un evento al seleccionar un producto; el carrito lo recibe y actualiza su interfaz. El shell concede los permisos que necesita cada app. Aprende esos mecanismos después del primer montaje, en [comunicación entre aplicaciones](/es/docs/framework/communication/).
**WU CLI prepara el proyecto.** El comando `wu` trabaja en la terminal: genera archivos, prepara dependencias, inicia el desarrollo y reúne los archivos de producción. El runtime trabaja en la aplicación que abre el usuario. Puedes usar WU sin la CLI si preparas esos archivos con tus propias herramientas. [Conoce el flujo de la CLI](/es/docs/cli/overview/).
## Cuándo tiene sentido
- Distintos equipos necesitan mantener y publicar partes de una misma experiencia por separado.
- Quieres incorporar una aplicación nueva junto a otra existente durante una migración.
- Necesitas componer interfaces con límites de estilos y comunicación explícita entre aplicaciones.
Si una sola aplicación con su router y sus componentes cubre tus necesidades, dividirla en microapps añade trabajo de configuración, montaje y coordinación. No necesitas varios frameworks para utilizar WU ni necesitas WU por el solo hecho de usar varios componentes.
WU tampoco es una frontera para ejecutar código hostil. Shadow DOM encapsula DOM y estilos, pero no impide por sí mismo el acceso al contexto JavaScript de la página. Consulta [aislamiento](/es/docs/framework/sandbox/) y [seguridad y permisos](/es/docs/framework/security/) antes de elegir cómo cargar código de terceros.
## Empieza con una app
Sigue [Tu primera app](/es/docs/guides/quickstart/) para generar un shell con una microapp y comprobar el resultado en el navegador. Después puedes [añadir otra app](/es/docs/guides/add-an-app/) y [preparar producción](/es/docs/guides/production/).
El recorrido utiliza Astro y React como ejemplo. El shell y los frameworks que elijas pueden ser otros.
## Qué sucede al montar una app
El shell declara la URL de la app. En esa URL, un **manifest** (`wu.json`) describe el archivo JavaScript que debe cargar WU: su **entry**. Ese archivo registra el ciclo de vida; el shell pide el montaje y la interfaz aparece.
Ver un montaje mínimo en JavaScript
Este ejemplo muestra los archivos que intervienen. Presupone un proyecto que resuelve `import ... from 'wu-framework'` mediante su bundler y sirve los archivos de la app; no es una receta de instalación. [La primera app](/es/docs/guides/quickstart/) prepara ese entorno.
El HTML del shell contiene ``. Su módulo **cliente** ejecuta:
```js
import { wu } from 'wu-framework';
await wu.init({
apps: [{ name: 'hello', url: '/apps/hello' }],
sandbox: 'module',
});
await wu.mount('hello', '#hello-slot');
```
La URL sirve un archivo `/apps/hello/wu.json`:
```json
{
"name": "hello",
"entry": "assets/hello.js",
"styleMode": "own-only",
"wu": { "permissions": [] }
}
```
El bundle `assets/hello.js` registra la app al evaluarse:
```js
import { wu } from 'wu-framework';
wu.define('hello', {
mount(container) {
const heading = document.createElement('h2');
heading.textContent = 'Hola desde WU';
container.append(heading);
},
unmount(container) {
container.replaceChildren();
},
});
```
Al resolver `wu.mount`, el contenedor muestra **Hola desde WU**. `wu.define` registra cómo dibujar la app; `wu.mount` hace que aparezca. El nombre debe coincidir en registro, manifest y `define`. El entry debe ser JavaScript utilizable por el navegador; publicar JSX/TSX crudo en un servidor estático no lo convierte en un módulo ejecutable.
### Una instancia compartida y permisos por app
La importación principal crea o reutiliza `window.wu` y expone también `Symbol.for('wu-framework')`. Los módulos de una misma página deben resolver el runtime de manera coherente; duplicar paquetes no produce automáticamente runtimes aislados. En Node, una importación de `wu` sigue siendo una instancia de módulo compartida por ese proceso: para SSR se utiliza `wu-framework/server` y datos por petición.
El `wu` importado por el shell tiene autoridad de host. El segundo argumento del callback `mount(container, context)` de la app contiene `context.wu`: una **fachada**, es decir, el acceso a WU limitado a los permisos de esa aplicación. Se revoca al desmontarla. Usa ese argumento para conservar el contrato de permisos. Recuperar `window.wu` desde un microfrontend que comparte el contexto JavaScript del shell recupera autoridad del host.
## Si necesitas profundizar
| Lo que quieres entender | Continúa aquí |
| --- | --- |
| Declarar apps, URLs, manifests y permisos | [Configuración](/es/docs/framework/configuration/) |
| Montar, desmontar y limpiar recursos | [Ciclo de vida](/es/docs/framework/lifecycle/) |
| Enviar eventos o pedir una respuesta a otra app | [Comunicación](/es/docs/framework/communication/) |
| Compartir datos que la interfaz pueda observar | [Estado compartido](/es/docs/framework/state/) |
| Buscar la firma y el contrato de un método | [Referencia de API](/es/docs/framework/api-reference/) |
| Integrar Astro, Next o renderizado en servidor | [Integraciones](/es/docs/framework/integrations/) |
Consultar límites técnicos y fuentes de implementación
El paquete distribuye ESM, CommonJS y UMD y exige Node `>=20.0.0` para sus herramientas. El navegador ejecuta el runtime cliente; el entrypoint `wu-framework/server` proporciona las funciones de renderizado de servidor. Cada adapter tiene sus propios requisitos de renderer e hidratación.
WU no requiere que Astro renderice los árboles React/Vue mediante sus propias islas: puede montar bundles independientes en contenedores del shell.
### Alcance del runtime
- No hay un router general del core que interprete rutas del manifest.
- Shadow DOM encapsula DOM/CSS; no impide por sí mismo acceso a la ventana principal.
- `strict` y `eval` usan iframes same-origin y no constituyen una frontera frente a código hostil.
- El store, su historial y timeline viven en memoria; no ofrecen una base de datos ni auditoría durable.
- Las aplicaciones se ejecutan en contextos del navegador; el core no incluye un motor general de drivers, Worker o WASM para tareas arbitrarias.
### Referencia de implementación
| Pieza | Responsabilidad | Fuente |
| --- | --- | --- |
| `WuCore` | Registro, inicialización, montaje, desmontaje y ownership de contenedores | `src/core/wu-core.js` |
| Manifest `wu.json` | Entry, exportaciones, dependencias declarativas y permisos solicitados | `src/core/wu-manifest.js` |
| Lifecycle de la app | Conectar y retirar su renderer del contenedor entregado | `src/index.d.ts` |
| Sandbox y style bridge | Límite DOM, distribución de estilos y seguimiento de efectos | `src/core/wu-sandbox.js` |
| Event bus y RPC | Eventos con identidad; preguntas con respuesta, versión y cancelación | `src/core/wu-event-bus.js` |
| Store | Datos compartidos, snapshots separados y notificaciones | `src/core/wu-store.js` |
| Shell | URLs, grants, navegación, composición y tratamiento visible de errores | `src/core/wu-core.js` |
El contrato de exports está en `package.json`; singleton y accesos globales en `src/index.js`; contexto scoped en `src/core/wu-core.js` y `src/core/wu-core.js`. Las pruebas relevantes incluyen `tests/unit/package-exports.test.js`, `tests/unit/core-store-isolation.test.js` y `tests/unit/capability-security-v3.test.js`.
Consulta [supervisión, recuperación y replay](/es/docs/framework/runtime-reliability/) para `superviseApp`, `createReplaySession` y los métodos scoped `reportError`, `now` y `random`.