Blazor es un nuevo marco web de Microsoft diseñado para competir con plataformas líderes en la industria como React. Excepto que, en lugar de utilizar JavaScript, se ejecuta en el tiempo de ejecución de .NET y posibilita a los desarrolladores crear aplicaciones web interactivas con C # y HTML.
¿Qué es ASP.NET inclusive?
Si viene del mundo de los marcos de JavaScript, es factible que esté confundido con relación a la vinculación de Blazor con ASP.NET. Ambos son «marcos web», pero Blazor es solo una parte del ecosistema ASP.NET.
Mientras que la Plataforma ASP.NET tiene casi 20 años en este momento, no es un marco de dinosaurio; ha mejorado constantemente junto con C # y .NET en su conjunto, puesto que Microsoft lo utiliza internamente. Es absolutamente multiplataforma y tan eficiente como siempre.
Al principio, solo existía ASP.NET, que se puede utilizar para hacer todo tipo de aplicaciones web. Estaba ASP.NET MVC (Model-View-Controller), que crea páginas web sustentadas en datos, y ASP.NET WebAPI, que se especializa en API de backend. Estos se fusionaron recientemente en un paquete unificado con ASP.NET Core modernizado.
Hace cinco años, Páginas de Razor (que es algo distinto de Blazor y tiene un nombre confuso) se lanzó para simplificar la sintaxis expresiva de MVC, que necesita mucho texto estándar y, como tal, no funciona bien con el diseño centrado en componentes de las aplicaciones modernas. MVC necesita que cree una vista y un modelo para cada página en archivos separados:
Mientras tanto, con Razor, puede crear páginas o componentes más optimizados con código integrado en la propia página. Esto funciona mejor cuando las páginas son más simples, pero ambas están disponibles como opciones para su uso.
Todas estas características forman parte del ecosistema «ASP.NET». La gran parte son los paquetes y el soporte. Del mismo modo que NPM para JavaScript, C # además tiene un entorno de paquetes saludable con el administrador de paquetes NuGet.
Entonces, ¿qué es Blazor?
Blazor no cambia nada sobre la sintaxis de estas páginas. Seguirás usando páginas de Razor y / o MVC. En realidad, esto ni siquiera es algo malo, debido a que ya existen numerosas interfaces de usuario y bibliotecas de componentes creadas para páginas de Razor respaldadas por C #.
Lo que agrega Blazor es interactividad. Las páginas tradicionales de MVC / Razor que usan ASP.NET siempre han sido torpes y han tenido problemas para mantenerse al día con las aplicaciones web en tiempo real como React. Las aplicaciones web en tiempo real son tan rápidas que además están comenzando a tomar el control del escritorio, con marcos como Electron que ejecutan aplicaciones en un contenedor Chromium, sin que los usuarios se den cuenta.
Entonces, Blazor fue creado para satisfacer esta demanda. Funciona de manera muy equivalente a React, donde las acciones modifican el estado y los accesorios y activan actualizaciones de la aplicación. El marco se encargará de actualizar el DOM según los componentes que necesiten actualizarse. Esto posibilita aplicaciones en tiempo real en las que la página se puede actualizar o inclusive volver a dibujar por completo sin tener que actualizar el navegador.
El beneficio de Blazor sobre un marco establecido como React es el lenguaje. Le posibilita crear aplicaciones web con C #, y eso por sí solo lo hace atractivo para muchos desarrolladores. Cualquiera que sea su opinión sobre el debate de la escritura dinámica frente a la estática, definitivamente existen beneficios para los lenguajes de «escritorio» como C #, y la web carece seriamente de alternativas a JavaScript.
Si tiene un backend que necesita un alto rendimiento, C # además se ejecutará mucho más rápido que JavaScript. Aún cuando JS no es de ninguna manera lento y ha mejorado mucho a lo largo de los años, seguirá teniendo menos rendimiento que C #, que en realidad se acerca bastante al rendimiento nativo de C ++.
Blazor posibilita una mejor interoperabilidad. Muchas aplicaciones además usan C # en el backend. A modo de ejemplo, puede tener una API ASP.NET que interactúa con su interfaz React. Necesitará modelos separados para el servidor y el lado del cliente, así como un código separado para interactuar con ellos. Si son del mismo idioma, le posibilita compartir fácilmente código y bibliotecas entre el cliente y el servidor. Esta es el motivo por la que NodeJS existe en el lado del servidor, aún cuando JavaScript no es el lenguaje de escritorio ideal, tener aplicaciones integradas en un solo idioma reduce el tiempo de desarrollo.
El futuro de Blazor
En realidad, hay algunos tipos diferentes de Blazor, puesto que Microsoft ha estado haciendo un gran impulso de desarrollo recientemente para modernizar el ecosistema ASP.NET. Hoy en día, hay dos versiones que se han lanzado:
- Servidor Blazor, que funciona como React Server Side Rendering y realiza la mayor parte del procesamiento en el servidor.
- Blazor WebAssembly, que utiliza la magia de WebAssembly para ejecutar código .NET real en un navegador web cliente real.
Microsoft además planea lanzar tres versiones más de Blazor, que aún están en desarrollo y disponibles para vista previa:
- Blazor PWA, que está diseñado para publicar el sitio como una aplicación web progresiva (PWA) instalable.
- Blazor Desktop / Híbrido, que posibilita empaquetar aplicaciones Blazor en aplicaciones de escritorio y es simplemente como Electron pero con mejor rendimiento.
- Nativo de Blazor, que reemplaza la interfaz de usuario basada en web con una interfaz nativa de la plataforma. No es claro qué tan útil es esto, al mismo tiempo de la interoperabilidad con las herramientas Blazor existentes, y esta versión aún se encuentra en las fases de planificación.
En su anuncio de Blazor Desktop, Microsoft declaró que “Blazor es un modelo de programación de aplicaciones. Es muy adaptable y se puede ejecutar de varias formas (según la necesidad) «.
Microsoft parece pensar en Blazor como su próximo estándar para crear interfaces de aplicaciones. Su trabajo además es importante destacar, debido a que a medida que las aplicaciones se vuelven cada vez más dependientes de la web, es más difícil justificar la creación de interfaces separadas para la web y el escritorio. Blazor tiene un futuro brillante y las aplicaciones web creadas hoy en Blazor Server y WebAssembly tendrán mucho espacio para crecer.
Blazor Server frente a Blazor WebAssembly
Blazor Server utiliza un Conexión SignalR para comunicarse entre el cliente y el servidor. Esta es solo una capa elegante sobre una conexión WebSocket, que opcionalmente puede recurrir a otras conexiones cuando sea necesario. Esto mantiene todo el procesamiento en el servidor y deja al cliente como una vista simple con una forma básica de manipular el DOM.
Blazor WebAssembly es donde se pone verdaderamente genial. WebAssembly (WASM) no es verdaderamente un lenguaje en el que escribe, sino un objetivo del compilador. En realidad, funciona casi exactamente como el lenguaje intermedio de Microsoft (MSIL) en el que se compilan todos los C #, F # y VB.NET. Excepto que, en lugar de ejecutarse con un tiempo de ejecución .NET, se ejecuta usando el tiempo de ejecución de WebAssembly en el navegador.
Lo bueno de WebAssembly es que es un objetivo de compilador relativamente fácil de lograr. Del mismo modo que C # se puede compilar en MSIL, C # además se puede compilar en WebAssembly. Bueno, técnicamente, es MSIL compilando en WebAssembly (puesto que es más simple), pero el punto es el mismo.
Cualquier lenguaje puede compilarse en WASM, inclusive lenguajes de escritorio absolutamente nativos como C ++. Esto no es teórico, en realidad funciona en la práctica. AutoDesk pudo portar AutoCAD, una base de código C ++ de 30 años, a una aplicación web basada en WebAssembly, en unos meses con relativa facilidad. Alguien inclusive portado Doom 3.
Blazor WebAssembly simplemente toma todo el servidor, así como el tiempo de ejecución de .NET y lo ejecuta sobre WASM. Posteriormente, en lugar de hablar con el servidor a través de SignalR, habla de forma directa con el DOM. Esto elimina el procesamiento del lado del servidor, que puede ser ideal para algunas aplicaciones.
Esto lo coloca en una posición única para competir con marcos como React, puesto que es esencialmente el primer competidor verdadero de JavaScript para aplicaciones web cliente. Aunque debe agregar algunas etiquetas de secuencia de comandos para cargar el tiempo de ejecución y es factible que tenga que sumergir los dedos de los pies en el código JavaScript para algunas cosas, en su mayor parte, debería poder crear una aplicación web de producción completa sin escribir una sola línea de JavaScript.
Blazor WASM tiene tiempos de carga inicial lentos, pero esto en realidad se puede arreglar a través de el uso de un modo híbrido que utiliza la representación previa para generar la representación inicial en el servidor, pero ejecuta todas las actualizaciones posteriores a través de WASM. Esto tiene un montón de peculiaridades y aún está en versión beta, pero si desea obtener más información, puede consulte estas guías de Jon Hilton.
Si utiliza Blazor Server o Blazor WebAssembly, depende de usted. Ambos disponen sus ventajas. Blazor Server ejecuta todo el código de procesamiento en un entorno confiable y no necesita que tenga una API pública. Blazor WASM responde y es rápido, e inclusive se puede poner en práctica como un sitio estático servido solo con NGINX.
¿Cómo funciona Blazor con JavaScript?
Sea cual sea el caso, cuenta con una interoperabilidad completa de JavaScript. Blazor puede llamar a funciones JS desde código administrado:
private async Task ConvertArray()
{
text = new(await JS.InvokeAsync<string>("convertArray", quoteArray));
}Y viceversa:
DotNet.invokeMethodAsync('{ASSEMBLY NAME}', '{.NET METHOD ID}', {ARGUMENTS});A pesar de esto, tenga en cuenta que esto, desde luego, usará la reflexión, y ciertamente no es lo más eficaz del mundo.
Técnicamente, puede utilizar todos los paquetes NPM con Blazor, aún cuando configurarlo e interactuar con él desde el lado .NET puede ser un dolor de cabeza, por lo que debería preferir un paquete NuGet la mayor parte del tiempo.
¿Puede usar Blazor en el escritorio (Electron)?
Sorprendentemente, la solución es sí. Aunque Microsoft planea lanzar Blazor Desktop / Hybrid, que hace lo mismo, mientras tanto, puede utilizar Electron normal. Esto se debe a que a Electron verdaderamente no le importa qué página web está sirviendo y solo puede servir una aplicación Blazor.
Podría pensar que usaría una aplicación Blazor WebAssembly, pero en realidad es más fácil simplemente agregar Electron a un servidor ASP.NET Core existente. WASM tiene algunos gastos generales, por lo que este método es más rápido. Eso es lo que Electron.NET lo hace, y funciona sorprendentemente bien. Todo lo que debe hacer es instalarlo y agregar Electron como un servicio ASP.NET. Además puede llamar a funciones nativas de Electron desde C #.
A pesar de esto, Microsoft tiene planes más grandes para Blazor Desktop. Planean deshacerse por completo de la dependencia de un navegador y JavaScript y simplemente ejecutar un contenedor nativo con una vista web que sea .NET hasta el final.
“El escritorio Blazor estará estructurado de manera equivalente a como funciona Electron. Habrá un control WebView que procesa contenido desde un servidor web Blazor integrado, que puede servir tanto Blazor como otro contenido web (JavaScript, CSS, etc.) «.
Esta vista web usaría Safari, WebKitGTK o WebView2, según el sistema operativo. WebView2 utiliza Chromium bajo el capó, por lo que funcionaría de manera muy equivalente a Electron, excepto por ser más eficiente y utilizar menos memoria.
Cualquiera que sea la implementación, es emocionante ver otra plataforma compitiendo con JavaScript y Electron para crear aplicaciones web y de escritorio multiplataforma. Blazor Desktop debería lanzarse en noviembre de 2021 con la primera vista previa de .NET 6.
