7 min de lectura
Una biblioteca JavaScript desarrollada por un ingeniero de Midjourney promete acelerar radicalmente el diseño de texto en el navegador. 6 800 estrellas en GitHub en pocos días, Hacker News en ebullición, debates en X sobre si CSS ha llegado a su fin. Las demostraciones parecen magia. Pero quien mira más de cerca descubre una historia hecha de vestigios heredados de los navegadores, hacks ingeniosos y la eterna pregunta: ¿cuándo una abstracción se convierte en la solución —y cuándo se convierte en el problema?
Lo esencial
- Qué: Pretext es una biblioteca JavaScript bajo licencia MIT que calcula el diseño de texto en el navegador sin activar reflows del DOM —según su autor, unas 500 veces más rápido que los enfoques basados en el DOM (una comparación que él mismo califica de «injusta»)
- Quién: Cheng Lou, ingeniero en Midjourney y colaborador de React, creador de react-motion (más de 21 700 estrellas en GitHub)
- Cómo: Enfoque en dos fases —medición única mediante Canvas (~19 ms para 500 textos), seguido de cálculo puramente aritmético en el hot path (~0,09 ms)
- Para quién: Interfaces de usuario de alto rendimiento, como herramientas de mensajería, editores o listas virtuales —no para sitios web estándar
- Contexto: Enfoque técnicamente válido, respaldado por un desarrollador serio, pero el entusiasmo viral supera con creces el nivel actual de madurez del proyecto
Por qué Internet se ha revolucionado
Hay momentos en el mundo del frontend en los que alguien presenta algo que, en teoría, simplemente no debería ser posible. Texto que fluye en tiempo real alrededor de formas arbitrarias. Burbujas de chat que se ajustan píxel a píxel a su contenido. Diseños de revistas que reaccionan a 120 imágenes por segundo. En el navegador. Sin trucos, sin soluciones alternativas, sin hacer que la página se desplome.
Cheng Lou lo demostró la semana pasada. «He atravesado las profundidades del infierno para traeros, para los próximos años, uno de los fundamentos más importantes de la ingeniería de UI», escribió en X. La modestia no es su fuerte. Pero las demostraciones cumplen lo prometido, al menos a primera vista.
Pretext es la biblioteca en cuestión. Más de 6.800 estrellas en GitHub en pocos días. En Hacker News, el debate se abrió bajo el título «El futuro del diseño de texto no es CSS». La comunidad React reaccionó como si se tratara del lanzamiento de un nuevo álbum de su grupo favorito.
Esto también se debe al remitente. Cheng Lou no es un desconocido en el mundo del frontend. En Meta, trabajó en React, ReasonML y Messenger. Su proyecto paralelo react-motion (más de 21.700 estrellas en GitHub) es una de las bibliotecas de animaciones más utilizadas en el ecosistema React. Hoy, en Midjourney, está construyendo la arquitectura frontend: pila Bun, React vanilla, sin frameworks. Cinco desarrolladores a tiempo completo para millones de usuarios. Cuando una persona de este calibre afirma que el navegador está roto, se le escucha.
El problema de treinta años que nadie había notado
Para entender por qué existe Pretext, hay que comprender qué hace realmente el navegador cuando muestra texto. Versión corta: demasiadas cosas.
Cada vez que debe calcular la altura de un bloque de texto o determinar dónde debe romperse una línea, el navegador activa un reflow de diseño. Mide los caracteres, calcula los espaciados, rompe las líneas, verifica las reglas de desbordamiento (overflow) y actualiza la disposición de todos los elementos circundantes. Se trata de una de las operaciones más costosas en el navegador. En un sitio web estático, esto no supone un problema. En interfaces dinámicas —aplicaciones de mensajería, editores, diseños animados, listas virtuales con miles de entradas—, se convierte en un cuello de botella.
¿La trampa? La mayoría de los desarrolladores nunca perciben este problema. Su sitio funciona, al fin y al cabo. El texto se muestra, las líneas se rompen, todo va bien. Solo cuando se intenta diseñar dinámicamente cientos de bloques de texto simultáneamente —una aplicación de mensajería, una herramienta de pizarra blanca, un editor de diseño de revistas— se choca contra el muro. Y ese muro lleva ahí desde que Netscape Navigator renderizó su primer diseño HTML en 1994.
Cómo Pretext engaña al navegador
La solución que propone Pretext es elegante en el plano conceptual y exigente en el técnico.
Fase 1 – prepare(): El texto se normaliza, se divide en segmentos y luego se mide mediante la API Canvas del navegador. No a través del DOM, sino mediante el motor de fuentes de bajo nivel que el navegador ya incorpora. Los resultados se almacenan en una caché. Esto lleva aproximadamente 19 milisegundos para 500 bloques de texto. Se paga una vez, se usa las veces que se quiera.
Fase 2 – layout(): A partir de ese momento, Pretext solo realiza cálculos aritméticos a partir de las anchuras memorizadas. Sin contacto con el DOM. ¿Dónde se rompe la línea? ¿Cuál será la altura del párrafo? ¿Cabe el texto en esta caja? Todas estas preguntas se resuelven mediante cálculos matemáticos, no por el motor de diseño del navegador. 0,09 milisegundos para 500 textos.
Esto permite funcionalidades imposibles de lograr solo con CSS: texto que fluye dinámicamente alrededor de formas arbitrarias; contenedores que se contraen con precisión al ancho mínimo necesario para un número determinado de líneas (shrink-wrap); diseños tipo revista con anchuras de columna variables —todo a 120 fotogramas por segundo.
Un detalle que hará fruncir el ceño a los desarrolladores frontend: según Cheng Lou, el motor se desarrolló en gran parte con ayuda de Claude Code y Codex. Estas herramientas de IA comparan sus resultados con la ground truth proporcionada por el navegador, iteran sobre los casos límite (edge cases) y optimizan el algoritmo de diseño. Se trata de un ejemplo fascinante de ingeniería asistida por IA, siempre que la tarea esté claramente definida y la señal de retorno sea explícita.
Las demos: efecto «wow» con notas a pie de página
La página oficial de demostración presenta siete ejemplos: desde diseños de acordeón hasta burbujas de chat con un espacio mínimo vacío, pasando por una demo de editor editorial con diseño multicolumna animado, citas destacadas (pull quotes) y live-reflow. A esto se suman demos comunitarias que replican diseños de revistas y cuadrículas Masonry.
A primera vista, las demos dan la impresión de algo que no debería ser posible en el navegador. El texto fluye con fluidez alrededor de obstáculos, los contenedores se adaptan en tiempo real y los diseños reaccionan sin demora perceptible. Y luego llegan los problemas cotidianos: áreas de texto (textareas) que se expanden automáticamente, centrado vertical de texto multilínea, e incluso ASCII Art tipográfico variable como prueba de concepto.
Y entonces se hace clic en el hilo de Hacker News. Y empiezan las notas a pie de página.
Lo que el entusiasmo pasa por alto
«~500x, pero es una comparación injusta».
Cheng Lou sobre su propio benchmark, X, marzo de 2026
Que el propio desarrollador califique su benchmark como «injusto» merece respeto. La aceleración de aproximadamente 500 veces en el hot path compara una ruta de cálculo en caché con una medición inicial completa mediante getBoundingClientRect(). Es un poco como decir «mi coche es 500 veces más rápido que el tuyo», pero solo si no se cuenta el tiempo de repostaje. La medición inicial (prepare) cuesta 19 milisegundos. Para la mayoría de sitios web, la diferencia es insignificante, ya que no activan cientos de reflows por frame.
Calidad de las demos al lanzamiento: Varios desarrolladores señalaron que la propia página de demostración presentaba problemas de renderizado. El texto aparecía truncado (overflow: hidden), y según un comentario en Hacker News, la página estaba «total y completamente rota» en móvil. Un desarrollador comentó con ironía: «La biblioteca que quiere arreglar la web tiene una web defectuosa». La mayoría de estos problemas ya se han solucionado.
CSS ya podía hacer esto: Algunos de los diseños mostrados —texto alrededor de formas, zonas de exclusión (exclusion zones), regiones— estaban previstos como funcionalidades CSS. CSS Exclusions y CSS Regions existen como especificaciones. Nunca se implementaron de forma generalizada porque los navegadores priorizaron otras cosas. Pretext no resuelve, por tanto, un problema de CSS, sino un problema de compromiso por parte de los navegadores. Es una distinción importante.
Nivel de madurez: Pretext es un proyecto open source temprano. El autor documenta con honestidad sus limitaciones: el uso de system-ui como fuente puede provocar mediciones imprecisas en macOS. Los contenedores muy estrechos causan saltos de línea dentro de palabras. El renderizado del lado del servidor (server-side rendering) aún no está finalizado. Quien implemente Pretext en producción hoy es un early adopter, con todas las consecuencias que ello conlleva.
Para quién es realmente relevante Pretext
La biblioteca resuelve un problema real, pero específico. Pretext resulta relevante allí donde es necesario diseñar dinámicamente y de forma simultánea numerosos bloques de texto:
- Interfaces de mensajería: Aplicaciones de mensajería que virtualizan miles de burbujas de mensajes y deben calcular previamente su altura
- Herramientas editoriales: Editores de maquetación para revistas, boletines informativos o presentaciones, que ajustan el texto en tiempo real alrededor de imágenes
- Interfaces basadas en Canvas: Herramientas de pizarra digital como Figma o Miro, que renderizan texto fuera del DOM
- Listas virtuales: Cualquier aplicación que muestre cientos o miles de bloques de texto y necesite conocer sus dimensiones antes de que aparezcan en el área visible (viewport)
Para empresas del espacio DACH que desarrollan sus propios productos SaaS con interfaces fuertemente centradas en el texto, merece la pena seguir de cerca la evolución y madurez del proyecto. Para una web corporativa, un blog o una página de destino, Pretext no aporta ninguna ventaja medible. Y eso está perfectamente bien. No toda biblioteca tiene que salvar al mundo. A veces basta con resolver elegantemente un problema complejo para un público objetivo adecuado.
Una perspectiva: entre genialidad y entusiasmo
Pretext no es ni un engaño ni una promesa vacía. El núcleo técnico —eliminar las mediciones del DOM del hot path del diseño y sustituirlas por cálculos aritméticos almacenados en caché— constituye un enfoque válido que marca una diferencia real en ciertos casos de uso. El hecho de que Cheng Lou califique él mismo su prueba de rendimiento como «injusta» y documente claramente los límites del proyecto lo distingue gratamente de los habituales influenciadores del mundo del desarrollo, que presentan cada semana un nuevo framework como la próxima revolución.
La verdad, como tantas veces, se encuentra en el medio. No, «cada sitio web que hayas usado» no está defectuoso. Esta afirmación viral entra dentro del clickbait, probablemente elegida deliberadamente. Pero el problema subyacente es real: el diseño en los navegadores es demasiado lento para ciertos casos de uso, y CSS prometió funcionalidades que nunca llegaron a materializarse. Pretext cubre ese vacío —con elegancia, rendimiento y límites claramente definidos.
Lo que queda: una hazaña técnica impresionante de un desarrollador que sabe exactamente lo que hace. Una biblioteca que, dentro de un año, será o bien un componente imprescindible en la caja de herramientas del frontend, o bien un prototipo brillante que acabará cubriéndose de polvo en la lista «Awesome JavaScript». Ambos destinos estarían plenamente merecidos.
Preguntas frecuentes
¿Qué es exactamente Pretext?
Una biblioteca JavaScript/TypeScript bajo licencia MIT que calcula el diseño del texto en el navegador sin ninguna operación DOM. Mide el texto una vez mediante la API Canvas y luego calcula los saltos de línea, alturas y posiciones puramente mediante métodos matemáticos. Desarrollada por Cheng Lou (Midjourney, ex empleado de Meta).
¿Es Pretext realmente 500 veces más rápido que CSS?
En el hot path, según el desarrollador, unas 500 veces más rápido: 0,09 ms para 500 bloques de texto frente a mediciones DOM mediante getBoundingClientRect(). El propio Cheng Lou califica esta comparación de «injusta», ya que no incluye la medición inicial única (~19 ms). Para sitios web estándar, la diferencia es irrelevante.
¿Sustituye Pretext a CSS?
No. Pretext no reemplaza el motor de renderizado del navegador. Utiliza el motor de fuentes del navegador como base, pero evita el proceso de diseño DOM para el cálculo del texto. CSS sigue siendo responsable del estilo, los colores, los espaciados y todos los demás aspectos del diseño.
¿Necesito Pretext para mi sitio web?
Probablemente no. Pretext es relevante para aplicaciones de mensajería, herramientas editoriales, interfaces basadas en Canvas y listas virtuales. No aporta ninguna ventaja para blogs, sitios corporativos o comercio electrónico. El propio desarrollador lo reconoce.
¿Qué nivel de madurez tiene el proyecto?
Más de 6.800 estrellas en GitHub, pero el proyecto sigue en desarrollo activo. Carece de renderizado del lado del servidor y la página de demostración presentó problemas de renderizado en el lanzamiento. El uso de system-ui como fuente puede llevar a mediciones imprecisas en macOS. Para su uso en producción, conviene seguir de cerca la evolución de su madurez.
¿Se desarrolló Pretext con ayuda de IA?
Sí. Según Cheng Lou, el motor se desarrolló en gran medida con Claude Code y Codex. Estas herramientas de IA comparan sus resultados con la ground truth proporcionada por el navegador e iteran sobre los casos límite. Se trata de un ejemplo interesante de desarrollo de bibliotecas asistido por IA, con una señal de retorno claramente definida.
Lecturas recomendadas por la redacción
Más artículos de la red MBF Media
Digital Chiefs: Digitalización del Mittelstand 2026 – El informe de situación sincero
SecurityToday: Copilot como riesgo de seguridad
MyBusinessFuture: La IA «Made in Germany» – 935 startups
Fuente de la imagen: Pexels / Rashed Paykary (px:31343632)
