¿Es cierto que el navegador deberá descargar la biblioteca de Webassembly cada vez que se cargue la página?
No, los navegadores pueden almacenar en caché los archivos. CDN común para aplicaciones Blazor hará el truco.
¿Es este sistema más rápido de trabajar que, por ejemplo, React / Vue, compilado en JavaScript?
Blazor usa el ensamblaje web, el ensamblaje web en papel debería ser más rápido que cualquier biblioteca js, sin embargo, no todos los navegadores tienen un analizador de ensamblaje web maduro todavía. Por lo tanto, es posible que los navegadores no ejecuten el ensamblaje web a una velocidad óptima a partir de ahora.
Puede 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 necesitan mejorar, incluso Firefox puede mejorar.
Si su aplicación necesita acceder a DOM con frecuencia, definitivamente el ensamblaje web / Blazor será más lento en comparación con cualquier biblioteca JS, ya que el ensamblaje web no puede acceder directamente al DOM sin usar Invokes (que es lento en este momento, consulte mi punto de referencia de blazer a continuación) .
En Firefox 10,000 RegisteredFunction.InvokeUnmarshalle
llamadas a métodos vacíos toman 250 ms, mientras que Chrome y Edge necesitan más de 2400 ms en mi PC '. En JS puro, se necesitan menos de 10 milisegundos para el mismo escenario.
Además, la implementación actual de Blazor tiene su propio motor 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 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 será 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 por el momento no podemos decir nada sobre el futuro de Blazor. Sobre el papel, Blazor puede ser más rápido que cualquier marco que exista, sin embargo, necesitamos el compromiso de los encargados del montaje 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.
Permitir que WebAssembly maneje DOM directamente.
https://github.com/WebAssembly/proposals/issues/8
Tipos de referencia para WebAssembly con GC. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md
Las dos propuestas anteriores allanarán el camino hacia 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 llegar a JS -> llamada WASM tan rápido como JS -> llamadas al método JS. A partir de ahora, FireFox está muy por delante de cualquier otro navegador cuando se trata de compatibilidad con WebAssembly
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/