WebForms Core 2.2 arranca su desarrollo con estado sin servidor y snapshot del DOM

WebForms Core ha empezado a desarrollar la versión 2.2. El proyecto, un framework de interfaz orquestada desde servidor que no guarda el estado de la UI en la máquina, quiere subir un escalón con nuevas operaciones de renderizado, gestión de estado, transformación de datos, formateo y aritmética. No hay release ni fecha: lo que se ha anunciado es la dirección del desarrollo.

Un modelo sin estado, a diferencia de Blazor Server

El propio proyecto marca la distancia con Blazor Server. Aquel mantiene un circuito con estado en el servidor por cada navegador conectado, con su árbol de componentes, su árbol de render y un espejo del DOM. WebForms Core no hace nada de eso: el servidor define las operaciones a través de la clase WebForms, genera comandos y WebFormsJS los ejecuta contra el documento HTML real que hay en el navegador. La estructura la decide el servidor; la ejecución sobre el DOM es cosa del cliente. El servidor orquesta sin convertirse en dueño permanente del estado del navegador, y eso cambia el perfil de escalado: no hay una estructura viva por usuario que mantener.

Las piezas que llegan en 2.2 van en esa línea.

Isole, snapshots y hashes

Isole es una abstracción de alto nivel sobre el DOM transitorio. Se encarga por su cuenta de la inicialización y el cierre alrededor de un grupo de operaciones, de modo que el desarrollador ya no tiene que manejar a mano las llamadas StartTransientDOM y EndTransientDOM. Sirve para aislar una tanda compleja de transformaciones sin salirse de la jerarquía de ejecución que ya existe.

Snapshot y rollback añaden algo parecido a un punto de guardado: se conserva el outerHTML de un elemento antes de tocarlo, se modifica, se renderiza o se enlaza repetidamente a una plantilla, y si hace falta se vuelve al estado anterior. Útil cuando varias operaciones tienen que partir del mismo HTML original.

GetTagHash genera un hash a partir de la representación HTML de una etiqueta. Se almacena y más tarde se compara con un hash nuevo para saber si el HTML ha cambiado. Es detección de estado sin que el servidor tenga que replicar el DOM del navegador, y abre la puerta a validación de estado, renderizado condicional y optimizaciones.

A esto se suman operaciones de formateo sobre valores cacheados o guardados: insertar el separador de miles en una cifra como 4200, o normalizar un tiempo del tipo 23:1:8 a 23:01:08. El mecanismo admite expresiones regulares, por ejemplo (\d)(?=(\d{3})+$), lo que evita cadenas de condicionales para casos de formato repetitivos. El anuncio también menciona operaciones aritméticas dentro del modelo de comandos, aunque ahí se queda.

El código vive en el repositorio de WebFormsJS y en la organización del proyecto.

El interés real está en el modelo, no en la lista de operaciones. Si el servidor no necesita espejar el DOM, el coste por usuario conectado baja y desaparecen los problemas clásicos de reconexión y circuitos colgados que arrastra cualquier arquitectura con estado en servidor. Queda por ver cuándo sale, si mantiene compatibilidad con la rama 2.x actual y si el rendimiento en cliente acompaña cuando las transformaciones se encadenan.