为什么你应该选择 HTMX 作为你的下一个基于网络的副项目，而不是选择复杂的 MPA 和麻烦的 SPA

我建立了很多副项目，因此我总是寻找能够让我以类似质量更快、更便宜地构建它们的技术和范式。在过去的几个月里，我一直在尝试使用低 JS 工具如 HTM 和 Alpine 来构建 web 应用程序。

在这篇文章中，我将分享为什么我认为HTMX是更快、更便宜地构建网络应用程序的一个不错选择，以及它为什么现在成为我的技术堆栈的核心部分 - HAM Stack。

MPA 与 SPA
MPA 与 SPA

多页面应用 (MPA)
一开始我们有多页面应用 (MPA)。

每个网址都会跳转到一个网页
该网页在服务器端渲染并发送回用户
如果您需要更新页面上的某些内容(因为用户更改了某些内容或需要刷新)那么整个页面需要重新加载
这很好用，但它给人一种非常缓慢/笨重的感觉，因为每次页面上的一件事发生变化时，你都需要重新加载所有内容。举个例子——想想一个州政府网站，许多这些网站仍然是老派的多页面应用，与大多数现代应用相比，它们显得陈旧和笨重。

MPA的优缺点

优点：简单构建
缺点：由于刷新，感觉缓慢而笨拙
单页应用(SPA)
为了解决这个问题，单页面应用(SPA)被创建。

一个URL加载了一个包含大量应用逻辑的大型JS负载
这个JS接管页面渲染
它使用内部状态来确定页面应该是什么样子，并在后台进行数据传输，因此只需要更新需要更改的页面部分。
这对用户来说感觉更好，因为变化感觉更快。页面只在需要的地方更新，我们不需要完全刷新页面来更改数据。今天大多数应用程序/网站都是这样，因为这通常提供更好的用户体验。

优点：丰富的“现代”用户体验
缺点：在大规模时复杂 - 处理数据传输(graphQL为此而建立)，抽象和应用逻辑负载大小
所以一般来说：

多页面应用 (MPA) - 容易构建，但很难获得丰富的"现代"用户体验
单页面应用 (SPA) - 构建复杂，但可以实现丰富的“现代”用户体验
MPA 与 HTMX 与 SPA
MPA 与 HTMX 与 SPA

图片灵感来自u/Abhilash26在r/htmx上的分享。

HTMX已经存在了好几年，但在过去的一年左右确实获得了大量的关注。这种关注并非毫无根据——它通常允许你比SPA更快、更便宜地构建现代网页应用。

HTMX 本质上扩展了 HTML，使其能够进行部分页面重载。

任何元素都可以指定如何检索最新数据以及何时进行检索
该元素可以指定如何处理新数据 - 替换自身或页面上的其他元素
如果我们回顾一下MPA与SPA的比较，我们可以看到，缺乏部分页面重新加载确实是阻碍MPA发展的主要因素。因此，将此功能添加到MPA中在很大程度上使您能够获取SPA的大部分丰富的“现代”用户体验，同时保持MPA的复杂性水平。

HTMX用于副项目
侧项目的目标往往只是构建这个东西。你可能没有一支工程师团队或一大笔风险投资资金来实现这一点——只有你和你的电脑。

因此，降低建设成本 - 无论是时间还是金钱 - 对于使一个副项目成功至关重要。

在我看来，HTMX 提供了一个很好的平衡，让你可以以非常低的复杂性构建现代应用(，从而节省时间和金钱成本)。因此，它已成为我技术栈的核心部分——HAM Stack。

下一步
Md Saidur Rahman