$ 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 应用可能比较耗内存，但这同样是 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 编写那部分代码。
