再谈组件化开发：我们真的在重蹈覆辙吗？

在 Dotcom 时代，HTML、JavaScript、CSS 和服务器逻辑混杂在一起，带来了无数维护噩梦。那时的 ASP、JSP 模型几乎就是“意大利面条代码”的代名词。

今天，React、Vue、Yew 等现代前端框架看似带来了“组件化”的先进理念，然而它们也在某种程度上重新融合了视图、状态和业务逻辑。我们真的解决了历史遗留的问题，还是在用新瓶装旧酒？

我们真正该思考的不是形式是否相似，而是这种“融合”究竟是历史的倒退，还是现代工程对效率与抽象的再一次进化？

Rust 全栈实践：我们处在什么阶段？

Rust 是近年来 Web 开发中值得关注的新势力。它以内存安全、高性能、并发友好著称。后端生态已然成熟：

• actix-web 支持多线程并发与 TLS/HTTP2
• 搭配 Diesel ORM 可高效管理 PostgreSQL
• 静态编译 + Docker 部署提高了可移植性与构建效率

而在前端，Rust 正通过 WebAssembly（Wasm）与 Yew 框架迈出全栈化的尝试。

一篇 Rust 全栈实战文章中，作者使用 actix-web + Yew 构建了完整 Web 应用，评估其减少样板代码与提升工程效率的可能性：

• 使用 html! {} 宏语法绕开 JS
• 前后端通过 WebSocket + Cap’n Proto 高效通信
• 构建流程统一于 Makefile 和 Docker

挑战也随之而来：

• Yew 缺乏成熟的组件测试、E2E 测试工具
• Cap’n Proto 在 wasm 下存在编译限制
• 前后端同仓库架构虽降低接口碎片化，但复用有限、维护成本高

结论：Rust 后端已可用于生产环境，但前端生态仍在探索期；全栈架构具备潜力，但生态和工具仍需打磨。

Rust 写前端：“酷”与“稳”的距离

Yew 是当前 Rust 前端最具代表性的框架：

• 灵感来自 Elm 与 React
• 支持组件化、Agent 状态共享
• 使用 html! {} 宏书写 HTML

但挑战仍然明显：

• 测试、调试、构建工具链不成熟
• wasm 编译与跨平台兼容性需权衡
• Cap’n Proto 在 wasm 环境下有一定限制

Rust 写前端很“酷”，但离真正稳定的生产实践仍有距离。

一个被忽视却常见的问题是：本地环境配置太复杂，尤其是多语言栈的协作开发。

这时候，ServBay 提供了新的解决方案：

• 一键拥有隔离的 Rust 编译/运行环境（无需配置 rustup、cargo、PATH）
• 同时支持 Node.js、PHP、PostgreSQL、MariaDB 等多语言服务
• 实现多服务统一管理与自动化构建

不仅降低配置门槛，也加速了团队协作和项目初始化流程。

“组件融合”：复刻历史，还是现代进化？

围绕 React、Yew 等框架的“代码融合”结构，开发者之间始终存在争议。

批评者认为：

• 将视图、逻辑、状态写在同一文件，是在复刻 ASP 式的“意大利面条代码”
• 破坏了关注点分离，组件复杂度上升
• Yew 宏与模板嵌套对新手不友好，不利于协作

支持者认为：

• 是一种职责明确的融合，并非混乱堆叠
• 聚合逻辑可降低心智负担，减少跳转和维护成本
• 生命周期管理 + 类型系统确保结构稳定性

融合 ≠ 倒退，关键在“组织方式”

我们不是在重复历史，而是在重构旧范式。

融合不是问题，组织能力才是核心问题。

组件设计得当，职责依旧清晰；若架构能力缺失，即便采用新技术，也可能演变成新的“意面怪物”。

关键在于：

• 你是否知道 何时该分离，何时该聚合
• 是否具备足够的架构意识和抽象能力

历史是镜子，不是桎梏

回望过去，是为了更好地前行。

我们必须对“融合开发”的趋势保持清醒与警惕，但不能因其“看起来像过去”就本能地排斥它。

借助现代工具与理念，我们拥有比过去更强大的抽象能力和工程体系。与其说我们在重蹈覆辙，不如说我们正在用新的方式解决旧的问题。