Blazor会成为新兴.netWeb开发潮流吗

[¿?¿?]

刚了解了一下Blazor，感觉不知道什么地方有点像webform
看一段代码吧

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    int currentCount = 0;

    void IncrementCount()
    {
        currentCount++;
    }
}

在前台写C#来处理，或许能干掉js？

[江湖评谈]

不会 觉得这个东西 跟 asp.net 之前的 asp 毫无区别 微软一直在走回头路，所以既超越不了Java 也会被Python 超越

[wanghui0380]

理解一下他准备干啥的----Blazor是编译成webassembly的，他是替代uwp和wpf的。当然其实还比较早，毕竟作为产品使用，俺们还有很多问题呢，比如访问本地文件，访问本地硬件，操作注册表 webassembly毕竟只是webassembly，做下所谓的大数据屏，纯展示app，游戏，VR有些优势，不过天生短板也就哪里 至于前端，人家不搞游戏，不弄VR，玩他干嘛。除非是js自己实在玩不转了，才会想起来用webassembly直接加速的

[wanghui0380]

其实这东西只需要比较一下vrml，webgl的地位就知道了，只有前端用js搞不定了，人家才会想起来用webgl搞 我们自己也是一样，net库搞不定了，你才会想起来用win32api

[¿?¿?]

引用 3 楼 wanghui0380 的回复:

其实这东西只需要比较一下vrml，webgl的地位就知道了，只有前端用js搞不定了，人家才会想起来用webgl搞 我们自己也是一样，net库搞不定了，你才会想起来用win32api

这玩意其实有点离谱，其他的网页看network流过来的事一堆js， Blazor做的流过来的是一堆dll

[wanghui0380]

当然多少webassembly多少还有人用，Blazor稍微差点 因为现在流行大数据屏，都是N*N的展示屏。 用其他方式开发麻烦，所以基本都是H5的，但是屏大了，东西就展示很多了，加上这种玩意就是要“高大上”的，所以基本基调就是“酷炫吊炸天”的模式，就是要加VR都有可能。 所以js们也头疼了，gpu，d3d都加上性能也就那样。那么用webassembly可以好点（js，typescript弄成webassembly方案早就有了，甚至python，pyqt弄成webassembly的方案也有） so，webassembly也许可以是种手段（比如unity3d的webgl版就可以用webassembly发布），不过就像我们说的webassembly可以使用的东西太多，而且都是人家现在就熟悉的东西，你要一个会搞这个东西的人去学一个Blazor？不靠谱，只能说以前玩uwp，wpf的伙计上去对付了，反正真正的前端不会转，玩uwp，wpf的“假前端”到可以临时客串

[楠小南]

他（微软）想累死你们

[XBodhi.]

这个不好说，引擎这个东西 看个人喜欢了。

[ProjectDD]

vs code + ts 这个也是微软的，发展比 blazer 好太多了，其实也蛮顺手的，主要是 ts 可以有非常丰富的前端 库可以用，使用的 dom接口那些 也是web标准的，和原来的js前端开发很接近，基本也就是现在的世界主流前端开发模式，而blazor可以做为一个 C#后端的 的学习方向，正如楼主，大佬所言，如果没特别的需求，比如游戏，2d,3d ar vr 什么的 用webassembly 没理由！主要是从生态的角度上看，不家 ts+ vscode 的易用性的角度上看 blazor并没有优势，而且还有差距

[Cougars]

Blazor主要是搞web assembly,并且用c#可以和微软现有的生态无缝对接。

[Goami]

技术框架只是工具，最终服务于具体的商业逻辑。 这个玩意可以解放后端开发人员，减少开发周期，降低开发门槛，不香么？

[中骑士]

狗屁微软blazor！ 我是个资深neter，一听blazor不错忙着去学习了blazor，这才有资格来评论。 理由1：别人说的：“凡是可以用 JavaScript 来写的应用，最终都会用 JavaScript 来写。”——Atwood定律。 理由2：我说的：我最讨厌微软一推出新产品就推出新标签，什么<asp:server> <asp:button> 到现在blazor的<editor> ，学不胜烦！凡是这么搞的都失败了。