Dat 是使用 Node.js 建構的，因此它自然而然地適合我們的整合。除此之外，我們的使用者使用各種機器，因為科學家、研究人員和政府官員可能被迫為其機構使用某些設定 —— 這意味著我們需要能夠以 Windows 和 Linux 以及 Mac 為目標。Dat Desktop 可以輕鬆地為我們做到這一點。
我們一直以來都是標準和最小抽象概念的忠實擁護者。我們的整個介面都是使用常規 DOM 節點和少量輔助程式庫建構的。我們已開始將其中一些組件遷移到 base-elements，這是一個低階可重複使用組件的程式庫。與我們的大多數技術一樣，我們不斷迭代它，直到我們做對為止，但作為一個團隊，我們感覺我們正朝著正確的方向前進。
$ bkr fork dat://0ff7d4c7644d0aa19914247dc5dbf502d6a02ea89a5145e7b178d57db00504cd/ ~/my-fork $ cd ~/my-fork $ echo "My fork has no regard for the previous index.html!" > index.html $ bkr publish
這是一個非常好的問題，這並不是因為市面上缺乏螢幕錄影工具！我們覺得替代方案要么太複雜、要么太昂貴、要么太有限。沒有任何一款工具感覺剛剛好，適合我們的日常需求。我們也認為，當我們用來工作的工具是開源的時候，那真是太棒了，這樣每個人都可以幫助塑造它們。建構 Kap 的結果與我們沒有做的事情一樣多。這一切都在細節中，小改進的累積成為我們想要使用的工具的輪廓。
使用 Electron 可用的資源來錄製螢幕是最大的挑戰。它們的效能根本不足以滿足我們的要求，並且會使該專案在我們眼中成為失敗。儘管這並非 Electron 本身的錯，但在原生開發和使用 Web 技術建構桌面應用程式之間仍然存在差距。
我們花費了大量時間試圖解決 getUserMedia API 的效能不佳問題，這個問題源於 Chromium。我們在開始製作 Kap 時的主要目標之一是使用 Web 技術建構整個應用程式。在嘗試了一切可以讓它運作的方法（最低要求是在 Retina 螢幕上達到 30 FPS）之後，我們最終不得不尋找其他解決方案。
我們都知道 Electron 應用程式可能會大量使用 RAM，但同樣，這實際上是 Chromium 的問題。這是它運作方式的一部分，並且它確實取決於您正在運行的內容，例如 Kap 和 Hyper 通常使用少於 100MB 的記憶體。
我們看到的最大改進領域之一是有效負載，特別是 Electron 如何分發 Chromium。一個想法是擁有一個共享的 Electron 核心，並使應用程式安裝程式檢查系統上是否已存在它。
創建跨平台 Electron 應用程式可能會是一個更好的體驗。目前，平台之間存在太多不一致之處、特定於平台的 API 和缺少的功能，這使得您的程式碼庫中充斥著 if-else 語句。例如，vibrancy 僅在 macOS 上受支援，自動更新程式在 macOS 和 Windows 上的運作方式不同，甚至在 Linux 上不受支援。透明度在 Linux 上時好時壞，通常是壞。
呼叫原生系統 API 也應該更容易。Electron 附帶一組非常好的 API，但有時您需要它不提供的功能。創建原生 Node.js 附加元件是一個選項，但使用起來很痛苦。理想情況下，Electron 會附帶一個良好的 FFI API，例如 fastcall。這將使我們能夠用 JavaScript 寫入 Swift 部分。
