本周我们与 Aprile Elcich 和 Paolo Fragomeni 会面，讨论了 Voltra，一款由 Electron 驱动的音乐播放器。

什么是 Voltra？​

Voltra 是一款为想要拥有自己音乐的人设计的音乐播放器。它也是一个商店，您可以在其中根据您已拥有的音乐发现和购买新音乐。它是无广告的，跨平台支持桌面和移动设备。它也不会监视您。

Voltra 适合哪些人？​

任何听音乐的人。

是什么促使您创建 Voltra？​

广播一直拥有大量的听众。它正在从无线电波转移到互联网上。现在您可以按需租用音乐——这是广播的复兴！许多新产品和服务因此而出现，但流媒体广播仍然让其他人控制您的音乐以及您体验音乐的方式。

我们想要一款完全专注于您拥有的音乐的产品。它可以让您轻松地直接从艺术家或唱片公司发现和购买新音乐。

有免费版本吗？​

桌面播放器是完全免费的。 销售您的音乐也是免费的！ 我们不支持广告。

由于该应用是免费的，我们稍后可能会开源它。目前我们没有带宽来管理它。我们对功能和我们想要发展的方向也有非常具体的想法。我们有一个活跃的 beta 社区，我们认真对待我们的反馈。

你们如何赚钱？​

我们有高级功能！

我们的 Voltra 音频存档 是一项专门为音乐设计的云备份服务。我们不压缩或共享数据块。您的音乐收藏会为您进行物理备份。

对于艺术家和唱片公司，我们的 Pro 会员 提供工具来帮助他们接触到更多相关的受众，例如分析和专业的艺术家网页。

Voltra 有什么不同？​

设计和可用性对我们来说非常重要。我们希望为听众提供无干扰的聆听体验！市面上有一些有趣的音乐播放器和商店。但是它们中的许多比其创建者意识到的更高级且更难使用。我们希望使 Voltra 尽可能多的人都能使用。

我们也不会从艺术家或唱片公司那里抽成。这对我们来说是一个关键的区别。这非常重要，因为它降低了艺术家将其音乐推向市场的门槛。

您做出了一些什么设计和技术决策？​

在设计 Voltra 时，我们考虑了来自原生应用和 Web 的 UI 约定，我们还认真考虑了可以删除哪些内容。在过去的几个月中，我们有一个活跃的私人 beta 测试组，他们为我们提供了重要的反馈。

我们发现专辑封面和摄影对人们来说非常重要。许多播放器只是文件列表。拥有实体专辑的酷炫之处之一是专辑封面，我们希望在 Voltra 桌面应用中强调这一点。

我们还确保不干扰人们的文件。我们使用文件监视，因此您可以将文件放在任何想要的位置，我们不会重命名或为您移动它们。我们有一个嵌入式数据库来跟踪受监视目录的状态，以便我们可以跟踪新内容，即使进程未运行也是如此。

在构建 Voltra 时您遇到了一些什么挑战？​

我们花费大量时间专注于性能。我们从框架开始，但后来转向了 vanilla Javascript。根据我们的经验，它们提供的通用抽象超过了它们引入的性能损失和仪式感。

在这一点上，我们很好地处理了非常大的集合。大型集合意味着可能包含数万张图像！从渲染进程直接访问 Node.js 的文件系统模块使得基于 DOM 事件非常容易地延迟加载和卸载大量图像。

一般来说，setImmediate 和 requestIdleCallback 一直是在保持 UI 响应性的同时执行大量处理的超级重要工具。更具体地说，将 CPU 密集型任务分配到单独的进程中确实有助于保持用户界面的响应性。例如，我们将实际的音频上下文移动到一个单独的进程中，通过 IPC 与其通信，以避免来自繁忙 UI 的潜在中断。

您为什么选择在 Electron 上构建 Voltra？​

浏览器的沙箱对于我们的应用来说限制太多了。但我们也在开发一个 Web 播放器。因此，我们可以在两个实现之间共享几乎 100% 的代码，这是一个巨大的胜利。

我们实际上是从使用 Swift 构建原生应用开始的。我们发现的主要问题是我们正在重新发明很多东西。Web 拥有世界上最大的开源生态系统。因此我们很快就切换到了 Electron。

此外，最重要的是，使用 Electron，您只需开发一次，它就应该在所有主要平台上 Just Work™。这不能保证，但为每个平台进行原生编码的成本绝对超过 Electron 引入的任何其他成本。

您最喜欢 Electron 的哪些方面？​

GTD！：将 Node.js 的网络堆栈和 Chromium 的演示层打包在一起是完成工作的秘诀。

能力：它只是 Web 堆栈，因此实际上我们整个团队都参与了实际的产品构建。

社区：有一个高度组织化的社区，他们知道如何很好地沟通！我们对在这样的支持下进行开发感到非常棒。

Electron 在哪些方面可以改进？​

我们希望看到 Electron 认可一个单一的打包器。打包器对于 Electron 的重要性就像包管理器对于 Node 的重要性一样。用户领域中有多个打包器，每个打包器都有有趣的功能，但每个打包器都有错误。社区的共识将有助于引导贡献者花费的精力。

接下来会发生什么？​

我们目前正在开发一个移动应用，并与艺术家和唱片公司合作，将他们的音乐添加到 Voltra 商店。嘿！如果您是艺术家或唱片公司，立即注册！我们计划在我们达到 1000 万首曲目的目标时开放商店。

Electron 基于 Google 的开源 Chromium，该项目不一定旨在供其他项目使用。这篇文章介绍了 Chromium 如何构建为供 Electron 使用的库，以及构建系统多年来的发展历程。

使用 CEF​

Chromium Embedded Framework (CEF) 是一个将 Chromium 转换为库的项目，并基于 Chromium 代码库提供稳定的 API。Atom 编辑器和 NW.js 的早期版本都使用过 CEF。

为了维护稳定的 API，CEF 隐藏了 Chromium 的所有细节，并使用自己的接口包装了 Chromium 的 API。因此，当我们需要访问底层的 Chromium API 时，例如将 Node.js 集成到网页中，CEF 的优势就变成了阻碍。

因此，最终 Electron 和 NW.js 都切换到直接使用 Chromium 的 API。

作为 Chromium 的一部分构建​

即使 Chromium 没有官方支持外部项目，但其代码库是模块化的，并且很容易构建一个基于 Chromium 的最小浏览器。提供浏览器界面的核心模块称为 Content Module。

要使用 Content Module 开发项目，最简单的方法是将项目构建为 Chromium 的一部分。这可以通过首先检出 Chromium 的源代码，然后将项目添加到 Chromium 的 DEPS 文件中来完成。

NW.js 和早期版本的 Electron 都在使用这种方式进行构建。

缺点是，Chromium 是一个非常庞大的代码库，需要非常强大的机器才能构建。对于普通笔记本电脑，这可能需要 5 个多小时。因此，这极大地影响了可以为项目做出贡献的开发人员数量，并且也使开发速度变慢。

将 Chromium 构建为单个共享库​

作为 Content Module 的用户，Electron 在大多数情况下不需要修改 Chromium 的代码，因此改进 Electron 构建的一个明显方法是将 Chromium 构建为共享库，然后在 Electron 中与其链接。这样，开发人员在为 Electron 做出贡献时不再需要构建所有的 Chromium。

libchromiumcontent 项目由 @aroben 为此目的而创建。它将 Chromium 的 Content Module 构建为共享库，然后提供 Chromium 的头文件和预构建的二进制文件供下载。libchromiumcontent 初始版本的代码可以在 此链接 中找到。

brightray 项目也作为 libchromiumcontent 的一部分诞生，它在 Content Module 周围提供了一个薄层。

通过一起使用 libchromiumcontent 和 brightray，开发人员可以快速构建浏览器，而无需深入了解构建 Chromium 的细节。它还消除了构建项目对快速网络和强大机器的要求。

除了 Electron 之外，还有其他基于 Chromium 的项目以这种方式构建，例如 Breach 浏览器。

过滤导出的符号​

在 Windows 上，一个共享库可以导出的符号数量有限制。随着 Chromium 代码库的增长，libchromiumcontent 中导出的符号数量很快超过了限制。

解决方案是在生成 DLL 文件时过滤掉不需要的符号。它的工作原理是 向链接器提供一个 .def 文件，然后使用脚本 判断命名空间下的符号是否应该导出。

通过采用这种方法，尽管 Chromium 不断添加新的导出符号，但 libchromiumcontent 仍然可以通过剥离更多符号来生成共享库文件。

组件构建​

在讨论 libchromiumcontent 中采取的后续步骤之前，重要的是首先介绍 Chromium 中组件构建的概念。

作为一个庞大的项目，Chromium 在构建时的链接步骤非常耗时。通常，当开发人员进行少量更改时，可能需要 10 分钟才能看到最终输出。为了解决这个问题，Chromium 引入了组件构建，它将 Chromium 中的每个模块构建为单独的共享库，因此最终链接步骤花费的时间变得不明显。

发布原始二进制文件​

随着 Chromium 的持续增长，Chromium 中导出的符号太多了，即使 Content Module 和 Webkit 的符号也超过了限制。仅通过剥离符号就无法生成可用的共享库。

最终，我们不得不 发布 Chromium 的原始二进制文件，而不是生成单个共享库。

如前所述，Chromium 中有两种构建模式。由于发布了原始二进制文件，我们不得不在 libchromiumcontent 中发布两种不同的二进制文件发行版。一种称为 static_library 构建，其中包含 Chromium 正常构建生成的每个模块的所有静态库。另一种是 shared_library，其中包含组件构建生成的每个模块的所有共享库。

在 Electron 中，Debug 版本与 libchromiumcontent 的 shared_library 版本链接，因为它下载量小，并且在链接最终可执行文件时花费的时间很少。Electron 的 Release 版本与 libchromiumcontent 的 static_library 版本链接，因此编译器可以生成完整的符号，这对于调试非常重要，并且链接器可以进行更好的优化，因为它知道需要哪些目标文件，哪些不需要。

因此，对于正常的开发，开发人员只需要构建 Debug 版本，这不需要良好的网络或强大的机器。虽然 Release 版本然后需要更好的硬件来构建，但它可以生成更好优化的二进制文件。

gn 更新​

作为世界上最大的项目之一，大多数普通系统都不适合构建 Chromium，Chromium 团队开发了自己的构建工具。

早期版本的 Chromium 使用 gyp 作为构建系统，但它的缺点是速度慢，并且其配置文件对于复杂的项目变得难以理解。经过多年的发展，Chromium 切换到 gn 作为构建系统，它速度更快，并且具有清晰的架构。

gn 的改进之一是引入 source_set，它代表一组目标文件。在 gyp 中，每个模块都由 static_library 或 shared_library 表示，对于 Chromium 的正常构建，每个模块都生成一个静态库，并在最终可执行文件中将它们链接在一起。通过使用 gn，每个模块现在只生成一堆目标文件，最终可执行文件只是将所有目标文件链接在一起，因此不再生成中间静态库文件。

然而，这种改进给 libchromiumcontent 带来了很大的麻烦，因为 libchromiumcontent 实际上需要中间静态库文件。

解决此问题的第一次尝试是 修补 gn 以生成静态库文件，这解决了问题，但远非一个体面的解决方案。

第二次尝试是由 @alespergl 做的，目的是 从目标文件列表中生成自定义静态库。它使用了一个技巧，首先运行一个虚拟构建来收集生成的目标文件列表，然后通过向 gn 提供列表来实际构建静态库。它仅对 Chromium 的源代码进行了最小的更改，并保持了 Electron 的构建架构。

总结​

如您所见，与将 Electron 构建为 Chromium 的一部分相比，将 Chromium 构建为库需要付出更大的努力，并且需要持续维护。然而，后者消除了构建 Electron 对强大硬件的要求，从而使更大范围的开发人员能够构建 Electron 并为其做出贡献。这种努力完全值得。

本周我们与 Automattic 的人们进行了交流，讨论了 WordPress Desktop，这是一个用于管理 WordPress 内容的开源桌面客户端。

每个人都知道 WordPress，但 WordPress Desktop 是什么？​

WordPress.com 桌面应用 提供无缝的跨平台体验，让您可以专注于您的内容和设计，而不会被浏览器标签分散注意力，或者让您的站点保持侧线但可访问。结合我们的浏览器支持和移动应用，您可以在任何地方、以任何有助于您完成工作的方式构建您的站点。

为什么要构建用于管理 WordPress 站点的桌面应用？难道不能全部基于 Web 吗？​

它实际上使用的正是您在浏览器中访问 WordPress.com 时获得的技术。但是，它都是本地托管的，因此加载时间最短。凭借停靠栏、通知等原生功能的优势，您真的可以专注于您的 WordPress 站点和博客。

您为什么选择在 Electron 上构建 WordPress Desktop？​

在 2015 年底，我们以 Calypso 的形式重建了大部分 WordPress.com，Calypso 是一个使用 React 的开源现代 JavaScript 应用。我们开始研究 Electron，并通过对 Calypso 进行一些更改，使其能够在本地运行。这是一个引人注目的体验，我们认为进一步开发它有很多价值。

我们有几个团队在 Calypso 上工作。要使用传统的桌面技术构建一个与之匹配的完整多平台 GUI 客户端，将需要更多的工作。通过使用 Electron，我们一个由 2-4 人组成的小团队能够利用其他团队的努力，并在几个月内构建桌面应用。

在构建 WordPress Desktop 时您遇到了一些什么挑战？​

我们非常快速地获得了该应用的初始版本，但是调整它以使其作为桌面应用最佳运行花费了更多的时间。该应用的一个巨大挑战是您实际上是在自己的机器上运行 Calypso 的副本 - 它纯粹是 API 驱动的 UI。其中涉及大量桥接工作，并且更改被反馈回 Calypso 本身。

此外，我们花费了大量精力来为不同的平台打包该应用——我们提供 Windows、macOS 和 Linux 版本——并且存在足够的差异使其变得棘手。

当时 Electron 还比较新，我们不断遇到很快就修复的问题（有时是同一天！）

Electron 在哪些方面应该改进？​

Electron 已经提供了我们桌面应用所需的大部分功能，并且自我们开始使用它以来，它已经取得了快速的进展。尽管如此，桌面应用中一些理所当然的领域，例如拼写检查和查找/替换，使用 Electron 现状很难复制。

我们也希望看到一些较新的 Chrome 技术也渗透到 Electron 中。我们特别热衷于尝试 WebVR。

您最喜欢 Electron 的哪些方面？​

我们选择 Electron 的主要原因，也是它最大的优势，是非常活跃和开放的社区。Automattic 一直信奉开源。这是我们的核心原则之一，Electron 项目和社区遵循了许多非常开放和积极的核心信念。

WordPress Desktop 的下一步是什么？​

我们模型的伟大之处在于桌面应用受益于任何新的 Calypso 功能 - 不断有改进。我们希望我们可以为该应用添加额外的功能，例如离线支持，这将真正将该应用带入原生领域，以及更好的系统通知。

Automattic 是否有任何团队正在开发其他 Electron 应用？​

是的，在我们为桌面应用做出努力之后，Simplenote 团队决定使用 Electron 为 Windows 和 Linux 构建桌面应用（已经存在原生 Mac 客户端）。Simplenote Electron 应用 也是开源的，可在 Github 上找到。

我们还有一个即将推出的 Raspberry Pi 集成，它使用了 Electron。

如果其中任何一项听起来很有趣，那么我们 很乐意收到您的来信！

是否有任何 Electron 技巧可能对其他开发人员有用？​

对我们来说，发布签名的桌面软件的过程相对较新，尤其是对于 Windows 而言。我们为 代码签名 Windows 应用 撰写了一篇文章，其中包含该过程以及我们为正确执行该过程而经历的一些障碍。

本周的特色项目是 Dat，一个 获得资助 的开源、去中心化工具，用于分发数据集。Dat 由一个 地理分布式团队 构建和维护，其中许多人帮助撰写了这篇文章。

首先，Dat 是什么？​

我们希望将点对点和分布式系统中最好的部分带到数据共享中。我们从科学数据共享开始，然后开始扩展到研究机构、政府、公共服务和开源团队。

另一种思考方式是像 Dropbox 或 BitTorrent Sync 这样的同步和上传应用，只是 Dat 是 开源 的。我们的目标是成为一个强大、开源、非营利的数据共享软件，用于大型、小型、中型、小批量和大批量数据。

要使用 dat CLI 工具，您只需输入

dat share path/to/my/folder

Dat 将创建一个链接，您可以使用该链接将该文件夹发送给其他人——没有中央服务器或第三方可以访问您的数据。与 BitTorrent 不同，也不可能嗅探出谁在共享什么（有关更多详细信息，请参阅 Dat Paper 草案）。

现在我们知道了 Dat 是什么。Dat Desktop 如何融入其中？​

Dat Desktop 是一种使无法或不想使用命令行的人员能够访问 Dat 的方式。您可以在您的机器上托管多个 dat，并通过您的网络提供数据。

您可以分享一些酷炫的用例吗？​

DataRefuge + Project Svalbard​

我们正在研究一个代号为 Project Svalbard 的项目，该项目与 DataRefuge 相关，DataRefuge 是一个致力于备份面临消失风险的政府气候数据的组织。Svalbard 以北极的斯瓦尔巴全球种子库命名，该种子库拥有大型地下植物 DNA 备份库。我们的版本是一个大型版本控制的公共科学数据集集合。一旦我们了解并可以信任元数据，我们就可以构建其他酷炫的项目，例如 分布式志愿者数据存储网络。

加州公民数据联盟​

CACivicData 是一个开源档案库，每日提供来自 CAL-ACCESS（加利福尼亚州追踪政治资金的数据库）的下载。他们进行每日发布，这意味着在其 zip 文件中托管大量重复数据。我们正在努力将他们的数据托管为一个 Dat 仓库，这将减少引用特定版本或更新到较新版本所需的麻烦和带宽。

Electron 更新​

这个想法目前尚未落实，但我们认为一个有趣的用例是将编译后的 Electron 应用程序放入 Dat 仓库中，然后使用 Electron 中的 Dat 客户端拉取已构建应用程序二进制文件的最新增量，从而节省下载时间，同时降低服务器的带宽成本。

哪些人应该使用 Dat Desktop？​

任何想要通过 p2p 网络分享和更新数据的人。数据科学家、开放数据黑客、研究人员、开发者。如果有人有我们尚未想到的酷炫用例，我们非常乐意接受反馈。您可以访问我们的 Gitter Chat 并向我们提问！

Dat 和 Dat Desktop 的下一步是什么？​

用户帐户和元数据发布。我们正在开发一个 Dat 注册表 Web 应用程序，将部署在 datproject.org 上，这基本上会是一个“数据集的 NPM”，唯一的区别是我们只会是一个元数据目录，而数据可以存在于任何在线位置（而不是像 NPM 或 GitHub 那样所有数据都集中托管，因为源代码足够小，可以放入一个系统中）。由于许多数据集都非常庞大，我们需要一个联合注册表（类似于 BitTorrent tracker 的工作方式）。我们希望让人们可以轻松地从 Dat Desktop 中通过注册表查找或发布数据集，从而使数据共享过程变得顺畅无阻。

另一个功能是多作者/协作文件夹。我们有宏大的协作工作流程计划，也许会使用分支，类似于 git，但围绕数据集协作而设计。但我们目前仍在努力提高整体稳定性和标准化我们的协议！

为什么选择在 Electron 上构建 Dat Desktop？​

Dat 是使用 Node.js 构建的，因此它自然而然地适合我们的集成。除此之外，我们的用户使用各种各样的机器，因为科学家、研究人员和政府官员可能被迫为其机构使用某些设置——这意味着我们需要能够以 Windows 和 Linux 以及 Mac 为目标。Dat Desktop 可以轻松地为我们实现这一点。

在构建 Dat 和 Dat Desktop 时，您遇到过哪些挑战？​

弄清楚人们想要什么。我们最初从表格数据集开始，但我们意识到这是一个有点复杂的问题，而且大多数人不使用数据库。因此，在项目进行到一半时，我们从头开始重新设计了一切，以使用文件系统，并且没有回头。

我们还遇到了一些通用的 Electron 基础设施问题，包括

• 遥测 - 如何捕获匿名使用统计数据
• 更新 - 设置自动更新有点零散且像魔法一样
• 发布 - XCode 签名、在 Travis 上构建版本、进行 beta 构建，这些都是挑战。

我们还在 Dat Desktop 的“前端”代码中使用了 Browserify 和一些很酷的 Browserify Transforms（这有点奇怪，因为即使我们有原生 require，我们仍然进行捆绑——但这因为我们想要 Transforms）。为了更好地管理我们的 CSS，我们从 Sass 切换到使用 sheetify。它极大地帮助我们模块化了 CSS，并使我们更容易将 UI 迁移到具有共享依赖项的面向组件的架构。例如，dat-colors 包含我们所有的颜色，并在我们所有项目之间共享。

我们一直都是标准和最小抽象的忠实拥护者。我们的整个界面都是使用常规 DOM 节点和少量辅助库构建的。我们已经开始将其中一些组件迁移到 base-elements，这是一个低级可重用组件库。与我们的大多数技术一样，我们不断迭代它，直到我们做对为止，但作为一个团队，我们感觉我们正朝着正确的方向前进。

Electron 在哪些方面应该改进？​

我们认为最大的痛点是原生模块。必须使用 npm 为 Electron 重建模块增加了工作流程的复杂性。我们的团队开发了一个名为 prebuild 的模块，它处理预构建的二进制文件，这对 Node 来说效果很好，但 Electron 工作流程仍然需要在安装后执行自定义步骤，通常是 npm run rebuild。这很烦人。为了解决这个问题，我们最近切换到一种策略，将所有平台的已编译二进制版本捆绑在 npm tarball 中。这意味着 tarball 会变得更大（尽管可以使用 .so 文件 - 共享库进行优化），这种方法避免了运行 post-install 脚本，也完全避免了 npm run rebuild 模式。这意味着 npm install 第一次就为 Electron 做了正确的事情。

您最喜欢 Electron 的哪些方面？​

API 似乎考虑得相当周到，相对稳定，并且在跟上上游 Node 版本方面做得相当不错，我们不能要求更多了！

是否有任何 Electron 技巧可能对其他开发人员有用？​

如果您使用原生模块，请试用 prebuild！

关注 Dat 发展的最佳方式是什么？​

在 Twitter 上关注 @dat_project，或订阅我们的 电子邮件新闻通讯。

本周我们与 Felix Rieseberg 进行了交流，他是 Slack 的桌面工程师，也是 Ghost Desktop 的维护者，Ghost Desktop 是 Ghost 发布平台的 Electron 客户端。

什么是 Ghost？​

Ghost 是一个完全开源、可黑客化的平台，用于构建和运行现代在线出版物。我们为从 Zappos 到 Sky News 的博客、杂志和记者提供支持。

它与其他发布平台有何不同？​

Ghost 成立于 2013 年 4 月，此前进行了一次非常成功的 Kickstarter 众筹活动，旨在创建一个专门专注于专业出版的新平台。我们的使命是为世界各地的独立记者和作家创建最好的开源工具，并对在线媒体的未来产生真正的影响。它提供了更简单、更专注的体验：我们的编辑器专门围绕提供最佳写作体验而设计。

与一直以来的经典 WordPress 相比，它提供了更简单、更精简的体验——它更容易设置和维护，开箱即用地配备了所有重要功能，并且速度显着更快。与其他在线平台相比，Ghost 让作者完全拥有和控制其内容，允许完全自定义，并使作者能够围绕其出版物建立业务。

Ghost 是一家营利性公司吗？​

这对我们来说非常重要：Ghost 是一个独立的非营利组织。我们为现代新闻业和博客构建发布工具，因为我们相信言论自由非常重要。我们的软件根据 免费开源许可证 发布，我们的商业模式 完全透明，我们的法律结构意味着我们赚到的 100% 的资金都再投资于改进 Ghost。

什么是 Ghost Desktop？​

Ghost Desktop 允许作者一次管理多个博客，并专注于写作。诸如常用写作快捷键之类的简单功能在浏览器中无法实现，但在我们的桌面应用程序中可用。它允许其他应用程序通过 deeplinks 与博客直接通信。

什么是 Ghost for Journalism？​

今年我们非常兴奋地将我们 10 人全职 Ghost 团队全部投入到帮助三个独立出版物的发展中，并为其努力提供 45,000 美元的资源。我们称之为 Ghost for Journalism。

大约三年半以来，我们一直在构建 Ghost，使其成为网络下一个伟大的独立发布商平台，现在我们已经达到了一个非常有趣的转折点。我们开始这段旅程是为了创建一个简单、设计精良的博客平台，几乎任何人都可以使用。这始终是第一步。

从长远来看，我们希望 Ghost 成为世界上最好的新闻业的强大平台，这意味着我们需要构建功能来吸引这些人。今年我们正在做出一个非常自觉的决定，专注于此。

为什么选择在 Electron 上构建 Ghost Desktop？​

Ghost 在后端和前端都使用 JavaScript 和 Node.js，因此能够利用相同的技术和技能组合使我们的团队能够更快地行动、构建更多内容，并最终提供更好的体验。此外，能够在 macOS、Windows 和 Linux 版本的应用程序之间共享超过 95% 的代码，使我们能够专注于构建出色的核心用户体验，而无需为每个平台维护一个代码库。

在构建 Ghost Desktop 时，您遇到过哪些挑战？​

拼写检查可能仍然是最难提供的服务之一——我们可以轻松地利用众多在线服务之一，但在保护用户隐私和自主权的同时正确地拼写检查多种语言的文本并非易事。

Electron 在哪些方面应该改进？​

我们很希望看到 Electron 将操作系统的原生拼写检查功能带到他们的应用程序中。我们梦想着一个 <input> 字段接收与 NSTextView 相同的服务的世界，但我们也深切意识到这有多么困难。

您最喜欢 Electron 的哪些方面？​

JavaScript 以其庞大的生态系统而闻名，其中涉及无数的工具和框架——但它为我们带来的便利是难以夸大的。使用 Electron 构建应用程序仅比构建 Web 应用程序稍微困难一些，这真是一项了不起的壮举。

Ghost 完成了吗？如果没有，下一步是什么？​

Ghost Desktop 也是一个持续进行的项目——我们离完成还很远。我们已经讨论了一段时间关于为用户带来完整离线模式的事情，我们已经非常接近了。其他值得注意的工作领域是扩展和与其他文本编辑应用程序（如 Word 或 Atom）的集成，最终允许人们使用他们最喜欢的工具编写帖子。总的来说，一旦我们发布了离线模式功能，我们就会寻求与操作系统更深入的集成。如果这听起来对您来说很有趣，请加入我们！

您最喜欢哪些 Electron 应用程序？​

我是 Kap、Felony 和 Visual Studio Code 的忠实粉丝。

👻

本周我们采访了 Paul Frazee，Beaker Browser 的创建者。Beaker 是一款实验性的点对点 Web 浏览器，它使用 Dat 协议从用户设备托管站点。

什么是 Beaker？您为什么创建它？​

Beaker 是一款参与式浏览器。它是为独立黑客打造的浏览器。

Web 是闭源的。如果您想影响社交媒体的工作方式，您必须在 Facebook 或 Twitter 工作。搜索方面，则是在 Google 工作。控制权掌握在公司手中，而不是用户自己手中。

借助 Beaker，我们有了一个新的 Web 协议：去中心化档案传输。“Dat”。它可以按需免费创建站点，然后从设备共享它们。无需服务器。这就是我们的创新之处。

当您在 Beaker 中访问 Dat 站点时，您会下载文件。该站点永远属于您。您可以保存它、fork 它、修改它，并免费共享您的新版本。这一切都是开源的。

这就是它的意义所在：我们正在为开源网站制作浏览器。我们希望它成为社交黑客的工具包。

哪些人应该使用 Beaker？​

黑客。模组制作者。创意人士。喜欢折腾的人。

如何创建一个使用 Dat 的新项目？​

我们有一个名为 bkr 的命令行工具，它有点像 git + npm。这是创建站点

$ cd ~/my-site
$ bkr init
$ echo "Hello, world!" > index.html
$ bkr publish

这是 fork 站点

$ bkr fork dat://0ff7d4c7644d0aa19914247dc5dbf502d6a02ea89a5145e7b178d57db00504cd/ ~/my-fork
$ cd ~/my-fork
$ echo "My fork has no regard for the previous index.html!" > index.html
$ bkr publish

这些站点随后将从您的浏览器中托管。这有点像 BitTorrent；您在 P2P 网格中共享站点。

如果您想要 GUI，我们在浏览器中内置了一些基本工具，但我们正在将这些工具推送到用户区。这一切都将是可修改的用户应用程序。

为什么选择在 Electron 上构建 Beaker？​

对于这个项目来说，这很明显。如果我自己 fork Chrome，我现在就在编写 C++！没人想这样做。我了解 Web 技术栈，并且可以快速使用它。这是不费脑筋的选择。

事实是，我不确定没有 Electron 我是否能做到这一切。它是一款很棒的软件。

在构建 Beaker 时，您遇到过哪些挑战？​

一半的时间是在摆弄工具，弄清楚我可以容忍多少。

制作浏览器本身很容易。Electron 实际上是制作浏览器的工具包。 ...除了浏览器标签页；我花了很长时间才弄对。我最终崩溃并学会了如何制作 SVG。它看起来好多了，但我迭代了 3 或 4 次才弄对。

Electron 在哪些方面应该改进？​

如果我可以将 devtools 停靠在 webview 中，那就太好了。

Beaker 的下一步是什么？​

Dat 站点的安全 DNS 名称。一种可社交配置的 URL 方案，称为 “app scheme”。更多 Dat API。

对于可能有兴趣为该项目做出贡献的人，Beaker 在哪些方面需要帮助？​

我们有很多未解决的问题。不要害怕 ping 我。在 freenode 上 #beakerbrowser。我们保留了一个 贡献者页面，我们会将您添加到其中。如果您来奥斯汀，我会请您喝啤酒。

是否有任何 Electron 技巧可能对其他开发人员有用？​

1. 使用现有的构建工具。相信我，您不想与自己的解决方案搏斗。使用 electron-builder。使用样板仓库。
2. 如果您需要在 Electron 仓库中打开一个 issue，请多走一步，使其易于重现。您会更快地得到回复，并且团队会对此表示感谢。更好的是，尝试自己修复它。看看内部结构实际上非常有趣。
3. 至少通读一遍所有指南和高级文档。
4. 不要构建浏览器，这是一个饱和的市场。

Electron 社区正在快速发展，人们正在以惊人的速度创建强大的新应用程序和工具。为了庆祝这种创造性的势头，并让社区了解其中一些新项目，我们决定开始一个每周博客系列，专门介绍值得关注的 Electron 相关项目。

这篇文章是该系列的第一篇，重点介绍了 Kap，这是一款由 Wulkano 构建的开源屏幕录制应用程序，Wulkano 是一个由自由设计师和开发者组成的地缘分布式团队。

什么是 Kap？​

Kap 是一款开源屏幕录像机，主要为设计师和开发人员构建，以便轻松捕捉他们的工作。人们使用它来分享动画原型、记录错误、创建傻傻的 GIF 以及介于两者之间的一切。

我们已经看到各个年龄段和背景的人们在教育环境、截屏视频、教程中使用它……用途数不胜数。甚至可以用来创建生产资源！我们完全被我们的小型副项目如此受欢迎而震惊。

您为什么构建它？​

这是一个非常好的问题，这并不像缺少屏幕录像机！我们觉得替代方案要么太复杂、要么太昂贵、要么太有限。没有一种感觉恰到好处，适合我们的日常需求。我们还认为，当我们用来工作的工具是开源的时，那就太棒了，这样每个人都可以帮助塑造它们。构建 Kap 最终与我们没有做什么同样重要。一切都在细节中，小改进的积累构成了我们想要使用的工具的轮廓。

然而，也许最重要的是，Kap 已成为我们放下烦恼，只是为了自己和像我们这样的人构建一些有趣的东西的地方。创建一个让您可以发泄、尝试新事物并享受您的手艺的环境非常重要。没有要求，没有压力，没有期望。设计师和开发人员应该做副项目吗？为什么，是的。是的，他们应该这样做。

为什么选择在 Electron 上构建 Kap？​

有很多原因

• Web 技术
• 团队的大多数成员都是 Web 开发人员
• 我们对 JavaScript 进行了投资
• 它为更多人贡献打开了大门
• Electron 本身是开源的
• node_modules 的强大功能和易于维护的模块化
• 跨平台可能性

我们认为应用程序的未来在浏览器中，但我们还没有完全实现。Electron 是朝着那个未来迈出的重要一步。它不仅使应用程序本身更易于访问，而且使其构建所用的代码也更易于访问。一个有趣的想法是想象一下未来，操作系统是一个浏览器，而选项卡本质上是 Electron 应用程序。

此外，作为主要的 Web 开发人员，我们非常喜欢 JavaScript 的同构性质，您可以客户端、服务器和现在的桌面运行 JS。借助 Web 技术（HTML、CSS 和 JS），许多事情都比原生技术简单得多：更快的原型设计、更少的代码、flexbox > auto-layout (macOS/iOS)。

在构建 Kap 时，您遇到过哪些挑战？​

使用 Electron 可用的资源来录制屏幕是最大的挑战。它们的性能根本不足以满足我们的要求，并且在我们看来会使项目失败。虽然这并非 Electron 本身的过错，但在原生开发和使用 Web 技术构建桌面应用程序之间仍然存在差距。

我们花费了大量时间试图解决 getUserMedia API 性能不佳的问题，这个问题源于 Chromium。当我们开始制作 Kap 时，我们的主要目标之一是用 Web 技术构建整个应用程序。在尝试了一切可以使其工作的方法（最低要求是在 Retina 屏幕上达到 30 FPS）之后，我们最终不得不找到另一种解决方案。

我在 repo 中看到一些 Swift 代码。那是关于什么的？​

由于被迫寻找 getUserMedia 的替代方案，我们开始尝试 ffmpeg。除了是音频和视频转换的最佳工具之一外，它还具有在几乎任何操作系统中录制屏幕的功能，并且我们能够录制清晰的视频，满足我们在 Retina 屏幕上达到 30 FPS 的最低要求。问题？性能是“😩”，CPU 使用率变得异常。因此我们回到了绘图板，讨论了我们的选择，并意识到我们必须做出妥协。这导致了 Aperture，我们自己的 macOS 屏幕录制库，用 Swift 编写。

Electron 在哪些方面应该改进？​

我们都知道 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 部分。

您最喜欢 Electron 的哪些方面？​

我们最喜欢的是，任何具有 Web 创建知识的人都可以构建和贡献多平台原生体验。更不用说在其上开发的轻松和乐趣、优秀的文档以及蓬勃发展的生态系统。

从前端角度来看，构建 Kap 感觉与使用浏览器 API 构建一个简单的网站没有什么不同。Electron 在使应用程序开发类似于（基本上相同于）Web 开发方面做得非常出色。实际上非常简单，以至于无需框架或类似工具来帮助我们，只需干净且模块化的 JS 和 CSS 即可。

我们也是构建它的团队、他们的奉献精神和支持，以及他们维护的活跃而友好的社区的忠实粉丝。向大家致以拥抱！

Kap 的下一步是什么？​

我们的下一步是审查应用程序，为我们的 2.0.0 里程碑做准备，其中包括 React 重写以及对插件的支持，允许开发人员扩展 Kap 的功能！我们邀请大家关注该项目并在我们的 GitHub 存储库上贡献。我们正在倾听，并希望尽可能多地听取您的意见，请告诉我们如何使 Kap 成为对您来说最好的工具！

什么是 Wulkano？​

Wulkano 是一家设计工作室和数字集体，是一个由远程技术专家组成的团队，他们喜欢一起处理客户项目和我们自己的项目。我们是一群来自不同地方和背景的分布式但紧密的团队，在我们的虚拟办公室（恰好是基于 Electron 的 Slack！）中分享知识、想法、经验，但最重要的是傻傻的 GIF 和 meme。

是否有任何 Electron 技巧可能对其他开发人员有用？​

充分利用并参与到出色的 社区 中，查看 Awesome Electron，查看 示例 并利用出色的 文档！

我们最近在 GitHub 总部为 Hackbright Academy（旧金山一所为女性创立的编程学校）的成员举办了一次 Electron 黑客马拉松。为了帮助与会者在他们的项目中取得领先，我们自己的 Kevin Sawicki 创建了一些示例 Electron 应用程序。

如果您是 Electron 开发新手或尚未尝试过，这些示例应用程序是一个很好的起点。它们很小，易于阅读，并且代码中包含大量注释，以解释一切是如何工作的。

要开始使用，请克隆此存储库

git clone https://github.com/electron/simple-samples

要运行以下任何应用程序，请更改到应用程序的目录，安装依赖项，然后启动

cd activity-monitor
npm install
npm start

活动监视器​

显示 CPU 系统、用户和空闲活动时间的圆环图。

哈希​

显示使用不同算法输入的文本的哈希值。

镜像​

以最大化尺寸播放电脑摄像头视频，就像照镜子一样。包含一个可选的彩虹滤镜效果，该效果使用 CSS 动画。

价格​

使用 Yahoo Finance API 显示当前石油、黄金和白银的价格。

URL​

在窗口中加载命令行中传递的 URL。

其他资源​

我们希望这些应用程序能帮助您开始使用 Electron。这里还有一些其他资源供您学习更多内容

• electron-quick-start：一个最小化的 Electron 应用程序样板。
• Electron API Demos：一个交互式应用程序，演示了 Electron API 的核心功能
• electronjs.org/docs/all：所有 Electron 文档集中在一个可搜索的页面上。
• hokein/electron-sample-apps：另一个 Electron 示例应用程序集合，由 Electron 维护者 Haojian Wu 编译。
• awesome-electron - 一个 GitHub 仓库，收集了最新最好的 Electron 相关教程、书籍、视频等。

我们在 Electron 网站上添加了一个新的 userland 部分，以帮助用户发现构成我们蓬勃发展的开源生态系统的人员、软件包和应用程序。

Userland 的起源​

Userland 是软件社区中的人们聚集在一起分享工具和想法的地方。这个术语起源于 Unix 社区，在 Unix 社区中它指的是任何在内核之外运行的程序，但今天它的含义更加广泛。当今 Javascript 社区的人们提到 userland 时，他们通常指的是 npm 包注册表。这是大多数实验和创新发生的地方，而 Node 和 JavaScript 语言（就像 Unix 内核一样）保留了一组相对较小且稳定的核心功能。

Node 和 Electron​

像 Node 一样，Electron 拥有一小部分核心 API。这些 API 提供了开发多平台桌面应用程序所需的基本功能。这种设计理念使 Electron 能够保持为一个灵活的工具，而不会对如何使用它进行过多的规定。

Userland 是 “core” 的对应物，使用户能够创建和共享扩展 Electron 功能的工具。

收集数据​

为了更好地了解我们生态系统中的趋势，我们分析了来自 15,000 个公共 GitHub 仓库的元数据，这些仓库依赖于 electron 或 electron-prebuilt

我们使用了 GitHub API、libraries.io API 和 npm 注册表来收集有关依赖项、开发依赖项、被依赖项、包作者、仓库贡献者、下载计数、fork 计数、stargazer 计数等信息。

然后我们使用这些数据生成了以下报告

• 应用程序开发依赖项：Electron 应用程序中最常列为 devDependencies 的软件包。
• GitHub 贡献者：为众多 Electron 相关 GitHub 仓库做出贡献的 GitHub 用户。
• 软件包依赖项：其他 npm 软件包经常依赖的 Electron 相关 npm 软件包。
• Starred Apps：拥有大量 stargazers 的 Electron 应用程序（不是 npm 软件包）。
• 下载次数最多的软件包：下载次数很多的 Electron 相关 npm 软件包。
• 应用程序依赖项：Electron 应用程序中最常列为 dependencies 的软件包。
• 软件包作者：Electron 相关 npm 软件包最多产的作者。

筛选结果​

像 应用程序依赖项 和 starred apps 这样的报告列出了软件包、应用程序和仓库，它们都有一个文本输入框，可用于筛选结果。

当您在此输入框中键入内容时，页面的 URL 会动态更新。这允许您复制代表 userland 数据的特定切片的 URL，然后与他人共享。

更多内容即将推出​

这第一组报告仅仅是个开始。我们将继续收集有关社区如何构建 Electron 的数据，并将向网站添加新的报告。

用于收集和显示此数据的所有工具都是开源的

• electron/electronjs.org：Electron 网站。
• electron/electron-userland-reports：有关 Electron userland 中软件包、仓库和用户的数据切片。
• electron/repos-using-electron：GitHub 上所有依赖于 electron 或 electron-prebuilt 的公共仓库
• electron/electron-npm-packages：所有在其 package.json 文件中提到 electron 的 npm 软件包。

如果您对如何改进这些报告有任何想法，请通过在网站仓库中打开一个 issue 或任何上述仓库告知我们。

感谢您，Electron 社区，使 userland 成为今天的样子！

Electron 1.4.12 包含一个重要的补丁，修复了一个上游 Chrome 问题，该问题导致某些 Symantec、GeoTrust 和 Thawte SSL/TLS 证书从 libchromiumcontent（Electron 的底层 Chrome 库）的构建时间起 10 周后被错误地拒绝。受影响站点上使用的证书没有问题，更换这些证书也无济于事。

在 Electron 1.4.0 — 1.4.11 中，在特定日期之后，对使用这些受影响证书的站点发出的 HTTPS 请求将失败并出现网络错误。这会影响使用 Chrome 底层网络 API（例如 window.fetch、Ajax 请求、Electron 的 net API、BrowserWindow.loadURL、webContents.loadURL、<webview> 标签上的 src 属性等）发出的 HTTPS 请求。

将您的应用程序升级到 1.4.12 将防止这些请求失败发生。

注意： 此问题是在 Chrome 53 中引入的，因此早于 1.4.0 的 Electron 版本不受影响。

影响日期​

下面是一个表格，列出了每个 Electron 1.4 版本以及对使用这些受影响证书的站点的请求开始失败的日期。

您可以通过提前设置计算机时钟，然后检查 https://symbeta.symantec.com/welcome/ 是否成功加载来验证应用程序的影响日期。

更多信息​

您可以在以下位置阅读有关此主题、原始问题和修复的更多信息

• 什么是证书透明度？
• Symantec 知识库文章
• Chrome issue 664177
• Chrome issue 664177 的修复
• libchromiumcontent issue 664177 的补丁