使用 WebAssembly + Blazor 的优缺点？
Pros and cons of using WebAssembly + Blazor?
我的问题是：
- 是否每次打开SPA都下载runtime？即使它被缓存，下载运行时对于网络应用程序来说不会花费太多时间吗？
- 是否将其他程序集（Nuget、C++ 库等）发送到浏览器？如果是这样，那是不是太贵了，会不会导致应用程序打开时间太长？
- 与 V8 上的 Javascript 相比，性能是否足够好？
- 与 Razor 相比有什么惊人的区别吗？
并且，在回答所有这些问题后，是否有任何理由在 Javascript 上使用 Blazor+Wasm？
这些是您可以不费吹灰之力就用谷歌搜索到的多个问题，我想人们会因此对您投反对票。我会花时间回答你的问题。
Is runtime downloaded every time SPA is opened? Even if it is cached, won't downloading runtime take way too much time for web app?
正如您在 webassembly.org 上看到的那样，webassembly（进一步称为 Wasm）是 stack-based 虚拟机的二进制指令格式，具有开放的 API并运送到 Chrome、Edge、Firefox 和 WebKit。正如@HenkHolterman 提到的，有一个小的运行时需要由客户端至少加载一次，除非他们清除缓存。这意味着客户端第一次加载基于 Wasm 的 Web 应用程序时可能会有更糟糕的体验，这种体验有多糟糕，我无法准确地说出，使用 Fiber 2,5 mb 并不显着，使用edge/2g 或 gsm/3g 移动连接可能很重要。
Are additional assemblies (Nuget, C++ libs, etc) sent to browser? If so, isn't that too size-expensive and won't it cause an app to open way too long?
当您构建/编译您的 Blazor 应用程序时，您通常会恢复所有依赖的程序集和包，并且它们在部署后静态托管在主机上。客户将不需要任何额外的程序集。
Is performance better enough comparing to Javascript on V8?
这取决于。 Wasm 目前不知道 DOM，因此 Blazor 在需要时使用 Wasm 重新呈现页面。应该清楚的是，使用 JavaScript 对大页面中的单个或少数 DOM 元素进行操作会更快。除此之外 Wasm 渲染整个页面的速度更快，可能最适合需要这种性能的网络应用程序，例如游戏或 3d 渲染。对于正常的浏览体验来说差异太小，如果应用程序设计不好，使用任何一个都会很糟糕。
Are there any breathtaking differences comparing to Razor?
Blazor 是一个侧重于应用程序交付的框架，而 Razor Pages 是作为一种新的 .Net 开发方法引入的，与 MVC 不同。现在 Blazor 使用与 Razor 非常相似的语法，简化了事件调用之类的事情并将视图和代码统一在一个文件中，但主要区别在于 Blazor 可以是 serve-rside 或 client-side，而 Razor 只能服务于第一个。这是您在两者之间做出决定时要考虑的因素。
话虽如此，您应该知道 WebAssembly 并没有试图取代 JavaScript，正如他们 FAQ 中所描述的那样，它旨在作为对它的补充。决定是否在任何 JavaScript 框架上使用 Blazor 取决于您是否想要依赖 JavaScript 以及您的开发团队是否对 C# 更有信心以及.Net 堆栈和生命周期。
我的问题是：
- 是否每次打开SPA都下载runtime？即使它被缓存，下载运行时对于网络应用程序来说不会花费太多时间吗？
- 是否将其他程序集（Nuget、C++ 库等）发送到浏览器？如果是这样，那是不是太贵了，会不会导致应用程序打开时间太长？
- 与 V8 上的 Javascript 相比，性能是否足够好？
- 与 Razor 相比有什么惊人的区别吗？
并且，在回答所有这些问题后，是否有任何理由在 Javascript 上使用 Blazor+Wasm？
这些是您可以不费吹灰之力就用谷歌搜索到的多个问题，我想人们会因此对您投反对票。我会花时间回答你的问题。
Is runtime downloaded every time SPA is opened? Even if it is cached, won't downloading runtime take way too much time for web app?
正如您在 webassembly.org 上看到的那样，webassembly（进一步称为 Wasm）是 stack-based 虚拟机的二进制指令格式，具有开放的 API并运送到 Chrome、Edge、Firefox 和 WebKit。正如@HenkHolterman 提到的，有一个小的运行时需要由客户端至少加载一次，除非他们清除缓存。这意味着客户端第一次加载基于 Wasm 的 Web 应用程序时可能会有更糟糕的体验，这种体验有多糟糕，我无法准确地说出，使用 Fiber 2,5 mb 并不显着，使用edge/2g 或 gsm/3g 移动连接可能很重要。
Are additional assemblies (Nuget, C++ libs, etc) sent to browser? If so, isn't that too size-expensive and won't it cause an app to open way too long?
当您构建/编译您的 Blazor 应用程序时，您通常会恢复所有依赖的程序集和包，并且它们在部署后静态托管在主机上。客户将不需要任何额外的程序集。
Is performance better enough comparing to Javascript on V8?
这取决于。 Wasm 目前不知道 DOM，因此 Blazor 在需要时使用 Wasm 重新呈现页面。应该清楚的是，使用 JavaScript 对大页面中的单个或少数 DOM 元素进行操作会更快。除此之外 Wasm 渲染整个页面的速度更快，可能最适合需要这种性能的网络应用程序，例如游戏或 3d 渲染。对于正常的浏览体验来说差异太小，如果应用程序设计不好，使用任何一个都会很糟糕。
Are there any breathtaking differences comparing to Razor?
Blazor 是一个侧重于应用程序交付的框架，而 Razor Pages 是作为一种新的 .Net 开发方法引入的，与 MVC 不同。现在 Blazor 使用与 Razor 非常相似的语法，简化了事件调用之类的事情并将视图和代码统一在一个文件中，但主要区别在于 Blazor 可以是 serve-rside 或 client-side，而 Razor 只能服务于第一个。这是您在两者之间做出决定时要考虑的因素。
话虽如此，您应该知道 WebAssembly 并没有试图取代 JavaScript，正如他们 FAQ 中所描述的那样，它旨在作为对它的补充。决定是否在任何 JavaScript 框架上使用 Blazor 取决于您是否想要依赖 JavaScript 以及您的开发团队是否对 C# 更有信心以及.Net 堆栈和生命周期。