企业官网建设流程全解析

• 前端

导读：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 为何最终淡出 Facebook？

Makinde 对"Primer 为什么在 Facebook 失败了"的回答，比技术归因更深刻——他并不认同"失败"这个叙事本身：

我不认为有任何单一技术方案能在 Facebook 平台上存活 15 年。网站的需求在演进，技术在变化，互联网的版图也在随时间推移而改变。Primer 在其所处的时代与约束下很好地服务了网站，但最终产品需要更丰富的交互性——那并不是 Primer 的设计目标。

他补充了两层理由：

1. 取舍（tradeoffs）随规模漂移：开发者便利性/速度、安全性、可扩展性，这些优先级会随着时间变化，尤其是当一家公司规模增长 10 倍时。
2. 行业呈周期性运转：轻快、精简的方案会让位于更重、更丰富的工具，而后者最终又会循环回到轻快与精简。"如果某个类似 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 最初只是给请求追加?pjax=1，发布前才改为发送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 解读 等文章共同构成一套完整的"超媒体史观"。

从时间线上看：

• 2010：Primer 在 Facebook 用极小的抽象解决了 10 秒加载的性能问题，印证"取数据 + 更新标记"是当时前端 JavaScript 的主流形态；
• 2011：pjax 借助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 的动机与快速上手示例）

• 前端