Saltar al contenido
Framework Ecosystems LabsUn contrato, muchos ecosistemas, la misma prueba.

Por qué sí y por qué no — Hidratación#

⬅️ Clase 094 · 📚 Parte 7

Por qué sí Por qué no Qué se paga
Astro Por omisión no hidrata nada: su pantalla inerte pesa 277 bytes Cada isla necesita una integración —React, Vue, Preact— y su motor completo Islas que no se hablan entre sí sin un almacén aparte
Next.js La frontera es explícita y está en una línea del archivo Quitar interactividad no quita bytes: la carga RSC crece con lo renderizado Vigilar qué cruza la frontera, porque todo lo que cruza se envía
SvelteKit csr = false por ruta: el interruptor más claro de los cinco El resultado de load se serializa siempre, quieras o no Elegir entre bytes ahora o una petición después
Nuxt El HTML más ligero del elenco en las dos pantallas Su interruptor lleva «experimental» en el nombre Depender de una opción que puede cambiar de forma
Remix Una sola etiqueta gobierna toda la hidratación, y se ve en el documento raíz No hay forma de apagarla para una ruta: es todo o nada Aceptar el coste en pantallas que no lo necesitan

🧭 Lo que este contrato no puede probar#

💡 Lo que hay que llevarse#

La hidratación es un arreglo, no un diseño. Nació de juntar dos cosas que se habían inventado por separado —renderizar en el servidor, que es lo que la web hacía desde el principio, y componentes con estado en el navegador, que es lo que trajo la parte 6— y el pegamento entre las dos es serializar el estado y repetir el render.

De ahí salen las tres cosas que hay que recordar:

  1. El dato viaja dos veces, y sale 2 en los cinco. No es una mala implementación de nadie. Es la definición del mecanismo.
  2. El trabajo se hace dos veces. El componente se ejecuta en el servidor y se vuelve a ejecutar en el navegador para llegar al mismo resultado. Svelte manda menos motor, pero repite el render igual.
  3. Quitar interactividad no siempre quita peso. La pantalla sin hidratar de Next pesa más que la hidratada. Si la intuición dice lo contrario, hay que medir.

Y de ahí sale también el resto de la parte. Las cuatro clases siguientes son cuatro formas de pagar menos por lo mismo: hidratar solo un trozo (095, islas), no mandar el componente en absoluto (096, componentes de servidor), empezar a mandar HTML antes de tenerlo entero (100, flujo) y renunciar al mecanismo (103, hipermedia).

Ninguna de las cuatro existiría si hidratar fuera gratis. Entender esta clase es entender por qué existen las otras.

Fuentes#