我非常激动能采访Henning Koch，Unpoly的创造者。这是一个与intercooler.js同期开发的超媒体导向JavaScript库。
感谢您接受采访！
问：首先请向读者介绍您的专业和技术背景：
当然！我目前是makandra的开发主管，这家Ruby on Rails咨询公司是我2009年联合创立的，之前多年从事自由网页开发。我的工作背景是同时维护多个不同Web应用。每周可能涉及10+个项目，涵盖教育、汽车到网络安全等行业。Unpoly提炼自我们在客户项目中反复出现的模式。
问：我创建intercooler.js的重要原因是当时不愿处理流行SPA库（如Angular和ExtJS）。Unpoly有类似背景吗？
我们团队曾全力投入AngularJS，试图取代jQuery的混乱代码。当谷歌用Angular 2重写扼杀AngularJS后，我们复盘了这段时期，结果喜忧参半。虽然用SPA模型构建了部分优秀应用，但多数项目存在代码库膨胀、依赖增多、逻辑分散在客户端/服务器、大量样板API将数据从已有位置（服务器）搬运到需要处（浏览器）等问题。
那时我们重新尝试渐进增强，但这次提供了高层结构，让应用免于手动发起AJAX请求和操作单个DOM元素。基本上是构想HTML6幻想规范：如果HTML6专注服务器渲染应用会怎样？会包含哪些功能？这个思想实验催生了Unpoly。
问：Unpoly是"开箱即用"的库，对渐进增强支持极佳。我知道您也是Rails开发者。这影响了Unpoly的设计吗？
当然！像Rails一样，Unpoly为一切提供强默认设置，偏好非侵入式约定而非显式配置。例如若想让Unpoly处理所有链接和表单，可全局设置且无需修改HTML。
Rails近期的座右铭是"压缩现代Web应用的复杂度"和"单人框架"。作为makandra的新人培训负责人，这深得我心。我十分关注维护能让单人成为全栈开发者并持续交付优质成果的技术栈。
此外作为Ruby主义者，我极度痴迷代码在调用时的工效学和美学。当一个小功能需要不成比例的代码量时，我会彻夜难眠。
问：构建Unpoly时是否深入思考超媒体、REST等概念？您觉得这些有用或有趣吗？
问：从Unpoly中汲取的最重要技术经验是什么？
我理解您对交互式文档的热爱（其UI随内容实时传输）。这始于1990年代的字符界面BBS和WinHelp文件，直至Web最终取代一切。
如今我不太哲学化思考，但相信超媒体方法能在极简代码下实现高UI保真度。对普通应用而言，超媒体可能比SPA模型效果更好。感觉SPA的理论上限与实际交付成果间存在巨大脱节。SPA允许乐观UI（很棒！），但相比等待JSON端点需要更多代码。因此当网络不稳定时，许多SPA退化为加载图标和空白页。
我学到浏览器在添加JavaScript前已正确处理大量边界情况。例如管理焦点、并发输入、不稳定连接等。用JavaScript模拟页面过渡时，要达到同等正确性需大量代码。每次看到声称用2000字节"重新实现React"的微库，我都会想起这点——精简包体积必然以牺牲正确性为代价。