En abril de 2021, hicimos una prueba de Blazor WASM contra una aplicación web heredada de Angular.js, así como contra Flutter Web (procesadores HTML y CanvasKit). Hemos recreado la página principal de la aplicación heredada (que es esencialmente una gran cuadrícula de datos con filtros, paginación, clasificación, etc.). Aquí hay algunas conclusiones:

 Lighthouse perf. Scores Grid Displ. Data transf. Data uncomp. Reqs. FCP SI LCP TTI TBT CLS Blazor* 2.2s 4.7MB 13.7MB 99 0.5s 1.6s 0.5s 2.1s 1.3s 0.01 Flutter HTML 1.7s 2.1MB 3.7MB 15 1.9s 2.5s 2.2s 2.3 0.2s 0 Flutter CanvasKit^ 2.8s 4.7MB 10.5MB 17 1.0s 2.2s -/- 2.2s 1s 0 AngularJS` 1.9s 2.0MB 5.7MB 294 2.1s 2.2s 2.6s 2.6s 0.1s 0

• Rejilla Despl. - tiempo que se tardó en mostrar completamente la faja (a juzgar por la línea de tiempo y las capturas de pantalla recopiladas por Lighthouse)
• transferencia de datos - datos transferidos al cargar la aplicación (pestaña Red en DevTools, cachés borrados)
• Descomposición de datos - tamaño sin comprimir de los datos transferidos (pestaña Red)
• Requisitos - número de solicitudes emitidas al cargar la aplicación (pestaña Red, cachés borrados)
• Desglose de la puntuación de Lighthouse Performance
• Probado en Windows 10, Google Chrome versión 89.0.4389.128 (compilación oficial, 64 bits), Intel Core i5 4460, 16 GB de RAM, conexión LAN por cable
• Configuraciones de lanzamiento utilizadas para crear aplicaciones, Blazor WASM/.NET 5, Flutter (Channel beta, 2.1.0-12.2.pre), AngularJS 1.7.7

*Lighthouse proporciona un valor de LCP incorrecto (cuenta la página en blanco "Cargando..." de Blazor como LCP)

^El renderizador CanvasKit de Flutter no permite que Lighthouse obtenga mediciones LCP

`La aplicación heredada es mucho más grande que las PoC creadas, hay muchas más pantallas y activos que afectan la cantidad de solicitudes al iniciar la aplicación

Según tengo entendido, Blazor usa WebAssembly para compilar C# en el lado del cliente.

Cierto a medias. Puede escribir su código en el lado del cliente WebAssembly (WASM) (sí, es C# en el lado del cliente), pero también puede ejecutar el lado del servidor lógico. Ambos tienen beneficios. Todo su código es visible si sigue la ruta WASM. Pero puede volver a procesarse más rápido que si la lógica estuviera basada en un servidor, pero si está basada en un servidor, su código no se puede ver.

¿Este enfoque se ejecuta más rápido que, por ejemplo, React/Vue.js, compilado en JavaScript?

No. He hecho un montón de Vue.js y Vue.js se ejecuta más rápido. Pero puedo escribir código mucho más rápido con Blazor. Y Blazor ofrece una solución de desplazamiento virtual que puede hacer que aparezca más rápido. En mi caso, los componentes de trazado disponibles eran demasiado lentos. Escribí un componente Blazor usando C# y JavaScript que funcionó muy bien. La mayor parte del tiempo no me preocupa que el código WASM se ejecute demasiado lento... pero el trazado tenía que ser mucho más rápido... y Blazor me dejó mi pastel... Solo tenía que hacer un trabajo de bajo nivel en JavaScript. La ejecución de Blazor se ha vuelto más rápida en los últimos seis meses y el equipo dice que habrá más cuando salga .NET 6 . Pero es más que lo suficientemente rápido para el 99% de lo que necesito hacer.

¿Es cierto que el navegador necesitará descargar la biblioteca WebAssembly cada vez que se carga la página?

No si están en caché. E incluso la primera vez que se cargan, no es lento si tienes una conexión decente. Es del orden de 10 MB.

La gran pregunta sin respuesta: ¿vale la pena usarlo? Lo he estado usando durante unos seis meses.

Para mí ha sido genial. C# es un lenguaje muy bueno. A veces echo de menos agregar una propiedad dinámicamente y, a menudo, tiene que iniciar manualmente un redibujado, pero con funciones como las comprobaciones de objetos anulables que le advierten que no verificó si su código podría causar una verificación de referencia nula; es mucho mejor que JavaScript. A menudo sentí que era doloroso trabajar con la "cadena de herramientas" de JavaScript. Es muy agradable poder optar por no participar en la biblioteca de JavaScript.

La hoja de ruta de ASP.NET Core para .NET 6 se puede encontrar en github aquí . Descubrirá que Blazor tiene, con mucho, la mayoría de las tareas.

Tenga en cuenta que la lista indica aquellos elementos en los que se centrará el equipo de ASP.NET, lo que significa que están poniendo mucho énfasis en mejorar Blazor.

Este problema representa la lista de las principales inversiones en las que se centrará nuestro equipo durante el período de tiempo de .NET 6. Los elementos de esta lista son solo áreas importantes de inversión y no incluyen todas las funciones y correcciones de errores que abordaremos durante este tiempo.

A continuación se muestran algunas de las tareas en las que han estado trabajando:

Tareas completadas:

1. Compilación AOT. Compile todo en WebAssembly

2. Mejore la compatibilidad con SVG en Blazor. Problema de nivel superior para compatibilidad con SVG en Blazor

3. Admite la transferencia de matriz de bytes en JS Interop.

Tareas en progreso

1. Recarga en caliente para Blazor. Optimización del rendimiento de compilación

2. Pausar y reanudar las aplicaciones de Blazor.

3. Apunte e implemente en plataformas de escritorio.

4. Elimine las limitaciones de tamaño impuestas por el tamaño del mensaje de SignalR.

5. Arrastrar y soltar. Proporcione eventos a los que los usuarios puedan suscribirse arrastrando y soltando