导读

blazor是个极好的东西, 如果微软的 blazor 路线贯彻实施下去，将会是截至目前为止最优秀的全栈解决方案。

blazor 生态包括 blazor server/blazor wasm/maui+blazor。其中，blazor server 是最简单粗暴的，这玩意开发用户量不多的 web 应用速度天下第一快，比第二快的快很多的那种快，能把其他解决方案甩到看不见。搭配一套熟悉的ui框架，开发速度跟他娘的画原型图速度差不多，甚至比画原型图还快。

当有个需求，直接上 blazor server，可以以极快的速度搞个可以跑的东西出来。用户量几百几千都扛得住，套个壳可以搞成桌面程序。这个程序可以抗住需求验证和小规模推广阶段，当有更多需求时，可以考虑拆成前后台，ui 代码大部分可以复用，弄到 blazor wasm，maui+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# 强大的生产力，整个技术架构也是有最多的共享代码，最节省人力的。