Resumibilidad: continuar en vez de reconstruir

Las tres técnicas anteriores aceptan que el cliente tiene que reconstruir el árbol de componentes y discuten cuánto y cuándo. La resumibilidad rechaza la premisa: si el problema es que el cliente necesita el estado y los cierres que el servidor ya tenía, la solución es mandárselos, serializados, y que continúe desde ahí sin ejecutar nada. El cambio no es de grado sino de categoría, porque el coste de arranque deja de depender del tamaño de la aplicación.

La idea: continuar en vez de reconstruir

Cuando el servidor renderiza, tiene todo lo necesario: el árbol de componentes, el estado, y los cierres de cada manejador con sus variables capturadas. Al terminar, tira todo eso y manda solo el HTML. El cliente lo reconstruye desde cero. Esa es la hidratación.

La pregunta de la resumibilidad es: ¿y si no lo tiramos? Si el servidor serializa el estado y anota, junto a cada elemento interactivo, qué función hay que ejecutar y con qué variables capturadas, el cliente no necesita ejecutar nada por adelantado. Necesita un fragmento minúsculo de código que escuche eventos globalmente y que, cuando llegue el primero, lea la anotación, descargue esa función concreta y la invoque con su estado.

El resultado es que la carga de una página no ejecuta código de aplicación. Ninguno. El arranque cuesta lo que cuesta descargar y ejecutar un kilobyte de escucha, sea la aplicación de cinco componentes o de cinco mil.

Qwik es la implementación de referencia de esta idea y es donde conviene estudiarla, pero el concepto es independiente del framework.

Cómo se serializa un cierre

Aquí está la parte técnicamente interesante, porque un cierre no es un dato: es código más un entorno.

El código se resuelve en tiempo de compilación. Un paso del compilador extrae cada función marcada como frontera a su propio módulo, con un nombre estable. Donde tú escribiste una función en línea, el resultado compilado es un módulo aparte y una referencia con la forma “en este fichero, este símbolo”.

El entorno se resuelve por serialización. Todas las variables que el cierre captura se recogen en una tabla global de estado que se emite al final del HTML, y la referencia del manejador incluye los índices de sus capturas dentro de esa tabla.

Esquemáticamente, el HTML resultante tiene esta forma:

<button on:click="/build/q-a3f0.js#s_boton_comprar[0,2]">
  Comprar
</button>

<!-- ... al final del documento ... -->
<script type="application/json" id="estado">
  [ {"id":42,"precio":19.9}, "eur", {"unidades":1} ]
</script>

El atributo dice tres cosas: de qué fichero cargar, qué símbolo invocar, y qué posiciones de la tabla de estado son las variables que ese cierre capturaba. Cuando el usuario pulsa, el escuchador global —registrado en el documento desde el primer momento— lee el atributo, importa el módulo, reconstruye el cierre con los valores de las posiciones 0 y 2, y lo llama.

Tres detalles que hacen que esto funcione de verdad y que no son obvios.

El escuchador es global y minúsculo. Un único manejador delegado en el documento para todos los tipos de evento que aparecen en la página. No recorre nada, no conoce el árbol, no tiene estado propio.

La deserialización es perezosa. La tabla de estado puede ser grande, y analizarla entera al cargar reintroduciría el problema que se quería evitar. Lo que se hace es envolverla en proxies que deserializan cada rama la primera vez que alguien la lee. Si el usuario solo pulsa un botón, solo se deserializa lo que ese botón necesita.

El grafo de estado admite referencias compartidas y ciclos. Dos componentes que apuntan al mismo objeto tienen que seguir apuntando al mismo objeto después de deserializar, o el estado deja de estar sincronizado. Por eso el formato no es JSON plano sino una tabla con referencias por índice: es lo que permite reconstruir un grafo y no un árbol.

El coste se mueve a otro sitio

Ninguna técnica elimina trabajo; lo reubica. Aquí se reubica en dos sitios muy concretos.

En el tamaño del HTML. El estado serializado viaja en el documento. En páginas con mucho estado —una tabla con doscientas filas y su modelo completo— eso pesa. La contrapartida es que ese peso sustituye al que ya pagabas con hidratación, donde el estado también viajaba duplicado; la diferencia es que aquí no hay además un paquete de framework que ejecutar.

En la primera interacción. Cuando el usuario pulsa por primera vez, hay que ir a buscar el módulo de ese manejador. Si no está en caché, es una petición de red en el camino crítico de la interacción, y eso cuenta para el INP.

La mitigación es una precarga especulativa: el framework emite, junto al HTML, la lista de módulos que probablemente se necesiten, y un service worker o unos link de precarga los traen durante el tiempo ocioso. Bien afinado, cuando el usuario pulsa, el módulo ya está en caché y la interacción cuesta la ejecución sola. Mal afinado —una conexión lenta, una lista de precarga demasiado optimista— la primera pulsación de cada componente tiene una ida y vuelta encima.

Este es exactamente el mismo intercambio del disparador de interacción de la hidratación progresiva, con dos diferencias a favor: aquí los trozos son mucho más pequeños, porque la unidad es una función y no un componente entero, y la precarga la calcula el framework en vez de tú.

Qué exige y qué limita

Ser honesto con los requisitos importa más que la promesa, porque son los requisitos los que deciden si esto encaja en un proyecto.

Exige un compilador y una sintaxis de frontera. El programador tiene que marcar dónde están las fronteras de serialización. En Qwik eso se hace con un sufijo en las funciones. No es opcional ni deducible: el compilador necesita saber qué extraer.

Restringe lo que se puede capturar. Todo lo que un cierre capture tiene que ser serializable. Objetos planos, arrays, primitivos, fechas, mapas, conjuntos y referencias a otros objetos serializados, sí. Instancias de clases con métodos, funciones arbitrarias, conexiones abiertas, no. Cuando lo necesitas, hay que reestructurar para que lo que cruce sea un dato y no un comportamiento.

Rompe la compatibilidad con el ecosistema. Una librería de componentes escrita para un modelo de hidratación asume que se ejecuta al cargar. Hay capas de compatibilidad, con su coste, pero no es cierto que puedas usar cualquier paquete existente sin pensar.

Cambia el modelo mental del equipo. El razonamiento sobre qué se ejecuta y cuándo deja de ser el habitual. Es aprendible y no es complicado, pero es distinto, y ese coste hay que contarlo.

La comparación honesta, entonces: