用 HTML-first 方式构建网站让我们的用户一夜之间翻倍

HTML-first 与渐进增强

• 许多人将这个故事视为 HTML-first、渐进增强网站的有力案例，尤其适用于公共服务和表单。
• 经典 Web 模式（链接、表单、重定向、多页面“向导”）被赞赏，因为它们：
  • 在关闭或损坏 JS 的情况下也能工作。
  • 为用户提供浏览器内置行为（后退/前进、验证 UI、焦点、键盘访问）。
  • 减少 SPA 中常见的不可见故障模式（加载中的转圈、静默的 JSON 错误）。
• 有人指出，这本质上是对“渐进增强”的重新发现，也是 Rails/Django 之类框架长期倡导的做法。

React、SPA 与性能

• 一个反复出现的主题，是对沉重的 React/SPA 技术栈、构建步骤，以及为基础表单或大多静态的内容而引入的数 MB JS 的挫败感。
• 一些人认为，虽然你可以用 React 构建良好的 UX，但更容易做出糟糕、脆弱、不可访问或臃肿的应用：
  • 默认倾向于客户端渲染和自定义组件，而不是语义化 HTML。
  • 许多开发者不知道如何在没有 JS 的情况下构建可工作的表单。
• 也有人反驳：真正的问题在于设计和开发者水平，而不是框架本身；你同样可以用 React 交付纯 HTML 的应用，或者做出缓慢的服务器渲染网站。

Astro、HTMX、Go 以及其他技术栈

• Astro 因默认生成静态 HTML，并将 JS 以“按需启用”的 islands 形式引入而多次受到称赞，这与 React/Next 的“默认启用、需要时再关闭”倾向不同。
• HTMX + Go + SQLite 被称为许多应用中“无聊但有效”的技术栈，JS 极少且部署容易。
• 还有人讨论了 Hotwire、服务端驱动的移动端方案、静态站点生成器（Jekyll）以及简单的 SSR 作为可行替代方案。

可访问性、设备与用户同理心

• 评论者强调了使用低端手机、旧浏览器、游戏主机或较差网络连接的真实用户；这些用户往往不会出现在基于 JS 的分析中。
• 关于究竟有多少用户没有 JS 或现代 TLS，存在争论：
  • 一方认为：即使只有约 1%，他们往往是最脆弱的人群，而服务（尤其是政府/公用事业）也应当照顾他们。
  • 另一方则认为：仅 HTTPS 和重 JS 的做法如今已成为常态，有时还受到浏览器和平台政策推动。
• 年龄和数字素养也被讨论：许多非技术用户（无论年龄）并没有复杂界面的心理模型，所以简单、稳健的流程很重要。

指标、权衡与文化

• 几位评论者指出，“用户翻倍”的结果其实更多是表单完成率更高/流失更低，而不是流量增长。
• 也有人强调权衡：
  • HTML-first 可能意味着更多定制 UI 工作，以及更少现成的组件库。
  • 团队和招聘流程都更偏向 React；偏离它会显得有风险，或者像“更多工作”。
• 还有对行业激励的更广泛批评：追逐潮流的工具、对基础知识重视不足，以及对慢设备和弱势用户缺乏同理心。