El 15 de septiembre pasado tuve el honor de participar como ponente en las 4Sessions que organiza la fundación Techdencias, y aburrí un rato al personal hablándoles de la nueva librería experimental para .Net, llamada Blazor.

Comencé la charla recalcando (para evitar tomates y otros proyectiles hacia mi persona si las demos fallaban), que este framework es totalmente experimental (aún no hay versión final), y por tanto, la evolución del framework es muy rápida. Lo que hoy funciona, mañana puede dejar de hacerlo, o bien porque se haya roto algo, o bien porque los desarrolladores hayan decidido que una determinada implementación no les parece adecuada y la han cambiado. Sea como sea, desde el repositorio del proyecto Blazor en github ya lo dejan claro:

Nota: Blazor es un proyecto experimental. No es (todavía) un producto final. -Esto es para dar tiempo a investigar a fondo los problemas técnicos asociados con el funcionamiento de .NET en el navegador y para asegurarnos de que podemos construir algo que a los desarrolladores les guste y con lo que puedan ser productivos. Durante esta fase experimental, esperamos comprometernos profundamente con los primeros usuarios de Blazor como tú, para escuchar tus comentarios y sugerencias.

Pero, ¿qué es exactamente esto de Blazor?

Blazor es un framework experimental de .Net para web, basado en HTML y Razor Pages, que se ejecuta directamente en el navegador, mediante un nuevo estándar web llamado «WebAssembly». Podéis obtener más información sobre WebAssembly aquí. Por resumir, Blazor es un framework basado en razor pages ejecutadas en el cliente, con recursos del cliente y sin proceso en servidor. Blazor se apoya en Mono, el framework OpenSource y multiplataforma para .Net , cuyo runtime ha sido compilado para WebAssembly. Gracias a Mono, Blazor puede ejecutarse directamente en el navegador, sin necesidad de transpilaciones ni pasos adicionales.

Este framework ha sido pensado para crear aplicaciones SPA completas basadas en Razor Pages. Así, podemos ejecutar una página razor directamente en el cliente, y utilizar de forma local cualquier librería NetStandard, ya que será compatible con Mono y por tanto debería cargarse sin problemas.

Muchas veces la gente pregunta si es algo parecido a Silverlight, pero nada más lejos de la realidad. Silverlight era un plugin que permitía ejecutar un reducido runtime de .Net. Sin embargo, WebAssembly es un estándar, y con él se ha compilado el runtime de Mono. Blazor funciona en todos los navegadores modernos: Chrome, Firefox, Safari… y lo hace en todas las plataformas. ¿mola, a que sí?

En la charla, a modo demostrativo, creé un proyecto de Blazor basado en una de las plantillas por defecto de Visual Studio. Se trataba de una aplicación cliente Blazor, alojada en una aplicación web de asp.Net Core. Esto no es para nada obligatorio. De hecho, podemos crear una aplicación Blazor y alojarla de manera estática, ya que no requiere de un servidor que procese ningún tipo de código. Con un Apache sin módulos adicionales nos valdría. Sin embargo, la combinación Blazor + asp.net core nos permite tener código cliente Blazor y consumir API’s de servidor desde la misma web, sin preocuparnos de cosas como cross domain. Sin embargo y para mi desgracia, el proyecto no arrancaba (no cargaba en el navegador el runtime de Mono). Más tarde (y ya sin presiones 😉 ), vi que el problema era una issue reportada con una de las últimas versiones de la librería de build. ¡Menos mal que tenía mi proyecto de demostración ya hecho y funcionando con versiones de los paquetes nuget que sí iban bien. El proyecto, que podéis descargar desde mi repositorio en Github, es una pequeña biblioteca de pega en la que podemos consultar libros, añadir libros nuevos, y editar y eliminar los libros existentes. Con este proyecto pude enseñar los conceptos más básicos de Blazor: renderización parcial basada en los cambios del dom durante la ejecución, el uso de componentes para reutilizar código entre distintas páginas, el ciclo de vida de cada componente, la forma de asignar rutas a las distintas páginas, el paso de parámetros por ruta y entre componentes, y la manera de llamar a API’s externas mediante la interoperabilidad con Javascript (más sencillo imposible, por cierto). También hablé un poco más en profundidad sobre la interoperabilidad de Blazor con Javascript (se pueden ejecutar funciones de Javascript sobre Blazor y obtener los valores de retorno), y basándome en eso, pude mejorar la accesibilidad de las páginas SPA, al poder manejar el foco, entre otras cosas. Finalmente expliqué algunas carencias que aún tiene este Framework: localización a distintos idiomas, validación en formularios… Y la más importante: la parte de cliente aún no tiene depuración. Lo bueno es que desde la consola del navegador podemos leer los mensajes de error que nos lance la aplicación, y trazar la ejecución utilizando Console.WriteLine.

En conclusión: Aprendí cómo funcionaba Blazor en menos de dos días, pues toda la sintaxis c#, razor y librerías ya las conocía. Es solo trasladar lo que ya conocemos si venimos de MVC o Razor Pages al mundo del cliente. ¡Y la velocidad de carga es genial!

En el repositorio Github del proyecto de ejemplo, podréis ver cómo está montado, cómo he compartido una librería NetStandard tanto en la parte cliente como en el servidor (para reutilizar entidades o funciones, por ejemplo), y cómo funcionan las rutas, los componentes, las llamadas a API’s y las mejoras para hacer que una SPA sea accesible utilizando la interoperabilidad con Javascript. ¡Y por supuesto, cualquier mejora en forma de pull request o comentarios será bienvenida! 🙂

¡Hasta la próxima!