编程与软件工程sheshbabu.com
使用 Rust 构建单页应用
Single Page Applications using Rust
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
一篇教程，介绍如何用 Rust 编译到 WebAssembly、配合 Yew 框架构建单页应用（SPA）。文章演示了组件化、单向数据流等 React 式的前端开发范式在 Rust 中的实现方式。
为什么经久不衰：它展示了用 Rust 替代 JavaScript 做前端开发的可行路径，是 Rust + WASM 前端生态的入门经典，两次登上 HN 首页说明这一方向持续受到关注。
HN 评论精选
Rust 有望实现 Elm 未竟的理想：类型系统更强、社区更开放，且前后端统一。
我希望 Rust 能做到 Elm 没做到的事。我很早就爱上了 Elm，它很多方面都做对了，但正当它开始获得关注时，开发变得停滞、封闭、对用户诉求响应极慢，阻碍了语言的发展。Rust 的类型系统比 Elm 更有表达力，社区更开放、更关心用户，还提供 unsafe 逃生舱。而且 Rust 前后端都能用，这在它正成为最强后端语言之一的背景下尤其有吸引力。
nilkn查看英文原文
I am hopeful that Rust can achieve what Elm did not. I really fell in love with Elm early on, back when it was an experimental language for functional reactive programming that just happened to compile to JavaScript. It was an outgrowth of failed experiments in FRP from the Haskell world. I thought it got so many things right -- and it totally did. But then, just as soon as it started gaining real traction, development on Elm went silent and became siloed, staggeringly slow, locked-down, and unresponsive to users. I understand why this happened and I don't even hold it against the Elm team, but it certainly stunted the language's growth and adoption. Rust has a much more expressive type system than Elm. The Rust world is much more open, responsive, and caring about user concerns. Rust isn't afraid to offer unsafe escape hatches even if they're not pretty or elegant. With Rust you have the added advantage of being able to use the language for the entire stack, both front- and back-end. That's especially compelling because Rust is on its way to being one of the strongest languages for back-end development due to its combination of type safety, expressiveness, and performance.
Rust+WASM 前端的包体积偏大，实用性仍受限制。
值得注意的是 WASM 包体积达 476kb，wasm.js 加载器还有约 25kb，所以这个极简网站发给客户端的就已经超过 500kb。很高兴看到 WASM 让这些成为可能，但还有很大改进空间，希望浏览器厂商能逐步解决。
vlucas查看英文原文
It's worth noting that the WASM package takes up 476kb shipped and the wasm.js loader is another ~25kb. So this bare-bones site is already sitting at > 500kb of JavaScript shipped to the client. I am glad to see things like this are possible now with WASM, but there is a lot of room for improvement here that I hope gets captured by browser vendors over time.
实战经验：前端用 React 生态、后端用 Rust 管理状态，比纯 Rust 前端更务实。
那个网站是很好的资源。我为自己的应用先试了 yew，后改用 seed（因为 yew 的 JSX 语法在 Rust 代码里感觉别扭、补全体验差）。但后续项目我前端用了 React，因为 React 工具链和生态兼容性好，支持热重载、浏览器内调试等。我用 WebSocket 和 Actix actor 把所有状态管理放在服务端，前端只负责发消息和渲染服务端返回的状态。这样各取所长：前端享受 JS 的灵活性，后端用上 Rust 的模式匹配和强类型。
jbandela1查看英文原文
First of all, that site (sheshbabu.com) is a great resource, and I have used it a lot. For my app (triviamaze.com), I ended up trying yew (which is referenced here) and then decided on seed (which is another rust WASM frontend framework which I preferred because it felt like the JSX syntax of yew did not play well with code completion, etc and felt weird to me inside Rust code). However, for the followup web app (triviarex.com) I ended up using React for the frontend. The big reason I did this was because React has a lot of tooling and compatibility. If I wanted a different CSS framework or to include one of the many available React components, it was easy. React also supports hot reloading, inbrowser debugging, etc. What I did do, was use web sockets and Actix actors to manage all the state server side. Basically, all the React frontend code did was send messages to the server, and render the state the server sent back. This to me felt like playing to the strengths of both languages. On the front-end, I got the flexibility and compatibility of Javascript. On the back end, I got to use all the Rust goodies such as pattern matching and strong typing for managing the state.
UI 结构与状态管理应分离，组件化+事件上抛的模型有根本性缺陷。
引用文章：'通过组合组件、单向传递数据来构建 UI 是前端世界的范式转变……' 我认为 UI 结构和状态管理是正交的关注点，把它们捆绑成'组件'正是 Angular 式陷阱的根源——永远无法覆盖 100% 用例，只能不断打补丁。事件沿组件链向上传递是尤其糟糕的约束（模态框、状态栏、导航菜单是谁的子组件？）。我在用 Blazor 时意识到：UI 的状态性与视觉呈现是完全不同的两回事，单向绑定渲染 UI，状态作为服务注入，UI 事件直接调用状态服务方法，状态只能通过公开方法修改。这样可以把 UI 状态机测试到确定性正确的程度。
bob1029查看英文原文
From the article: > Building UIs by composing components and passing data in a unidirectional way is a paradigm shift in the frontend world. It’s a huge improvement in the way we reason about UI and it’s very hard to go back to imperative DOM manipulation once you get used to this. IMO, UI structure and state management of the UI are orthogonal concerns. Trying to make these part of the same problem - a 'Component' - is how you wind up in the Angular-style trap where you can never quite cover 100% of the use cases, so you have to keep adding new leaky abstractions to compensate for prior ones. Passing events back up the chain is a particularly egregious constraint when you are trying to do things with the UI that the modeling does not agree with on paper (i.e. modals, status bars and nav menus are children of whom? One big global component?). I have made this realization recently when working with Blazor. The statefulness of a UI is a completely different thing from the visual presentation of the UI. We do one-way binding into UI (e.g. foreach over collections to build table rows). But, stateful concerns are injected as scoped services (i.e. per user session/request). UI events are passed into the state service methods directly, and the UI is redrawn on top of the updated state. Each state service can only be mutated by way of one of its public methods. This approach allows for us to build & test our UI state machines to deterministic levels of correctness without a single line of HTML/JS/CSS or manual user testing being involved. Once we have the state machine figured out, we can build whatever arbitrary UI we want on top of it.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选