Summary

  • El W3C publicó el primer borrador de Web Workers el 23 de abril de 2009. Una página podía iniciar un programa en un entorno paralelo separado y coordinarse con él enviando mensajes.
  • El ejemplo de números primos situaba la búsqueda en un worker. Cada resultado volvía a la página para que esta lo mostrara mientras seguía atendiendo la interacción.

El botón dice «Calcular». Usted hace clic y descubre que la página entiende la palabra de manera literal: ahora calcula y se olvida de usted. El puntero se mueve, el botón sigue dibujado, pero la respuesta parece haber salido a almorzar. Cuando el cálculo termina, llegan de golpe las consecuencias de todos los clics impacientes. A la máquina le salen bien las cuentas; a la conversación le falta alguien en la ventanilla.

El primer borrador de Web Workers, publicado por el W3C el 23 de abril de 2009, puso esa separación en su objetivo. Permitía ejecutar programas en segundo plano de forma independiente a los que responden a clics y otras acciones. Para explicarlo eligió una tarea humilde: buscar números primos. El documento principal crea un worker; este calcula y envía el último número encontrado; la página lo muestra. La oficina del fondo puede contar mientras la ventanilla sigue abierta.

La división tiene un procedimiento concreto. La página crea un Worker con la dirección de un archivo de programa. El navegador lo ejecuta en un entorno paralelo distinto. Ambos lados se envían datos con postMessage y reciben respuestas en gestores de mensajes. El worker hace el cálculo y la página conserva el control de lo visible. Cuando llega un primo nuevo, el código de la página cambia el texto. La respuesta cruza una frontera clara antes de presentarse al lector.

El borrador de diciembre de 2009 describió la coordinación como paso de mensajes entre tareas semejantes a hilos de ejecución. El intercambio impone una cortesía técnica: quien calcula informa; quien atiende decide qué información sigue siendo pertinente. Si la persona cambió la búsqueda mientras el worker seguía ocupado, el resultado viejo llega con fecha de caducidad. La página tiene el lugar y la responsabilidad de decidir qué enseñar.

Los números primos hacen que el ejemplo sea limpio. No hay una red lenta a la que echar la culpa ni un servidor remoto escondido tras la pantalla. El trabajo computacional ocupa el mismo espacio de ejecución que necesitaba la interfaz. Sacar el bucle de allí permite responder a los gestos y actualizar el número cuando llegue un mensaje. El usuario puede ver que el cálculo avanza sin organizar una vigilia delante de un botón mudo.

Los trabajadores de segundo plano consumen recursos. El texto de finales de 2009 advertía del coste de arrancarlos y de la memoria que ocupa cada uno. Proponía un ejemplo de exceso bastante memorable: iniciar un worker por cada píxel de una imagen de cuatro megapíxeles. Eso equivale a contratar a cuatro millones de empleados para colorear cuatro millones de casillas y luego buscar un edificio donde sentarlos. La unidad de trabajo importa.

Las etapas posteriores afinaron la correspondencia. La instantánea de recomendación candidata de 2012 mantenía la diferencia entre workers dedicados y compartidos. El dedicado habla con su creador por un canal implícito; el compartido puede atender conexiones de varios contextos del mismo origen mediante puertos. El borrador de 2015 detalló Worker, onmessage, postMessage y el MessagePort de la modalidad compartida. Cada ayudante tenía una dirección a la que responder.

Esta frontera organiza el tiempo del trabajo. Otras herramientas del navegador organizan dónde viven los datos según ventana y origen. Una página puede necesitar ambas cosas: recordar una selección y calcular una respuesta costosa. El worker recibe una tarea y devuelve resultados por mensajes; la interfaz conserva la relación con la persona. Esa separación hace visible quién tomó la decisión de mostrar un número y quién se limitó a encontrarlo.

La historia de publicaciones del W3C va del primer borrador de 2009 a las etapas de 2012 y 2015. El ejemplo de los primos conserva su fuerza porque pregunta algo cotidiano. Si el navegador está pensando, ¿puede seguir escuchando? Con un worker al fondo y mensajes que vuelven a la página, la respuesta llegó sin pedirle paciencia heroica al usuario.