htmx 2.0.0已经发布！

banq

宣布 htmx 2.0 的发布。此版本终止了对 Internet Explorer 的支持并收紧了一些默认设置，但不会改变库的大多数核心功能或核心 API。

主要变化

  • 所有扩展都已从核心存储库移至其自己的存储库 和网站：https://extensions.htmx.org。它们现在都单独版本化，并且可以在正常（缓慢）的 htmx 发布节奏之外进行开发。
    • 大多数 1.x 扩展可以与 2.x 一起使用，但是 SSE 扩展确实存在中断并且必须升级。
    • 较旧的扩展仍保留在/dist/ext目录中，以免破坏 unpkg 等 CDN 的 URL，但请继续迁移到新的扩展 URL
  • 我们删除了已弃用的hx-sse和hx-ws属性，转而使用在 1.x 中可用且推荐的扩展。
  • HTTPDELETE请求现在使用参数而不是表单编码主体作为其有效负载（这符合规范）。
  • /dist我们现在为各种 JavaScript 模块样式 提供特定的文件：
    • ESM 模块：/dist/htmx.esm.js
    • AMD 模块：/dist/htmx.amd.js
    • CJS 模块：/dist/htmx.cjs.js
    • 该/dist/htmx.js文件仍可通过浏览器加载
  • 该hx-on属性及其特殊语法已被删除，以支持不太复杂的hx-on:语法。

特征
确实不多：

  • 内部 API方法selectAndSwap()已被公共（且更好的）swap()方法取代
  • Web Component 支持已得到显著改善
  • 此版本的最大特点是：网站现在支持暗黑模式！（感谢@pokonski！）
完整的升级指南可以在这里找到：
htmx 1.x -> 2.x 迁移指南
如果您需要 IE 兼容性，则在可预见的未来将继续支持1.x。

安装
htmx 2.0 可以通过引用版本的包管理器进行安装2.0.0，也可以通过 CDN 链接：

<script src="https://unpkg.com/htmx.org@2.0.0/dist/htmx.min.js"></script>

或下载

网友：
1、我喜欢使用 htmx 加载数据，使用 js 为 Web 应用制作动画。不知道这是否比直接使用 js 更划算，但说实话，效果很流畅、简单。

2、htmx 至少对于简单或中等复杂度的原型应用程序来说非常简洁，消除了很多愚蠢的样板代码，这就是最小化使用 js 的优势所在。

3、 HTMX 用起来很开心。我在生产中使用它来逐步取代 VueJS，因为在生产中不需要完整的 SPA 交互，它让开发变得简单多了。
HTMX​​ 和 VueJS 用于具有不同路由/端点的不同视图，因此我们可以一次重写任何基于 VueJS 的视图。
HTMX 与 HTML 模板和普通路由一起使用，而 VueJS 则被隔离到具有自己端点的单一用途 SPA 样式视图
HTMX 就像一股清新的空气。

4、HTML 仅需 166 字节的 JS 粘合代码即可实现许多 HTMX 功能，请参阅 HTMZ：https://leanrada.com/htmz

5、至于随着时间的推移而缩小，HTMX 1.0 最小化后为 26KB，现在 2.0 版本最小化后为 48KB。为什么在放弃 IE 支持后，体积却膨胀了 184%？为什么不让它保持轻量级？

例如，与最小化后为 16KB 的 Petite Vue 相比。

这不仅与带宽有关，还必须解析和执行 JS 代码，这会占用 CPU 时间，这对低端移动设备的影响尤其大。例如，将 HTMX 与 Ajaxial 进行比较，后者压缩后只有 5KB：https://ajaxial.unmodernweb.com

更好的 Web 组件支持有点过头了。计划会在接下来的几个月内慢慢削减。

6、我正在开发的简单 Web 应用程序的后端完全采用 Rust。重点：

maud 允许您编写标记的方式与 htmx 配合得很好。HX-Request 标头让您知道请求是来自 htmx 还是常规请求。如果是常规请求，您可以调用顶级函数来渲染整个页面，如果是 htmx 请求，您可以调用函数子集来渲染相应的部分页面。

能够轻松测试渲染后的页面也很不错。我的单元测试也涵盖了渲染后的 HTML 的验证。

7、就我个人而言，我反对在服务器端渲染 UI 的想法。
原因如下：
1）在客户端运行业务逻辑意味着服务器必须为每个连接的客户端运行业务逻辑。这意味着：

  •  由于业务逻辑处理，服务器必须非常庞大才能及时满足所有请求。这意味着极高的服务器成本。
  •  维护可能连接并执行请求或根本不连接的断开连接的客户端的业务逻辑状态非常困难，尤其是对于像 Spring 这样的多线程服务器。
由于客户端执行业务逻辑，服务器变得更加轻量级，仅处理授权和身份验证以及与内部系统/数据库的连接。

2）客户端业务逻辑永远无法 100% 避免，因为很多 UI 功能都依赖于 UI 状态：按下这个按钮，就会出现这个表单，选择这个选项，就会出现这个内容，单击这个，UI 状态就会执行那个操作等等。我并不是在谈论业务逻辑本身，我只是在谈论业务逻辑在 UI 端的反映。
通过服务器端渲染，大多数业务逻辑将位于服务器上，但业务逻辑的 UI 端将位于客户端，因此会形成意大利面条式代码。

3）客户端性能问题。
例如，当用户单击选项卡或选项时，这些操作的结果应该是立即的，即使结果是延迟获取的。
如果客户端需要跟服务器进行通信，让服务器发回合适的UI，那么UI就会出现严重的滞后。

这是个很大的可用性问题。这是 React 的一大可用性问题，它有时需要“很长时间”才能更新屏幕，尤其是在复杂的 UI 上。我无法想象 UI 服务器端渲染会有多慢。

事实上，我使用过 Vaadin，它使用完全相同的方法：UI 在服务器上呈现，并且呈现的结果（即其对先前状态的修改）被发送到客户端。
嗯，这不太好。使用 Vaadin 的 UI 总是很慢，因为客户端必须始终向服务器询问任何用户操作。

4) 将数据与数据表示进行耦合不是一个的选择
因为这种耦合不允许业务逻辑的重用。
例如，使用这种方法，很难让桌面客户端和移动客户端使用相同的数据 API，因为 API 将返回 UI 而不是数据。