我如何将 HTMX 与 Go 搭配使用
将服务器渲染的 HTML 与 HTMX 结合，正在成为 Go Web 开发者替代沉重 JavaScript 前端的热门方案，因为它带来更简单的心智模型、更少的构建步骤，以及可以交付 `one binary` 应用的能力。评论者分享了多种技术栈模式（例如 Go + HTMX + SQLite、Datastar、templ）以及用于模板、SQL 和流式处理的工具，同时也指出了 Go 的 `html/template` 使用体验、复杂交互组件（如复杂数据表格）以及团队对非 React 方案的抵触等痛点。许多人认为 HTMX 非常适合 CRUD 风格应用和仪表盘，但不太适合高度交互、共享状态的 UI；在这些场景下，SvelteKit、LiveView 或 React 可能仍然更合适。
关于 Go + HTMX 的总体看法
- 许多评论者非常喜欢用 Go + HTMX 来开发小到中型的 Web 应用：速度快、部署简单、
one binary、JS 很少，并且能利用传统的服务器端渲染。 - HTMX 被称赞为用声明式属性替代了重复的原生 JS 事件/DOM 样板代码，尤其适合 CRUD、仪表盘、管理后台以及“以超文本为原生”的设计。
- 也有几位提到在其他后端（Rust、Python、ASP.NET Razor Pages、Kotlin、Bun 技术栈）上采用了类似模式。
技术栈、工具与模板
- 提到的常见“技术栈”包括：GUS/HUGS（Go/HTMX/Unix/SQLite）、GoTH、Go + Datastar、PAHG（Pico.css/Alpine/HTMX/Go）。
- 常见的 Go 工具：templ、gomponents、sqlc、jet、goose、OpenAPI 生成器、SQLite 库、durable workflows、浏览器自动化等。
- 大家对类型安全的 HTML 和 SQL 兴趣很高：templ、gomponents、JSX 风格或 DSL 风格的 HTML（Kotlinx.html、gsx、JinjaX、带标签的模板字面量）。
- 不少人不喜欢 Go 的
html/template的使用体验（克隆、字符串化模板）；也有人认为它在不同用法下其实安全而直接。 - 有一个讨论希望看到更“生产可用”的写法：资源打包、哈希、开发服务器、热重载，以及如何管理少量 JS 依赖。
使用场景、限制与替代方案
- 许多人表示 HTMX 在简单到中等复杂度的应用中表现出色；但在以下情况下会出现痛点：
- 交互性很强的组件（复杂数据表格、复杂筛选、虚拟化）。
- 分布在许多互相关联组件之间的共享状态。
- 实时多人协作。
- 在这些情况下，人们报告说 Svelte/SvelteKit、React、Vue 或 Elixir Phoenix LiveView 的体验更好。
- Datastar 和 Unpoly 被提为更接近“完整响应式”但仍以 HTML 为中心的替代方案；Datastar 因其能力/体积比受到称赞，但它部分商业化，而且（根据某条评论）在渐进增强方面稍弱。
- 有些人认为 HTMX 是故意把你从移动应用式 UI 引导回经典 Web 流程；也有人把这看作一种限制。
安全性与 Hyperscript
- Hyperscript 被喜欢用来处理客户端状态/DOM 变化，而无需单独的 JS 文件。
- 讨论的焦点在 CSP：内联或会执行的代码可能迫使采用更弱的策略；也提到了扩展和基于 nonce 的方式作为缓解手段。
- 结论是：在严格 CSP 和正确的服务端校验下，风险是可以控制的，但 CSP 细节很重要。
团队动态、流行度与元讨论
- 多位评论提到，团队会把 HTMX 当作“不严肃”或“不熟悉”的东西来抵触，或者对表单/SSR 缺乏基本理解。
- 也有人遇到相反情况：组织深陷 React SPA，即使已经出现扩展性问题也难以改变。
- 有人说 HTMX 的作用范围有限，而且在大型应用中复杂度上升，这解释了它为什么不算“超级流行”；也有人表示，只要抽象设计得当，中型/大型应用完全能跑得很好。
- 有评论者指出，如今更原创、深入的长文可能会更显眼，因为深入写博客的人变少了，这或许解释了它为什么会反复出现在 HN 首页。