我们有时会听到对htmx和超媒体的反对意见，大致如下：
嗯，它可能适用于小型项目，但无法扩展。
用这种话题来刺激我们总是危险的，因此让我们深入探讨一下这个说法，看看是否能阐明超媒体驱动应用（HDAs）是否能够扩展。
首先，让我们定义“扩展”一词及其在开发中的不同语境。在软件领域，扩展通常指软件处理“更大”事物的能力。这些事物可以是：
“扩展”一词的每一种含义都需要针对HDAs进行单独分析。
尽管这对个体开发者决定自己的应用并不太重要，但值得指出的是，作为一个分布式网络系统，万维网的扩展能力令人难以置信。无论如何，它是我所知道的最成功的分布式系统。
这对个体应用开发者来说可能并不重要，但它为讨论奠定了基调：超媒体能够扩展。
超媒体在性能方面能良好扩展吗？要回答这个问题，首先让我们看看性能可扩展软件的一些特征。虽然没有权威来源定义这些特征，但大多数有扩展软件经验的工程师会同意以下大多数条目至少是有帮助的：
幸运的是，设计良好的超媒体系统可以具备所有这些特征。
无状态性是Roy Fielding为描述万维网而创建的REST架构的约束之一。在实践中，许多超媒体驱动应用使用会话cookie来管理服务器端的一小部分状态，但这是一种成熟的技术，尚未在扩展应用时造成致命问题。
水平扩展在超媒体驱动应用中有悠久的历史，并且与大多数超媒体驱动应用的无状态性相辅相成：早期的PAAS供应商如heroku（令人怀念）就提供了对Rails驱动应用的简单水平扩展。
功能独立性是HDAs的另一优势。在HDAs中，屏幕的端点往往彼此解耦，这与通用JSON API不同。这意味着这些端点可以独立监控、演进和优化。我们有着悠久的历史来优化这类端点，以实现低于100毫秒的响应时间（例如通过SQL调优减少特定端点的数据库查询）。
基于视图端点的独立性，平台性能易于监控和理解。与通用JSON API不同，HDAs中的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方法倾向于保持团队较小，并消除团队间的沟通摩擦。