复杂度预算：软件架构师的核心管理工作
软件项目都有复杂度预算，架构师的核心工作是决定哪些复杂度值得花。 作者以 OSGi 为例，指出治理复杂度的方案本身可能大幅增加复杂度，导致开发停滞。 复杂度随项目规模几何级增长，存在一道"复杂度墙"。 管理预算的关键是：把复杂度概念显式化、只在增值区投入、敢于说"不"、拥抱 KISS、合理拆分组件。 成熟应用应尊重既有复杂度，避免盲目重构。
评论
点赞
收藏与 AI 协作：一个具体的例子
总体而言，我对人工智能持一种矛盾的态度。毫无疑问，过去一年中，AI 已经成为推动发展的强大工具，但与此同时，它也带来了诸多风险——既对个人（例如，我们的智慧逐渐变得迟钝）如此，对集体而言也同样如此（例如，环境问题、日益高昂的个人计算成本等）。在《代码更便宜》一书中，我曾警示过“巫师学徒”这一问题：当开发者过度依赖 AI，便难以理解并妥善应对那些随之而来的……
REST 是如何变成其反义词的？
文章梳理了 REST 概念从“超媒体驱动”被行业误读为“基于 JSON 的 HTTP 接口”的历史演变过程。作者指出，随着 JSON 和 SPA 的兴起，业界普遍忽略了 HATEOAS 这一核心约束，导致 REST 一词的含义发生了根本性的反转。 这一现象源于技术栈变迁中对简单性的追求，以及 GraphQL 等新型 API 风格的崛起。文章旨在澄清概念，强调真正的 REST 架构与当前主流做法的本质区别。
面向超媒体的 MCP 应用架构设计
作者结合 SpeedyStride 应用开发经验，提出在 Model Context Protocol (MCP) 应用中采用超媒体架构的设计思路。 文章探讨了如何将 htmx 等技术与 MCP 结合，利用 HTTP 缓存和超媒体约束来简化 AI 代理应用的构建，提升工程效率。
有了 AI，我还应该考虑成为程序员吗？答案是：是的，而且……
蒙大拿州立大学计算机科学教师认为，尽管 AI 发展迅速，但程序员职业依然值得追求。作者结合教学经验与个人经历，阐述了编程在 AI 时代的持续价值。 他认为 AI 更多是辅助工具而非替代者，掌握编程思维能让人更好地利用 AI 解决复杂问题。
比起多态，我更偏爱 if 语句
作者 Carson Gross 提出了一系列反传统的编程原则，主张优先使用 if 语句而非多态，减少抽象层级，甚至提倡“复制粘贴驱动开发”。文章以幽默且略带自嘲的口吻，挑战了面向对象设计中的过度工程化倾向。 最后作者坦言自己经历了一次“精神崩溃”，为这篇充满争议的技术观点增添了个人色彩。
htmx 的 SSE（服务端发送事件）扩展指南
htmx 官方文档介绍了 SSE 扩展的使用方法。该扩展允许在 HTML 中直接连接 EventSource，实现服务端向客户端的实时数据推送。 文章详细说明了安装方式、核心属性配置、事件监听机制以及从旧版本迁移的步骤。相比 WebSocket，SSE 更适合单向通信场景。
用 Htmx 构建关键基础设施：巴黎 2024 奥运网络自动化实战
作者利用 Htmx 和 Django 为巴黎奥运会开发了网络自动化配置应用。相比传统 SPA，单代码库模式大幅缩短了开发周期，从预估 18 个月减至 9 周。 文章重点展示了该架构如何提升代码可读性，并验证了其对 AI 编程工具的友好度。随着业务逻辑简化，AI 生成代码比例从 0% 提升至 95%，显著提高了开发效率。
htmx 预加载扩展：提升前端响应速度的技巧
介绍 htmx 的 preload 扩展，可在用户点击前预加载 HTML 片段到浏览器缓存，提升页面感知速度。支持 mousedown、mouseover 等多种触发方式，并限制仅预加载 GET 请求以节省带宽。
Htmx 4.0：Fetch 革命与未来路线图
Htmx 创始人 Carson Gross 宣布将跳过 3.0 直接发布 4.0 版本。核心变动是用 fetch 替代 XMLHttpRequest，并重构事件模型。 新增特性包括核心支持流式响应、DOM 差异对比算法及显式属性继承。升级路径将分多年缓慢过渡。
Htmx：让 HTML 直接拥有现代浏览器能力
htmx 官网介绍其核心功能，允许开发者通过 HTML 属性直接使用 AJAX、WebSocket 等技术构建现代界面。文章提到 v4 版本正在开发中，并展示了代码示例和性能优势。 同时推广了相关书籍和周边商品，强调其作为轻量级库的特性。
行为局部性原则：让代码逻辑一目了然
htmx 作者提出“行为局部性”原则，主张代码的行为应尽可能在查看该单元时显而易见。文章对比了 htmx 属性与 jQuery 分离实现的差异，认为后者存在“远程魔法”问题，维护困难。同时讨论了该原则与 DRY、SoC 等常见设计原则的冲突与权衡。 这不仅是 htmx 的理论基础，也触及前端开发中 HTML 与 JS/CSS 分离的传统痛点。对于关注代码可维护性、反感过度抽象和分离架构的开发者来说，这是一个具有鲜明立场且能引发关于“代码组织方式”激烈讨论的话题。
软件依赖的“vendoring”方式
文章介绍了软件“vendoring”技术，即将第三方源码直接复制到项目中。以 htmx 为例，展示了通过下载源码到本地目录来使用它的简单方法。 这是一种古老且持续使用的开发技巧。
从 Next.js 到 htmx：一个真实世界的迁移案例
作者分享将开源 URL 短链接服务从 Next.js 迁移到纯 HTML 加 htmx 的实践。 迁移后依赖减少 87%，构建时间归零，网站体积缩减超 85%。
架构同理心：为何新软件应顺应而非颠覆现有架构
htmx 作者提出“架构同理心”概念，主张新软件应顺应现有架构而非取代。 以 htmx 遵循 Web REST 架构为例，对比 SPA 框架的替代式设计。 文章分析了这种设计原则的优势与劣势，认为顺应架构能降低学习成本并保持整体协调。
对话 Leonard Richardson：为何 REST API 止步于 Level 2，以及 GraphQL 的本质
Richardson Maturity Model 创始人 Leonard Richardson 回顾 REST API 发展史。他指出业界普遍停滞在 Level 2，未能实现 Level 3 超媒体互操作。 他认为核心原因是商业公司的“厂商锁定”策略与互操作性相悖。同时，JSON 取代 XML 导致超媒体控制丢失，GraphQL 被视为面向数据库查询的现代 RPC 方案。
Primer.js 创始人访谈：Facebook 早期的超媒体 JS 库往事
Facebook 早期 Primer.js 库创始人 Makinde Adeagbo 回顾该库如何帮助解决 2010 年页面加载缓慢问题。 Primer 作为超媒体方案曾与 React 共存，后因 Facebook 需求演变而退出历史舞台，其理念可能回归。
专访《RESTful Web APIs》作者 Mike Amundsen
本文是对 REST 领域专家 Mike Amundsen 的访谈，探讨超文本媒体的历史演变及现状。Amundsen 分享了他自 2008 年以来对 REST 和超媒体理念的研究与思考。 访谈回顾了他出版的书籍及其对构建超媒体 API 的观点，适合对 Web 架构演进感兴趣的开发者阅读。
专访 pjax 作者兼 GitHub 联合创始人 Chris Wanstrath
本文是对 pjax 作者及 GitHub 联合创始人 Chris Wanstrath 的深度访谈，回顾 pjax 库的诞生背景、设计灵感及其对后续技术的影响。 文章梳理了从 pjax 到 intercooler.js 再到 htmx 的技术演进脉络，探讨了超文本驱动开发的历史与理念。
什么时候该用超媒体？
htmx 作者详细分析了在哪些场景下应该使用超媒体架构，以及哪些场景不适合。 适合的场景包括以文本图片为主的界面、CRUD 应用、嵌套更新界面、需要深度链接和首屏性能的情况。 不适合的场景包括 UI 状态频繁更新、需要离线功能、强动态依赖（如电子表格）以及团队缺乏技术共识的情况。文章主张采用混合架构，根据具体需求选择合适方案。