CACivicData 是一个开源档案库，每天提供来自 CAL-ACCESS 的下载，CAL-ACCESS 是加利福尼亚州跟踪政治资金的数据库。他们进行 每日发布，这意味着在其 zip 文件中托管大量重复数据。我们正在努力将他们的数据托管为 Dat 存储库，这将减少引用特定版本或更新到较新版本所需的麻烦和带宽。
Dat 是使用 Node.js 构建的，因此它是我们集成的自然选择。除此之外，我们的用户使用各种各样的机器，因为科学家、研究人员和政府官员可能被迫为其机构使用某些设置——这意味着我们需要能够以 Windows 和 Linux 以及 Mac 为目标。Dat Desktop 可以非常轻松地为我们做到这一点。
$ 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 部分。
