前端【免费下载链接】htmxhtmx - high power tools for HTML项目地址https://gitcode.com/GitHub_Trending/ht/htmx点击查看免费下载导读本文基于 htmx 官方路线图文档www/content/essays/future.md撰写系统梳理 htmx 从 intercooler.js 一路走来的技术哲学、未来三大开发原则稳定性、克制新增、季度发布以及团队对超媒体Hypermedia生态的推广策略。读完本文你将理解 htmx 为什么刻意“慢下来”为什么把新功能推向扩展 API 而不是核心以及这套理念如何支撑“写一次、用十年”的长期 Web 应用。htmx 的前身是 intercooler.js一个构建在 jQuery 之上、通过 HTML 属性为页面添加行为的库。而今天htmx 团队正在用一套“向 jQuery 学习”的明确路线重新定义这个库的未来稳定的 API、克制的功能演进、以及对超媒体理念的长期推广。这不是一篇功能清单而是一份关于“一个库如何陪伴开发者十年”的思考。一切的开始intercooler.js 与 jQuery 的启示htmx 诞生于 intercooler.jsintercooler 是 htmx 的前身一个基于 jQuery 的属性驱动行为库。要理解 htmx 的未来必须先理解它从 jQuery 身上学到的经验。jQuery 是一个“年迈”的 JavaScript 库——它在浏览器实现极不一致、JavaScript 缺乏现代便捷 API 的时代让跨平台 JavaScript 开发变得容易得多。今天很多开发者把 jQuery 视为“遗留软件”但事实是jQuery 仍被约 75% 的公开网站使用这个数字远超其他任何 JavaScript 工具。为什么 jQuery 能保持如此普及文档给出了三个技术层面的原因极易集成只需一个无依赖的script链接即可加入项目API 高度一致在其整个生命周期中保持极大程度的向后兼容intercooler.js 甚至可以同时兼容 jQuery v1、v2、v3按需取用作为一个库你可以只用它的一小部分它不会喧宾夺主也不会规定你的应用结构。这三条正是 htmx 未来要刻意模仿的“低门槛、高价值”技术特质。htmx 是“新的 jQuery”一个目标而非现状“htmx 是新的 jQuery”——这是一个听起来荒谬甚至傲慢的表述但它是 htmx 团队正在努力的方向。团队明确表示以 jQuery 构建的网站可以存活极长时间用 htmx 构建的网站理应做到同样甚至更好。为此Alex Petros 提出的“构建百年级 Web 服务”Building The 100 Year Web Service是 htmx 的核心目标。今后 htmx 将为现有用户而开发如果你已经是 htmx 用户或者正在考虑成为用户下面三条原则定义了“为现有用户开发”的具体含义。稳定性本身就是一个特性htmx 将致力于在API 与实现两个层面都保持极度稳定。这意味着团队会接受并记录当前实现的各种 quirks怪癖——这份清单在仓库中就有专门的文档www/content/QUIRKS.md其中整理了属性继承、默认innerHTML交换策略、4xx/5xx不交换、GET请求默认不携带表单值、历史缓存、异步加载不可靠等十余项“已知怪癖”及其规避方式。核心承诺是用户从 1.x 升级到 2.x也应该预期一切照常工作。在合适的地方htmx 可能会增加更好的配置选项但不会更改默认值。例如 QUIRKS 文档中展示的配置方式都是通过meta标签或htmx.config提供“逃生舱”而非强制变更!-- 关闭属性继承 -- meta namehtmx-config content{disableInheritance:true} !-- 将默认交换策略改为 outerHTML -- meta namehtmx-config content{defaultSwapStyle:outerHTML} !-- 允许所有响应码都执行交换 -- meta namehtmx-config content{responseHandling: [{code:..., swap: true}]}这种“记录怪癖 提供配置逃生舱 不改变默认值”的组合就是“稳定性作为特性”在实现层面的具体落地。“不新增功能”本身也是一个特性团队将越来越倾向于不在库核心中接受新的功能提案。这背后的逻辑很务实用户不应该感到有压力必须随时间升级 htmx除非有他们希望修复的具体 bug他们应当安心地认为2025 年写的 htmx 代码在 2035 年乃至更久之后看起来依然相似。当然“不新增”不是绝对静止。当新的浏览器能力出现时htmx 会考虑将其纳入核心。最典型的例子是实验性的moveBefore()DOM API演示文档位于 www/content/examples/move-before/_index.md需要在 Chrome Canary 中开启chrome://flags/#atomic-move的 “Atomic DOM move” 特性htmx 将其集成进了hx-preserve属性允许元素在页面切换、内容合并时保持播放状态、焦点等在 src/htmx.js 中可以看到实现细节handlePreservedElements()会查找[hx-preserve], [data-hx-preserve]元素若浏览器支持moveBefore就利用该 API 将元素移入“pantry”暂存区#--htmx-preserve-pantry--随后在restorePreservedElements()中将其移回原位。但除此之外绝大多数新功能预期将通过 htmx 的扩展 APIExtensions API探索和交付。团队会致力于让扩展 API 变得更强大。仓库中的扩展体系见 www/content/extensions/_index.md官方核心扩展包括head-supporthead 标签合并、idiomorphDOM 变形交换、preload预加载、response-targets按响应码定向目标、sse、ws等社区扩展则覆盖 ajax-header、alpine-morph、class-tools、loading-states、multi-swap、client-side-templates、json-enc 等二十余个方向。从源码看扩展机制本身十分轻量defineExtension()将扩展合并进注册表并以extensionBase()为默认实现见 src/htmx.js扩展可覆盖七个钩子——init、getSelectors、onEvent、transformResponse、isInlineSwap、handleSwap、encodeParameters完整定义见 www/content/extensions/building.md。这套机制把“给核心加功能”的压力转移到了扩展层正是“不新增功能作为特性”原则的制度保障。季度发布没有“死亡行军”式升级htmx 的发布节奏今后将大致按季度进行。这意味着没有与 htmx 相关的“死亡行军”式升级death march upgrades没有理由去紧盯 htmx 的每个版本寻找重大功能变化——就像 jQuery 一样如果 htmx 1.x 对你工作良好就完全没必要感到必须迁移到 2.x。以当前仓库为例package.json 显示 htmx 版本为2.0.112.x 系列作为大版本升级其哲学依然是在保持稳定 API 的前提下演进而不是推倒重来。推广超媒体让“伴生工具”也变好htmx 并不旨在成为构建 Web 应用与服务的“全面解决方案”它的定位非常克制它泛化了超媒体控件generalizes hypermedia controls仅此而已。这意味着提升 htmx 价值的一个重要途径——且仍有大量工作可做——是帮助改善人们与 htmx 配合使用的工具和技术。这样做可以在不修改 htmx 本身的情况下让 htmx 变得显著更有用。支持伴生工具后端无关与模板引擎htmx 只给 HTML 增添了几个新工具但对构建网站的其他重要方面没有意见。htmx 的标志性特性之一就是它不规定你使用什么后端或数据库。htmx 与大量后端兼容——这一主题的完整论述见 www/content/essays/hypermedia-on-whatever-youd-like.md即“HOWL 栈”Hypermedia On Whatever youd Like当你采用超媒体驱动的方式构建应用你就摆脱了“前端用了 JavaScript 所以后端也得用 JavaScript”的所谓“JavaScript 压力”可以自由选择 Java、Go、Python、PHP、Rust、Ruby、.NET、Clojure 乃至 Cobol 等任何你最顺手的服务端技术。超媒体生态中htmx 已经帮助改善的一个领域是模板引擎。当团队最初撰写“模板片段”Template Fragments一文时这个特性在模板引擎中还相当罕见。该文www/content/essays/template-fragments.md展示了核心思想与其把局部 UI 拆成一个个独立模板文件再 include不如在单个模板中用#fragment指令标记出可单独渲染的区块从而既能渲染整页也能只渲染局部片段例如 Archive/Unarchive 按钮区保持“行为局部性”Locality of Behavior。如今模板片段已相当普及该文也常被引作实现该特性的灵感来源例如 minijinja、jinja2-fragments 等项目的相关讨论。除模板片段外还有更多改善超媒体应用编写体验的方向htmx 团队将持续识别并推广这些努力。写作、研究与标准化让 htmx 的功能“消失”进 Web 平台虽然 htmx 自身不会剧烈变化但团队会继续充满热情地宣扬超媒体的理念。具体而言团队正尝试把 htmx 的思想推进到HTML 标准本身途径是 Triptych 项目在理想世界中htmx 的功能会“消失”进 Web 平台自身——今天写的 htmx 代码当然会永远工作下去但从更长远的视角看也许未来不再需要引入这个库就能通过超媒体实现类似的 UI 模式参见 www/content/examples/_index.md 中的各类示例如点击编辑、无限滚动、键盘快捷键、模态框、活动搜索等。换句话说htmx 的“终极成功”不是让所有人都用它而是让它的思想足够好、足够通用最终被平台吸收开发者不再需要它。这正是“推广超媒体”与“稳定核心”两条路线在长远目标上的交汇。Intercooler 是对的从“维护”到“保管”Stewardship在 intercooler 文档的结尾有一段关于其哲学的话至今仍是对 htmx 未来最贴切的注脚许多 JavaScript 项目以令人眩晕的速度更新。Intercooler 不是。 这不是因为它死了而是因为它大体上是对的基本思想是对的实现至少足够正确。 这意味着项目不会有持续的活跃和变动而是一种保管stewardship关系主要目标是不把它搞砸。文档会被改进测试会被补充声明式的小新特性会在边缘被添加但不会有大规模重写或持续更新。这与整个软件行业——尤其是前端世界——那种可笑程度的 churn变动形成鲜明对比。 Intercooler 是一个坚固、可靠的 Web 开发工具。抛开这段文字第三段的讽刺不谈这种思考对 htmx 完全适用甚至更甚——因为 htmx 是独立软件它受益于 intercooler.js 的经验和错误。在仓库中也能看到这种“保管”精神的实践痕迹测试体系覆盖了核心行为与回归场景见 test/core 与 test/attributes 下的测试文件QUIRKS 文档被明确地保留并公开www/content/QUIRKS.md行为怪癖不是被“修复掉”而是被“记录并配置化”。结语为一个百年级的 Web 服务而写htmx 团队希望看到 htmx 以它自己的小小方式加入 jQuery 这类“巨人”的行列成为构建百年级 Web 服务的坚固可靠工具。对开发者而言这份路线图可以浓缩为几条可操作的结论放心使用、放心长期依赖htmx 的 API 与实现将保持稳定默认行为不会变升级包括 1.x → 2.x不会带来破坏性惊喜不必追新季度发布意味着没有功能“军备竞赛”1.x 用得好就继续用新需求优先看扩展需要新能力时先查找或编写扩展www/content/extensions/_index.md而不是期待核心膨胀生态是价值的一部分模板片段等伴生工具的进步会让 htmx 变得更有用值得持续关注超媒体生态的演进面向长远htmx 的终极愿景是让超媒体思想进入 Web 平台本身——今天写的代码会成为未来平台能力的一部分。如果你正在为“这个库三年后还在不在”而犹豫是否采用 htmx这份文档给出的答案足够明确htmx 的目标就是让你十年后依然不必换掉它。赞分享前端【免费下载链接】htmxhtmx - high power tools for HTML项目地址https://gitcode.com/GitHub_Trending/ht/htmx点击查看免费下载相关推荐10个必学的线性代数Python技巧Linear-Algebra-With-Python核心概念解析10个必学的线性代数Python技巧Linear Algebra With Python核心概念解析 Linear Algebra With Python是一教程教育数据可视化科学计算为什么传统爬虫已死从逆向工程到浏览器模拟的跨平台内容采集新范式为什么传统爬虫已死从逆向工程到浏览器模拟的跨平台内容采集新范式 在数据驱动的时代 跨平台内容采集 已成为市场研究、舆情分析、学术研究的必备能力。然而当开发网页爬虫tiny-dnn未来发展规划从v1.0.0a3到稳定版的演进路线tiny dnn未来发展规划从v1.0.0a3到稳定版的演进路线 想要了解tiny dnn这个轻量级深度学习框架的未来发展方向吗作为一款header onl人工智能深度学习嵌入式上一篇让普通鼠标在macOS上重获新生Mac Mouse Fix的5大核心功能解析 下一篇KMS_VL_ALL_AIOWindows和Office智能激活终极解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 htmx 的未来：从 intercooler.js 到“百年级 Web 服务”的稳定主义路线
前端【免费下载链接】htmxhtmx - high power tools for HTML项目地址https://gitcode.com/GitHub_Trending/ht/htmx点击查看免费下载导读本文基于 htmx 官方路线图文档www/content/essays/future.md撰写系统梳理 htmx 从 intercooler.js 一路走来的技术哲学、未来三大开发原则稳定性、克制新增、季度发布以及团队对超媒体Hypermedia生态的推广策略。读完本文你将理解 htmx 为什么刻意“慢下来”为什么把新功能推向扩展 API 而不是核心以及这套理念如何支撑“写一次、用十年”的长期 Web 应用。htmx 的前身是 intercooler.js一个构建在 jQuery 之上、通过 HTML 属性为页面添加行为的库。而今天htmx 团队正在用一套“向 jQuery 学习”的明确路线重新定义这个库的未来稳定的 API、克制的功能演进、以及对超媒体理念的长期推广。这不是一篇功能清单而是一份关于“一个库如何陪伴开发者十年”的思考。一切的开始intercooler.js 与 jQuery 的启示htmx 诞生于 intercooler.jsintercooler 是 htmx 的前身一个基于 jQuery 的属性驱动行为库。要理解 htmx 的未来必须先理解它从 jQuery 身上学到的经验。jQuery 是一个“年迈”的 JavaScript 库——它在浏览器实现极不一致、JavaScript 缺乏现代便捷 API 的时代让跨平台 JavaScript 开发变得容易得多。今天很多开发者把 jQuery 视为“遗留软件”但事实是jQuery 仍被约 75% 的公开网站使用这个数字远超其他任何 JavaScript 工具。为什么 jQuery 能保持如此普及文档给出了三个技术层面的原因极易集成只需一个无依赖的script链接即可加入项目API 高度一致在其整个生命周期中保持极大程度的向后兼容intercooler.js 甚至可以同时兼容 jQuery v1、v2、v3按需取用作为一个库你可以只用它的一小部分它不会喧宾夺主也不会规定你的应用结构。这三条正是 htmx 未来要刻意模仿的“低门槛、高价值”技术特质。htmx 是“新的 jQuery”一个目标而非现状“htmx 是新的 jQuery”——这是一个听起来荒谬甚至傲慢的表述但它是 htmx 团队正在努力的方向。团队明确表示以 jQuery 构建的网站可以存活极长时间用 htmx 构建的网站理应做到同样甚至更好。为此Alex Petros 提出的“构建百年级 Web 服务”Building The 100 Year Web Service是 htmx 的核心目标。今后 htmx 将为现有用户而开发如果你已经是 htmx 用户或者正在考虑成为用户下面三条原则定义了“为现有用户开发”的具体含义。稳定性本身就是一个特性htmx 将致力于在API 与实现两个层面都保持极度稳定。这意味着团队会接受并记录当前实现的各种 quirks怪癖——这份清单在仓库中就有专门的文档www/content/QUIRKS.md其中整理了属性继承、默认innerHTML交换策略、4xx/5xx不交换、GET请求默认不携带表单值、历史缓存、异步加载不可靠等十余项“已知怪癖”及其规避方式。核心承诺是用户从 1.x 升级到 2.x也应该预期一切照常工作。在合适的地方htmx 可能会增加更好的配置选项但不会更改默认值。例如 QUIRKS 文档中展示的配置方式都是通过meta标签或htmx.config提供“逃生舱”而非强制变更!-- 关闭属性继承 -- meta namehtmx-config content{disableInheritance:true} !-- 将默认交换策略改为 outerHTML -- meta namehtmx-config content{defaultSwapStyle:outerHTML} !-- 允许所有响应码都执行交换 -- meta namehtmx-config content{responseHandling: [{code:..., swap: true}]}这种“记录怪癖 提供配置逃生舱 不改变默认值”的组合就是“稳定性作为特性”在实现层面的具体落地。“不新增功能”本身也是一个特性团队将越来越倾向于不在库核心中接受新的功能提案。这背后的逻辑很务实用户不应该感到有压力必须随时间升级 htmx除非有他们希望修复的具体 bug他们应当安心地认为2025 年写的 htmx 代码在 2035 年乃至更久之后看起来依然相似。当然“不新增”不是绝对静止。当新的浏览器能力出现时htmx 会考虑将其纳入核心。最典型的例子是实验性的moveBefore()DOM API演示文档位于 www/content/examples/move-before/_index.md需要在 Chrome Canary 中开启chrome://flags/#atomic-move的 “Atomic DOM move” 特性htmx 将其集成进了hx-preserve属性允许元素在页面切换、内容合并时保持播放状态、焦点等在 src/htmx.js 中可以看到实现细节handlePreservedElements()会查找[hx-preserve], [data-hx-preserve]元素若浏览器支持moveBefore就利用该 API 将元素移入“pantry”暂存区#--htmx-preserve-pantry--随后在restorePreservedElements()中将其移回原位。但除此之外绝大多数新功能预期将通过 htmx 的扩展 APIExtensions API探索和交付。团队会致力于让扩展 API 变得更强大。仓库中的扩展体系见 www/content/extensions/_index.md官方核心扩展包括head-supporthead 标签合并、idiomorphDOM 变形交换、preload预加载、response-targets按响应码定向目标、sse、ws等社区扩展则覆盖 ajax-header、alpine-morph、class-tools、loading-states、multi-swap、client-side-templates、json-enc 等二十余个方向。从源码看扩展机制本身十分轻量defineExtension()将扩展合并进注册表并以extensionBase()为默认实现见 src/htmx.js扩展可覆盖七个钩子——init、getSelectors、onEvent、transformResponse、isInlineSwap、handleSwap、encodeParameters完整定义见 www/content/extensions/building.md。这套机制把“给核心加功能”的压力转移到了扩展层正是“不新增功能作为特性”原则的制度保障。季度发布没有“死亡行军”式升级htmx 的发布节奏今后将大致按季度进行。这意味着没有与 htmx 相关的“死亡行军”式升级death march upgrades没有理由去紧盯 htmx 的每个版本寻找重大功能变化——就像 jQuery 一样如果 htmx 1.x 对你工作良好就完全没必要感到必须迁移到 2.x。以当前仓库为例package.json 显示 htmx 版本为2.0.112.x 系列作为大版本升级其哲学依然是在保持稳定 API 的前提下演进而不是推倒重来。推广超媒体让“伴生工具”也变好htmx 并不旨在成为构建 Web 应用与服务的“全面解决方案”它的定位非常克制它泛化了超媒体控件generalizes hypermedia controls仅此而已。这意味着提升 htmx 价值的一个重要途径——且仍有大量工作可做——是帮助改善人们与 htmx 配合使用的工具和技术。这样做可以在不修改 htmx 本身的情况下让 htmx 变得显著更有用。支持伴生工具后端无关与模板引擎htmx 只给 HTML 增添了几个新工具但对构建网站的其他重要方面没有意见。htmx 的标志性特性之一就是它不规定你使用什么后端或数据库。htmx 与大量后端兼容——这一主题的完整论述见 www/content/essays/hypermedia-on-whatever-youd-like.md即“HOWL 栈”Hypermedia On Whatever youd Like当你采用超媒体驱动的方式构建应用你就摆脱了“前端用了 JavaScript 所以后端也得用 JavaScript”的所谓“JavaScript 压力”可以自由选择 Java、Go、Python、PHP、Rust、Ruby、.NET、Clojure 乃至 Cobol 等任何你最顺手的服务端技术。超媒体生态中htmx 已经帮助改善的一个领域是模板引擎。当团队最初撰写“模板片段”Template Fragments一文时这个特性在模板引擎中还相当罕见。该文www/content/essays/template-fragments.md展示了核心思想与其把局部 UI 拆成一个个独立模板文件再 include不如在单个模板中用#fragment指令标记出可单独渲染的区块从而既能渲染整页也能只渲染局部片段例如 Archive/Unarchive 按钮区保持“行为局部性”Locality of Behavior。如今模板片段已相当普及该文也常被引作实现该特性的灵感来源例如 minijinja、jinja2-fragments 等项目的相关讨论。除模板片段外还有更多改善超媒体应用编写体验的方向htmx 团队将持续识别并推广这些努力。写作、研究与标准化让 htmx 的功能“消失”进 Web 平台虽然 htmx 自身不会剧烈变化但团队会继续充满热情地宣扬超媒体的理念。具体而言团队正尝试把 htmx 的思想推进到HTML 标准本身途径是 Triptych 项目在理想世界中htmx 的功能会“消失”进 Web 平台自身——今天写的 htmx 代码当然会永远工作下去但从更长远的视角看也许未来不再需要引入这个库就能通过超媒体实现类似的 UI 模式参见 www/content/examples/_index.md 中的各类示例如点击编辑、无限滚动、键盘快捷键、模态框、活动搜索等。换句话说htmx 的“终极成功”不是让所有人都用它而是让它的思想足够好、足够通用最终被平台吸收开发者不再需要它。这正是“推广超媒体”与“稳定核心”两条路线在长远目标上的交汇。Intercooler 是对的从“维护”到“保管”Stewardship在 intercooler 文档的结尾有一段关于其哲学的话至今仍是对 htmx 未来最贴切的注脚许多 JavaScript 项目以令人眩晕的速度更新。Intercooler 不是。 这不是因为它死了而是因为它大体上是对的基本思想是对的实现至少足够正确。 这意味着项目不会有持续的活跃和变动而是一种保管stewardship关系主要目标是不把它搞砸。文档会被改进测试会被补充声明式的小新特性会在边缘被添加但不会有大规模重写或持续更新。这与整个软件行业——尤其是前端世界——那种可笑程度的 churn变动形成鲜明对比。 Intercooler 是一个坚固、可靠的 Web 开发工具。抛开这段文字第三段的讽刺不谈这种思考对 htmx 完全适用甚至更甚——因为 htmx 是独立软件它受益于 intercooler.js 的经验和错误。在仓库中也能看到这种“保管”精神的实践痕迹测试体系覆盖了核心行为与回归场景见 test/core 与 test/attributes 下的测试文件QUIRKS 文档被明确地保留并公开www/content/QUIRKS.md行为怪癖不是被“修复掉”而是被“记录并配置化”。结语为一个百年级的 Web 服务而写htmx 团队希望看到 htmx 以它自己的小小方式加入 jQuery 这类“巨人”的行列成为构建百年级 Web 服务的坚固可靠工具。对开发者而言这份路线图可以浓缩为几条可操作的结论放心使用、放心长期依赖htmx 的 API 与实现将保持稳定默认行为不会变升级包括 1.x → 2.x不会带来破坏性惊喜不必追新季度发布意味着没有功能“军备竞赛”1.x 用得好就继续用新需求优先看扩展需要新能力时先查找或编写扩展www/content/extensions/_index.md而不是期待核心膨胀生态是价值的一部分模板片段等伴生工具的进步会让 htmx 变得更有用值得持续关注超媒体生态的演进面向长远htmx 的终极愿景是让超媒体思想进入 Web 平台本身——今天写的代码会成为未来平台能力的一部分。如果你正在为“这个库三年后还在不在”而犹豫是否采用 htmx这份文档给出的答案足够明确htmx 的目标就是让你十年后依然不必换掉它。赞分享前端【免费下载链接】htmxhtmx - high power tools for HTML项目地址https://gitcode.com/GitHub_Trending/ht/htmx点击查看免费下载相关推荐10个必学的线性代数Python技巧Linear-Algebra-With-Python核心概念解析10个必学的线性代数Python技巧Linear Algebra With Python核心概念解析 Linear Algebra With Python是一教程教育数据可视化科学计算为什么传统爬虫已死从逆向工程到浏览器模拟的跨平台内容采集新范式为什么传统爬虫已死从逆向工程到浏览器模拟的跨平台内容采集新范式 在数据驱动的时代 跨平台内容采集 已成为市场研究、舆情分析、学术研究的必备能力。然而当开发网页爬虫tiny-dnn未来发展规划从v1.0.0a3到稳定版的演进路线tiny dnn未来发展规划从v1.0.0a3到稳定版的演进路线 想要了解tiny dnn这个轻量级深度学习框架的未来发展方向吗作为一款header onl人工智能深度学习嵌入式上一篇让普通鼠标在macOS上重获新生Mac Mouse Fix的5大核心功能解析 下一篇KMS_VL_ALL_AIOWindows和Office智能激活终极解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考