asp.net - net - blazor roadmap
Rendimiento Blazor (1)
Me gustaría comenzar a usar blazor, a pesar de que todavía está en el nivel alfa. Como lo entiendo, blazor usa WebAssembly para compilar C # en el lado del cliente. Y tengo una pregunta: ¿este sistema funciona más rápido que, por ejemplo, React / Vue, compilado en JavaScript? ¿Es cierto que el navegador necesitará descargar la biblioteca de ensamblajes web cada vez que se carga la página? En Internet no hay comparaciones del rendimiento de los marcos de trabajo populares de JS, por lo que me gustaría conocer el rendimiento teórico del nuevo marco de Microsoft. Gracias de antemano
¿Es cierto que el navegador necesitará descargar la biblioteca de ensamblajes web cada vez que se carga la página?
No, los navegadores pueden almacenar en caché los archivos. CDN común para las aplicaciones Blazor hará el truco.
¿Es este sistema más rápido para trabajar que, por ejemplo, React / Vue, compilado en JavaScript?
Blazor utiliza el ensamblaje web. El ensamblaje web en papel debe ser más rápido que cualquier biblioteca js, sin embargo, no todos los navegadores tienen aún un analizador de ensamblaje web maduro. Por lo tanto, es posible que los navegadores no ejecuten el ensamblaje web a una velocidad óptima a partir de ahora.
Puedes crear una pequeña aplicación blazor y ejecutarla en Firefox, chrome o edge. En la mayoría de los casos, Firefox ejecuta aplicaciones blazor mucho más rápido que Chrome o Edge, lo que implica que los fabricantes de navegadores aún deben mejorar, incluso Firefox puede mejorar.
Si su aplicación necesita acceder a DOM con frecuencia, entonces definitivamente el ensamblado web / Blazor será más lento en comparación con las bibliotecas JS ya que el ensamblaje web no puede acceder directamente al DOM sin usar Invokes (lo cual es lento en este momento, consulte mi referencia de blazer a continuación) .
En Firefox 10,000 RegisteredFunction.InvokeUnmarshalle llamadas a métodos vacíos requieren 250 ms, mientras que Chrome y Edge necesitan más de 2400 ms en mi PC ''. En JS puro, toma menos de 10 milisonds para el mismo escenario.
https://webassemblycode.com/webassembly-cant-access-dom/
Además, la implementación actual de Blazor tiene su propio motor de MSIL en la parte superior del motor de ensamblaje web de los navegadores, lo que significa que hay dos intérpretes trabajando para ejecutar un proyecto de Blazor, como dos traductores que interpretan una conversación en lugar de uno. Actualmente Microsoft está trabajando en un compilador AOT, que aún no se ha lanzado. Una vez que su lanzamiento Blazor sea mucho más rápido que la implementación actual.
http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/
Podemos asumir con seguridad que el ensamblaje web es el futuro del desarrollo web, pero en este momento no podemos decir nada sobre el futuro de Blazor. En papel, Blazor puede ser más rápido que cualquier marco existente, sin embargo, necesitamos el compromiso de los mantenedores de ensamblajes web, los desarrolladores de navegadores, Microsoft y las comunidades para que las teorías sean prácticas.
Actualización 10 de julio de 2018
Hay nuevas propuestas en los repositorios de WebAssembly.
- Permitiendo que WebAssembly maneje DOM directamente. https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md
- Tipos de referencia para montaje web con GC. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md
Por encima de dos propuestas, se abrirá el camino para una interacción mucho más rápida entre DOM y el ensamblaje web en el futuro. IOW Blazor será mucho más rápido en el futuro.
Actualización 17 de octubre de 2018
El equipo de Firefox pudo alcanzar la llamada JS -> WASM tan rápido como las llamadas de método JS -> JS. A partir de ahora, Firefox está muy por delante de cualquier otro navegador en lo que se refiere al soporte de WebAssembly.