微软为什么还要推blazor？

HaHa

还是美帝思想想靠 .net 统一世界吗，为什么不抛弃那些东西，是想做下一个silverlight，还是想要IT大同

原文地址：https://www.zhihu.com/question/449227536

检验医师

对我来说，Blazor的优势，主要体现在嵌入式Linux方向。
所有的跨平台UI框架，在嵌入式系统方面，都集中在安卓上发力。
而像树莓派、香橙派这种以嵌入式Linux为主的小电脑上面，常年来只有QT可用。可QT的各种设计非常反人类。加上现在又有C++和QML的路线之争、QMake和Cmake的路线之争，搞得我越来越不想继续用了。
然后一个偶然的机会，我发现Blazor可以取代QT，甚至比QT更适合嵌入式Linux。
互联网行业，一个页面要多个人同时访问，追求迸发，所以都是用短连接。而Blazor的Server模式用的是长连接，迸发不容易拉上去，这是Blazor Server最主要的痛点。
但嵌入式行业并不追求迸发，而是追求实时性。尤其在监控程序方面，实时性压倒一切。Blazor使用长连接，反倒成了优势。
至于WASM模式，在嵌入式Linux用处也很大，就是它可以一键生成Windows商店里那种UWP的应用。用起来跟APP的感觉非常接近。
跟普通UWP程序的不同在于，它可以在嵌入式Linux上运行。还能跨不同的发行版，树莓派上能用、香橙派上能用、Ubuntu上也能用，不需要交叉编译！！！
这在安卓和IOS上貌似是理所当然的，但在嵌入式Linux上能获得接近APP的体验，本身就是革命性的变化。
最后说句得罪人的话，若不是因为嵌入式Linux一直不能跑App的话，用安卓搞嵌入式，绝对属于脑子有坑。
只要你有过一次编译安卓源码，写JNI驱动硬件的体验，这句话你就一定认同。

感恩由您

该说的其他答主都答得不错，我就来个提供个例子给大家感受一下吧。
大家说，如果用Vue、Angular、React实现一个展示数据库数据的表格，至少需要写（或维护）多少代码？
首先是前端：列定义得写多少行？写接口请求要多少行？当然用生成器生成出来的，接口改了还要跟着维护吧。
然后后端配合：写API接口，写sql...

而如果用blazor呢？请看图：



加上页面路由5行代码

看看效果：



就展现了一个从数据库获取数据的表格

这是后端用 EF Core, 加上 Ant Design Blazor 组件库的 Table 组件，直接可以绑定DbContext的DbSet，就可以自动根据实体属性生成列头，并实现服务端翻页的数据表格了。后面在用几个配置即可加上CRUD表单。
可能大家会以为这是服务端静态渲染，其实效果跟单页面一样是局部刷新的交互方式。



每次翻页是常规的两个查询

Blazor就是这么省时省力，能让开发者留出更多精力去对待生活、学习、锻炼身心，各方面发展，让前后端分离的爱好者们卷去吧...这不应该是我们想要的生活。
WebAssembly加载慢的问题在.NET 8 即将解决，全栈webui 版本的 blazor 包含的 Auto 渲染模式，在WebAssembly加载的过程中先启动Blazor Server，加载完后自动切换到WebAssembly。代码还不用写两套。
https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-4/?WT.mc_id=DT-MVP-5003987

长长的路

巨硬的东东往往理念太先进而不被大众接受。拖控件20年前就有了，但是前端圈还在追捧。数据双向绑定都玩烂了好多年各种框架才开始抄袭……blazor推一推，不是很好嘛，看哪家技术能最先效仿

感恩由您

开发web还不行，开发桌面gui已经无敌了，想象一个基于web技术栈比react更易用，又不需要考虑打包问题，还没有浏览器沙箱限制可以随意调用本地代码（包括不限于文件IO，本地多线程，多进程）且性能是js n倍的桌面开发技术是什么概念，这就是blazor hybrid

同花顺

6月26日更新：
感觉很多人对 blazor 很感兴趣，再深入详细讲讲我的看法。
(1) blazor 技术的实质
blazor 的技术实质是使用 html/css 来绘制界面，但是使用 C# 语言来互动操作而并非 js 语言来进行互动操作。C# 语言相对于 js 带巨大的生产力提升，哪怕是相对于 typescript ，生产力的提升也非常大。
因为使用 C# 得有个运行时。运行时放在服务器端的，叫 blazor server。运行时用 wasm 实现的，叫 blazor wasm。运行时扔给 MAUI，是 blazor maui （这个我没实际用过，猜的）。
当然，运行时还可以往 winform，wpf，avalonia 等上放。
(2) blazor server
这是几种 blazor 里我最喜欢的，用之前觉得它很垃圾，越用越喜欢。
它的运行时在服务器端，跟 asp.net 在一起，前端的互动会通过 websocket 发给后端，后端的响应会传递给前端进行 ui 的更新。这里不用过多考虑前后端咋通讯的，微软封装的特别好，使用体验非常棒。
从技术角度来说，blazor server 有两个缺点：
（a）由于UI响应操作是服务器端进行的，网络的延时会影响 UI 体验；
（b）服务器承担了相比传统web程序更多的计算量，服务器端的压力要大一点。
对于缺点（a），如果你的用户跟服务器距离的不远，比如，就是局域网用，或同城用，或者就国内用，体验度还可以，而全球的话，体验就不行了。
对于缺点（b），现在服务器硬件越来越强大，越来越便宜，写的时候稍微注意点，一台服务器也能抗几百人、几千人同时用，更多的就不好说了。也就是说，相同的硬件，抗的人数较传统的技术抗的人数要低。
在能规避这两个缺点的地方，它就是王炸。
它的优点：在所有 web 开发技术中 ，它是生产力最高，出东西最快的。前端拖一个 css ui 框架，Ant Design Pro 这种，后端用 Lite DB 这样的纯 .net 的文档数据库，生产力简直是狂霸酷帅龙傲天，在座的（其它技术）都是垃圾。生产力的提升不是一倍两部，而是三倍五倍这种。
传统的 web 开发，要考虑 UI，要考虑服务器，要考虑 UI 和服务器的交互，这里 UI 和服务器的交互是两个机器间的交互，可他娘的复杂了。但是 blazor server 里，UI 虽然是在浏览器端展现的，但是 UI 和服务器端交互是在服务器进程里的，直接在内存里开干。
blazor server 的潜力非常大。大家体验过通过远程桌面远程办公没？我放了一台很强的外星人台式机在家里，通过反向代理远程桌面练上去，办公体验已经非常不错了。这种模式，就是应用在远程跑，UI渲染在服务器端，通过视频流传到远程控制端。现在的云电脑，还有云游戏，也都是这种模式。服务器端渲染把画面传到客户端展现。这属于最重的服务器渲染的搞法，而 blazor server 在技术上，可以看作这种模式的轻量级实现，他将渲染指令通过 html 的方式，发送给浏览器来展现，无论响应速度还是对带宽的要求，还是对服务器的压力，都小得多。
随着网络的进一步发展，云电脑、云游戏用的人会越来越多，比这两种技术轻量得多的 blazor server ，也会有一些独特的应用场景。这是一个介于 web 程序和云电脑之间的生态位，这个生态位还没有人占，至于会涌现出什么样的新产品，我他娘的也想不出来，得让子弹飞几年。
我也只有一些想法。比如，要开发在线视频编辑这种应用，完全在 web 端在线编辑视频，受到技术限制体验会很差，用 blazor server，可以突破这个限制。在服务器端进行渲染，web 端只做显示和交互转发。这个要基于 webrtc 来做，还没有封装好的控件。在这个架构下，很多传统的重量级应用可以搬到 web 上了。
抛开上面这种还需要探索的新场景不提，看看现在 blazor server 可以干的事情：
（a）0-1 阶段的新产品开发。新产品开发存在巨大不确定性，需要以最快的速度搞个可以看到东西来消除不确定性。传统搞法是产品经理画原型图，然后就原型图讨论确定做还是不做。做的话，再让开发来搞。就我的体验，中后台型产品，直接用 blazor server + Ant Design Pro + LiteDB 搭一个看着很漂亮，具备真实交互逻辑的原型，它的速度几乎和用 Axure 等工具画原型图一样快。可以非常快的搞个原型出来讨论，讨论通过决定做了，得了，这不已经做出来了嘛 …… 还开发个毛线啊。直接上手用，哪里出现了限制，咱再改。
（b）局域网程序或同城Web应用开发。这种情况下，用户量不多，又都很集中，可以完美避开 blazor server 的缺点。这里提一个小的应用场景，比如，你开发了一个 web 系统，在 linux 下跑，要做内部用的可视化运维工具，blazor server 就非常合适。
（c）桌面程序。.net 程序现在打包非常容易，开发完了直接把 server 打包，用 electron 或者什么的包一下，就是桌面程序了。
现阶段，blazor server 在论证新产品这块，具有非常大的优势。在中小型企业（一半都不跨城吧）、大型企业内部应用领域，具有非常大的优势。在开发桌面程序，具有一定的优势。而在未来，开发类似于云游戏这种服务器渲染的新应用，具备技术优势。它是当前最完美的 baby 阶段产品开发技术。用 blazor server，你能以最快速度开发出产品，这个产品能在 server 端跑，能在桌面上跑。放服务器端跑的话，还他娘的天生带了反破解、反爬虫的特性。一个半吊子懂点产品的C#程序员，可以一个人当三个人用 - 产品经理 + 前端 + 后端。
因为 blazor wasm 和 blazor maui 还没成熟，blazor server 是我现在最提倡的 blazor 使用模式，当然，互联网公司没法用，用户量大，服务全球用户，恰恰踩住了 blazor server 的两个缺点，而互联网程序员的话语权比较大，所以在网上，看不到啥人吹 blazor server 的。
（3）blazor wasm
blazor 将运行时放在 wasm 里，缺点就是尺寸比较大，怎么也有几M。在现阶段来说，还是有些大。目前默认 wasm 下跑的 C# 是以解释的方式跑的，性能较 js 要低得多，AOT 速度块，但是整体还不够成熟。而随着网速越来越快，AOT 成熟后，blazor wasm 的应用场景会增多。blazor wasm 是网上讨论最多的 blazor。它相对于传统的前端后端分离开发来说，解决了 C# 写前端的问题，可以提升前端开发的效率。AOT 成熟后，可以在浏览器端跑部分高性能应用。缺点就是，现在速度还不够快，浏览器要加载运行时，会导致加载时间比较长。
由于 C# 程序员稀缺，以及 js 前端程序员及生态的泛滥，这里的前景，我不是很看好。js 三大框架 + springboot 的生态优势太强大了。而 blazor wasm 现阶段，也没法开发小程序，也会影响采用。
未来可期，未来有多远，还不清楚。
(4) blazor maui
blazor maui 就相当于把 electron 用 maui 替代了，由于 maui 自身就是 C# 程序，它就可以成为 blazor 的宿主，asp.net 那块也没必要要了（没看具体实现，我是这么猜的）。
可以把它看成 maui + blazor，也可以看成 blazor + maui。看成前者的话，blazor 为 maui 提供了 web ui 技术。看成后者的话，maui 为 blazor 提供了寄宿环境，可以直接和本地交互。而 maui 是跨平台的，这一来，一套代码，在桌面端和在移动端都能跑。
blazor maui 等于 blazor server 和 blazor wasm 的演化。对于 blazor server 来说，它等于将运行时从远程给放在本地了。对于 blazor wasm 来说，它等于将解释环境变成了本地编译环境。可以用它来做没 server 的程序，也可以用它来做有 server 的程序。
blazor maui 是我比较看好的。但由于 vs 正式版还没把它集成进来，我没怎么实际用过。上面这些技术细节是推测的，有错误地方，还请指正。
(5) 总结
我看好 blazor server 和 blazor maui。
要采纳一个技术，它必须相比现有技术有不可替代的优势。
blazor wasm 在现阶段很难说服大家去用。
blazor server 在产品 baby 阶段有非常强的生产力优势，成本的投入也较其他技术要低得多。钱少、事急是 baby 阶段重要特征，blazor server 可以解决这两个痛点，并且，为后续发展提供了一个很清晰的演化路径：
（a）使用 blazor server 进行产品论证；
（b）产品论证完了，就放出去可以直接用了，用户不接受，直接 GAME OVER；
（c）用户没意见，掏腰包付钱；
（d）用户需要桌面版程序：现阶段用 electron 之类的包一下发出去；等 blazor maui 成熟后，用 maui 包一下发出去；
（e）产品突然爆火了：将 blazor server 代码，抽离出 Restful 接口出来，如果 blazor wasm 可行，用 blazor wasm 写下前端，如果不可行，用 vue.js 之类的写下前端。后端改动很少。原产品继续跑着，等新产品开发出来后，直接切换升级。
（f）产品要提供原生移动端工具：用 maui 包一下发布。
如果做 Web 产品，当 blazor server 扛不住了：blazor server -> 前后端分离 -> blazor wasm + asp.net / js + asp.net；
如果做 移动 产品：blazor server -> blazor maui；
如果做 桌面产品：blazor server -> blazor + electron / blazor maui;
如果做全制霸的产品，几个路径一起推进。
整个路径很平滑。就算不考虑 C# 强大的生产力，整个技术架构也是有最多的共享代码，最节省人力的。
<hr/>原回答：
blazor是个极好的东西, 如果微软的 blazor 路线贯彻实施下去，将会是截至目前最优秀的全栈解决方案。
blazor 生态包括 blazor server/blazor wasm/maui+blazor。其中，blazor server 是最简单粗暴的，这玩意开发用户量不多的 web 应用速度天下第一快，比第二快的快很多的那种快，能把其他解决方案甩到看不见。搭配一套熟悉的ui框架，开发速度跟他娘的画原型图速度差不多，甚至比画原型图还快。
当有个需求，直接上 blazor server，可以以极快的速度搞个可以跑的东西出来。用户量几百几千都扛得住，套个壳可以搞成桌面程序。这个程序可以抗住需求验证和小规模推广阶段，当有更多需求时，可以考虑拆成前后台，ui 代码大部分可以复用，弄到 blazor wasm，maui+blazor，前台就可以跨浏览器，桌面，移动设备，改动不大。