我们一直都非常推崇标准和最小抽象。我们的整个界面都使用常规 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 的内存。
我们看到的一个最大改进领域是应用包大小（payload），特别是 Electron 如何分发 Chromium。一个想法是拥有一个共享的 Electron 核心，并让应用安装程序检查系统上是否已经存在它。
创建跨平台 Electron 应用的体验可以更好。现在，不同平台之间存在太多不一致、特定于平台的 API 和缺失的功能，导致你的代码库充满了 if-else 语句。例如，vibrancy 效果只在 macOS 上支持，自动更新器在 macOS 和 Windows 上工作方式不同，在 Linux 上甚至不支持。透明度在 Linux 上时好时坏，通常是不行。
调用原生系统 API 也应该更容易。Electron 提供了一套非常好的 API，但有时你需要它不提供的功能。创建一个原生的 Node.js 插件（addon）是一种选择，但使用起来很痛苦。理想情况下，Electron 应该自带一套好的外部函数接口 (FFI) API，比如fastcall。这将使我们能够用 JavaScript 而不是 Swift 来编写那部分代码。
