前端【免费下载链接】htmxhtmx - high power tools for HTML项目地址https://gitcode.com/GitHub_Trending/ht/htmx点击查看免费下载导读2010 年Facebook 网站因页面加载缓慢而陷入性能危机一小队工程师用寥寥代码构建了超媒体hypermedia导向的 JavaScript 库 Primer将 90 分位页面加载时间砍半。本文基于 htmx 官方仓库收录的专访原始文档完整呈现 Primer 的诞生背景、它与 React 的路线分野、最终淡出 Facebook 的原因以及创造者关于构建开发者工具的第一手经验并结合本仓库的 超媒体驱动应用HDA 与 SPA 替代方案 等论述梳理超媒体思路在行业中的周期性回归。读完你将理解为什么从服务器拿 HTML 来更新页面这种朴素思路会在十余年后以 htmx 的形式卷土重来。一、被专访者是谁从微软实习生到 Primer 的创造者Makinde Adeagbo 是 Primer一个在 2010 年代被 Facebook 大规模使用的超媒体导向 JavaScript 库的创造者之一。专访开篇他回顾了自己的职业与技术成长路径高中时期就热衷技术为亲友组装电脑选修计算机科学课程并在大学主修计算机科学对仅凭一台电脑和一条网络连接就能构建游戏、工具等酷东西深感着迷通过Explore Microsoft实习项目一个面向代表性不足的大一新生的实习计划进入微软由此坚定了以软件为职业的决心此后又在 Apple 与 Microsoft 实习大学期间在员工规模约 150 人的 Facebook 工作——那是工程师拥有近乎完全自由、可以自主构建并为公司增长做贡献的时代这段经历被他视为职业生涯早期最需要的历练之后辗转 Dropbox、Pinterest并联合创办了非营利组织/dev/color。这段履历的价值在于Makinde 是亲历 Facebook 从小团队膨胀为平台级公司的工程师而 Primer 正是在这个剧烈变化的时间窗口内诞生与消亡的他的视角天然带有规模与架构取舍的纵深。二、Primer 的诞生2010 年 Facebook 的性能危机专访的第二问直指 Primer 的起源这也是整个访谈最具史料价值的部分。背景是 Facebook 网站在 2010 年慢得离谱slooow。Makinde 强调这并非某个人的过错——每位工程师都在添加功能同时顺手塞进一小段 JavaScript但公司缺乏一套连贯的体系来共享库或追踪每个页面到底携带了多少 JavaScript。日积月累90 分位页面加载时间膨胀到约 10 秒。2010 年年中将这一加载时间减半成为公司三大最高优先级事项之一Makinde 所在的小团队被委以重任。调查 JavaScript 的来源时团队发现绝大多数 JavaScript 都在执行简单的任务且高度同构要么从服务器获取额外的数据或标记markup要么提交一个表单然后接收更多标记来更新页面。时间紧迫团队决定构建一个小型方案来抽象这两种模式从而压缩页面上所需的代码量。Makinde 与Tom Occhino一起完成了 Primer 的第一个版本并亲自改造了几个用例验证可行性确信无误后才引入更多工程师将其推广到整个代码库。这一起源故事与 htmx 的动机高度呼应。本仓库 README.md 中htmx 的 motivation 正是追问四个为什么为什么只有a和form能发起 HTTP 请求为什么只有 click 与 submit 事件能触发它们为什么只有 GET 和 POST 可用为什么只能替换整个屏幕——而 Primer 团队在 2010 年观察到的大多数 JavaScript 只是在取数据/提交表单并更新标记恰恰是这四个约束最日常化的表现。可见超媒体方案并非凭空发明而是从真实性能问题中反向提炼出的最小抽象。三、Primer 与 React同一家公司内的两条技术路线Primer 与 React 都诞生于 Facebook一个常见追问是两个团队是否存在内部竞争Makinde 的回答相当明确这两个项目来自不同的时代、不同的需求、不同的代码库区域。据我所知它们之间从未有过竞争。他进一步解释了二者适用边界的差异Primer 擅长的是 2010 年那种类型网站。它成功的关键在于理解自己并不需要处理所有用例——它是一个80/20 的解决方案团队不会用它去实现特别复杂的交互例如创建新帖子的界面。React 则源自一个完全不同的挑战广告工具ads tools。管理、组合、追踪数百条广告需要一个高度复杂、高度投入的界面。Makinde 坦言即便当时没有这套术语这本质上是典型的单页应用SPA场景需要专门为其目的打造的工具而且该站点的用户画像也与浏览信息流或翻看照片的普通用户截然不同。这段回答实际上勾勒出了一条清晰的决策准则交互复杂度决定架构选择。超媒体方案适合文档/信息流型界面而重状态、重编排的工具型界面更适合 SPA。这与本仓库 SPA 替代方案 一文的核心论点一致——htmx 并不主张一切皆超媒体而是主张 HTML 作为一种有限超文本只有a与form可发请求、只有 click/submit 可触发、只有 GET/POST、请求必须整屏替换的四个约束应当被解除让 HTML 成为能与 SPA 在诸多应用域竞争的高功率超文本。Primer 的 80/20 定位正是这一思路在 2010 年的早期实践。四、Primer 为何最终淡出 FacebookMakinde 对Primer 为什么在 Facebook 失败了的回答比技术归因更深刻——他并不认同失败这个叙事本身我不认为有任何单一技术方案能在 Facebook 平台上存活 15 年。网站的需求在演进技术在变化互联网的版图也在随时间推移而改变。Primer 在其所处的时代与约束下很好地服务了网站但最终产品需要更丰富的交互性——那并不是 Primer 的设计目标。他补充了两层理由取舍tradeoffs随规模漂移开发者便利性/速度、安全性、可扩展性这些优先级会随着时间变化尤其是当一家公司规模增长 10 倍时。行业呈周期性运转轻快、精简的方案会让位于更重、更丰富的工具而后者最终又会循环回到轻快与精简。如果某个类似 Primer 的东西在某个时间点卷土重来我一点也不会惊讶。周期性回归的判断恰好是本仓库所承载的思想主线。htmx 官方在 超媒体驱动应用HDA 中用正题—反题—合题概括了这一周期MPA多页应用是正题SPA单页应用是反题而HDA超媒体驱动应用是合题——它融合了 MPA 的简单性与 SPA 的体验通过扩展 HTML 基础设施来达成。Primer 可以看作这一合题在 2010 年的早期雏形htmx 则是其在当代的成熟实现。仓库 未来展望 一文还记录了 htmx 自身从 XMLHttpRequest 迁移到fetch()的内部演进说明即便是超媒体方案本身也在持续回应产品需要更丰富交互性的压力。五、Primer 有多少理论关于 REST 与超媒体访谈第五问很直接构建 Primer 时你们想过多少超媒体、REST 之类的理论Makinde 的回答坦诚而有趣没多少。说实话当时我很年轻对互联网的历史或过往研究了解不多。我被 Web 底层构建模块的简洁性所吸引觉得按这些工具本来的设计方式去使用它们很有意思。不过一如既往Web 是一层由 hack 和创可贴堆叠起来的千层蛋糕所以你必须保持灵活。值得注意的是这与本仓库采访系列中其他超媒体库创造者的体验惊人地一致pjax 作者 Chris Wanstrath 在 pjax 专访 中表示pjax 最初只是给请求追加?pjax1发布前才改为发送X-PJAX请求头理论是事后才补上的Unpoly 作者 Henning Koch 在 Unpoly 专访 中则把 Unpoly 描述为HTML6 幻想规格的产物——如果 HTML6 专为服务端渲染应用而设计规格里该有哪些特性这种实践先行、理论后置的模式与 htmx 项目在理论层面刻意做的功课形成互补本仓库 HATEOAS 专题 用银行账户的 HTML 示例细致说明了超媒体作为应用状态引擎的含义指出 HTML 响应天然把下一步可执行的动作deposit、withdraw、transfer……编码在超媒体里而 JSON API 则必须依赖文档这类带外out-of-band信息。Primer 这类库之所以能按工具本来的设计方式使用它们正是因为 HTML 本身就是自描述的而理论的价值在于事后把这些朴素实践命名、体系化让它们可以被传承与复用。六、最重要的技术教训是关于人的访谈以你从 Primer 带走的最重要技术教训是什么收尾答案出人意料地朴素说实话最大的教训是关于人的。构建 Primer 这样的系统是一回事但要让它在公司内成功你必须训练数百名工程师去使用它。你必须教他们用不同的方式思考如何构建东西、在正确的时机提出正确的问题、避免在错误的方向上走得太远。归根结底即便系统本身完美如果工程师讨厌使用它它就不会成功。对于任何内部基础设施/开发工具的缔造者这是一条可迁移的普适经验采纳率adoption与技术正确性同等重要。同系列 pjax 专访 中 Chris Wanstrath 表达了相似观点——他坦言自己的目标不是库的采纳而是理念的采纳让更多人知道pushState()知道在服务器端整体或部分渲染页面仍然可行且能被现代技术加速。两相对照让工程师与理念同时被说服正是这类超媒体库传播的共同命门。七、与 htmx 的交汇一段被验证的行业周期将这篇专访放回本仓库的语境中其价值便清晰起来htmx 官方把对 Primer、pjax、Unpoly 等前代超媒体库创造者的访谈集中收录在 interviews 目录与 HDA 架构论述、SPA 替代方案、HATEOAS 解读 等文章共同构成一套完整的超媒体史观。从时间线上看2010Primer 在 Facebook 用极小的抽象解决了 10 秒加载的性能问题印证取数据 更新标记是当时前端 JavaScript 的主流形态2011pjax 借助history.pushState()在 GitHub 上实践同一思路2010 年代中后期行业整体滑向重交互的 SPA超媒体方案沉寂今天htmx 以high power tools for HTML的姿态用声明式属性hx-post、hx-swap、hx-target等让以超媒体为应用状态引擎重新变得可及——正如 Makinde 在访谈中所预言的卷土重来。正如 HDA 文章 所言HDA 并非凭空创造而是对两种前代架构的合题它试图同时捕获 MPA 的简单性与 SPA 的体验。Primer 用实践证明了这条路径在真实大规模场景中的可行性将 90 分位加载时间减半也诚实地划出了它的边界不做复杂交互、不覆盖所有用例htmx 则在这份遗产之上把HTML 作为一等公民的方法论打磨成了现代、可扩展、小而美的工具。对今天的开发者而言这篇专访提供的判断框架是先识别你的交互复杂度落在哪个区间——80% 的常见场景列表、表单、分页、搜索往往值得用超媒体方案换取更小的复杂度预算而 20% 的重交互场景再诉诸 SPA 或前端框架同时记住任何内部工具的成败最终都取决于能否让团队用不同的方式思考。延伸阅读仓库内本专访原文makinde_adeagbo.md同系列pjax 创造者 Chris Wanstrath 专访、Unpoly 创造者 Henning Koch 专访、Richardson 成熟度模型作者 Leonard Richardson 专访、REST 专家 Mike Amundsen 专访理论基石超媒体驱动应用HDA、HATEOAS 解读、SPA 替代方案项目入口README.md含 htmx 的动机与快速上手示例赞分享前端【免费下载链接】htmxhtmx - high power tools for HTML项目地址https://gitcode.com/GitHub_Trending/ht/htmx点击查看免费下载相关推荐xManager团队访谈开发者xc3fff0e专访xManager团队访谈开发者xc3fff0e专访 引言从痛点到解决方案的诞生 你是否曾被音乐流媒体应用中的广告打断沉浸式体验是否在寻找一个既能自由管理应开发工具Popcorn.js: 创造交互式多媒体体验的JavaScript库Popcorn.js: 创造交互式多媒体体验的JavaScript库 是一个由Mozilla基金会开发的开源JavaScript库它使得开发者能够轻松地在网页IceCream的开发者访谈创建团队的故事IceCream的开发者访谈创建团队的故事 项目起源从调试痛点到创新工具 你是否还在使用 print 语句进行调试IceCream简称 ic 的诞生正开发工具调试器上一篇Capybara与Webpacker集成处理JavaScript打包下一篇Delta模拟器金手指完整指南从预设启用到自己写码的 5 个实操要点创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考