Chrome 150 estrena el streaming HTML fuera de orden en el navegador
Las primitivas declarativas ya están en el HTML Living Standard y WebKit y Mozilla han dado su visto bueno; los métodos de streaming para JavaScript siguen en otro proceso.
Chrome y Edge 150 ya reparten soporte nativo para el streaming HTML fuera de orden, la técnica que permite ver y usar una página antes de que la respuesta HTTP se cierre. Hasta ahora cada framework se lo montaba por su cuenta; la propuesta lo lleva al propio motor del navegador, que va parchando huecos en el DOM conforme llegan los datos. Las primitivas declarativas han entrado en el HTML Living Standard del WHATWG y tanto WebKit como Mozilla han publicado posturas favorables.
Cómo funciona el marcado
Todo se apoya en el elemento <template> y en un atributo for nuevo. El desarrollador deja un punto de inserción con una instrucción de procesado, por ejemplo <?marker name="profile">, o envuelve un contenido de relleno entre <?start name="profile"> y <?end>. Cuando el servidor manda más tarde un <template for="profile">, el parser localiza el identificador que coincide, borra los marcadores y los nodos de relleno que queden entre ellos, e inserta el contenido del template en esa posición del DOM. El mecanismo admite varias actualizaciones sobre el mismo punto: basta con repetir el template con su <?marker> para ir añadiendo elementos a una lista según llegan.
Hay una restricción de seguridad que conviene tener clara. Un <template for> solo puede parchear instrucciones de procesado situadas en su elemento padre inmediato, es decir, sus hermanos directos y los descendientes de estos, para que un marcado no confiable no secuestre formularios ni destinos de navegación de otra parte del documento. La excepción está escrita en el propio estándar: si el template cuelga directamente de <body>, el ámbito pasa a ser todo el documento y las actualizaciones diferidas pueden alcanzar elementos dentro de <head> o en contenedores estructurales anidados.
La API de JavaScript va por otro camino
Junto al marcado hay una familia de métodos de inserción estáticos y de streaming: setHTML, replaceWithHTML, beforeHTML, prependHTML, appendHTML y afterHTML, con sus equivalentes streamHTML, streamAppendHTML y las variantes *Unsafe. streamHTMLUnsafe() devuelve un WritableStream que va metiendo los trozos en el parser de fragmentos interno. En el lado del cliente, fetch se apoya en response.textStream() para encadenar la respuesta directamente al contenedor de destino.
La idea tampoco es nueva. Facebook la puso en producción con BigPipe en 2009 y frameworks como React, con el streaming de Suspense, o Next.js popularizaron variantes parecidas. Lo que cambia es que el objetivo común, que una parte lenta de la página no bloquee el resto, deja de depender de la implementación de cada framework. Los detalles de la propuesta están en el repositorio del WICG.
Los métodos DOM de streaming siguen en un proceso de estandarización aparte, así que el soporte no está cerrado: textStream() llega en la versión 151. Para quien mantiene una aplicación con renderizado en servidor, la pregunta práctica es cuándo compensa soltar el framework y cuándo lo que ya hace bien sigue siendo mejor negocio que migrar.