Aspnetcore: 将 .NET Core 与 WASM 体验与 Blazor 分开

嗨@EisenbergEffect！ WebAssembly 的核心工作实际上由 Mono 团队处理。 我们正在他们提供的基础上构建 Blazor。 .NET 社区中的其他人也可以免费这样做，其中一些已经是（ Ooui 、 Uno 、 cshtml5 ）。 您可以在Mono 存储库中关注 mono.wasm 的进展。

我对将 Mono 编译为 WebAssembly 非常不感兴趣。 我只对 .NET Core 感兴趣。 我要求的是这样的：

• 使用 .NET CLI 创建 .NET Core C# 项目。
• 使用 .NET CLI 将我的 .NET Core 项目编译为 WASM，具有上述 3 个输出。

@danroth27今天支持吗？

Mono 人员还致力于将 .NET 代码以及支持的 MSBuild SDK 完全提前 (AoT) 编译为 WebAssembly。 他们发布的最后一次更新是http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/。 @mhutch可能是获取最新状态的最佳联系人。

我对 Mono 不感兴趣。 我只对 .NET Core 感兴趣。 有关于 .NET Core WASM 的故事吗？

有关于 .NET Core WASM 的故事吗？

不是现在。 .NET Core 目前主要用于跨平台服务器方案。 Mono 是当今用于跨平台客户端场景（Android、iOS、macOS、游戏）的 .NET 运行时。 今天大多数 WebAssembly 场景都是客户端场景，所以 Mono 是目前最便宜的方式。 随着时间的推移，预期会出现收敛是合理的，但这需要一些时间。

FWIW 我真的认为这个运行时和平台目标的问题需要首先解决。 当我听说我必须使用两种不同风格的 .NET 来构建应用程序时……将 Mono 用于您的客户端，然后将 .NET Core 用于您的服务器……这并没有让我感到兴奋。 我只想使用 .NET Core，坦率地说，忘记了任何其他 .NET 的存在。 一个.NET 请:)

@EisenbergEffect从消费的角度来看，它应该是运行时正在运行代码的实现细节。

我不同意。 在我作为软件工程师的历史中，我从未考虑过哪个运行时正在运行我的代码是我可以忽略的实现细节。

@danroth27只是来自我的开发团队的一些反馈，我们也希望 Blazor 最终使用 .NET Core。 我们对 Mono 甚至完整的 .NET 框架都不感兴趣。 我们希望客户端和服务器上的运行时相同。

我们对 Mono 甚至完整的 .NET 框架都不感兴趣。 我们希望客户端和服务器上的运行时相同。

好吧，无论我们做什么，您都不会在服务器和浏览器中拥有完全相同的运行时：浏览器运行时需要基于 WebAssembly，但服务器不需要。 这与在 iOS 上运行与在服务器上运行的根本不同没有什么不同。 客户端和服务器的统一因素是 .NET Standard。 也就是说，我认为我们与您的目标是一致的，即希望在单个运行时实现上进行统一。 从长远来看，微软以两倍的价格拥有和维护两个运行时是没有意义的。 融合工作已经以多种方式进行。 Mono 和 .NET Core 中越来越多的代码被共享。 但是获得单个运行时仍然是一项需要一些时间的重大努力。

与此同时Blazor是一个实验，我们用什么可以工作今天进行试验😃

@danroth27感谢您的出色回复，丹！

优秀 完全同意

在星期二，2018 5月15日，上午10:54 paulost [email protected]写道：

@danroth27 https://github.com/danroth27感谢您的出色
回应，丹！

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589或静音
线程
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect我对 Mono 也有类似的看法，但是当我了解到自从微软收购 Xamarine 以来，Mono 是微软的技术......并且针对客户端场景进行了优化......我可以用它在里面运行我的“.net 标准”代码今天的浏览器......所有的担忧都被搁置一旁。

仅获取浏览器运行时组件：
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-amd64/

...现在我回到构建我自己的基于 XAML 的 UI 堆栈的 C# 目标 WebGL

需要明确的是，这与使用非 Microsoft 技术无关。 这是关于只想使用 .NET Core。 我正在寻找一个具有统一跨平台 CLI 的开源跨平台 .NET。 不是两个或三个 .NET 或多个编译器。 我原以为新的努力将集中在 .NET Core 和统一方面，所以我发现 WASM 仅适用于 Mono 并且需要不同的工具链，这让我感到惊讶。

10 多年来，我个人一直在要求统一 .NET 平台。 所以，如果我在这个线程中有点激动，请原谅我，因为 10 年后我仍然需要 3 个 .NET 来构建我的服务和客户端。 我愿意等10年的事情很少。 几年前我离开了 .NET，自 12 月以来一直在回顾它，看看情况是否有所改善。 发现我留下的许多相同问题仍然挥之不去，我感到非常沮丧。

我是真诚的，我想再次爱上 .NET。 请认真对待这件事。

我是真诚的，我想再次爱上 .NET。 请认真对待这件事。

我们正在认真对待这个问题，我们正在积极致力于各种 .NET 运行时的融合。 但这需要时间，而且我们很可能会在短期内决定，出于实际考虑，继续使用 Mono 并制定更长的路线图以与 .NET Core 融合是有意义的。

我仍然需要 3 个 .NET 来构建我的服务和客户端

我假设您所指的三个 .NET 是 .NET Framework、.NET Core 和 Mono。 好消息是我们在 BUILD上

FWIW，Mono 已经切换到 Roslyn 编译器和 msbuild 构建系统，所以它并不是一个真正不同的工具链。 您可以在一个解决方案中使用相同的构建系统和编译器构建基于 .Net Core 和 Mono 的项目。 Mono 还使用了 .NET Core 类库中大量且不断增加的部分。

WASM 是一个非常不寻常的目标。 不仅无法进行 JIT 编译，线程、文件和套接字等与大多数其他平台具有非常不同的模型。 Mono 有许多现有技术为移植到其他不寻常/受限平台（如 iOS、watchOS、PS4 等）而开发，这些技术有助于 WASM 移植，例如 IL 解释器、合作 GC 暂停、具有泛型共享的完整 AOT（对于泛型来说非常困难） 、LLVM 位码后端和托管链接。

我完全希望 Mono 的 WASM 项目类型使用 SDK 风格的项目，通过 NuGet 提供 MSBuild SDK，并且可以从dotnet 。

我想我在这里闻到了一些讨厌 Mono 的味道，不是吗？
请不要这么快就想把 Mono 扔掉。 还记得微软不喜欢 Linux 的时候吗？ Mono 适用于 C# 开发人员。 还记得微软不喜欢 Mac OS 的时候吗？ Mono 又出现了。 现在 JavaScript 正在吃我们的午餐，猜猜谁出现了？ 你打赌，Mono 是来拯救这一天的，它是第一个在 Wasm 上运行的完整 .net。 请表现出一些尊重！

听着，我们这边的 C# 开发人员喜欢 Mono。 他们做得非常出色。 让 Mono 独自一人。 如果酷孩子 .Net Core 想参加派对，那也没关系，但是 MONO 会留下来！

@humbersoft如果你想知道我们“讨厌” Mono 的原因，我会给你一个。 它在浏览器控制台中看到这样的错误：“WASM：它应该已经安装在`/Users/builder/jenkins/workspace/test-mono-mainline-webassembly/label/highsierra/sdks/out/wasm-interp/ lib/mono/4.5/mscorlib.dll' 目录。” 詹金斯是谁？ 多么奇怪的消息！ Mono 开发人员显然在运行时硬编码了他/她的个人路径。

@paulost Jenkins 是一个持续构建服务。 搜索它。 它很受欢迎。

谢谢@MisinformedDNA但为什么 Mono 告诉我它应该安装在我系统上的那个确切路径中？ 我不是要构建 Mono，而是仅使用它来运行 blazor 应用程序。 附带的运行时不应该告诉您它的构建服务路径。

我没有错误的完整上下文，但我可以保证您会看到其他调试信息，因为 Blazor 不是已发货的产品。 Mono 可能会发布，但我们也可能使用 Mono 的预览版本或构建在 Mono 之上的预览库。 请记住，我们仍处于试验阶段。

最后，Xamarin 在 Mono 上运行，Mono 可能运行数以千计的移动应用程序。 这是一项很好的技术。 有一个运行时会更好吗？ 当然。 但是 .NET Framework 仅适用于 Windows，Mono 后来被创建为与 Linux 兼容的端口，然后创建了 .NET Core 以在云中实现更好的可扩展性。 您真的认为 MS 更喜欢管理三个独立的运行时吗？ 当然不是。 但并非每种语言都具有 .NET 的规模或雄心。 此外，万一您错过了，MS 正在将 WPF、WinForms 和 UWP 移植到.NET Core 3.0 。 .NET Core 是未来，但这需要时间。

是的，Mono webassembly 支持处于预览阶段，尚未在任何版本中提供。

在这种特殊情况下，运行时尝试根据其当前文件系统位置确定运行时程序集目录（其中包含 mscorlib.dll 之类的文件），最后一个回退是编译运行时的路径。 在 wasm 上，“文件系统位置”的概念并不真正适用......在其他类似的嵌入式设置中，嵌入代码通常会注册一个自定义程序集解析器（例如，从 android APK zip 中解析），我想这没有已经在这里设置了。

@PaulOst
这就是生活在最前沿的事情，你很可能会被裁掉。 用于 WASM 的 Mono 处于早期阶段并且非常具有实验性，但它比 Blazor 最初基于的 DotNet Anywhere 更完整。 它肯定还没有完善，所以像你遇到的那样的错误是可以预料的。

有些开发人员喜欢热门话题，有些则宁愿等到一切都平静下来。 这些都是热点，也许您需要稍微调整一下您的期望。 不过我理解观点，你想要一个抛光的产品。 你能想象等待 .NET Core 以 Wasm 为目标吗？ 他们可能要到 3 年才能得到它。 Mono 是一个可靠的产品，微软拥有它们是一件幸运的事情，否则，我们不会有 WASM 和许多其他平台的 .NET 故事。

另一件事，我向您提出，大多数开发人员更喜欢正在公开开发此类重要技术的新 Microsoft。 我们最终会得到更好的产品。

尽管如此，由于各种充分的理由，Blazor 甚至可能看不到曙光。 也为此做好计划。

我继续并开始构建一个在浏览器中本地运行的 Xaml 引擎。 你可以在这里查看： https :

加入这个讨论有点晚，但惊讶的是这么多人关心他们的 .NET 标准代码如何运行。 将您想要的任何标签贴在运行时上——Mono、.NET Core、FlubberGast——无论实际运行时会有所不同。 服务器上的 .NET Core 不可能与 WASM 上的 .NET Core 相同，也不会针对 WASM 进行编译。 那么到底谁在乎呢？

重要的是橡胶如何与道路相遇或访问该运行时代码的难易程度。 我同意@EisenbergEffect 的观点，即拥有更简单的低级路径来引导 .NET 可能对 .NET 总体来说是一个巨大的推动。

除了 Blazor 所做的事情之外，为什么不认真推动这一点，因为这肯定会推动围绕在浏览器中使用 .NET 的不同方式的创新。 如果在浏览器中以新的和创新的方式使用 .NET 的大量新项目弹出，那么这对于 NET 的可见性只会是一个巨大的优势。 我确定 Rob 在问是因为他对如何构建某种新框架有一些想法:-)

这在今天使用当前的 Mono.wasm 模块是可行的，在未来使用 .NET Core 或至少是 Mono AOT 编译器，但我认为构建一个标准的托管接口可以促进 .NET 引导到浏览器中，这将大有帮助这个目标。 当更新的技术和资源可用时，实际的运行时间可以被插入和换出。

对于 .NET 来说，这似乎是一个巨大的机会，可以成为 WebAssembly 领域的早期采用者。 我所看到的 Blazor 看起来非常有希望，但我认为如果这是 .NET 的唯一官方 WASM 暴露点，我认为它的思考还不够深入。 我真的很喜欢 Blazor 模型及其允许的功能，但我认为如果运行 .NET 的生态系统像创建标准 .NET 应用程序一样简单，那这只是冰山一角。 我不一定在这里谈论 UI 框架 - 但即使只是能够引导和调用松散的 .NET 类，或者作为入口点和 Web Worker 之类的处理，或者甚至作为与现有 JavaScript 应用程序进行互操作的手段。 即便如此，共享一些业务/验证代码的好处也可能非常有价值。

潜力巨大 - 通过使这项技术（即使是较低级别的位）易于使用来尽可能地实现这一点会很酷！

@RickStrahl它可能看起来并不进步，因为他们仍处于实验阶段，但他们有很多想法正在研究，包括服务器渲染、桌面/移动应用程序、网络工作者等。这会让你更好地了解什么他们正在考虑。

哦，我不认为 Blazor 不是进步的 - 我在上面的消息中澄清了。 即使只是玩这个，我也完全可以说这将是构建应用程序的好方法。 有很多小时刻，你只是去 - 这在 Javascript/Typescript 中会很痛苦。

我的观点主要是我认为除了Blazor 内容

我不确定我是否理解，Blazor 允许我们使用大部分 .NET 功能，您认为缺少哪些具体功能？

我必须使用 Blazor。 如果我有一个现有的 HTML 应用程序，或者使用另一个框架构建一些东西并且不需要 Blazor，该怎么办？ 在 HTML 框架之外的浏览器中提供对 .NET 代码的访问（共享验证代码、实用程序等）仍然是一个很好的用例。

我必须使用 Blazor。 如果我有一个现有的 HTML 应用程序，或者使用另一个框架构建一些东西并且不需要 Blazor，该怎么办？ 在 HTML 框架之外的浏览器中提供对 .NET 代码的访问（共享验证代码、实用程序等）仍然是一个很好的用例。

我不明白。 Blazor 本质上是：

1. Web 组件的 Razor 语法，
2. 各种 JS 互操作助手，
3. 基于 Mono 的 WebAssembly .NET

你大概想要其中的第二个和第三个，第一个不会伤害你。

我的观点主要是我认为除了 Blazor 内容之外，他们还应该添加原始 .NET 功能。 无论如何都必须构建此基础结构以支持 Blazor，所以为什么不以更用户友好的方式公开它，以便将 .NET“托管”放入客户端应用程序中很容易。

这当然是我理解的mono.wasm 努力的意图。 我们经常将 Blazor 和 mono.wasm 相提并论，但实际上 Blazor 只是一个 Web 框架。 mono.wasm 提供了基于 WebAssembly 的底层 .NET 运行时。 其他框架可以自由地构建在相同的运行时之上，并且已经存在替代框架（ Ooui 、 Uno ）。 @kumpera @mhutch可能是 Xamarin 团队中合适的人，他们希望围绕使用 mono.wasm 独立于任何特定 UI 框架来实现开发体验。

今天，该 zip 文件为在没有 Blazor 的情况下编写 C# 应用程序提供了极其原始的支持。 这足以验证技术，但它需要大量的手动工作。

我们的目标是提供这个问题描述所暗示的内容，一个完整的工具链，包括丰富的绑定和调试。

哪个压缩文件？

@EisenbergEffect您应该关心的是 .NET Standard，而不是 .NET Core。
确保您的依赖 API 依赖于 .NET Standard，并且您很好。

@weitzhandler我认为您可能没有理解我的观点。 如果我想用 .NET 构建一些东西，我必须安装一些具体的工具集，不是吗？ 我在 15 年前开始使用 .NET，所以我个人并不觉得这些令人生畏或令人困惑（尽管我不想在我的机器上安装准复制工具）。 但是，想象一下没有 .NET 经验的 Mac 用户。 他们决定要构建一个 .NET 应用程序，包括前端和后端。 他们听说 .NET Core 是最新的、时髦的东西，所以他们通过繁琐的程序来安装 .NET CLI 和 VS Code。 然后，他们发现他们无法用它来构建前端。 他们需要去获得一套不同的工具（不同的名称，来自不同的地方，不同的领导，等等）。 再一次，假设他们之前没有使用过 .NET。 这不是一次好的第一次体验。 好的，现在想象这个人是一名架构师或 CTO，他试图对 .NET 进行第一次或多年后的新评估。 也许他们正在为他们的公司设定方向。 这是您希望那个人或他们的技术顾问拥有的经验吗？ 他们将把它与 Go、Node、Rust 等进行比较。

至于我个人的感受，在.NET这么多年，这么多版本之后，我的容忍度是相当低的。 我正在努力帮助像@danroth27这样的人了解一些必须发生的事情才能让像我这样的人再次对 .NET 产生兴趣。 除了这些，还有很多，但更多的统一肯定会有所帮助。 我只想安装一个 CLI 和 VS Code。 在非 Windows 平台上启动和运行全栈 .NET 应用程序的过程不应该比这更复杂。

我最初的帖子旨在从开发体验和构建输出的角度简单地描绘 WASM“北极星”应该是什么样子。 我安装了 CLI，我编写了一些 C# 代码（使用我想要的任何编辑器），然后我执行 CLI 命令将我的 C# 代码构建到 WASM，生成一组合理的输出文件（wasm、绑定、类型）。 那应该是目标。 如果它今天不在那里，那是可以理解的。 但是，让我们确保我们在正确的方向上航行 .NET 船，朝着最好的体验前进，而不是满足于对 Microsoft 工程师来说最简单或最快的方法。

@艾森伯格效应
Rob，我同意目标最终是让 .NET Core 到处运行，甚至用它替换 Mono。
我什至想要一个“ .NET UI 标准”，它在任何地方都呈现相同的内容以包含在 .NET Core 中，但 .NET Core 相对较新。 .NET Standard 是解决这种差异的最佳解决方案，目前看来您没有比这更好的要求了。

对于@EisenbergEffect提出的相同观点，我的投票是用 .NET Core 替换 Mono。

@EisenbergEffect我有一个 caliburn micro for web 的梦想，这是你的想法吗？ 实际上，在 webassembly 出现之前的一段时间，我就开始使用淘汰赛和 Duocode（mscorlib 的 JavaScript 端口）开发精神继承者。

@AndersMalmgren Aurelia 很像今天的网络版 Caliburn.Micro。 我们今年要发布的 vNext 版本甚至支持替代渲染器，因此它不仅可以渲染 HTML，还可以渲染原生桌面、3d 和控制台应用程序。 它是用 TypeScript 编写的，而不是 .NET。 一旦这项技术更加成熟，将来某个时候可能会将 Aurelia 移植到 .NET Core。

也就是说，由于微软正在构建 Blazor，我不太可能亲自为 .NET WASM 构建任何东西，因为这会让我与微软竞争。 从历史上看，我们知道，当微软决定构建类似的东西时，.NET 生态系统中的任何开源都没有任何意义，无论开源是否设计得更好、更可扩展、更高性能等。我承认很漂亮厌倦了这里。 唯一可能改变这种情况的是，如果微软聘请我领导一个基于 .NET Core 的前端框架和生态系统。 不过，它不会是 Blazor。 在我看来，Blazor 的设计不正确（它重复了 10 年前的 .NET 反模式），也不够雄心勃勃，不够符合标准，或者不够前瞻性。 这对微软来说是一个更大的机会，但窗口正在关闭。 我曾试图说服微软的各种人接受他们能做的事情，但到目前为止我都没有成功。 前端现在似乎并不是微软的重中之重。

@EisenbergEffect对我来说问题是 Blazor 使用 Razor，它是 MVC。 我们需要一个真正的 MVVM，它可以发挥完整 clr 运行时的功能。 就像基于类型约定的模板等。我从 DuoCode 和 Knockout 开始这项工作，并使用我的 Knockout.BindingConventions 将它们粘合在一起。 我什至得到了这样的语法

public IEnumerable<IResult> Save()
{
    var confirm = new ConfirmResult("Proceed?");
    yield return confirm;

    if (confirm.Result == ConfirmResults.Cancel)
        yield break;

    yield return new service.SendCommand(new SaveSomethingCommand(this.something));
}

https://github.com/AndersMalmgren/Knockout.BindingConventions.DuoCode/wiki/IResult-state-machine

淘汰赛消失了，我对它产生了兴趣。 但梦想还在继续：D

好吧，我可能会再次从事这项工作，但使用 Vue 或类似的工具。

也许是 Aurelia 而不是 Vue，因为 Aurelia 来自 Durandal，后者来自 Caliburn.Micro。 此外，Aurelia 具有约定、vanilla JS 模型、性能更好、具有很强的标准合规性以及其他框架没有的更多优点😄

不过，它不会是 Blazor。 在我看来，Blazor 的设计不正确（它重复了 10 年前的 .NET 反模式），也不够雄心勃勃，不够符合标准，或者不够前瞻性。

它出什么问题了？

@EisenbergEffect或 Aurelia。 我喜欢 Aurelia，但由于它使用 JavaScript 或 Typescript，这是一种类型擦除语言，因此您失去了所有可以做的美妙的 CLR 运行时魔法。 加上 JavaScript DI 与您可以使用适当的 clr 运行时所做的事情相比，老实说是废话。 我为前面提到的同一个项目为 Duocode 实现了一个小型 DI 容器，在我看来，前端基于类型的注入是前进的方向。 我需要研究 Aurelia 的模块化，在当时，淘汰赛是非常可扩展的，而 Vue 似乎延续了这一趋势。

@AndersMalmgren Aurelia 可能是当今最具扩展性的前端框架。 我们正在处理的 vNext 实现也将其提升到另一个层次。 您可能还会对我们可以用 DI 做什么感到惊讶:) 它是基于类型的并且具有可扩展的生命周期等。由于 JS 对类具有本机支持，因此没有擦除。 我们还可以使用 DI 辅助方法或 Vanilla JS Symbol 对接口进行建模。 因此，TS 可以将这些与 TS 接口合并，从而实现与 .NET 相同的模式。 换句话说，你可以在运行时将IAuthenticationService注入到一个类中就好了😄 据我所知，我们是唯一可以做到这一点的框架。 我试图将尽可能多的 Xaml 和 Caliburn.Micro 好的部分带到网络上，同时留下不好的部分。 所以 MVVM 在 Aurelia 中也更加简单和强大。 我将为 Xaml 开发人员编写关于 Aurelia 的一系列博客文章，以及为 ASP.NET MVC 开发人员编写关于 Aurelia 的博客文章。 这可能会帮助人们把点点滴滴地联系起来，并理解为什么/如何使前端开发不仅快速简单，而且可靠。

@manigandham作为 .NET 开发人员、.NET 开源领导者和 Microsoft MVP，我花了很多年时间，就此类问题向 Microsoft 提供了大量反馈。 我什至曾在 Microsoft 担任过一段时间的高级 PM、高级 PM 经理和首席 PM 经理（尽管不在 .NET 团队中）。 不幸的是，在我这样做的大约 12 年左右的时间里，我看到的很少，特别是关于我就前端框架提供的反馈。 所以，如果我不想在周六写一篇关于 Blazor 的设计问题、网络标准问题、产品愿景等的 10k 字论文，你将不得不原谅我。我只是不确定它会不会不胜枚举。 如果微软想聘请我为他们领导前端的未来，我当然会考虑，但正如我所说，前端现在并不是他们真正的优先事项。 据我所知，Blazor 甚至还没有获得资金。

对于那些不认识我的人，我只想补充一点，我并不为这一切或一个愤怒的人生气。 我知道有时候当你不认识我而你只是在这里或那里阅读我的评论时，事情看起来有点像这样。 但是，我对前端非常热情。 我几乎在整个职业生涯中都在构建前端框架、库和工具。 15 年时间很短，但专注于该领域的时间相对较长。 所以，我看过很多东西，做过很多东西，并且绝对有强烈的意见。 当我看到 Microsoft 重复旧错误或做一些我已经在其他地方看到的错误时，我充满激情，并且感到沮丧。 所以，我在这里没有恶意。 我真的希望微软成功。 我希望看到他们成为前端的领导者。 老实说，当我看到这并没有发生时，我只是感到沮丧和难过。 我想要最好的 .NET 及其社区。

如果我不想在周六写一篇关于 Blazor 设计问题的 10k 字论文，你将不得不原谅我

关键是您提出了索赔，然后有人只是要求您详细了解它：

在我看来，Blazor 的设计不正确（它重复了 10 年前的 .NET 反模式），也不够雄心勃勃，不够符合标准，或者不够前瞻性。

我也会对特定的例子感到好奇。

鉴于现在 Blazor 的性质，我不确定将它与普通的 Microsoft 产品进行比较是否公平。 它_还不是_一个产品，而且它的公开开发程度远远超过了它的水平。

@chucker我明白了。 做出这样的声明而不详细说明我很便宜。 我很感激你有兴趣听到更多。

不过，从我的角度来看，我要说的大部分内容都是我以前给 Microsoft 的反馈，以前经常重复。 因此，虽然这对您来说会很有趣，但我不确定它是否会对 Microsoft 产生影响。 不知道会不会有什么变化。

也就是说，我将尝试开始概述一些东西。 不过，在 GitHub 上发表评论太长了。 如果我发布有关它的博客，我有点害怕遭到强烈反对。 在我的职业生涯中，我曾多次被不喜欢被批评的各种团体欺负和憎恨。 虽然最近主要是 Facebook/React 团队成员，但我不确定我是否想再次为它敞开心扉。

也许我可以通过某种方式来构建这样一个帖子，它会产生影响并且不会引起很多负面影响。 这是一场艰难的比赛。 不过我会考虑一下。

我可以确认，在许多方面，已知和未知的 Blazor 都不是完美的设计，我们欢迎任何建设性的反馈以使其更好。 正如我们的问题积压所证明的那样，还有很多工作要做！ 虽然设计完美几乎肯定会难以捉摸，但最终真正重要的是开发人员是否发现使用 Blazor 富有成效且有用。 这似乎是可以实现的。

@EisenbergEffect我当然欢迎您提出的任何客观和建设性的批评或反馈。 与任何客观批评一样，我不能保证它会改变任何事情。 我只能说，我们会尽力深思熟虑。

此外，没有人值得被欺负或憎恨，这种行为明显违反了我们的行为准则。

在我看来，Blazor 已经成功了。 在我使用 Microsoft 和非 Microsoft 技术进行开发的 20 年中，我每次都看到相同的模式出现。 每当出现新事物时，您都会看到两种类型的开发人员。 一个将编程模型视为到达某个地方的工具，一个喜欢花费数小时和数小时修补不同库的人。 我试图说服自己，使用来自所有这些不同公司的所有这些不同的 js 库为我作为开发人员提供了更多的流动性和自由度，但很快就会发现它们在愿景、使命和令人遗憾的某个时间点的兼容性方面是如何不同的。 我最终总是在寻找统一的编程模型，并意识到严格的约定并不总是一件坏事。 简而言之。 我关心解决方案，微软从未让我失望。 我的一些最好和最常用的 Web 应用程序都是在 Microsoft 技术上完成的，我相信 Blazor 将带来一个很好的统一编程模型，该模型运行良好，但不依赖于数百个其他库的协同工作。

在我看来，Blazor 已经成功了。 在我使用 Microsoft 和非 Microsoft 技术进行开发的 20 年中，我每次都看到相同的模式出现。 每当出现新事物时，您都会看到两种类型的开发人员。 一个将编程模型视为到达某个地方的工具，一个喜欢花费数小时和数小时修补不同库的人。 我试图说服自己，使用来自所有这些不同公司的所有这些不同的 js 库为我作为开发人员提供了更多的流动性和自由度，但很快就会发现它们在愿景、使命和令人遗憾的某个时间点的兼容性方面是如何不同的。 我最终总是在寻找统一的编程模型，并意识到严格的约定并不总是一件坏事。 简而言之。 我关心解决方案，微软从未让我失望。 我的一些最好和最常用的 Web 应用程序都是在 Microsoft 技术上完成的，我相信 Blazor 将带来一个很好的统一编程模型，该模型运行良好，但不依赖于数百个其他库的协同工作。

如果微软没有受到外部的影响，我们将被困在 winforms 和 webforms 上

https://devblogs.microsoft.com/dotnet/introducing-net-5/
今天，我们宣布 .NET Core 3.0 之后的下一个版本将是 .NET 5。这将是 .NET 系列中的下一个重要版本。

未来只会有一个 .NET，你将能够使用它来定位 Windows、Linux、macOS、iOS、Android、tvOS、watchOS 和 WebAssembly 等等。

我们将在 .NET 5 中引入新的 .NET API、运行时功能和语言功能。