Blazor 正在悄悄取代 JavaScript 开发者在 Web 领域的地位

当 JS 开发者还在为一个分号而苦恼时，Blazor 正如马可·伊纳雷斯接管太阳系般地接管了 Web 领域。

在像 Angular 和 Vue.js 这样的 Web 框架的舒适环境中，一个人可能会觉得自己对 Web 开发了如指掌。

这次微软可能走在了正确的轨道上

然而，WASM 和 WASI 这样的解决方案开始将 Web 向不同的语言和技术开放。

在这个领域中最引人注目的解决方案之一是 Blazor，这是微软推出的一个开源且免费的框架，用于用 C# 和 HTML 构建 Web 应用。

微软在进入开源领域时经历了起伏。例如，它曾经收购了 GitHub。 但我理解这种困惑，指令并不明确。

TypeScript 是 C# 的预演

现在，C# 是一门非常有趣的语言，有很多原因。主要是因为它不是 Java，并且在更高层次上与 TypeScript 有相同的动机。

这意味着只进行编译时类型检查的 TypeScript 可以被视为 C# 的预演版本。

因此，结合易于使用的语言和全天候的类型检查，以及用 HTML 作为模板系统而不是奇怪的基于 XML 的语言，可能实际上是 Web 的完美组合，特别是因为 Blazor 全力支持全栈开发。这意味着它可以处理现有工具的后端以及前端。

JavaScript 全栈框架在基础上挣扎

当然，也有一些 JavaScript/TypeScript Web 框架尝试结合后端和前端，结果各异。

所以像 Next.js 这样的框架在处理服务器端（以及其他所有事情）时很难，而 Blazor 至少在后端已经相当不错了。

Blazor 应用看起来像普通的 Web 应用

Radzen Blazor、Blazorise、Fuent UI Blazor、MatBlazor 和 MudBlazor

尤其是最后一个 MudBlazor 引起了更多关注，到目前为止，它提供了一个相当完整的组件列表供使用。

Buttons, chips, calendars。正是你从受 Material Design 启发的 UI 组件库中所期望的常规内容。

使用 Blazor 和像 MudBlazor 这样的组件库构建的应用程序与使用 JavaScript 的组件库构建的应用程序没有区别，这意味着我们已经达到了一个可以使用 Blazor 构建用户友好应用程序的阶段。

C# 让编码超级舒适

此外，虽然 C# 不是 JavaScript，但这门语言本身为创新提供了空间。每隔几个月，我们就会迎来一个新版本，通常围绕改善开发者体验展开。

几天前发布的 C# 13 提供了一个特殊的字符字面量来转义字符串、类型改进以及数组末尾的隐式索引扩展。

然而，对于那些习惯了 JavaScript 动态类型的开发者来说，C# 可能难以消化。

JavaScript 世界在与猜测属性和类型的束缚中挣扎

虽然 JavaScript 开发者仍然习惯于猜测属性名称和类型，但在 C# 中编码通常只是从列表中选择属性名称，并且可以舒适地编写代码而无需多次编译。

C# 在编码过程中抛出所有错误，因此无需像在 JavaScript 中那样进行反复运行和测试以交付功能应用程序。

即使有 TypeScript，整个 JS Web 工具生态系统也分为三个阵营。

第一个阵营是以 JavaScript 为中心，采用动态类型的库。没有类型的库让你探索它们的源代码和单元测试，感受使它们运行的成就感。

这个阵营主要由 React 及其衍生框架占据，这是一个建立在抛弃所有类型、类、设计模式等软件工程基础之上的框架。结果是，必须发明各种变通方法，例如钩子规则或 Redux。

第二个阵营是混合的，虽然有一些类型，但并不真正符合强类型原则，更不用说面向对象编程了。

Blazor 将不得不与 Angular 和 Vue 竞争

第三个阵营致力于严格的类型检查和面向对象编程。这个阵营主要围绕 Angular 和 Vue 框架，这自然吸引了企业世界中基于 C# 后端的解决方案。

随着 Angular 在新模板创作方面的重大进展和 Vue 的常规开发，二者都在为新的前沿做准备。

React 和 Next.js 不是竞争对手

React 生态系统的开发者对此情况并不陌生。在这些圈子里，人们普遍认为 Blazor 能赢得与 React 的竞争，因为 React 只是一个前端库。

这就是为什么我们看到 Next.js 努力构建一个同时在客户端和服务器端运行的稳定框架的主要原因。JavaScript 作为两个位置的唯一语言被视为竞争优势。

不评判框架本身在此阶段有多么实验性（仅提到最近切换到“app”文件夹），它可能有长期发展的机会。但这不是 Blazor 成为强大竞争者的原因。

C# 和 Blazor 是经过深思熟虑且对开发者友好的。这种组合转化为更低的维护和开发成本。

Next.js 的烟雾与镜子世界仍需弄清楚如何真正使开发更容易。

很少有人会听到前端用 React、后端用 C# 的组合。正是因为这个原因。

虽然后端开发者可能并不总是理解前端在不该简化的地方简化了什么，但他们明白一点：构建前端应该简单，以便专注于业务价值和用户体验。

这正是一些起源于 JavaScript 和 React 的前端开发者似乎忘记的东西。

因此，真正的竞争将围绕 Angular、Vue 和 Blazor，以及 TypeScript 和 C# 展开。

TypeScript 首先的重点可以与 Blazor 竞争

为了整个 JavaScript 生态系统的未来光明，需要区分 TypeScript 首先的解决方案。一种轻松识别以 TypeScript 为核心构建的库的方法。不只是表面上的说法。

从这里开始，有机会与 Blazor 竞争，构建对开发者友好、成本高效的解决方案，在这个经济困难时期提供价值。

Blazor 的未来光明

Blazor 和 C# 在 Web 领域的未来是光明的。C# 定义明确，从第一天起就传播了优秀的价值观，影响了从 Blazor 到组件库的一切，使其易于使用。

Blazor 正在全力进入全栈世界，只要稳定发展，它加入最受欢迎的 Web 框架列表并在未来几年中保持其地位只是时间问题。