我们有时会听到对 htmx 和超媒体的反对意见，其中一种变体如下：
嗯，它可能适用于小型项目，但无法扩展。
总是很危险用这种文章素材来刺激我们，所以让我们深入探讨一下这个说法，看看是否能
为超媒体驱动应用 (HDAs) 是否能扩展提供一些启示。
首先，让我们定义“扩展”这个术语，然后是开发中该词的使用情境。在软件
情境中，扩展通常意味着软件处理“更大”事物的能力。这些事物可以是：
“扩展”这个词的每一种含义都要求针对 HDAs 进行独立的分析。
虽然这对决定自己应用的单个开发者来说兴趣不大，但值得指出的是，Web 作为分布式网络系统已经扩展得_非常出色_。无论如何，它是我所知的最成功的分布式系统。
这对_单个_应用开发者来说不一定有兴趣，但它设定了正确的基调：超媒体
可以扩展。
超媒体在_性能_方面扩展得好吗？要回答这个问题，让我们先看看一些性能可扩展软件的特征。虽然没有权威来源定义这些特征，但大多数有经验扩展软件的工程师都会同意，这个列表中的大多数项目至少是有帮助的：
幸运的是，正确设计的超媒体系统可以具备所有这些特征。
无状态性是 Roy Fielding 创建来描述 Web 的 REST-ful 架构的约束。
在实践中，许多超媒体驱动应用使用_会话 Cookie_在服务器端管理少量状态，但这是一个众所周知的技巧，在扩展应用时并未证明是致命的。
水平扩展在超媒体驱动应用中有悠久的历史，并且与大多数超媒体驱动应用的
无状态性质相辅相成：早期的 PAAS 供应商如 heroku（神圣的记忆）提供了
rails 驱动应用的轻松水平扩展，例如。
功能独立性是 HDAs 的另一个优势。在 HDAs 中，屏幕的端点往往是
解耦的，与通用 JSON API 不同。这
意味着这些端点可以独立监控、演进和调优。我们有很长的历史，通过 SQL 调优来最小化给定端点的数据库查询，从而创建亚 100 毫秒的响应时间（例如）。
基于端点的独立性来支持各种视图，平台性能易于监控和理解。与可以通过多种方式访问应用的通用 JSON API 不同，你有
为特定视图构建超媒体的 UI 特定端点。当视图在服务器端构建并且请求通过简单的超媒体交换驱动时，确定性能问题的原因变得更容易。
最后，Web 应用有悠久而传奇的 缓存 历史。
HTTP 通过标头在浏览器端提供缓存。像 Rails 这样的成熟服务器端框架在控制器层提供复杂的缓存。
缓存对 HDAs 来说是第二天性。
所有这些结合在一起，使 HDAs 从性能角度来看极具可扩展性。随着用户负载增加，有经过实战检验的性能技巧可用于扩展你的 HDA。
HDA 方法是否将更多计算推向服务器端？在一定程度上，这是正确的。然而，给定资源的 JSON 表示与其 HTML 表示之间的差异并不像一些人认为的那么大，特别是如果你不包括 HTML 请求中的头部和页脚信息，这在
htmx 基础应用中很常见。网络延迟和数据存储访问通常主导请求时间，而使用 SQL（或类似的服务器端查询语言）的能力为你提供了优化请求的这一方面的机会。
HDAs 通常自然地具有最佳的 “每个视图一个请求”，因为，嗯，在 HDAs 中请求就是你的视图。
因为 HDAs 往往有由 UI 需求驱动的独立端点，而不是通用 JSON 数据 API，所以随着
功能数量的扩展通常非常容易。假设服务器端有合理的模型-视图-控制器分离，
控制器和模型往往彼此非常独立。当功能真正重叠时，在服务器端开发和测试功能提供了更受控和可测试的环境。
视图可以通过服务器端包含来实现重用，这在几乎所有服务器端模板库中都可以找到，或者为了避免相互依赖而单独维护。
所有这些都是说，在合理的应用架构下，HDAs 往往随着应用中功能数量的扩展_非常出色_，特别是当这些功能本质上相互解耦时。
随着功能数量的扩展在某种程度上类似于_水平扩展_：只要它们相对独立，它们就会扩展良好（如果不是，HDAs 通常也会扩展得与其他选项一样好或更好。）
但什么是_深度_功能：本身_复杂_的功能呢？
在这里，我们必须将深度功能分为两类：
对于深度服务器端功能，HDAs 往往是很好的选择。一个很好的例子是像 AI 聊天机器人这样的东西：
这是一个非常复杂的服务器端功能，但它通过简单的文本界面与用户交互。许多
AI 聊天机器人 使用 htmx 构建，人们
评论说它有多简单。
对于深度_客户端_功能，HDAs 有时_不是_很好的选择。我们在关于何时选择超媒体的文章中概述了细节。总结那篇文章：如果你的 UI 需要快速响应大量事件
（例如拖动地图视图）或有大量 UI 间依赖关系无法通过批量超媒体交换更新（例如电子表格应用），超媒体方法将无法良好工作。
然而，我们要指出两件事：
我们将考虑的扩展的最后一种含义是扩展开发团队的想法。这里我们必须依赖更多
主观和轶事性的衡量标准，不幸的是。
根据我们的经验（和其他人的经验），HDAs 似乎让你可以用_更少_的开发者完成更多事情。
它们还消除了前端/后端分离，以及这种分离的沟通摩擦，因为
开发者负责整个功能。有些人_喜欢_前端/后端分离，并觉得这通过使团队独立来更好地扩展团队。
我们不同意。我们认为大多数 Web 应用的前端和后端本质上是_耦合_的，因此，
最好的方法是采用一种接受这种耦合并设计为良好处理变化的架构，而超媒体方法就是这样（通过统一接口）。
HDAs 能否扩展到 100 人或更多人的团队？这我们无法回答，因为我们没有见过这种场景。但它当然
可以扩展到数十人。我们可以_想象_这种方法扩展得更高（毕竟它在 Web 1.0 时代做到了），但
此时我们是在推测。
无论如何，我们更喜欢更小的团队。10 个开发者应该足以应对任何应用。
所以，将这些综合起来，我们对扩展超媒体驱动应用的结论如下：
HDAs 在性能和功能数量方面可以扩展得非常好。它们可以随着功能复杂性扩展，
但有注意事项。最后，关于团队规模的扩展，陪审团仍在审议，尽管我们可以说明 HDA 方法
倾向于保持团队更小并消除团队间沟通摩擦。