Web Workers: el segundo cocinero

En el módulo 9 congelaste una página con un while de 3 segundos y aprendiste la ley: el único cocinero no puede bloquearse. Pero ¿y si el trabajo pesado es INEVITABLE — procesar un archivo enorme, comprimir una imagen, calcular estadísticas de miles de registros? Hoy conoces la salida de emergencia: Web Workers — JavaScript corriendo en OTRO hilo, de verdad.

La segunda cocina

El experimento: la prueba del contador

El mismo latido del módulo 9 — ahora con el trabajo pesado en cada cocina, para COMPARAR:

Haz el experimento con los ojos en el latido: el botón ámbar lo CONGELA varios segundos (300 millones de raíces en tu cocina); el violeta ni lo despeina — mismo cálculo, otra cocina. Las piezas: new Worker(url) contrata al cocinero con su código (en tus proyectos: new Worker("./trabajador.js") con el archivo aparte — aquí el playground nos obligó al truco del Blob, que es idéntico por dentro); postMessage envía por la ventanilla; y cada lado escucha message del otro (¡tu addEventListener de siempre — módulo 8 hasta en la otra cocina!). Dentro del worker, self es "este hilo" — su globalThis.

Las reglas de la segunda cocina

• Sin DOM: document no existe allá. El worker calcula y REPORTA; pintar es trabajo del hilo principal. (Por eso el resultado vuelve por mensaje y el listener de acá lo pone en pantalla.)
• Sin variables compartidas: los datos del mensaje viajan COPIADOS (clonado estructurado — el primo de tu structuredClone del módulo 5). Mandas un array de un millón de items y allá llega una copia; mutarla allá no toca la tuya. Cero condiciones de carrera, el terror de otros lenguajes.
• Es asíncrono por diseño: enviar no espera respuesta — reaccionas cuando llegue el mensaje. Módulos 8 y 9, otra vez.

Nota honesta de dosificación: el worker tiene costo (crear el hilo, copiar mensajes) — para sumar diez gastos es ridículo. Su territorio: cálculos que tomarían >50-100ms en el hilo principal (procesar CSV/imágenes/audio, criptografía, física de juegos, búsquedas sobre volúmenes grandes). Regla práctica: si el usuario PUEDE notarlo, va al worker. Y por si te cruzas con ellos: existen los Service Workers — otra cosa (interceptan peticiones de red, hacen apps offline) — los verás cuando toque PWA.

Mini-reto

Dale oficio al segundo cocinero: 1) mándale por mensaje un objeto { tarea: "estadisticas", valores: [...] } con 100.000 números (genéralos con un bucle) y haz que responda { suma, promedio, mayor } — los mensajes pueden ser objetos completos, viajan clonados; 2) mide con console.time cuánto tarda ida y vuelta; 3) provoca el error de la regla: intenta usar document en el worker y estudia el mensaje. Ese "document is not defined" en un stack de worker te ubicará al instante el resto de tu carrera.

Qué sigue

Cálculo pesado: resuelto. Las próximas APIs son de otra categoría — las que tocan al USUARIO y su mundo: su portapapeles, su ubicación, sus notificaciones. Todas comparten un ritual que debes dominar: pedir permiso… y diseñar para el NO.