DEV Community

loading...

Blazor

pablinme profile image Pablo Miranda Updated on ・5 min read

Blazor presenta la oportunidad de escribir interfaces web con HTML, CSS y C#

Lo importante sería que permite utilizar C# en vez de JavaScript, y esto para mi ya es un punto a favor y el tener el runtime de .NET es valor agregado.

TypeScript sería lo más cercano ha utilizar C# ya que lleva parte de la funcionalidad y características existentes en C# a JavaScript y lo natural debía ser llegar a un punto en el que se pueda utilizar C# directamente. Lenguajes van y vienen con la promesa de "mejorar" JavaScript pero siempre hay alguna descompensacion, se mejora en unas partes pero los problemas de fondo persisten.

Flexibilidad

La flexibilidad que Blazor presenta a nivel de renderers se da gracias a la separación que existe entre la aplicación y los componentes.

alt text

De estos lo que cabe recalcar es que hay que ver hasta que punto resulta funcional, por ejemplo yo no veo que tenga sentido alguno tener renderer -tipo Electron- para escritorio cuando se tiene ya la experiencia con Electron y los resultados que dejan mucho que desear por el pobre desempeño y alto consumo de memoria.

Espero que Microsoft se concentre primero en WebAssembly para que Blazor sea competitivo en front-end, de allí a nivel remoto haciendo el "render" en el servidor me imagino que Blazor reemplazará a Razor Pages eventualmente cuando exista una mayor acogida, y en principio los dos trabajan con Razor Components

Blazor WebAssembly

En este caso todo sucede a nivel de cliente en el navegador, por lo que el runtime -Mono- es compilado y transferido al navegador junto con las librerías y dependencias por lo que lo primero que se tendría que revisar es que tan pesado es el runtime, en previews estaba por los 2 megas, y lo seguirán reduciendo conforme optimizan el tamaño del mismo.

alt text

Lo particular es que al ejecutar código de C# en el navegador utilizando WebAssembly se pude reutilizar código y librerías existentes en el servidor

alt text

Aquí es donde debería brillar la ventaja de utilizar C# en front-end y back-end al mantener un lenguaje común, de paso el formato de WebAssembly es bytecode eficiente y optimizado que no requiere de plugins. WebAssembly también brinda acceso a toda la funcionalidad del navegador a través de interoperabilidad con JavaScript y por lo mismo todo el código se ejecuta en un sandbox.

Este modelo presenta varios beneficios respecto a "Blazor Server"

  • No hay dependencia del servidor ya que una vez descargada es completamente funcional.
  • No se necesita necesariamente un hosting ya que se puede proveer la aplicación a través de CDN.
  • La carga de trabajo sucede en el cliente

A tener en cuenta:

  • La aplicación funciona en el marco de las capacidades del navegador.
  • A medida que la aplicación es mas compleja puede adquirir un tamaño que no sea conveniente para descargar, se traduciría en un mayor tiempo de carga.
  • Conlleva las limitaciones que presenta utilizar .NET Standard.

Blazor Server

En este caso el renderer esta a nivel de servidor y los cambios en la interfaz de usuario desde el cliente son transmitidos al servidor a través de una conexión -constante- SignalR.

alt text

Los eventos que se registran en el navegador se transmiten al servidor donde los componentes son actualizados y enviados de vuelta al navegador donde los cambios se fusionan a nivel de nodos en el DOM.

Toda esta carga en el servidor por la actualización constante de los componentes podría presentar problemas de desempeño y por lo mismo su uso depende mucho del escenario en el que se lo quiera utilizar.

Este modelo presenta varios beneficios respecto a "Blazor WebAssembly"

  • El tiempo de carga es mucho menor ya que el payload de descarga es significativamente mas pequeño.
  • La aplicación se mantiene en el marco de posibilidades que presente el framework de .NET existente en el servidor.
  • La aplicación funciona en navegadores que no soportan WebAssembly.
  • El código de la aplicación no se transfiere al navegador.

A tener en cuenta:

  • Cada interacción del usuario implica el uso de la red y puede existir latencia.
  • Al necesitar una conexión constante al servidor, no hay modo offline y si la conexión falla la aplicación deja de funcionar.
  • El servidor no solo debe mantener las conexiones a los clientes sino también su estado.

Cómo se compara con Razor Pages?

Respecto a los modelos tradicionales como Razor Pages y Razor Views utilizan Razor para describir los componentes de HTML.

El render con Razor funciona de la siguiente manera, cada línea escrita con Razor emite HTML y el servidor desecha la página o vista junto con el estado que se haya producido hasta ese punto, por lo que cuando se necesita nuevamente de esa página o vista se requiere emitir nuevamente todo el HTML y transmitirlo al cliente.

Aún si es un cambio minúsculo se necesita regenerar la página por completo.

Blazor trabaja con componentes reutilizables que contiene el código C# , markup y a su vez otros componentes. Cuando un componente es renderizado Blazor produce un grafo similar al DOM donde también guarda la información del estado, campos y propiedades y con esto produce una representación binaria (bytecode) del mismo.

Esta representación binaria puede ser convertida a HTML (texto) o reutilizada eficientemente.

Cuando un componente es requerido, es compilado en el servidor y este transmite el HTML resultante al cliente donde es renderizado por el navegador.

En este punto el grafo se vuelve importante ya que cuando es renderizado se calcula la diferencia respecto a la última petición y esta se envía al cliente para que sea aplicada por el navegador.

En Blazor los componentes son mantenidos en memoria siempre que el cliente interactúe con ellos, recordemos que el componente conlleva el código y posiblemente otros componentes a la vez, por lo que podría llevar a consumir recursos en exceso.

SignalR

Cada cliente se comunica con el servidor utilizando una o varias conexiones llamadas circuitos, en el contexto de Blazor este circuito es una abstracción sobre la conexión SignalR que puede tolerar interrupciones temporales en la red.

En el navegador un iframe o una pestaña, representa una o varias nuevas conexiones al servidor, es decir demanda más recursos.

Cada circuito nuevo representa nuevas instancias de los componentes y la administración del estado de los mismos para el servidor. Solo cuando se cierra el navegador o la pestaña el servidor da por terminada esa conexión y libera los recursos asociados a ese circuito.

Latencia

A nivel de UI la latencia es el tiempo transcurrido desde que el usuario interactúa con un elemento lo que conlleva el inicio de una acción a la que el servidor debe responder, procesar y enviar el resultado de vuelta al cliente. En el camino se suma la latencia de la red y la del servidor al procesar la acción (RAM).

En una intranet esta latencia seria casi imperceptible, cosa que no sucede si la aplicación esta en internet donde entra en juego también la ubicación geográfica. No hay que olvidar tampoco la latencia que introduce el servidor en memoria si se hace uso frecuente del garbage collector y/o paginación de la memoria en el disco.

Así aplicaciones desarrolladas con Blazor Server, presentan un ejercicio interesante al obligar al desarrollador a tomar en cuenta cosas como el uso eficiente de memoria y tener un ojo en la latencia de red también, cosa no muy común en el desarrollo web.

Discussion (0)

pic
Editor guide