我非常興奮能採訪到 Unpoly 的創辦人 Henning Koch，這是一個以超媒體為導向的 JavaScript 函式庫，與 intercooler.js 同時創建。
感謝您同意接受採訪！
問：首先，您能否向讀者簡述一下您的專業和技術背景？
當然！我目前是 makandra 的開發主管，這是一家我於 2009 年共同創辦的 Ruby on Rails 諮詢公司，在那之前我做了多年的網頁開發自由職業者。因此，我的背景是在許多不同的 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 的另一項職責是培訓年輕開發人員，這與我產生了很大的共鳴。我非常關心維護一個堆疊，讓一個人可以成為全端開發人員並始終如一地交付良好的結果。
此外，作為一名 Rubyist，我對程式碼被調用時的人體工學和美感有著過度的執著。我非常強調一個功能在客戶端程式碼中被使用時的外觀。當一個小想法需要不成比例的程式碼量時，我會為此失眠。
問：在您構建 Unpoly 時，您是否考慮過超媒體、REST 等？您覺得這些東西有用嗎？有趣嗎？
我與您一樣喜歡將 UI 與內容一起串流的互動式文件。對我而言，這始於 1990 年代的基於字元的 BBS UI 和 WinHelp 檔案，直到 Web 最終取代了這一切。
今天我對此沒有過多的哲學思考，但我確實認為超媒體方法是一個甜蜜點，您可以用非常少且大多是枯燥的程式碼獲得良好的 UI 保真度。對於中等應用程式而言，超媒體可能比 SPA 模型提供更好的結果。我覺得 SPA 模型理論上限與大多數 SPA 交付的內容之間存在巨大的脫節。SPA 允許樂觀的 UI（這很棒！），但這只是比等待 JSON 端點更多的程式碼。因此，一旦您在不穩定的連線上進行任何有意義的互動，許多 SPA 會降級為旋轉器和空白頁面。
問：您從 unpoly 中吸取的最重要的技術教訓是什麼？
我了解到，在您透過添加 JavaScript 來破壞它之前，瀏覽器會正確處理大量的邊緣案例。例如，管理焦點、並行輸入、不穩定的連線。要提供相同程度的正確性並非易事，例如，當您在 JavaScript 中模擬頁面轉換時。這需要大量的程式碼才能解決。當我看到一個聲稱以 2000 個位元組或類似的程式碼重新實現 React 的微型函式庫時，我總是會想起這一點。您不能在過程中不犧牲一些正確性的情況下，就透過程式碼高爾夫來減少一半的捆綁包大小。