为什么 Java 后端开发者需要关注 HTMX在当前的 Web 开发浪潮中前端框架的复杂度似乎永无止境。对于习惯了 Spring Boot、Thymeleaf 或 JSP 的 Java 后端开发者而言为了实现一个简单的“无刷新删除”或“实时搜索”往往需要引入 React 或 Vue搭建 Node.js 构建环境编写大量的 JavaScript 胶水代码还要处理前后端分离带来的 CORS、状态同步等棘手问题。这种“杀鸡用牛刀”的开发模式不仅拉长了学习曲线也让原本清晰的后端逻辑变得支离破碎。HTMX 的出现恰恰是为了解决这一痛点。它不是一个试图取代 JavaScript 的庞大框架而是一个轻量级的库压缩后仅约 14kb允许你直接在 HTML 属性中声明 AJAX 请求、CSS 过渡、WebSocket 连接等服务端交互行为。它的核心理念是“超文本驱动”即服务器返回的是 HTML 片段而非 JSON 数据浏览器接收到片段后直接替换页面上的指定部分。这意味着你可以继续使用熟悉的 Java 技术栈在 Controller 中处理业务逻辑返回渲染好的 HTML而无需编写复杂的 frontend code。对于 Java 开发者来说这不仅是技术的回归更是开发效率的显著提升。Spring Boot 集成实战从 HTTP 动词到控制器映射要将 HTMX 融入 Spring Boot 项目过程异常简单。你只需要在页面的head标签中引入 HTMX 的 CDN 脚本剩下的工作几乎全部可以在后端的 Controller 中完成。HTMX 通过特定的hx-前缀属性来触发请求这些属性天然对应着标准的 HTTP 动词与 Spring MVC 的注解体系完美契合。处理 POST 请求与表单提交最常见的场景莫过于表单提交。在传统开发中我们需要拦截表单的 submit 事件阻止默认行为序列化数据发送 AJAX 请求然后手动更新 DOM。而在 HTMX 中这一切只需一个属性。假设我们有一个简单的任务创建表单HTML 结构如下form hx-post/tasks hx-target#task-list hx-swapbeforeend input typetext nametitle placeholder输入新任务... required button typesubmit添加任务/button /form div idtask-list !-- 现有任务列表 -- /div这里的hx-post/tasks告诉浏览器当表单提交时向/tasks发送一个 POST 请求。hx-target#task-list指定了响应内容要插入的目标元素而hx-swapbeforeend则表示将新内容追加到目标元素的末尾而不是替换整个列表。对应的 Spring Controller 代码非常直观Controller RequestMapping(/tasks) public class TaskController { PostMapping public String createTask(RequestParam String title, Model model) { // 业务逻辑保存任务到数据库 Task newTask taskService.save(new Task(title)); // 将新任务对象放入模型准备渲染片段 model.addAttribute(task, newTask); // 返回一个 Thymeleaf 片段只包含新任务的 HTML 结构 return fragments/task-item :: taskItem; } }注意这里返回的不是一个完整的视图名称如tasks/list而是一个具体的片段fragments/task-item :: taskItem。Spring Boot 配合 Thymeleaf 只会渲染这个片段对应的 HTML例如li classtask新任务名称/li。HTMX 接收到这段 HTML 后会自动将其插入到页面上 ID 为task-list的容器中。整个过程没有一行 JavaScript后端逻辑清晰且内聚。PUT 与 DELETE 的优雅处理除了 POSTHTMX 同样支持 PUT 和 DELETE 动词这对于 RESTful 风格的资源更新和删除至关重要。例如我们要实现一个“标记任务完成”的功能可以使用hx-putbutton hx-put/tasks/123/complete hx-targetclosest tr hx-swapouterHTML 完成任务 /button点击按钮后HTMX 会发送 PUT 请求。后端 Controller 接收请求并处理业务最后返回整行tr的新 HTML可能包含不同的样式类表示已完成。hx-targetclosest tr是一个强大的选择器它指示 HTMX 查找当前按钮最近的祖先tr元素作为更新目标。对于删除操作hx-delete的使用同样自然button hx-delete/tasks/123 hx-confirm确定要删除这个任务吗 hx-targetclosest tr hx-swapouterHTML 删除 /button这里还引入了hx-confirm属性它在发送请求前会弹出一个原生的浏览器确认对话框极大地提升了用户体验的安全性。后端的DeleteMapping方法只需返回一个空的字符串或者简单的成功消息HTMX 收到响应后会根据hx-swapouterHTML将原来的tr元素从 DOM 中移除实现行的无缝消失。DeleteMapping(/{id}) ResponseBody public String deleteTask(PathVariable Long id) { taskService.delete(id); // 返回空字符串HTMX 会根据 swap 策略移除目标元素 return ; }精准操控 DOMTarget 定位与 OOB 跨区更新在实际业务场景中页面交互往往比单一的增删改查复杂。有时候一个操作需要同时更新页面上的多个不连续区域。例如在电商后台删除一个商品不仅需要从列表中移除该行还需要实时更新顶部的“商品总数”统计。如果只用传统的hx-target我们只能更新一个区域这就显得捉襟见肘。这时HTMX 的hx-swap-oobOut of Band Swap功能就成为了救星。hx-target 的基础定位hx-target是 HTMX 最基础的定位工具它接受任何 CSS 选择器。除了常见的 ID 选择器#id和类选择器.classHTMX 还提供了一些扩展关键字让定位更加灵活this指代触发请求的元素本身。closest selector查找最近的祖先元素。next selector/previous selector查找相邻的兄弟元素。find selector查找内部的子元素。这些选择器让你无需给每个 DOM 元素都硬编码一个 ID就能精确控制更新范围保持了 HTML 结构的整洁。hx-swap-oob 解决多区域刷新难题hx-swap-oob允许服务器在响应中包含多个 HTML 片段并指定它们分别更新页面上不同位置的元素。即使这些元素并不是本次请求的直接目标target也能被“跨区”更新。让我们回到刚才的商品删除场景。用户点击删除按钮我们希望从商品列表中移除该行。更新顶部的库存计数。前端 HTML!-- 顶部统计区域 -- div idinventory-count当前库存100/div !-- 商品列表 -- table tbody idproduct-list tr idproduct-99 td商品 A/td td button hx-delete/products/99 hx-target#product-99 hx-swapouterHTML 删除 /button /td /tr !-- 其他商品... -- /tbody /table后端 Controller 逻辑在 Spring Boot 中我们需要构造一个包含两个片段的响应。虽然通常我们返回单个 Fragment但利用 Thymeleaf 的特性我们可以返回一个包含多个带有hx-swap-oob属性元素的模板。DeleteMapping(/products/{id}) public String deleteProduct(PathVariable Long id, Model model) { productService.delete(id); // 计算新的库存数量 long newCount productService.getCount(); model.addAttribute(newCount, newCount); // 返回一个包含两个部分的模板 // 1. 主响应空字符串或直接移除目标行由 hx-target 处理 // 2. OOB 响应更新库存计数 return fragments/product-delete-response :: deleteContent; }Thymeleaf 模板 (product-delete-response.html)th:block th:fragmentdeleteContent !-- 这部分其实可以留空因为 hx-target 已经负责移除行了 -- !-- 但为了明确我们可以返回一个空节点或者什么都不返回 -- !-- 关键部分OOB 更新 -- !-- 注意这个 div 的 ID 必须与页面上要更新的元素 ID 一致 -- div idinventory-count hx-swap-oobtrue 当前库存span th:text${newCount}0/span /div /th:block当 HTMX 收到这个响应时它会执行两步操作首先根据请求元素上的hx-target指令移除 ID 为product-99的行其次扫描响应内容发现带有hx-swap-oobtrue且 ID 为inventory-count的元素于是自动找到页面上对应的元素并用新内容替换它。这种机制彻底解决了“一次操作多处更新”的难题而且所有逻辑依然牢牢掌握在后端手中。前端不需要知道库存怎么算也不需要关心如何同时操作两个 DOM 节点它只是忠实地执行后端的指令。进阶交互体验提示框、历史记录与渐进增强为了让 Web 应用体验更接近原生桌面软件或单页应用SPAHTMX 提供了一系列高级属性处理用户输入、浏览器历史等细节而这些同样无需编写 JavaScript。动态输入与确认hx-prompt 与 hx-confirm在某些敏感操作中仅仅依靠后端校验是不够的我们需要在前端即时获取用户确认或额外输入。hx-confirm我们已经见过它能弹出标准的确认框。而hx-prompt则更进一步它能弹出一个输入框让用户输入文本并将该文本作为参数发送给服务器。场景管理员删除一个重要配置项系统要求输入“确认删除”字样才能执行。button hx-delete/config/critical hx-prompt请输入确认删除以继续操作 hx-confirm这是高危操作 hx-target#config-row hx-swapouterHTML 删除配置 /button当用户点击按钮先弹出确认框确认后弹出输入框。用户输入的内容会被 HTMX 自动添加到请求参数中默认参数名为prompt。后端接收处理DeleteMapping(/config/critical) ResponseBody public String deleteCriticalConfig(RequestParam String prompt, HttpServletRequest request) { // 检查 HTMX 传来的 prompt 值 if (!确认删除.equals(prompt)) { // 如果验证失败返回错误信息HTMX 会将此信息显示在 target 位置 return span classerror验证失败未执行删除。/span; } configService.deleteCritical(); return ; // 成功则移除元素 }这种方式将交互逻辑前置减少了无效请求对后端的冲击同时保持了代码的简洁性。保持浏览器历史hx-push-url传统 AJAX 操作的一个大问题是 URL 不会改变导致用户无法使用浏览器的“后退”按钮回到之前的状态也无法分享当前页面的特定状态。HTMX 通过hx-push-url属性完美解决了这个问题。当你在一个列表中进行分页或筛选时希望 URL 随之变化例如从/items变为/items?page2以便用户收藏或回退。a href/items?page2 hx-get/items?page2 hx-target#item-container hx-push-urltrue 第 2 页 /a设置hx-push-urltrue后HTMX 会在请求成功后自动将浏览器的地址栏更新为href属性中的 URL。如果你希望自定义 URL比如不带查询参数的友好路径也可以直接指定字符串hx-push-url/items/page/2。这样用户点击“后退”按钮时浏览器会触发一个新的 GET 请求或者利用 HTMX 的历史缓存机制恢复到上一页的状态完全符合用户对 Web 应用的直觉预期。这对于 SEO 也是友好的因为每个状态都有独立的 URL。渐进增强策略旧项目的低成本现代化改造很多 Java 开发者面临的现实是手头维护着大量的遗留系统这些系统基于 JSP 或早期的 Thymeleaf 构建全是同步跳转用户体验生硬。重构为前后端分离架构成本太高风险太大。HTMX 的“渐进增强”理念正是为此而生。渐进增强的核心在于基础功能在不支持 HTMX 的环境下依然可用而在支持的环境中则获得增强体验。观察上面的代码示例你会发现hx-get、hx-post等属性通常是与标准的href或action属性共存于同一个标签中的。!-- 渐进增强示例 -- a href/details/123 hx-get/details/123 hx-target#detail-panel hx-push-urltrue 查看详情 /a在没有加载 HTMX 脚本的老式浏览器或网络故障时hx-get属性被忽略浏览器执行标准的href跳转加载整个新页面。功能完全正常只是体验是传统的同步刷新。在现代浏览器且 HTMX 加载成功后HTMX 拦截点击事件执行 AJAX 请求只更新#detail-panel区域并推送 URL。用户体验瞬间升级为无刷新的流畅模式。这意味着你可以今天就在生产环境的旧项目中引入 HTMX 脚本然后挑选几个高频操作的页面如列表删除、详情加载、表单提交加上hx-属性。一旦加上这些功能立刻变身为“准 SPA体验。如果出现问题只需移除脚本或属性系统立刻回退到原始的同步模式绝不会导致页面白屏或功能不可用。这种策略极大地降低了技术升级的风险和成本。你不需要重写前端路由不需要重构后端接口为纯 JSON API虽然保留 JSON API 也没问题但 HTMX 更倾向于直接返回 HTML 片段甚至不需要改变现有的权限认证和会话管理机制。所有的 Session、Security Context 在后端 Controller 中照常工作因为请求本质上依然是标准的 HTTP 请求。对于 Java 后端团队而言HTMX 不仅仅是一个工具更是一种思维方式的解放。它让我们重新认识到服务端渲染SSR在现代硬件和网络条件下依然具有强大的生命力和开发效率优势。通过将交互逻辑回归到后端我们得以用更少的代码、更低的复杂度构建出响应迅速、体验优秀的 Web 应用。在这个前端框架层出不穷的时代或许最简单的方案才是最适合 Java 开发者的“救星”。
为什么 Java 后端开发者需要关注 HTMX在当前的 Web 开发浪潮中前端框架的复杂度似乎永无止境。对于习惯了 Spring Boot、Thymeleaf 或 JSP 的 Java 后端开发者而言为了实现一个简单的“无刷新删除”或“实时搜索”往往需要引入 React 或 Vue搭建 Node.js 构建环境编写大量的 JavaScript 胶水代码还要处理前后端分离带来的 CORS、状态同步等棘手问题。这种“杀鸡用牛刀”的开发模式不仅拉长了学习曲线也让原本清晰的后端逻辑变得支离破碎。HTMX 的出现恰恰是为了解决这一痛点。它不是一个试图取代 JavaScript 的庞大框架而是一个轻量级的库压缩后仅约 14kb允许你直接在 HTML 属性中声明 AJAX 请求、CSS 过渡、WebSocket 连接等服务端交互行为。它的核心理念是“超文本驱动”即服务器返回的是 HTML 片段而非 JSON 数据浏览器接收到片段后直接替换页面上的指定部分。这意味着你可以继续使用熟悉的 Java 技术栈在 Controller 中处理业务逻辑返回渲染好的 HTML而无需编写复杂的 frontend code。对于 Java 开发者来说这不仅是技术的回归更是开发效率的显著提升。Spring Boot 集成实战从 HTTP 动词到控制器映射要将 HTMX 融入 Spring Boot 项目过程异常简单。你只需要在页面的head标签中引入 HTMX 的 CDN 脚本剩下的工作几乎全部可以在后端的 Controller 中完成。HTMX 通过特定的hx-前缀属性来触发请求这些属性天然对应着标准的 HTTP 动词与 Spring MVC 的注解体系完美契合。处理 POST 请求与表单提交最常见的场景莫过于表单提交。在传统开发中我们需要拦截表单的 submit 事件阻止默认行为序列化数据发送 AJAX 请求然后手动更新 DOM。而在 HTMX 中这一切只需一个属性。假设我们有一个简单的任务创建表单HTML 结构如下form hx-post/tasks hx-target#task-list hx-swapbeforeend input typetext nametitle placeholder输入新任务... required button typesubmit添加任务/button /form div idtask-list !-- 现有任务列表 -- /div这里的hx-post/tasks告诉浏览器当表单提交时向/tasks发送一个 POST 请求。hx-target#task-list指定了响应内容要插入的目标元素而hx-swapbeforeend则表示将新内容追加到目标元素的末尾而不是替换整个列表。对应的 Spring Controller 代码非常直观Controller RequestMapping(/tasks) public class TaskController { PostMapping public String createTask(RequestParam String title, Model model) { // 业务逻辑保存任务到数据库 Task newTask taskService.save(new Task(title)); // 将新任务对象放入模型准备渲染片段 model.addAttribute(task, newTask); // 返回一个 Thymeleaf 片段只包含新任务的 HTML 结构 return fragments/task-item :: taskItem; } }注意这里返回的不是一个完整的视图名称如tasks/list而是一个具体的片段fragments/task-item :: taskItem。Spring Boot 配合 Thymeleaf 只会渲染这个片段对应的 HTML例如li classtask新任务名称/li。HTMX 接收到这段 HTML 后会自动将其插入到页面上 ID 为task-list的容器中。整个过程没有一行 JavaScript后端逻辑清晰且内聚。PUT 与 DELETE 的优雅处理除了 POSTHTMX 同样支持 PUT 和 DELETE 动词这对于 RESTful 风格的资源更新和删除至关重要。例如我们要实现一个“标记任务完成”的功能可以使用hx-putbutton hx-put/tasks/123/complete hx-targetclosest tr hx-swapouterHTML 完成任务 /button点击按钮后HTMX 会发送 PUT 请求。后端 Controller 接收请求并处理业务最后返回整行tr的新 HTML可能包含不同的样式类表示已完成。hx-targetclosest tr是一个强大的选择器它指示 HTMX 查找当前按钮最近的祖先tr元素作为更新目标。对于删除操作hx-delete的使用同样自然button hx-delete/tasks/123 hx-confirm确定要删除这个任务吗 hx-targetclosest tr hx-swapouterHTML 删除 /button这里还引入了hx-confirm属性它在发送请求前会弹出一个原生的浏览器确认对话框极大地提升了用户体验的安全性。后端的DeleteMapping方法只需返回一个空的字符串或者简单的成功消息HTMX 收到响应后会根据hx-swapouterHTML将原来的tr元素从 DOM 中移除实现行的无缝消失。DeleteMapping(/{id}) ResponseBody public String deleteTask(PathVariable Long id) { taskService.delete(id); // 返回空字符串HTMX 会根据 swap 策略移除目标元素 return ; }精准操控 DOMTarget 定位与 OOB 跨区更新在实际业务场景中页面交互往往比单一的增删改查复杂。有时候一个操作需要同时更新页面上的多个不连续区域。例如在电商后台删除一个商品不仅需要从列表中移除该行还需要实时更新顶部的“商品总数”统计。如果只用传统的hx-target我们只能更新一个区域这就显得捉襟见肘。这时HTMX 的hx-swap-oobOut of Band Swap功能就成为了救星。hx-target 的基础定位hx-target是 HTMX 最基础的定位工具它接受任何 CSS 选择器。除了常见的 ID 选择器#id和类选择器.classHTMX 还提供了一些扩展关键字让定位更加灵活this指代触发请求的元素本身。closest selector查找最近的祖先元素。next selector/previous selector查找相邻的兄弟元素。find selector查找内部的子元素。这些选择器让你无需给每个 DOM 元素都硬编码一个 ID就能精确控制更新范围保持了 HTML 结构的整洁。hx-swap-oob 解决多区域刷新难题hx-swap-oob允许服务器在响应中包含多个 HTML 片段并指定它们分别更新页面上不同位置的元素。即使这些元素并不是本次请求的直接目标target也能被“跨区”更新。让我们回到刚才的商品删除场景。用户点击删除按钮我们希望从商品列表中移除该行。更新顶部的库存计数。前端 HTML!-- 顶部统计区域 -- div idinventory-count当前库存100/div !-- 商品列表 -- table tbody idproduct-list tr idproduct-99 td商品 A/td td button hx-delete/products/99 hx-target#product-99 hx-swapouterHTML 删除 /button /td /tr !-- 其他商品... -- /tbody /table后端 Controller 逻辑在 Spring Boot 中我们需要构造一个包含两个片段的响应。虽然通常我们返回单个 Fragment但利用 Thymeleaf 的特性我们可以返回一个包含多个带有hx-swap-oob属性元素的模板。DeleteMapping(/products/{id}) public String deleteProduct(PathVariable Long id, Model model) { productService.delete(id); // 计算新的库存数量 long newCount productService.getCount(); model.addAttribute(newCount, newCount); // 返回一个包含两个部分的模板 // 1. 主响应空字符串或直接移除目标行由 hx-target 处理 // 2. OOB 响应更新库存计数 return fragments/product-delete-response :: deleteContent; }Thymeleaf 模板 (product-delete-response.html)th:block th:fragmentdeleteContent !-- 这部分其实可以留空因为 hx-target 已经负责移除行了 -- !-- 但为了明确我们可以返回一个空节点或者什么都不返回 -- !-- 关键部分OOB 更新 -- !-- 注意这个 div 的 ID 必须与页面上要更新的元素 ID 一致 -- div idinventory-count hx-swap-oobtrue 当前库存span th:text${newCount}0/span /div /th:block当 HTMX 收到这个响应时它会执行两步操作首先根据请求元素上的hx-target指令移除 ID 为product-99的行其次扫描响应内容发现带有hx-swap-oobtrue且 ID 为inventory-count的元素于是自动找到页面上对应的元素并用新内容替换它。这种机制彻底解决了“一次操作多处更新”的难题而且所有逻辑依然牢牢掌握在后端手中。前端不需要知道库存怎么算也不需要关心如何同时操作两个 DOM 节点它只是忠实地执行后端的指令。进阶交互体验提示框、历史记录与渐进增强为了让 Web 应用体验更接近原生桌面软件或单页应用SPAHTMX 提供了一系列高级属性处理用户输入、浏览器历史等细节而这些同样无需编写 JavaScript。动态输入与确认hx-prompt 与 hx-confirm在某些敏感操作中仅仅依靠后端校验是不够的我们需要在前端即时获取用户确认或额外输入。hx-confirm我们已经见过它能弹出标准的确认框。而hx-prompt则更进一步它能弹出一个输入框让用户输入文本并将该文本作为参数发送给服务器。场景管理员删除一个重要配置项系统要求输入“确认删除”字样才能执行。button hx-delete/config/critical hx-prompt请输入确认删除以继续操作 hx-confirm这是高危操作 hx-target#config-row hx-swapouterHTML 删除配置 /button当用户点击按钮先弹出确认框确认后弹出输入框。用户输入的内容会被 HTMX 自动添加到请求参数中默认参数名为prompt。后端接收处理DeleteMapping(/config/critical) ResponseBody public String deleteCriticalConfig(RequestParam String prompt, HttpServletRequest request) { // 检查 HTMX 传来的 prompt 值 if (!确认删除.equals(prompt)) { // 如果验证失败返回错误信息HTMX 会将此信息显示在 target 位置 return span classerror验证失败未执行删除。/span; } configService.deleteCritical(); return ; // 成功则移除元素 }这种方式将交互逻辑前置减少了无效请求对后端的冲击同时保持了代码的简洁性。保持浏览器历史hx-push-url传统 AJAX 操作的一个大问题是 URL 不会改变导致用户无法使用浏览器的“后退”按钮回到之前的状态也无法分享当前页面的特定状态。HTMX 通过hx-push-url属性完美解决了这个问题。当你在一个列表中进行分页或筛选时希望 URL 随之变化例如从/items变为/items?page2以便用户收藏或回退。a href/items?page2 hx-get/items?page2 hx-target#item-container hx-push-urltrue 第 2 页 /a设置hx-push-urltrue后HTMX 会在请求成功后自动将浏览器的地址栏更新为href属性中的 URL。如果你希望自定义 URL比如不带查询参数的友好路径也可以直接指定字符串hx-push-url/items/page/2。这样用户点击“后退”按钮时浏览器会触发一个新的 GET 请求或者利用 HTMX 的历史缓存机制恢复到上一页的状态完全符合用户对 Web 应用的直觉预期。这对于 SEO 也是友好的因为每个状态都有独立的 URL。渐进增强策略旧项目的低成本现代化改造很多 Java 开发者面临的现实是手头维护着大量的遗留系统这些系统基于 JSP 或早期的 Thymeleaf 构建全是同步跳转用户体验生硬。重构为前后端分离架构成本太高风险太大。HTMX 的“渐进增强”理念正是为此而生。渐进增强的核心在于基础功能在不支持 HTMX 的环境下依然可用而在支持的环境中则获得增强体验。观察上面的代码示例你会发现hx-get、hx-post等属性通常是与标准的href或action属性共存于同一个标签中的。!-- 渐进增强示例 -- a href/details/123 hx-get/details/123 hx-target#detail-panel hx-push-urltrue 查看详情 /a在没有加载 HTMX 脚本的老式浏览器或网络故障时hx-get属性被忽略浏览器执行标准的href跳转加载整个新页面。功能完全正常只是体验是传统的同步刷新。在现代浏览器且 HTMX 加载成功后HTMX 拦截点击事件执行 AJAX 请求只更新#detail-panel区域并推送 URL。用户体验瞬间升级为无刷新的流畅模式。这意味着你可以今天就在生产环境的旧项目中引入 HTMX 脚本然后挑选几个高频操作的页面如列表删除、详情加载、表单提交加上hx-属性。一旦加上这些功能立刻变身为“准 SPA体验。如果出现问题只需移除脚本或属性系统立刻回退到原始的同步模式绝不会导致页面白屏或功能不可用。这种策略极大地降低了技术升级的风险和成本。你不需要重写前端路由不需要重构后端接口为纯 JSON API虽然保留 JSON API 也没问题但 HTMX 更倾向于直接返回 HTML 片段甚至不需要改变现有的权限认证和会话管理机制。所有的 Session、Security Context 在后端 Controller 中照常工作因为请求本质上依然是标准的 HTTP 请求。对于 Java 后端团队而言HTMX 不仅仅是一个工具更是一种思维方式的解放。它让我们重新认识到服务端渲染SSR在现代硬件和网络条件下依然具有强大的生命力和开发效率优势。通过将交互逻辑回归到后端我们得以用更少的代码、更低的复杂度构建出响应迅速、体验优秀的 Web 应用。在这个前端框架层出不穷的时代或许最简单的方案才是最适合 Java 开发者的“救星”。
