Bun impulsa hilos compartidos en JavaScriptCore

Bun abrió una propuesta que apunta a un tema que casi siempre se deja para después en JavaScript: el modelo de concurrencia real. No hablamos solo de “hacer cosas en paralelo” en abstracto, sino de permitir hilos con memoria compartida sobre JavaScriptCore, el motor sobre el que corre Bun. Si eso avanza, el impacto no sería menor: cambia qué tan rápido puede procesar trabajo CPU-bound, cómo se reparten tareas pesadas y qué tan lejos puede llegar JavaScript cuando de verdad necesita paralelismo.

La discusión importa porque hoy gran parte del ecosistema JavaScript vive entre dos extremos. Por un lado, tienes APIs como Web Workers, Worker Threads en Node.js o procesos separados. Por otro, tienes un lenguaje históricamente pensado para un solo hilo de ejecución por contexto. La propuesta de Bun toca justo ese punto incómodo: cómo sumar concurrencia útil sin obligarte a copiar datos todo el tiempo ni a rediseñar toda tu arquitectura.

Qué está proponiendo Bun exactamente

La PR abierta en el repositorio de WebKit plantea sumar soporte para shared-memory threads en JavaScriptCore. En términos simples, eso significa que varios hilos podrían acceder a una misma región de memoria, en vez de intercambiar mensajes o clonar estructuras completas para coordinar trabajo. La fuente original está aquí: PR 249 de Bun sobre WebKit.

Ese detalle técnico cambia bastante el panorama. Hoy, cuando trabajas con concurrencia en JavaScript, lo normal es pasar datos entre contextos mediante structured clone, mensajes o serialización. Eso funciona bien para muchas apps web, pero no es lo ideal cuando mueves volúmenes grandes de datos o cuando quieres compartir estructuras de estado con baja latencia.

La idea de memoria compartida no es nueva en computación. En otros lenguajes y runtimes, los hilos compartiendo memoria son la base de muchos sistemas de alto rendimiento. Lo novedoso aquí es llevar ese modelo más cerca del runtime JavaScript que usa Bun, con el objetivo de reducir fricción y mejorar throughput en escenarios concretos.

Por qué esto no es solo una mejora de performance

Si la propuesta avanza, no estarías viendo únicamente una optimización puntual. Estarías viendo un cambio en el tipo de aplicaciones que pueden escribirse de forma razonable en JavaScript. Por ejemplo, procesamiento de imágenes, parsing masivo, compresión, simulación, motores de reglas o pipelines de datos podrían beneficiarse de compartir buffers y estado sin tantos saltos de copia.

También hay una implicación de diseño. Cuando el runtime te ofrece memoria compartida, empiezas a pensar distinto sobre locking, sincronización y aislamiento. Eso obliga a subir el nivel de disciplina técnica, pero también abre la puerta a patrones que antes quedaban fuera por costo o complejidad.

En otras palabras, no se trata solo de “más rápido”. Se trata de qué tan viable es usar JavaScript para trabajo paralelo serio sin salirte del ecosistema.

Qué cambia frente al modelo tradicional

El modelo más común en JavaScript para concurrencia sigue siendo el intercambio de mensajes. En navegadores, los Web Workers aíslan el trabajo y usan postMessage. En Node.js, los Worker Threads también permiten paralelismo, pero el costo de mover datos sigue existiendo. Cuando el payload crece, ese costo se vuelve visible en CPU, memoria y latencia.

Con memoria compartida, el enfoque cambia. En vez de copiar un buffer de 50 MB entre hilos, puedes compartirlo y coordinar acceso. Eso no elimina los problemas, pero sí elimina una parte cara del proceso. Si tu carga de trabajo depende de mover datos grandes entre etapas, ese ahorro puede ser la diferencia entre escalar o no.

Ahora bien, compartir memoria no significa que todo sea más fácil. Al contrario: aparecen riesgos de race conditions, sincronización incorrecta y bugs difíciles de reproducir. Por eso el valor de una propuesta así depende mucho de qué tan bien se integre con las primitivas de sincronización y con el modelo de seguridad del runtime.

Comparación rápida con alternativas

La tabla no significa que una opción reemplace a las otras. Significa que cada una tiene un costo distinto. Si tu problema principal es coordinar muchos datos grandes, la memoria compartida suele ser más atractiva. Si tu prioridad es aislamiento fuerte, los procesos separados siguen teniendo sentido.

Por qué JavaScriptCore es una pieza clave

JavaScriptCore es el motor de JavaScript de Apple y una pieza central en el ecosistema de WebKit. Bun lo usa como base para ofrecer un runtime rápido y moderno. Por eso, cualquier cambio en el motor o en su integración puede tener efectos directos en cómo se comporta Bun en producción.

A diferencia de V8, que domina gran parte del mundo Node.js y Chromium, JavaScriptCore tiene una historia distinta y un conjunto de decisiones internas propio. Eso hace que una propuesta de hilos compartidos no sea un simple port de lo que ya existe en otro runtime. Hay que encajarla con la arquitectura del motor, con sus GC, con la seguridad de memoria y con sus APIs expuestas.

Si quieres revisar el contexto oficial de JavaScriptCore, puedes partir de la documentación de WebKit: JavaScriptCore en WebKit. No te da todos los detalles de esta PR, pero sí te ubica en el ecosistema correcto.

Qué busca Bun con esta apuesta

Bun lleva tiempo empujando una narrativa bastante clara: reducir fricción para construir y ejecutar software JavaScript con mejor rendimiento y menos piezas sueltas. En ese camino, el soporte de concurrencia no es un adorno. Es una forma de ampliar el tipo de problemas que puedes resolver sin salirte del runtime.

Si el runtime logra ofrecer shared-memory threads de forma estable, Bun podría convertirse en una opción más seria para cargas donde hoy Node.js o incluso lenguajes como Go y Rust tienen ventaja por su modelo de concurrencia.

También hay un ángulo práctico para equipos pequeños. Cuando operas con menos personas, prefieres herramientas que te permitan hacer más con menos infraestructura mental. Un modelo de concurrencia más directo, siempre que esté bien diseñado, puede simplificar algunos pipelines internos.

Casos de uso donde sí puede importar

No todo proyecto necesita hilos compartidos. De hecho, muchas apps web nunca deberían tocar este tipo de complejidad. Pero hay escenarios donde el beneficio puede ser muy concreto y medible.

1. Procesamiento de archivos grandes: si divides un archivo de 500 MB entre varios workers, compartir buffers reduce copias y presión de memoria.
2. Compresión y descompresión: tareas como gzip, brotli o parsing de formatos pesados suelen ganar cuando varias etapas trabajan sobre la misma memoria.
3. Analítica y ETL: mover registros entre fases sin serializar cada lote puede bajar bastante la latencia total.
4. Imagen y video: operaciones sobre matrices de píxeles o frames se benefician de acceso compartido a buffers.
5. Motores de reglas o simulación: cuando varios hilos consultan y actualizan estado controlado, la memoria compartida puede ser más eficiente.

En un equipo de LatAm, donde muchas veces se optimiza tanto por costo de infraestructura como por tiempo de entrega, una mejora de este tipo puede traducirse en menos instancias, menos memoria o menos colas internas. No es magia, pero sí una palanca útil si tu carga de trabajo encaja.

Ejemplo práctico: buffer compartido

Imagina un pipeline que recibe un archivo CSV de 200 MB, lo divide en segmentos y los procesa en paralelo. Con un enfoque clásico, cada worker puede recibir una copia o una transferencia del segmento. Con memoria compartida, varios hilos podrían leer de una misma región y coordinar offsets.

const shared = new SharedArrayBuffer(1024 * 1024);
const view = new Uint8Array(shared);

for (let i = 0; i < view.length; i++) {
  view[i] = i % 256;
}

console.log("Shared buffer length:", view.length);

Ese ejemplo no resuelve por sí solo la coordinación entre hilos, pero muestra la idea base: el dato no necesita copiarse para existir en varios contextos. Lo que falta después es una capa sólida de sincronización.

Riesgos, límites y preguntas abiertas

La memoria compartida siempre trae el mismo dilema: ganas velocidad, pero sube la complejidad. Si dos hilos escriben al mismo tiempo sin coordinación, el bug puede no aparecer en pruebas pequeñas y sí en producción, cuando el tráfico o la carga suben. Ese tipo de error es caro porque suele ser intermitente.

Otro punto es la seguridad. Cualquier runtime que exponga concurrencia con memoria compartida tiene que cuidar bien el aislamiento y los límites de acceso. Si la implementación no está bien cerrada, puedes terminar con problemas difíciles de auditar.

También está la pregunta de adopción. Aunque Bun avance con esta PR, eso no significa que el ecosistema JavaScript vaya a migrar de inmediato a este modelo. Muchas librerías, frameworks y equipos están construidos alrededor del patrón de eventos y asincronía clásica. El cambio real suele ser gradual.

Qué deberías mirar si quieres evaluar esta propuesta

Si trabajas en backend o infraestructura, te conviene mirar al menos estos puntos:

• cuánto dato necesitas mover entre tareas
• si hoy tu cuello de botella es CPU, memoria o I/O
• si el costo de serialización ya te está pegando en métricas reales
• si tu equipo puede manejar sincronización y debugging más complejo
• si tu entorno de despliegue puede beneficiarse de menos copias de datos

La recomendación práctica es no enamorarte de la idea solo por rendimiento. Primero mide. Si tu app ya se cae por CPU en tareas intensivas, la propuesta puede ser relevante. Si tu problema real es una consulta lenta a base de datos, esta discusión no te va a salvar.

Qué significa para el ecosistema JavaScript

Si Bun logra llevar esta capacidad a JavaScriptCore de forma estable, el ecosistema gana otra opción seria para trabajo paralelo. No reemplaza a Node.js ni a los Web Workers, pero sí empuja la conversación hacia modelos más cercanos a sistemas de alto rendimiento.

Eso puede tener efectos secundarios interesantes. Librerías de procesamiento intensivo podrían empezar a ofrecer rutas optimizadas para runtimes con shared memory. Equipos que hoy separan servicios por miedo al costo de concurrencia podrían reconsiderar parte de su arquitectura. Y más de un benchmark podría dejar de compararse solo en throughput de requests y empezar a mirar también latencia de coordinación entre hilos.

Para Latinoamérica, donde muchas empresas combinan presupuestos ajustados con necesidad de escalar rápido, cualquier mejora que reduzca copias, memoria y tiempo de CPU tiene valor real. No porque sea una moda, sino porque impacta directamente en infraestructura y operación.

Tabla resumen

La lectura corta es esta: Bun está empujando una pieza que, si madura, puede mover la conversación sobre concurrencia en JavaScript. No porque cambie todo de golpe, sino porque abre una vía más directa para compartir memoria y exprimir mejor el hardware en tareas pesadas.

Si tu trabajo vive cerca del procesamiento de datos, buffers grandes o pipelines intensivos, vale la pena seguir esta propuesta de cerca. Si tu app es más de UI, formularios y llamadas HTTP normales, probablemente te afecte poco. Pero incluso ahí conviene entender el cambio, porque el ecosistema JavaScript suele adoptar primero estas ideas en runtimes nuevos y después las filtra al resto.

Tabla resumen