我很高兴能够采访 Makinde Adeagbo，他是 Primer 的创建者之一， 这是一个面向超媒体的 JavaScript 库，在 2000 年代的 Facebook 中使用。
感谢您同意接受采访！
Q: 首先，您能向读者介绍一下您的职业和技术背景吗？
我一直对技术感兴趣。在高中时，我曾为朋友和家人组装电脑。我上过高中提供的计算机科学课程，并在大学继续学习计算机科学。我总是对这样一个事实感到惊奇：我只需一台电脑和互联网连接，就能构建酷炫的东西——游戏、工具等。
我有幸参加了 Explore Microsoft，这是一个实习项目，它针对大学新生中的弱势群体，并给他们一个在 Microsoft 工作的机会。在那次经历之后，我决定将软件作为我的未来。我后来又在 Apple 和 Microsoft 实习过。在大学期间，我还在 Facebook 工作，当时公司大约有 150 名员工。这是一次令人难以置信的经历，工程师们几乎拥有完全的自由来构建并为公司的增长做出贡献。这正是我职业生涯早期所需要的，我在其中茁壮成长。从那里，我继续在 Dropbox 和 Pinterest 工作，并共同创立了非营利组织 /dev/color。
Q: 您能告诉我 Primer 的起源历史吗？
2010 年，Facebook 网站非常慢。这不是任何特定个人的错——每位工程师都在添加功能，并在此过程中添加少量 JavaScript。然而，我们没有一个连贯的系统来共享库或跟踪每个页面运送的 JavaScript 数量。随着时间的推移，这导致了第 90 百分位页面加载时间膨胀到大约 10 秒！在年中，将加载时间减半成为公司三大优先事项之一。我在一个小型工程师团队中，负责实现这一目标。
当我们调查大多数 JavaScript 来自哪里时，我们注意到其中大部分都在执行简单任务。这些任务涉及从服务器获取额外数据或标记，或者提交表单然后接收更多标记来更新页面。由于时间有限，我们决定构建一个小型解决方案来抽象这些模式，并减少页面上所需的代码量。
Tom Occhino 和我构建了 Primer 的第一个版本，并亲自转换了一些用例来确保它运行良好。一旦我们有信心，我们就引入更多工程师来扩展它到整个代码库。
Q: Primer 和 React 都是在 Facebook 创建的。团队之间有任何内部竞争或讨论吗？这看起来是什么样的？
这两个项目来自不同的时代、需求和代码库的不同部分。据我所知，它们之间从未有过竞争。
Primer 在 2010 年我们构建的网站类型中运行良好。它成功的一个关键部分是理解它并非旨在处理每个用例。它是一个 80/20 解决方案，我们没有用它来处理特别复杂的交互（比如创建新帖子的界面）。
React 来自一个完全不同的挑战：广告工具。管理、组合和跟踪数百个广告需要一个高度复杂、涉及的界面。我不确定他们是否尝试过用 Primer 来处理它，但那将是一次糟糕的经历。我们当时还没有那个术语，但这是一个经典的单页应用程序需要专用工具的例子。该网站的用户的特征也与浏览首页动态或浏览照片的人完全不同。
Q: 您认为 Primer 在 Facebook 最终失败的原因是什么？
我不认为 Facebook 平台上有任何单一的技术解决方案能持续 15 年。网站的需要会演变，技术会变化，互联网的格局也会随着时间推移而改变。Primer 在它那个时代和约束下很好地服务了网站，但最终，产品需要更丰富的交互性，而这不是 Primer 设计的目的。
其他权衡因素也会发挥作用：开发者便利性/速度、安全性、可扩展性。这些优先事项和权衡会随着时间变化，尤其是当公司规模增长 10 倍时。
更广泛地说，这些东西在行业中往往是循环的。简化的、快速的解决方案会让位于更丰富、更重的工具，这些工具最终又会循环回简化且快速。我不会惊讶于类似 Primer 的事物在某个时候会卷土重来。
Q: Primer 有多少“理论”基础？在构建它时，您是否考虑了很多关于超媒体、REST 等内容？
不多。老实说，我当时很年轻，对互联网的历史或过去的研究了解不多。我被 Web 底层构建块的简单性所吸引，并认为使用这些工具如其设计的那样很有趣。但是，一如既往，Web 是一层层黑客和临时修补的蛋糕，所以你必须灵活。
Q: 从 Primer 中，您学到了哪些最重要的技术教训？
老实说，最大的教训是关于人的。构建像 Primer 这样的系统是一回事，但要让它成功，你必须培训数百名工程师使用它。你必须教他们以不同的方式思考构建事物，在正确的时间提出问题，并避免走错方向。即使系统完美，如果工程师讨厌使用它，它也不会成功。