关于Blazor

看了Blazor的介绍，非常兴奋。WebAssembly的汇编级性能，结合C#的能力，简直就是互联网的王炸。写了一些本地例子，发现总体还不错，简单高效。

突然看到微软官方文档有一句“不适于高并发场景”，顿时想起WebForm。联系祖孙三代，让我一身冷汗。通常，当王婆都说自己的瓜可能不甜，事情一定很严重。

WASM模式打包启动慢

是缺点。初次启动需要下载和初始化运行时、类库等必要部分。官方仍在优化裁剪功能，减小初次启动加载内容的体积，但目前也只能这样了。

WASM+AOT打包体积大

AOT之后打包体积变大是意料之中的情况，不能说是缺点。只能说有条件地使用，AOT不是什么万能灵药。

Server端模式占用Socket和服务器内存

这也不能说是缺点...这是一种框架层面支持的项目设计模式，即通过长连接来处理前后端的交互逻辑主要都在后端完成。如果你采用了这样的设计，后端当然要占用Socket和内存。这是陈述，而非评价。

(p.s.我更建议学习Client端模式，比较贴近一般的前端开发）

再说说我个人的观点。

Blazor的缺点主要有2个：

①、wasm的普及和支持还不够广泛

②、生态问题

Blazor发展的天花板肯定是受wasm制约的。对2C市场来说，诸如IE 9-11等不支持或仅部分支持wasm的浏览器还没被淘汰呢，采用Blazor就意味着放弃大量底层用户。2B市场是可以争取的，但也有很多企业和单位的硬件环境，不支持wasm,这也是Blazor无法染指的蛋糕。总而言之，在短期内，若企业或个人选择Blazor做产品，可选的买方市场相对有限。

生态问题分为2个部分：一个是Blazor本身出来没多久，各种开源组件、应用、设计、最佳实践还需要继续丰富和成熟；另一个是国内C#生态相对屏弱。这2个结合起来，很容易会形成“伸手的人多，贡献的人少->伸手的要不到，贡献的忙不来“，恶性循环，最后双方都放弃了。如果社区活跃不起来的话，微软砍刀部可能……好在就目前来说，Blazor也有后发优势，很多设计思想其实跟当下主流的前端开发是一致的，少走了很多弯路。

而展望未来的话，不支持wasm的浏览器迟早会淘汰，因此第一个（天生的）缺点反倒不是最严重的。最严重的“缺点”可能是开源社区。例如，国内的开源项目ant-design-blazor就提供了一套企业化的组件，据我所知，项目的管理者们在工作之余已经花费了很多精力和时间，但还有很多已知的问题吸待人力解决。我个人在使用antd-blazor的过程中，感受到了开发效率的极大提高，同时也针对遇到的一些问题，贡献了自己的PR,这是一个双向受益的过程，因此我希望能有更多的同行们参与到开源社区中。

假若用过开源产品的开发人员，永远都指望着“现成的”，而不主动参与到其“成熟化”的努力中去，那么Blazor的未来，的确是灰暗的。TG：li9047