我很高兴能够采访 Henning Koch，他是 Unpoly 的创建者，这是一个与 intercooler.js 同时创建的超媒体导向型 JavaScript 库。
感谢您接受采访！
问：首先，您能向读者介绍一下您的专业和技术背景吗？
当然！我目前是 makandra 的开发主管，这是一家我在 2009 年与人共同创办的 Ruby on Rails 咨询公司，在此之前我做了很多年的 Web 开发自由职业者。所以我的背景是同时处理多个 Web 应用，并长期维护它们。在一个星期内，我们可能会接触到 10 多个项目，涉及的行业从教育到汽车到网络安全。Unpoly 是从我们在客户项目中反复出现的模式中提取出来的。
问：当我创建 intercooler.js 时，很大一部分原因是我不愿处理当时流行的 SPA 库（例如 Angular 和 ExtJS）。Unpoly 也有类似的历史吗？
我们的团队实际上曾经全力投入 AngularJS，试图用它来替换我们之前大量的 jQuery 混乱代码。当 Google 用他们的 Angular 2 重写来废弃 AngularJS 时，我们对这段时间进行了回顾，得出了褒贬不一的结论。虽然我们构建了一些非常适合 SPA 模型的应用程序，但大多数项目却因为代码库更大、依赖项更多、逻辑在客户端和服务器之间分割、大量的样板 API 来移动已经存在的数据（服务器）到需要它们的地方（浏览器）而苦恼。
正是那时，我们再次尝试了渐进增强，但这次我们提供了一些更高层次的结构，以便应用程序可以免于手动进行 AJAX 请求和处理单个 DOM 元素。基本上是提出一个 HTML6 的幻想规范，询问：如果 HTML6 全部是关于服务器端渲染的应用程序，那么该规范中会有什么功能？这个思想实验就是 Unpoly 的起源。
问：Unpoly 是一个非常“包含电池”的库，对渐进增强提供了极好的支持。我知道您也是 Rails 开发人员。这是否影响了您对 Unpoly 的方法？
绝对的！与 Rails 一样，Unpoly 为所有内容提供了强大的默认值，并且更喜欢不显眼的约定而不是明确的配置。例如，如果您想让 Unpoly 处理所有链接和表单，您可以在全局范围内设置它，而无需更改您的 HTML。
Rails 最近的一些座右铭是“压缩现代 Web 应用的复杂性”和“一人框架”。由于我在 makandra 的另一个职责是培训年轻的开发人员，这与我产生很大的共鸣。我真的很关心维护一个堆栈，让一个人可以成为全栈开发人员，并始终如一地交付良好的结果。
此外，作为一名 Ruby 开发人员，我对代码调用方式的人机工程学和美学有着过度的痴迷。我非常重视功能在客户端代码中的使用方式。当一个小的想法需要不成比例的代码量时，这是我失眠的原因。
问：在构建 Unpoly 时，您是否考虑过超媒体、REST 等？您觉得这些东西有用吗？有趣吗？
我与您对交互式文档的热爱不谋而合，这些文档将 UI 与内容一起流式传输。对我来说，这始于 20 世纪 90 年代的基于字符的 BBS UI 和 WinHelp 文件，直到网络最终取代了这一切。
今天，我对它没有那么哲学化的思考，但我确实认为，超媒体方法是一个最佳位置，您可以在其中获得良好的 UI 保真度，而代码量很少，而且大多是无聊的代码。对于中等的应用程序，超媒体可能比 SPA 模型的效果更好。我感觉 SPA 模型的理论上限与大多数 SPA 提供的服务之间存在着巨大的脱节。SPA 允许乐观 UI（这很好！），但这只是比等待 JSON 端点更多的代码。因此，一旦您在不稳定的连接上进行任何有意义的交互，许多 SPA 就会退化为转轮和空白页面。
问：从 unpoly 中，您吸取了哪些最重要的技术教训？
我了解到浏览器处理大量的边缘情况，在您通过添加 JavaScript 来破坏它之前。比如管理焦点、并发输入、不稳定的连接。例如，当您在 JavaScript 中模拟页面转换时，要实现相同级别的正确性并不容易。这需要大量的代码来解决这个问题。每当我看到一个声称用 2000 字节或更少的代码量重新实现 React 的微型库时，我都会想起这一点。您不能仅仅通过代码高尔夫来缩减一半的包大小，而不会在过程中牺牲一些正确性。