Dos perfiles de renderizado, un núcleo

Rustelo empezó con una única forma de renderizar una página: compilar cada componente a WebAssembly e hidratarlo en el navegador. Para una aplicación interactiva es el intercambio correcto. Para un sitio hecho sobre todo de artículos, no. El coste cae donde el sitio no recibe nada a cambio: una compilación wasm32 en cada pipeline, bundles de varios megabytes, una cadena de herramientas que se rompe con desajustes de versiones y errores de hidratación entre el HTML del servidor y las señales del cliente, un tipo de fallo que solo existe porque la página se hidrató.

La decisión: un eje tipado, no una bifurcación

En lugar de un segundo framework, Rustelo añadió un perfil de renderizado al que ya tenía (ADR-006). RenderingProfile es un enum con dos valores:

• LeptosHydration: renderizado de Leptos en el servidor más hidratación WASM. Es el valor por defecto, así que los sitios existentes mantienen su comportamiento sin cambiar una línea.
• HtmxSsr: HTML renderizado en el servidor, con HTMX para la interacción: el cambio de tema, el de idioma, los filtros y los formularios pasan por endpoints propios con intercambios fuera de banda. Sin WebAssembly.

Una ruta puede declarar su perfil; un espacio de trabajo declara uno por defecto; el enum aporta el último recurso. La resolución es ruta sobre espacio de trabajo sobre valor por defecto, y ocurre al resolver la ruta, así que cada ruta resuelta ya lleva su perfil efectivo.

Por qué importa que sea tipado

El perfil es un tipo, no una cadena repartida por los crates. Una configuración que nombra un perfil desconocido se rechaza al leerla, y el código que decide según el perfil hace match sobre un enum cuya exhaustividad comprueba el compilador. El proyecto lo mantiene como restricción estricta: los nombres de perfil solo aparecen como cadenas donde se interpretan.

Lo que gana un sitio

Un sitio cuyas rutas son todas HtmxSsr se ahorra por completo la compilación wasm32: un único destino nativo, un artefacto más pequeño, nada de wasm-bindgen en CI. Sus páginas son plantillas que renderiza Minijinja, y cambiar una plantilla no exige recompilar Rust.

Un sitio que necesita ambos conserva ambos. Una página tipo panel que necesita respuesta local inmediata puede seguir en LeptosHydration mientras los artículos que la rodean se sirven como HTML desde el mismo binario. El coste es explícito: bajo HTMX-SSR cada interacción es un viaje al servidor, lo correcto para contenido y lo incorrecto para una interfaz rica; justo por eso la elección es por ruta.

Puntos de extensión en lugar de interruptores

Cada perfil llega al código propio del sitio a través de puntos de extensión que define el framework y que el sitio rellena una sola vez al arrancar: un renderizador de la carcasa, fragmentos, filtros, plantillas. Sin registro, el framework responde con un error tipado en lugar de un intercambio roto. El framework es el mismo para todos los sitios; lo que cambia es lo que registra cada uno.

Este sitio se sirve con el perfil HTMX-SSR.