WebTorrent Desktop 的贡献者之一 Feross 最近在 NodeConf Argentina 发表了题为 *“Real world Electron: Building Cross-platform desktop apps with JavaScript”* 的演讲，其中包含有关发布高质量 Electron 应用程序的有用技巧。如果您正处于拥有基本可用应用程序并希望将其提升到更高水平的打磨和专业水平的阶段，这次演讲尤其有用。
$ 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 部分。
