Rask：只靠 C# 就能撸出实时 Web 应用，不用 .razor，也不用 JavaScript

说实话，现在做 Web 开发挺累的。得同时玩转好几门语言、好几个框架，脑子里还得切换不同的思维模式。后端用 C#，前端用 JavaScript（或者 TypeScript），然后再想办法让它们好好配合。整个过程一点都不丝滑。

今天要聊的 Rask 有点意思——它是个开源框架，主打的是：只写 C#，一个代码库，既能走服务端 WebSocket 渲染，也能走客户端 WebAssembly 渲染，而且全程不需要 .razor 文件，也不需要你碰一行 JavaScript。

Rask 跟别家有什么不一样？

Rask 没有走传统 .NET Web 开发的老路。它没有把你绑在 Blazor 的组件模型上，也没有逼你去学外面的 JavaScript 框架。你就写 C#，剩下的交给 Rask 来处理渲染的问题。

核心思路很简单：你的 C# 代码是主力，但渲染这一步你可以自己选——放服务器上做（通过 WebSocket 推送更新给客户端），或者放浏览器里跑（通过 WebAssembly 执行）。同一个代码库，两种玩法都行。

方案一：服务端 WebSocket 渲染

选这个模式的话，UI 是在服务器上生成的，然后实时推送到客户端。

好处挺实在的：

• 浏览器端零负担 —— 客户端只收到渲染好的 HTML，加上一点点负责 WebSocket 通信的代码
• 服务端资源随便用 —— 想调数据库、访问文件系统？尽管上，服务端什么都不缺
• SEO 天然友好 —— 内容在服务端就渲染好了，搜索引擎抓取毫无压力
• 对客户端要求低 —— 老设备、低配机器都能跑得动

方案二：客户端 WebAssembly 渲染

另一个玩法是把 C# 编译成 WebAssembly，直接在浏览器里跑。

这种模式下：

• 能离线用 —— 首次加载之后，没网也能跑
• 服务端压力小了 —— 计算全放客户端，服务端可以歇着了
• 交互更跟手 —— UI 更新不用每次都跟服务器来回一趟
• 真正的单页应用体验 —— 路由、状态管理全在浏览器里搞定

两边的好处都占了

最香的地方在于：同一个代码库，随时切换渲染模式。

比如项目一开始为了快速开发、为了 SEO，走服务端 WebSocket 渲染。等业务稳定了，想省点服务器开销、想支持离线功能，切到 WebAssembly 就完事了——业务逻辑代码一行不用改。

不用 .razor，不用 JavaScript

Rask 最特别的一点，就是彻底拒绝了 .razor 文件。如果你被 Blazor 里 C# 和 HTML 混在一起的写法搞过，应该懂这种痛苦。Rask 就清爽多了——写 C#，就写 C#。UI 渲染逻辑全靠代码本身，没有那种特殊的标记文件。

JavaScript？当然也不用碰。底层该遵守的 Web 标准还是得遵守，但写代码的时候你不需要写一行 JS。WebSocket 通信也好、WebAssembly 交互也好，Rask 自动帮你生成对应的客户端代码。

这框架适合谁用？

Rask 对以下这几类人特别有吸引力：

• .NET 团队 —— 公司里全是 C# 技术栈，想做 Web 但不想从头学 JavaScript 框架
• 企业级应用 —— 需要服务端渲染、安全边界清晰的场景
• 追求简洁的开发者 —— 受够了为了一应用得维护好几门语言、好几套构建流程
• 快速原型 —— 想用熟悉的工具快速跑出一个带实时交互的 Web 应用

聊聊我的看法

Rask 这个思路挺有意思，算是「一次编写，多处运行」这个理念在 Web 开发领域的实践——只不过是用你熟悉的语言来驱动。

它不会取代 React、Vue，甚至也不会完全取代 Blazor。但如果你就想待在 C# 的世界里做有交互的 Web 应用，这东西值得试试。

目前框架还在发展阶段（GitHub 上能搜到：pal-tamas/rask），社区反馈会很大程度上影响它的走向。不过核心卖点确实够硬——一套 C# 代码、两种渲染选择、不用写 JS——光是这几点就值得关注。

如果你正好在做 Web 项目，又不想在语言之间来回横跳，Rask 可能正是你需要的那个实验品。去瞅一眼，跑几个示例，看看这套工作流合不合你的胃口。

你怎么看？会考虑用 Rask 跑生产项目吗，还是觉得生态还不够成熟？评论区聊聊。