构建以HTML为先的网站如何让用户数量一夜翻倍

# 构建以 HTML 为先的网站如何在一夜之间让我们的用户翻倍 来源：https://mohkohn.co.uk/writing/html-first/ 这是一个关于构建以 HTML 为先的网站如何在一夜之间让一家公司的用户数量翻倍的故事。我的客户是一家公用事业公司，他们遇到了一个大问题。要申请他们的服务，客户要么使用网站上一个古老的 ASP 表单，要么走一个手动流程。当然，手动流程对公司来说成本更高。雪上加霜的是，这是一家受监管的垄断企业，如果客户满意度低于 96%（如果我没记错的话），可能会面临数百万英镑的罚款。之前有两次尝试解决这个问题都失败了（而且代价非常高昂）。最近一次，其他国家的承包商构建了一个 React 应用。这个 React 应用上线了 3 天，就因为客户投诉而被撤下。我只看了一眼就告诉老板：“我们无法接手这个。” 它充满了加载转圈和全局 JavaScript 状态。它不具备可访问性。图片上传是表单的关键部分，但它试图将图片（以及所有其他表单数据）存储在只有 5MB 限制的 localstorage 中！我做出了一个非常大胆的决定，使用 [Astro](https://astro.build/) 构建了一个新版本的网站。它是 HTML 优先的。JavaScript 存在，以 Web 组件的形式，但仅仅用于渐进增强，即使没有它，网站也能完美运行。我的逻辑如下：1. 这是一项公共服务 2. 它应该在所有可能的机器上都能工作 3. 它应该在网络连接不佳时也能工作 4. 表单一旦输入数据，绝不能丢失。我深受 [Terence Eden 的这篇轶事](https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/) 的感动： > 几年前，我在伦敦的一个住房福利办公室做政策研究。那地方着实不讨人喜欢。墙上贴着一些海报，为逃离家庭暴力的人们提供帮助服务。门口的保安对走进来的人漠不关心。空气中弥漫着伴侣之间紧张的对话 —— 被孩子们的尖叫声淹没。中间，一个年轻女人坐在硬塑料椅子上。她周围堆着帆布包，里面装着她全部家当。她看起来情绪不太好。她手里紧紧攥着一个游戏机 —— 一个 PlayStation Portable。她全神贯注地盯着它，用 Candy Crush 屏蔽外界。或者，至少我当时是这么想的。我走到她身后，瞥了一眼她的游戏机，认出她在的界面。她连上了免费的 WiFi，正在浏览 GOV.UK 上关于住房福利的页面。她不是在切水果；她是在武装自己的知识。PSP 的网络浏览器 —— 客气地说 —— 很简陋。它速度慢，经常内存不足，一次只能打开 3 个标签页。但是 GOV.UK 的页面是用简单的 HTML 编写的。它们被设计成轻量级，即使在糟糕的浏览器上也能工作。它们必须如此。这是为所有人服务的。 我得出了一些需求： 1. 表单的每个会话都应该有一个唯一的 ID 2. 在表单向导的每一步，提交的数据都应该存储在后台，包括上传的文件 3. 应该可以在没有 JavaScript 的情况下完成表单 4. 应该可以在过时和糟糕的网页浏览器上完成表单 5. 我们必须满足 WCAG 可访问性（团队最终选择了 AA 级而不是 AAA 级） 6. 应该使用 JavaScript 和现代 CSS 来增强体验 基本设置最终是：表单向导的每一步都是一个独立的页面。当用户点击“下一步”时，表单会提交。如果 API 判断数据有效，浏览器就会被重定向到下一步。这是一个古老的 Web 应用程序模式，由于 [Remix](https://remix.run/) 而经历了一次小小的现代复兴。向我的同事解释表单提交和重定向花了一些时间，因为每个人都习惯了重度客户端 Web 应用程序。我并不反对在适当的地方使用重度客户端应用程序。但这只是一个大型表单 —— 它不需要显示实时数据。我们的用户可能正站在一个新建住宅区的田野里，手里拿着一部他们在 Tesco 买的用了十年的廉价安卓手机。在渲染表单之前就给他们发送 20MB 的 JavaScript，这将是一件荒谬的事情。 接下来，我解决了我最大的痛点之一：表单验证（以及表单和表单错误渲染）。我见过有些团队花费数人月的时间与 React 验证库作斗争。如果你是 React 开发者，你可能会对此嗤之以鼻 —— 我猜，这是技能问题 —— 但这对于许多团队来说是现实。我想谦逊地建议，你可能也在花费比你以为的更多的时间，以及远比必要更多的时间，来与每个浏览器自带验证系统的劣质模仿品打交道和进行维护。所以我构建了一个 [HTML Web 组件](https://adactio.com/journal/20618)。这些是简单的自定义元素，包装在现有的 HTML 周围，使其变得生动。没有 Shadow DOM，没有（或很少）在 JavaScript 中渲染 HTML。我的组件包装了任何 HTML 表单，拾取 HTML 验证，并使其看起来现代化。它会阻止那些 HTML 验证弹出提示框，而是把错误信息放在与字段关联的 `aria-describedby` 元素中（如今建议使用 `aria-errormessage`）。当你在输入时，如果你达到了有效状态，它会清除验证，并在失焦和提交时再次评估。这正是表单所需的用户体验，而且大小不到 1KB。如果它失败了，表单会回退到内置的浏览器验证。如果那也失败了，后台 API 会处理验证。我们会根据用户浏览器的能力，尽早地向用户报告验证问题，并且始终在失败时回退到可接受的体验。后来我用从头开始重写了这个 Web 组件的一个新版本，旨在通用。它叫做 [validation-enhancer](https://www.npmjs.com/package/validation-enhancer)。我从事这个行业已经超过 20 年，这是我用过的最好的表单验证库。我为此感到非常自豪。代码使用起来非常简单： ```html <enhanced-form> <form> <label for="email">邮箱</label> <input type="email" id="email" name="email" required> <button type="submit">提交</button> </form> </enhanced-form> ``` 结果如何？当我们上线时，完成表单的人数翻了一番。分析人员甚至不知道这些用户从哪里来。当然，你的基于 JavaScript 的分析包看不到那些因为 JavaScript 失败而被你抛弃的用户。用户如潮水般涌来！我们还看到我的“保持后台会话，永不丢失用户数据”的方法得到了回报。有一个案例，有人在一个月后完成了之前开始的表单。 有一个悲伤的尾声；就像合同工作的常态一样，我离开了。我向我的继任者解释了我构建的内容，即使没有 JavaScript 它也能工作。他感到很震惊，说：“但这对我们来说工作量大多了。” 将使用老浏览器、网络连接差的用户以及使用辅助技术的用户抛弃是不可接受的。尤其对于垄断性的公共服务来说更是如此。大量的炒作和噪音正在驱使我们将软件行业的扩张延续到牛仔式的、狂野西部的阶段。我们应该把那些放在一边，认真对待自己作为一个成熟行业的态度。构建一个能够在 3G 连接的 PlayStation Portable 上运行的 Web 应用程序 —— 如果你做到了，它就能为你所有的用户工作，并且在 30 年后仍然能够工作。