Htmx 与 Web Components：天作之合
HTMX 和 Web Components 重新引发关注，作为比重量级单页应用框架更简单的替代方案，它们把更多逻辑推回服务端，并让 HTML 片段来驱动交互。支持者强调更容易的状态管理、减少客户端/服务端模型重复，以及对 CRUD 风格或内容密集型应用的良好适配；怀疑者则质疑其可扩展性、复杂用例，以及属性密集型 HTML 的可用性——尤其是与 Tailwind 这类实用优先的 CSS 方案结合时。讨论很大程度上围绕开发体验、长期可维护性，以及为特定项目选择合适 JavaScript 规模之间的取舍展开。
HTMX + Web Components 的协同与生命周期问题
- 许多人认为 HTMX 和 Web Components 是互补的：组件在附加到 DOM 时会自我初始化，因此很容易“通过 AJAX 加载进来”。
- 实践模式：像
<my-modal>这样的自定义标签包裹普通 HTML，并配合少量 JS 处理监听器和属性。 - 讨论中提到生命周期问题：父组件可能需要在子自定义元素连接到 DOM 之前就访问它们。讨论中的变通办法包括：
- 子元素在父元素上自行注册。
- 使用
CustomEvent冒泡、slotchange、MutationObserver或whenDefined。
- 也有人认为，如果没有框架，Web Components 的组合能力有限，因为属性是基于字符串的，更丰富的状态共享会比较麻烦。
HTMX：优势、局限与架构问题
- 支持者喜欢 HTMX 让服务端驱动的 UI 重新回归：更少的 JS、客户端和服务端不需要重复模型、更简单的 CRUD 应用，以及“像 2007 年那样有趣，但配上现代 CI/CD”。
- 它被称赞适合中小型、内容较多且不值得引入完整 SPA 复杂度的应用。很多人表示自己写的 JS 少了很多，只在边缘场景才使用。
- 怀疑者认为，它只是用一种类似旧式 MVC 应用的方式拼接 HTML 片段，而那类应用最终往往变得难以维护。也有人更倾向于嵌入小型 SPA 组件。
- 有个担忧是：HTMX 需要单独的 HTML 端点，而 JSON API 也要单独提供；另一些人则认为把 UI 和集成 API 分开是健康的。
- 仍然存在一些未解问题：
- 如何扩展到非常大的代码库；线程里几乎没有公开记录的大型 HTMX 部署案例。
- 通过部分 HTML 响应时的 SEO 和爬虫行为（线程中没有明确共识）。
SPA 框架与超媒体方案
- 几位参与者比较了自己的体验：React/Angular 项目被描述为迭代缓慢，状态管理痛苦（全局 store、reducer、prop drilling），不过也有人说这更多是架构问题，而不是框架本身的问题。
- 有人强调现实中的大多数应用都很小；对于基本表单和表格这类场景，SPA 技术栈和重 JS 被认为是过度设计，而 HTMX 配合服务端渲染就足够了。
- 也有人强调，SPAs 在复杂、高交互性的“webapp”界面以及共享全局状态方面仍然非常出色；HTMX 在这些场景下被认为并不适合。
Tailwind、CSS 与“重新想象的内联样式”
- 观点分歧很大：
- 支持 Tailwind：UI 构建更快，间距/颜色等有一致的尺度，所有内容集中在一处更容易阅读和更新，对团队和设计系统很友好，通常总体 CSS 更少。
- 反对 Tailwind：HTML 变成噪音很大的“class soup”，长期维护更难，失去语义化类名和传统 CSS 学习路径，感觉像披着华丽外衣的内联样式。
- 有些人会通过组件库（Bootstrap、daisyUI）、原子 CSS 库（UnoCSS、open-props），或把 Tailwind 工具类与自定义类混用来缓解这些问题。
- 争论仍在继续：Tailwind 那种“像内联样式”的方式到底是倒退，还是一种务实的抽象。