Blazor (I): La revolución del front-end web

Desde los primeros tiempos, cuando un desarrollador Netscape llamado Brendan Eich invento el lenguaje JavaScript, este lenguaje fue ganando importancia, según la web se convertía poco a poco de información estática en información dinámica, y puesto que la web necesitaba cada vez más tener la posibilidad de que las páginas en el servidor fueran programables, controlando la información que introducía el usuario, verificarla, producir efectos visuales etc termino convirtiendo a JavaScript (y en los últimos años sus distintos frameworks) en uno de los lenguajes de programación más importantes, usados, demandados laboralmente y de práctica casi obligada de ser aprendido.

Pero los principios de JavaScript no fueron tan maravillosos, ya que como tantas veces ha pasado, cada compañía tiene ligeras variantes del lenguaje, lo que obligaba a conocer esos detalles, pero poco a poco esto ha ido mejorando según se vio la necesidad de estandarizarlo.

A día de hoy JavaScript y sus distintos frameworks (por ejemplo Angular o Vue.js) sigue siendo el rey indiscutible de la programación del lado del cliente (frontend).

La tendencia actual del mercado es a hacer cada vez más lo que se llama aplicaciones enriquecidas, es decir, aplicaciones que interactúan con el usuario como si fueran nativas del propio sistema operativo, o sea, rápidas, robustas, amigables, visualmente muy atractivas, y debido a esto tenemos lo que se llama SPAs (del inglés Single Page Application).

Este tipo de aplicaciones, SPA, obligan a los desarrolladores .NET (al igual que otros lenguajes como Java) a aprender mucho más que si simplemente pudieran tenerlo todo en .NET.

La solución de Microsoft

Blazor es un proyecto desarrollado por Microsoft creado para permitir crear SPAs únicamente usando como lenguajes de programación C# y Razor Pages, haciendo nula la necesidad de programar en Javascript o frameworks derivados, o al menos casi siempre, porque sigue habiendo algunos casos donde no se puede.

El objetivo y el deseo de Microsoft está muy claro: entrar de manera directa en el mundo de los SPA a través de Blazor, teniendo una curva de aprendizaje plana para los desarrolladores .NET, abstrayendo la complejidad que requiere el tener que trabajar con frameworks Javascript. Basta echar un vistazo a las ofertas de trabajo para ver como la situación actual esta creando esa dualidad, entre aquellos que controlan un lenguaje .NET, (o Java, Python, etc) que se ejecuta en el servidor (desarrolladores backend) y aquellos que controlan el desarrollo en el navegador (frontend, usando HTML5, CSS3 y Javascript con sus correspondientes frameworks). Finalmente veremos con «Developer fullstack» a aquellos que controlan ambos lados. Evidentemente la curva de aprendizaje es mayor.

Vamos a ver los diferentes modelos de hospedaje que ofrece Blazor a continuación.

Modelos de hospedaje de Blazor

Blazor presenta dos modos, enfoques diferenciados:

• Blazor Server: se construye el DOM (Document Object Model) que se ha de enviar al cliente desde el servidor. Es el modelo más tradicional, cuyo objetivo es sustituir el modelo Web Forms de .NET. Su principal fuerte es la interacción en tiempo real entre cliente y servidor a través de SignalR.
• Blazor WebAssembly: modelo SPA basado en WebAssembly, es decir, la construcción del DOM se realizará en el lado del cliente. Permite  a su vez realizar operaciones en el lado del servidor, llamando a APIs para solicitar datos, con la intencionalidad de obtener información sensible que no se quiera calcular en el cliente. Para entender esto, hay que explicar qué es WebAssembly.

Respecto a que son los componentes Razor podéis ver una explicación de la propia Microsoft en este enlace

https://docs.microsoft.com/es-es/aspnet/core/blazor/components/?view=aspnetcore-6.0

Blazor WebAssembly

 WebAssembly

Esta tecnología que suena (por lo de Assembly a viejos tiempos) es la clave del funcionamiento de Blazor WebAssembly (que puede abreviarse como Wasm), el modelo más nuevo y que es un estándar que permite ejecutar código binario en un navegador web para ofrecer un rendimiento a priori mayor que Javascript.

El servidor web se encargará de enviar al navegador cliente que realice una petición a nuestra aplicación las librerías directamente compiladas (dlls), y el navegador a través de esta tecnología sabrá interpretar lo que queremos ejecutar. Como consecuencia, el servidor web se liberará de procesar lógica, ya que se realizará en el cliente, lo que evidentemente acelera mucho la percepción que tenemos del funcionamiento de la aplicación SPA.

Con este modo de operación, se tiene la necesidad de mantener en el servidor el procesamiento de información que no se quiera llevar al cliente, y que las librerías compiladas son fácilmente descompilables, lo que podría suponer un riesgo para la seguridad de la aplicación.

JS Interop

Como se comento antes, esto no significa que nunca sea necesario Javascript, ni tampoco que sea imposible usarlo, sino simplemente que eliminamos gran parte de su necesidad, simplificando y acelerando el desarrollo de nuevas aplicaciones. Para aquellos casos en que se quiera seguir usando Javascript tenemos el servicio IJSRuntime.

Esto quiere decir que, sin salirnos del entorno.NET, podremos realizar peticiones a funciones escritas en Javascript, pasando los datos que se requieran a dichas funciones.

Conclusión

Como resumen y conclusión final, podemos decir que Blazor (y en especial Blazor WebAssembly) ha venido para quedarse. Es un framework que apenas acaba de empezar a andar, pero muy completo, con el cual Microsoft está apostando fuerte para desarrollos en los que se requiera una alta carga de desarrollo front end, en especial si se requieren interfaces muy enriquecidas e interactivas para el usuario. Si triunfará o no, sólo el tiempo lo dirá. Lo que es seguro es que, a cada nuevo proyecto que se plantee, tendremos que meter en la ecuación de frameworks a utilizar la variable «Blazor».

De hecho, hace apenas unos meses si en una búsqueda de empleo poníamos Blazor el resultado era 0 … ahora eso está cambiando. Habrá que esperar para ver la evolución, pero apostaría que esta nueva idea, junto a otras como Azure van a ser una combinación ganadora.