Blazor vs JavaScript

大家好,我是Edison。

在Blazor推出之时的2020年,有人发布了这么一篇文章《Blazor vs JavaScript:谁会成为前端应用的首选框架?》,它将Blazor与JavaScript进行了全方位的比较,这里我将其转载出来,供大家参考。

过去几年里,JavaScript一直是单页面应用程序中最受欢迎、使用最广泛的语言。但是最近,微软发布了一款叫做Blazor的框架,使我们能够使用C#语言开发基于浏览器的应用程序。.

Blazor vs JavaScript
本文会带你认识Blazor以及其大量宣传的原因,并将其与JavaScript进行比较。
Blazor是什么?

Blazor(Browser+Razor)是微软开发的一款全新的网站开发框架,能在使用HTML和CSS的同时,运用C#语言和Razor语法开发基于浏览器的应用程序。之前,开发者要在浏览器中呈现HTML,需要在服务器端执行Razor视图——但是现在,Razor视图在客户端就能执行。

因为Blazor运用WebAssembly,我们不需要在网络浏览器中安装运行任何第三方插件或附加设备。有了Blazor,就可以运用C#语言开发客户端及服务器端口,通过共享库和代码使工作更加舒适。

Blazor vs JavaScript

广泛宣传背后的原因

Blazor的排名在短期内上升得很快,人们已经将其与广受欢迎的javascript框架相比。关于未来客户端网站开发的讨论有很多,这些讨论和比较使Blazor变得更受欢迎。让我们来看看Blazor的独特之处。

正如我在开头提到的,Blazor主要的亮点在于能够使用C#语言开发并执行基于浏览器的运用程序。在过去的几年,JavaScript(或是TypeScript)是创建前端的首选编程语言。如果你是个.NET开发者,要成为全栈网站开发者,必须额外学习JavaScript。运用Blazor可以使用C#语言同时开发服务器端和客户端,对我而言,这是Blazor最主要的优势。

与JavaScript不同,Blazor预编译到中间语言。当涉及到浏览器中运行的对性能要求高的应用程序时,这个特点有显著的优势。另外,当需要更多处理能力时,Blazor应用程序可以线下工作一段时间,例如PDF生成器、游戏算法等等。

上述之外,Blazor还有很多特点/优势:

· Blazor不需要浏览器插件
· 能够进行完整的.NET调试
· 使用最新的网页浏览器功能
· 可构建用户界面的模型
· 浏览器兼容性强(即使对象是旧版本)
· 可依赖注入
· 可在用户和服务器间共享代码

JavaScript vs Blazor

Blazor会替代JavaScript吗?JavaScript会一直保持其主导地位吗?每个人都在寻求答案。现在对这些问题做出直接预测或结论还为时尚早,但我们可以把一些JavaScript的主导框架和Blazor进行比较来看看它们的区别

在这个示例中,满足了刚刚所说的3个要点,接下来就在组建中来使用这个布局。

Blazor vs React

很多人认为React是web组件开发的最佳使用库。

虽然对这两者进行比较很难,但我们必须承认React组建完善,有可靠的工作业绩,并拥有强大的社区。

React生态系统的繁荣发展离不开优秀的库和框架。我认为,这个过程中的工具和库像Bit(Github)那样,是能帮助管理和共享React组件并真实存在的制动器。

这使得React成为“通用语言”,能够为web、CLI、iOS、Android、Windows等等提供应用程序的库。与像Bit一样的组件共享工具相结合,让React难以超越。

相比之下,Blazor很新,但是继承了其组建完善的副本Razor的风格,因此我们不认为它对开发者来说是全新的。此外,因为运用Blazor的开发使用C#语言,对任何.NET开发者来说转变都会更快速。虽然发展成熟的React带有大量的特点和优势,但我们也注意到,抛开年限问题,Blazor也具备很多先进的功能。

  • 和React类似,我们也可以把Blazor部署为静态文件。
  • 可以使用NuGet package。
  • 可以在客户端和服务器端使用相同的组件。(当然,这在使用JS/TS时也是可能的)
  • Blazor有路由、验证和表单处理的内置支持。

这只是Blazor提供的功能中的一部分。如果你的开发团队善于使用JavaScript,继续使用React会是很好的选择;如果你忠实于.NET而不是JavaScript,并且正在开始一个新的项目,Blazor是一个值得考虑的不错选择。

Blazor vs JavaScript

Blazor vs Angular

Angular是另一个受欢迎的JavaScript框架。与React相比,它更多的是一个完整的框架而不是库。Angular为客户端提供MVC架构来简化开发,并测试流程。

相比较,Angular仍处于领先位置,因为其知名度高、稳定,并且生产就绪。此外,Angular完全支持PWA,而Blazor的服务器端还不具兼容性。

再者,因为Angular使用TypeScript,它相较于JavaScript对C#语言开发者来说更相关、更好理解。有Angular控制局势,我没有发现Blazor有任何突破性的功能,可以促使擅长TypeScript的人转而使用Blazor。

说取代JavaScript还为时尚早,但不得不说,Blazor未来可期。

大佬观点 from 叶影

Blazor和前端三大框架之间,的确有相当一部分的功能其实可以互相取代。然而Blazor的目的,不是为了取代三大框架;从现状来看,甚至连竞争的地位都谈不上。Blazor能吸引的最主要人群,是.NET开发者,它给了开发者完全以C#作为主要语言实现全栈开发的机会。尤其是,前后端可以共享包含数据类型和逻辑模块的C#代码,这一优势只有C#全栈开发者才能深切体会到。例如,对于后端出身的C#开发者,在前后端分离的环境下,以往更偏爱设计模式上与后端更相近的Angular;如今Blazor已逐渐成熟,可以“横刀夺爱”了。

现在,我将个人的判断写在这里以供读者参考:

  • 在可预期的未来,Blazor将是微软主打的Web UI框架
  • Blazor完全借鉴和遵循当下前端流行的设计模式和思想,没有闭门造车
  • Blazor开源社区的活跃度在逐步提高,除了组件库之外,还有越来越多的功能库
  • Blazor的根基在于Web Assembly,wasm将是未来浏览器的核心规范,它更高效更安全更开放,且更标准(无版本,特性可测试、向后兼容)
  • Blazor在性能、可靠和开发效率上,是一流的框架。而近期在.NET 6到来后,AOT和Hot Reload将进一步提升Blazor程序的运行性能和开发体验

鉴于前后端分离的流行程度,以及WASM的发展空间,我个人的结论是:Blazor不会成为另一个Silverlight。相反地,它更可能成为.NET生态在前端开发领域的大本营。