HTMX允许你使用扩展的HTML语法代替 JavaScript 来实现交互性。HTMX 在标记中直接为你提供HTTP 交互，并支持许多其他交互需求，无需求助于 JavaScript。这是一个有趣的想法，可能最终会影响到web前端的工作方式。让我们看看如何使用HTMX以及它的吸引力。

什么是HTMX？

HTMX已经存在了一段时间，但它一直是一个不太为人知的项目。它最近被接受到 GitHub Accelerato r中可能会改变这一切。基本的想法是取代那些需要模板化的 JavaScript 和 HTML 交互的常见用例，仅使用HTML语法，而不是 JavaScript。许多交互与HTMX一起变得声明式。

这听起来很有前景，不是吗？每个web开发者都知道有很多常见的模板化用例。HTMX的创建者Carson Gross表示，他希望“完善HTML作为超文本，增加其表现力，使其成为更先进、现代web应用程序的有力竞争者。”

为了快速了解，看看这个HTMX演示。基本上，我们点击一个按钮来启用对用户对象的字段进行编辑。数据实际上是PUT到一个后端端点。你可以在图1中看到演示 —— 在你点击“显示”后注意底部框架中的网络交互。

通常，无论你使用什么框架，这都需要某种形式的JavaScript。HTMX 将交互转变为两块标记：一个用于显示UI，一个用于编辑UI，如Listing 1所示。

Listing 1. HTMX中的用户更新

:Joe:Blow:joe@blow.com点击编辑提交取消

如果你看Listing 1中的标记，很容易看出发生了什么：hx-swap属性为编辑前的 div 提供HTML，outerHTML告诉框架它如何与内部的动态内容相关。可编辑版本作为一个表单元素到达，其中包含x-put属性，该属性标识PUT HTML方法和要使用的端点。

问题变成，HTMX如何实现这种“交换”和后续的PUT，而不做任何JavaScript呢？答案很简单：它使用服务器端渲染的HTML作为编辑标记，并将表单封装抽象到框架中。JavaScript 仍然在幕后工作。实际上，我们得到了一个更细粒度的 HTML 语法，它只能加载片段而不是整个页面，并且可以提交Ajax请求。

这是DRY原则在行动中的一个有趣的例子。即使使用像React这样的东西，从一个表单到另一个表单也有一定数量的模板代码。当然，HTMX并没有完全消除这一点，但它已经将工作转移到了服务器上。

HTMX的服务器端

现在，让我们考虑等式的服务器端。有许多使用HTMX的服务器端技术的例子，因为，正如Gross所说，HTMX是“后端不可知的。它不关心你使用什么后端，只要它产生HTML。” 为了了解它是如何工作的，让我们看一个使用Express和Pug HTML模板引擎的TODO示例。这个例子是经典TODO应用程序的实现。

首先，现有的待办事项从Express输出，命令如下:

res.render('index',{todos:filteredTodos,filter,itemsLeft:getItemsLeft()});

此命令使用内存中的待办事项集合，并使用一个Pug模板渲染它们，该模板是典型的格式，但它包括驱动HTMX交互的特殊hx-属性。例如，用于POST新待办事项的表单显示在Listing 2中。

Listing 2. 具有HTMX属性的表单POST
form(hx-post="/todos",hx-target="#todo-list",hx-swap="afterbegin",_="onhtmx:afterOnLoadset#txtTodo.valueto''")input#txtTodo.new-todo(name="todo",placeholder='需要做什么" />form(hx-post="/todos/update/"+todo.id)input.edit(type="text",name="name",value=todo.name)

在Listing 3中，标记使用hx-post属性来指示发送已编辑待办事项的JSON的位置。从这些例子中得到的结论是我之前提到的：服务器负责提供HTML（带有HTMX标签）的适当大小的块，以填充前端为其各种交互所需的屏幕的不同部分。HTMX客户端将根据属性将它们放在它们应该在的位置，并处理发送由服务消费的适当数据。

负责接收数据的端点可以像典型的端点一样操作，区别在于响应应该是必要的HTMX。例如，在Listing 4中，你可以看到Express服务器如何处理POST以创建新的待办事项。

Listing 4. 处理待办事项创建
app.post('/todos',(req,res)=>{const{todo}=req.body;constnewTodo={id:uuid(),name:todo,done:false};todos.push(newTodo);lettemplate=pug.compileFile('views/includes/todo-item.pug');letmarkup=template({todo:newTodo});template=pug.compileFile('views/includes/item-count.pug');markup+=template({itemsLeft:getItemsLeft()});res.send(markup);});

Listing 4 是一个典型的POST body处理器，它从表单数据中取出值并使用它创建一个新的业务对象（newTodo）。然后，它使用这些值填充Pug模板并将其发送回客户端，用作前端的Todo列表中的插入。

其他服务器端技术的例子包括使用HTMX与Java世界中的Spring Boot和Thymeleaf以及Python世界中的Spring Boot和Django。

使用HTMX的客户端模板

HTMX支持的这种模式的一个变种是使用客户端模板。这是一个在客户端运行的层，接受来自服务器的JSON，并在那里进行标记转换。当我问Gross关于使用带有 JSON的 RESTful 服务时，他指出这是可能的，但前提是REST通常被误解。

一个相反的问题是，我们如何向服务器提交JSON，而不是默认的表单编码？再次，有一个扩展可以做到这一点；即，JSON-ENC。

结论

考虑HTMX会导致一堆想法同时到来。结论是这个概念和这个项目本身一样有益。作为一个成熟的项目的HTMX可能最终不会像今天这样工作，但它已经证明是一个有益的影响。最吸引人的是处理所有这些非常常见的Ajax风格的请求的想法，这通常意味着使用fetch()或类似的东西，只用一个HTML属性。这只是更简单、更干净，并且将一切都保持在一个地方。很明显标记做了什么。

我对服务器端标记生成持更加矛盾的态度。开发者习惯于为此目的处理JSON；引入标记只是在客户端创建中增加了一个步骤。我们已经看到了许多服务器端方法，它们总是似乎模糊了HTML、JavaScript和CSS的强大组合，这三者最终总是胜出。也许这次会不同。这是一个大的摆动。

当然，还有客户端模板选项，它使服务器成为一个熟悉的JSON发射器。我试图想象它在一个大型软件项目中是如何工作的。它会减少大规模项目中的总体复杂性吗？

Gross对复杂性有自己的想法。你可以看到他的想法在HTMX的设计中得到体现。这项技术希望通过将我们带回到Hypertext作为web应用程序的状态机制来简化事情。这个例子显示了这个想法的运作。使用JSON作为协议意味着使客户端更加智能、更加复杂，并使架构变得不那么自描述。

也许它都可以工作。如果我们避免了固有的复杂性，扩展了底层语言HTML，实际上处理现代需求，比如Ajax，我们可以回到一个更简单的时代。标记将再次成为中心数据描述符，并足以描述UI以及线上的数据。

欢迎长按图片加刷碗智为好友，定时分享 Vue React Ts 等。

最后：

vue2与vue3技巧合集

VueUse源码解读