$ 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 帧）后，我们最终不得不找到另一个解决方案。
我们都知道 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 部分。
我们最近在 GitHub 总部为 Hackbright Academy 的成员举办了一场 Electron 黑客马拉松，Hackbright Academy 是一家位于旧金山、专门为女性提供编程教育的学校。为了帮助参与者更好地开始他们的项目，我们的 Kevin Sawicki 创建了一些示例 Electron 应用程序。
如果您是 Electron 开发新手，或者还没有尝试过，这些示例应用程序是一个很好的起点。它们体积小巧，易于阅读，并且代码注释丰富，解释了所有功能的工作原理。
