wasm转htmx的真实案例

上大学时，我写了一些客户服务软件，将我训练的一些自定义AI模型、OpenAI API、数据库和一些社交媒体API结合起来，创建了Sidekick的第一个版本。

误入歧途

在接下来的几年里，我致力于添加更多功能并扩大用户群。作为独立创始人，我本应专注于销售、营销和市场发现。但作为一名工程师，我想手工打造完美的Web技术栈。我坚信前端和后端之间的网络鸿沟可以被抽象掉，我可以让编写Web应用变得像编写原生应用一样简单。这与我的业务、产品或客户有什么关系吗？完全没有，但像许多技术创始人一样，我相信如果我完善了技术，客户就会自然而来。

我的设计决策很天真，但也让人联想到今天行业中看到的情况：我希望后端和前端共享一种语言（Rust），我希望在网络边界上有编译时检查，我希望像编写应用程序一样编写前端代码（响应式），我希望能几乎即时重新加载。我从中得到的是一个充满错误的混乱。

我发明了一个系统，其中简单的rust函数可以用宏标记，生成后端路由和前端请求函数，因此你可以像调用标准函数一样调用它，它会在后端运行。一个真正的穷人版GraphQL。我希望在前端编写Rust的要求迫使我编译一个WASM包。我希望即时加载时间的要求需要同构SSR。所有这些复杂性，对于一个本质上是简单CRUD的网站来说。

更好的方式

此时Sidekick已经成长，现在有一个代码库负责每天处理不小的流量。有一次我了解了HTMX、多页面网站和HATEOAS，意识到Sidekick代码库已经增长到约36k行代码分布在8个不同的crate中，可以折叠成一个crate，一个运行后端的单一二进制文件，通过模板按需生成前端，而HTMX可以满足我们所有的交互需求。

大型重构通常有不良记录，所以我们快速粗略地重写了网站的一部分来说服自己它可以工作。在充分说服后，我们进行了完整的重写。总共，重写花了大约3周的紧张工作。结果非常显著：

• 36k行代码 → 8k行代码
• 8个crate → 1个crate
• 每周约5个错误报告 → 每周约1个错误报告
• 更多完整的夜间睡眠

重写比我预期的要好得多。它肯定不会代表每个经验，我们的应用绝对特别适合HTMX。Axum和一些自定义中间件也在整个网站共享公共基础设施方面发挥了很大作用。虽然没有适当的指标，但我们注意到加载时间显著改善。

反思

最后我要谈谈在我看来最大的好处：当客户提出新功能请求时，实现它们变得非常容易。一个需要2周才能完全实现、测试和发布的功能，现在只需一两天。作为一家客户需求众多的小型初创公司，这是基本要求。

Sidekick没有筹集VC资金，所以我负担不起雇佣大量开发人员。有了HTMX，我们不需要。