Fox*_*Pro 46 asp.net webassembly blazor
我想开始使用blazor,尽管它仍处于alpha级别.据我了解,blazor使用WebAssembly在客户端编译C#.我有一个问题:这个系统的工作速度是否比使用JavaScript编译的React/Vue更快？浏览器每次加载页面时都需要下载Webassembly库吗？在互联网上没有比较流行的JS框架的性能,所以我想知道微软新框架的理论性能.先感谢您
Vib*_*nRC 88
浏览器每次加载页面时都需要下载Webassembly库吗？
不,浏览器可以缓存文件.Blazor应用程序的常见CDN可以解决这个问题.
这个系统的工作速度是否比使用JavaScript编译的React/Vue更快？
Blazor使用Web组装,On paper web assembly应该比任何js库更快,但并非所有浏览器都有成熟的Web程序集解析器.因此,您可能会发现浏览器不会以最佳速度运行Web程序集.
您可以创建一个小的blazor应用程序并在Firefox,chrome或edge中运行它.在大多数情况下,Firefox运行blazor应用程序的速度比chrome或edge快得多,这意味着浏览器制造商仍然需要改进,即使Firefox可以改进.
如果您的应用程序需要经常访问DOM,那么与任何JS库相比,Web程序集/ Blazor肯定会更慢,因为Web程序集无法在不使用Invokes的情况下直接访问DOM(目前速度较慢,请参阅下面的我的blazer基准测试) .
在Firefox上,RegisteredFunction.InvokeUnmarshalle对空方法的10,000次调用需要250ms,而我的PC中的chrome和edge需要超过2400ms.在纯JS中,对于相同的场景,它需要低于10毫英寸.
https://webassemblycode.com/webassembly-cant-access-dom/
此外,当前的实现Blazor在浏览器Web程序集引擎之上有自己的MSIL引擎,这意味着有两个解释器正在运行Blazor项目,就像两个翻译员在一个上解释对话.目前,微软正在开发一种尚未发布的AOT编译器.一旦它发布Blazor将比当前实现快得多.
http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/
我们可以放心地假设网络组装是Web开发的未来,但目前我们对Blazor的未来一无所知.在纸面上Blazor可以比任何框架更快,但是我们需要Web组装维护人员,浏览器开发人员,Microsoft和社区的承诺来使理论变得切实可行.
WebAssembly存储库中有新的提议.
以上两个提案将为未来DOM与webassembly之间更快的交互铺平道路.IOW Blazor将来会更快.
Firefox团队能够像JS - > JS方法调用一样快地达到JS - > WASM调用.截至目前,FireFox在WebAssembly支持方面远远领先于任何其他浏览器
.NET 6 的 ASP.NET Core 路线图可以在 github上找到。您会发现 Blazor 迄今为止的任务最多。
请注意，该列表表明 ASP.NET 团队将重点关注的项目，这意味着他们将重点放在改进 Blazor 上。
本期代表了我们团队在 .NET 6 时间范围内将重点关注的主要投资列表。此列表中的项目只是主要的投资领域，并不包括我们在此期间要解决的所有功能和错误修复。
以下是他们一直在做的一些任务：
完成任务：
AOT 编译。将所有内容编译为 WebAssembly
改进 Blazor 中的 SVG 支持。Blazor 中 SVG 支持的顶级问题
支持 JS Interop 中的字节数组传输。
正在进行的任务
Blazor 的热重载。构建性能优化
暂停和恢复 Blazor 应用程序。
定位并部署到桌面平台。
消除 SignalR 消息大小施加的大小限制。
拖放。提供用户在拖放过程中可以订阅的事件
小智 5
据我了解，Blazor 使用 WebAssembly 在客户端编译 C#。
一半是真的。您可以将代码写入 WebAssembly (WASM) 客户端（是的，客户端是 C#），但您也可以执行逻辑服务器端。两者都有好处。如果你走 WASM 路线，你的所有代码都是可见的。但是它可以比逻辑全部基于服务器的情况更快地重新呈现——但是如果它是基于服务器的，则您的代码是不可见的。
这种方法是否比例如用 JavaScript 编译的 React / Vue.js 运行得更快？
不。我已经完成了大量的 Vue.js 并且 Vue.js 运行得更快。不过，我可以写代码大量使用Blazor更快。Blazor 提供了一个虚拟滚动解决方案，可以让它看起来更快。在我的情况下，可用的绘图组件太慢了。我使用 C# 和 JavaScript 编写了一个运行良好的 Blazor 组件。大多数时候我不担心 WASM 代码运行太慢......但是绘图需要快得多......而 Blazor 让我有我的蛋糕......我只需要做一些低级别的工作JavaScript。在过去的六个月中，Blazor 的执行速度变得更快，该团队表示，当.NET 6出现时，还会有更多。但是对于我需要做的 99% 的事情来说，它已经足够快了。
每次页面加载时浏览器都需要下载 WebAssembly 库是真的吗？
如果它们被缓存，则不会。即使它们是第一次加载，如果您有良好的连接，速度也不慢。它大约为 10 MB。
一个很好的未提出的问题 - 值得使用吗？我已经使用它大约六个月了。
对我来说已经很棒了。C#是一门非常好的语言。有时我会想念动态添加一个属性，并且通常您必须手动启动重绘，但是可空对象检查等功能会警告您没有检查您的代码是否会导致空引用检查——它比 JavaScript 好得多。我经常觉得使用 JavaScript“工具链”很痛苦。能够选择退出 JavaScript 库的冲击真是太好了。
2021 年 4 月，我们针对旧版 Angular.js Web 应用程序以及 Flutter Web（HTML 和 CanvasKit 渲染器）对 Blazor WASM 进行了试验。我们重新创建了旧版应用程序的主页（本质上是一个带有过滤器、分页、排序等功能的大数据网格）。这里有一些要点：
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
*Lighthouse 给出了错误的 LCP 值（它将 Blazor 的空白“正在加载...”页面计为 LCP）
^Flutter 的 CanvasKit 渲染器不允许 Lighthouse 获得 LCP 测量
`遗留应用程序比创建的 PoC 大得多，有更多的屏幕和资产会影响应用程序启动时的请求数量
| 归档时间： |
|
| 查看次数： |
10916 次 |
| 最近记录： |