Electron 中的社区计划
查看所有标签
Electron API 的历史更改现在将在文档中详细说明。
您好 👋，我是 Peter，2024 年 Google Summer of Code (GSoC) 的 Electron 贡献者。
在 GSoC 项目期间，我为 Electron 文档及其函数、类等实现了 API 历史记录功能，类似于 Node.js 文档：通过允许在 API 文档 Markdown 文件中使用简单但功能强大的 YAML 模式，并在 Electron 文档网站上很好地显示它。
我们很高兴地宣布，Electron 已被接受为第 20 届 Google Summer of Code (GSoC) 2024 的指导组织！Google Summer of Code 是一个全球性计划，专注于将新的贡献者引入开源软件开发。
有关更多计划详细信息，请查看 Google 的 Summer of Code 首页。
Electron 是一个使用 Web 技术构建跨平台桌面应用程序的 JavaScript 框架。Electron 核心框架是一个使用 Chromium 和 Node.js 构建的编译二进制可执行文件，主要使用 C++ 编写。
除了 Electron 核心之外，我们还致力于各种项目来帮助维持 Electron 组织，例如
作为 Summer of Code 的贡献者，您将与 Electron 的一些核心贡献者合作，参与 github.com/electron 下的众多项目之一。
如果您不太熟悉 Electron，我们建议您首先阅读 文档 并尝试 Electron Fiddle 中的示例。
要详细了解 Electron 应用分发，您还可以通过创建示例应用程序来试用 Electron Forge
npm init electron-app@latest my-app
在稍微熟悉代码后，请加入 Electron Discord 服务器 上的对话。
如果您是第一次参加 Google Summer of Code 或刚接触开源，我们建议您在参与社区之前，先阅读 Google 的 贡献者指南 作为第一步。
有兴趣与 Electron 合作？首先，查看我们准备的 七个项目创意草案。所有列出的创意目前都开放提案。
您是否有其他想让我们考虑的创意？我们也乐于接受未列入项目清单的新创意，但请确保您的方法已充分概述和详细说明。如有疑问，我们建议您坚持使用我们列出的创意。
您的申请应包括
此处提供了有关作为 Electron 申请的一部分提交哪些内容的详细指南。 请直接向 Google Summer of Code 门户网站提交提案。请注意，发送到 Electron 团队而非通过申请门户网站提交的提案将不被视为最终提交。
如果您想获得更多关于提案的指导或不确定要包含哪些内容，我们还建议您遵循 此处 Google Summer of Code 官方的提案撰写建议。
申请时间为 2024 年 3 月 18 日开始，2024 年 4 月 2 日截止。
我们的 2022 年 Google Summer of Code 实习生 @aryanshridhar 做得非常出色！如果您想了解 Aryan 在与 Electron 共度的夏季里做了哪些工作，您可以阅读他在 2022 年 GSoC 项目档案 中的报告。
如果您有任何我们在博客文章中未解决的问题或提案草案的疑问，请发送电子邮件至 [email protected] 或查看 GSoC 常见问题解答！
Electron 的 API 工作组 正在采用开放式的 **意见征集 (RFC)** 流程，以帮助指导 Electron 核心的大型变更。
简而言之，我们希望简化 Electron 核心重大变更的落地流程。
目前，新的代码更改主要通过 GitHub 上的问题和拉取请求进行讨论。对于 Electron 的大多数更改，这是一个良好的系统。许多 bug 修复、文档更改，甚至新功能都足够简单，可以通过标准的 GitHub 流程异步审查和合并。
对于更重大的更改——例如，大型 API 表面或会影响大多数 Electron 应用程序的重大更改——在编写大部分代码之前，在构思阶段进行审查更有意义。
此流程旨在对公众开放，这将使更广泛的开源社区更容易在更改落地到 Electron 之前提供反馈。
整个 RFC 流程都位于 GitHub 上的 electron/rfcs 存储库中。步骤在存储库的 README 中进行了详细描述。
简而言之，一旦向 electron/rfcs 存储库提交了 PR，RFC 就会被 **提议**。提议的 RFC 会变成
main 分支时，这意味着 Electron 维护人员同意在 electron/electron 中进行实现，或者要使 RFC 成为 **活跃** 的，PR 必须获得至少 2 名 API 工作组成员的批准。在合并之前，应由至少三分之二的 WG 成员组成的法定人数同步展示并一致接受 RFC。如果达成共识，将触发为期一个月的最终评论期，之后 PR 将被合并。
如果实现已合并到 electron/electron 中，则活跃的 RFC 则被认为是 **完成** 的。
Electron 社区的任何人都可以提交 RFC 或在 electron/rfcs 存储库中留下反馈！
text 文件夹。我们希望将此流程打造成双向对话，并鼓励社区参与，以从未来可能使用这些 API 的 Electron 应用程序中获得多元化的意见。如果您有兴趣对当前提议的 RFC 发表反馈，Electron 维护人员已经创建了一些
Electron 的 RFC 流程借鉴了许多已建立的开源 RFC 流程。许多想法和主要部分的文案灵感来自
electron/electron 存储库的第一个提交是在 2013 年 3 月 13 日1。
10 年后，来自 1192 位独特贡献者的 27147 次更多提交，Electron 已成为当今最流行的桌面应用程序构建框架之一。这个里程碑是庆祝和回顾我们迄今为止的旅程，以及分享我们一路走来所学到的知识的绝佳机会。
如果没有所有为项目贡献时间和精力的人，我们今天将无法取得这样的成就。尽管源代码提交始终是最明显的贡献，但我们也必须感谢那些报告错误、维护用户空间模块、提供文档和翻译以及在网络空间中参与 Electron 社区的人们。每一个贡献对我们维护人员来说都非常宝贵。
在我们继续本文的其他部分之前：谢谢。❤️
**Atom Shell** 是作为 GitHub 的 Atom 编辑器 的基础构建的，该编辑器于 2014 年 4 月公开发布测试版。它是从头开始构建的，作为当时可用的基于 Web 的桌面框架（node-webkit 和 Chromium Embedded Framework）的替代方案。它有一个杀手级功能：嵌入 Node.js 和 Chromium 以为 Web 技术提供强大的桌面运行时。
一年内，Atom Shell 的功能和受欢迎程度开始大幅增长。大型公司、初创企业和个人开发人员都开始用它构建应用程序（一些早期采用者包括 Slack、GitKraken 和 WebTorrent），并且该项目被恰当地更名为 **Electron**。
从那时起，Electron 就开始飞速发展，并且从未停止。以下是根据 npmtrends.com 提供的数据，我们每周下载次数随时间变化的趋势图。
Electron v1 于 2016 年发布，承诺提高 API 稳定性并改善文档和工具。Electron v2 于 2018 年发布，并引入了语义版本控制，使 Electron 开发人员更容易跟踪发布周期。
到 Electron v6 时，我们转向了与 Chromium 相匹配的 12 周定期主要版本发布周期。这一决定是项目心态的转变，将“拥有最新版本的 Chromium”从锦上添花变成了优先事项。这减少了升级之间的技术债务，使我们更容易保持 Electron 的更新和安全。
从那时起，我们一直像一台精密的机器，在 Chromium 稳定版发布的同一天发布新的 Electron 版本。到 2021 年 Chromium 加快其发布周期至 4 周时，我们能够耸耸肩，相应地将我们的发布周期增加到 8 周。
我们现在处于 Electron v23（并且还在继续），并且仍然致力于构建用于构建跨平台桌面应用程序的最佳运行时。即使近年来 JavaScript 开发人员工具蓬勃发展，Electron 仍然是桌面应用程序框架领域中一个稳定且经过实战检验的中坚力量。Electron 应用程序如今无处不在：您可以使用 Visual Studio Code 进行编程，使用 Figma 进行设计，使用 Slack 进行沟通，以及使用 Notion 记录笔记（以及许多其他用例）。我们对这一成就感到无比自豪，并感谢所有为此做出贡献的人。
通往十年里程碑的道路漫长而曲折。以下是一些帮助我们运营可持续的大型开源项目的关键因素。
我们必须克服的一个挑战是在 Electron 首次流行后处理项目的长期方向。当我们是一个由几十位工程师组成的团队，分布在不同的公司、国家和时区时，我们该如何处理？
在早期，Electron 的维护人员团队依靠非正式的协调，这对于小型项目来说既快速又轻量级，但无法扩展到更广泛的协作。2019 年，我们转向了一个治理模型，其中不同的工作组拥有正式的责任领域。这有助于简化流程并将项目所有权的部分分配给特定的维护人员。如今每个工作组 (WG) 负责什么？
在我们转向治理模型的同时，我们还将 Electron 的所有权从 GitHub 转移到 OpenJS 基金会。虽然最初的核心团队今天仍在微软工作，但他们只是构成 Electron 治理的更大协作者群体的一部分。2
虽然此模型并非完美无缺，但它已帮助我们顺利度过了全球大流行和持续的宏观经济逆风。展望未来，我们计划修改治理章程，以指导我们度过 Electron 的第二个十年。
如果您想了解更多信息，请查看 electron/governance 存储库！
开源的社区部分很难，尤其是在您的外联团队是一个穿着印有“社区经理”字样的风衣的十几位工程师时。也就是说，作为一个大型开源项目意味着我们拥有大量用户，利用他们的能量为 Electron 构建用户空间生态系统是维持项目健康的关键部分。
我们一直在做什么来发展我们的社区影响力？
如今，Electron 治理拥有大约 30 位活跃维护者。其中不到一半是全职贡献者，这意味着有很多工作需要分担。我们如何保持一切顺利运行？我们的座右铭是：电脑便宜，人力时间宝贵。工程师们秉持一贯的作风，开发了一套自动化支持工具来简化我们的工作。
Electron 的核心代码库是一个庞大的 C++ 代码库，构建时间一直是限制我们快速发布 bug 修复和新功能的因素。2020 年，我们部署了 Not Goma，这是一个针对 Google 的 Goma 分布式编译服务的自定义 Electron 后端。Not Goma 处理来自授权用户机器的编译请求，并在后端数百个核心上分配编译过程。它还会缓存编译结果，以便其他人编译相同的文件只需下载预编译的结果。
自 Not Goma 推出以来，维护者的编译时间从数小时缩短到几分钟。稳定的互联网连接成为贡献者编译 Electron 的最低要求！
如果您是开源贡献者，您还可以尝试使用 Not Goma 的只读缓存，该缓存默认情况下可用于 Electron Build Tools。
持续身份验证 (CFA) 是围绕 npm 的双因素身份验证 (2FA) 系统的一层自动化层，我们将其与 semantic-release 结合使用，以管理我们各种 @electron/ npm 包的安全和自动化发布。
虽然 semantic-release 已经自动化了 npm 包发布过程，但它需要关闭双因素身份验证或传入绕过此限制的密钥。
我们构建 CFA 以针对 npm 2FA 为任意 CI 作业提供基于时间的一次性密码 (TOTP)，从而使我们能够利用 semantic-release 的自动化功能，同时保持双因素身份验证的额外安全性。
我们将 CFA 与 Slack 集成前端一起使用，允许维护者从他们拥有 Slack 的任何设备上验证包发布，只要他们手边有 TOTP 生成器即可。
如果您想在自己的项目中尝试 CFA，请查看 GitHub 存储库 或 文档！如果您使用 CircleCI 作为您的 CI 提供商，我们还有一个 方便的 orb 可以快速使用 CFA 架构项目。
Sheriff 是我们编写的用于自动化管理 GitHub、Slack 和 Google Workspace 权限的开源工具。
Sheriff 的核心价值主张是权限管理应该是一个透明的过程。它使用单个 YAML 配置文件来指定所有上述服务的权限。使用 Sheriff，在存储库中获得协作者状态或创建新的邮件列表就像获得 PR 批准和合并一样简单。
Sheriff 还具有一个审计日志，该日志会发布到 Slack，并在 Electron 组织中的任何地方发生可疑活动时警告管理员。
GitHub 是一个具有丰富 API 可扩展性和名为 Probot 的第一方机器人应用程序框架的平台。为了帮助我们专注于工作中更具创意的部分，我们构建了一套较小的机器人来帮助我们完成繁琐的工作。以下是一些示例
总而言之，我们的小型机器人家族极大地提高了开发人员的生产力！
随着我们进入项目的第二个十年，您可能会问：Electron 的下一步是什么？
我们将与 Chromium 的发布节奏保持同步，每 8 周发布 Electron 的新主要版本，使框架与 Web 平台和 Node.js 的最新功能保持更新，同时维护企业级应用程序的稳定性和安全性。
我们通常在即将开展的计划具体化时宣布相关新闻。如果您想了解未来的版本、功能和一般的项目更新，您可以阅读 我们的博客 并关注我们的社交媒体资料（Twitter 和 Mastodon）！
这实际上是 electron-archive/brightray 项目 的第一个提交，该项目在 2017 年被吸收到 Electron 中，并合并了其 Git 历史记录。但谁会在意呢？这是我们的生日，所以我们来制定规则！ ↩
与普遍看法相反，Electron 不再归 GitHub 或 Microsoft 所有，现在是 OpenJS 基金会 的一部分。 ↩
Electron 团队很高兴地宣布，我们今年将首次参加 Google Summer of Code！
Google Summer of Code (GSoC) 是一项年度指导计划，旨在将开源软件项目与潜在贡献者联系起来。以前仅对学生开放，现在 18 岁及以上的人都可以注册 GSoC。
有关更多信息，请查看 Summer of Code 首页。
您有兴趣与 Electron 合作吗？如果您是新的或初学者开源贡献者，我们欢迎您申请！
为了被选中成为 Google Summer of Code 的 Electron 贡献者，您需要提交申请。申请将于 **2022 年 4 月 4 日** 开放，并于 **2022 年 4 月 19 日** 关闭。 您可以在此处关注 Google：Summer of Code 申请指南的更新。
想要申请？首先，查看我们准备的 五个项目创意草案。所有列出的想法目前都对提案开放。我们也乐于接受未在提议的项目列表中的新想法。
您的申请应包括
此处提供了有关作为 Electron 申请的一部分提交哪些内容的详细指南。
您还可以通读 官方 GSoC 学生/贡献者指南，了解有关准备提案的重要提示。
如果您想讨论项目提案或有任何疑问，请加入我们的 #gsoc-general Discord 频道！
加入我们，一起进行社区联谊，并庆祝为期一个月的开源盛会。
Electron 的 外联工作组 很高兴地宣布我们官方社区 Discord 服务器的启动！
在早期，作为 Atom 文本编辑器 的基础，Electron 框架的社区讨论发生在 Atom 的 Slack 工作区中的一个单独频道中。随着时间的推移，这两个项目之间日益脱钩，Atom 工作区与 Electron 项目的相关性下降，维护者在 Slack 频道的参与度也随之减少。
直到现在，我们仍然将更广泛的社区重定向到 Atom Slack 工作区，尽管我们收到了许多用户报告，称他们难以获得邀请，而且我们很少有核心维护者经常访问该频道。
我们正在建立这个闪亮的新服务器，使其成为社区的中心讨论枢纽，您可以在其中获取所有关于 Electron 的最新消息。
到目前为止，服务器的成员包括一些一直在共同设置服务器的维护者，但我们非常高兴能与大家聊天！欢迎来寻求帮助，及时了解 Electron 的最新版本，或只是与其他开发人员一起闲逛。我们有一个方便的 邀请链接 可供您使用，它将让您访问服务器！
作为一项大型且运行时间长的开源项目，如果没有来自社区的所有贡献，Electron 不会取得如此大的成功，从代码提交到错误报告再到文档更改，以及更多。因此，我们相信参与 Hacktoberfest 的重要性，将更广泛的各级开发人员社区引入项目。
今年，我们没有更广泛的项目供大家一起参与，但我们希望专注于为 Electron JavaScript 生态系统做出贡献的机会。
请关注我们各个代码库中标记为 hacktoberfest 的问题，包括主 electron/electron 代码库、electron/electronjs.org 网站、electron/fiddle 和 electron-userland/electron-forge！
附注：如果你觉得很有挑战性，我们还有很多问题用 help wanted 标记，如果你正在寻找更大的挑战。
此外，我们的 Discord 服务器盛大开幕与一年一度的开源软件盛典的举办时间巧合。查看 #hacktoberfest 频道，获取 Hacktoberfest PR 的帮助。如果你错过了，这里再次提供邀请链接！
Electron 很荣幸能够参与 Google 的第二届 Season of Docs 计划，该计划将来自开源组织的导师与技术作家配对，以改进项目文档。
Season of Docs 是一个促进技术作家与开源社区之间合作的项目，对双方都有利。开源维护者利用作者的技术写作专业知识来改进其文档的结构和内容，而技术作家则在导师的指导下接触开源社区。在 Google 的 Season of Docs 网站 上了解更多信息。
在我们首次参与该项目时，我们将指导一位技术作家，他将与 Electron 的 生态系统工作组 合作，重塑我们文档的很大一部分。您可以在 此处 了解整个项目的时程安排。
您是否对与我们合作担任技术作家感兴趣？首先，熟悉 Google 今年项目的 技术作家指南，并查看我们准备好的两个 项目想法草案。
为了被选中担任 Electron 的 Season of Docs 技术作家，候选人需要在 6 月 8 日至 7 月 9 日的技术作家申请阶段通过 Google Season of Docs 网站申请。
您的申请应包括一份提案，该提案是一份书面文件，详细描述您计划在 3 个月内为 Electron 文档实现的目标。该提案可以扩展项目想法文档中提到的其中一个起点，也可以是全新的内容。不知道从哪里开始？您可以查看去年的 已接受提案列表 以获得灵感。
除了提案之外，我们还会关注您的技术写作背景。请附上您的简历副本，重点突出相关的写作经验，以及技术写作样本（这些样本可以是现有的文档、教程、博客文章等）。
如果您想讨论项目提案，请发送电子邮件至 [email protected]，我们将与您进一步沟通！
Electron 正在努力使其发布周期更快、更稳定。为了实现这一目标，我们启动了应用反馈计划，供大型 Electron 应用测试我们的 Beta 版本并向我们报告特定于应用的问题。这有助于我们优先处理将应用程序尽快升级到下一个稳定版本的工作。
编辑 (2020-05-21)：该计划已停止。
我们加入该项目的应用程序的标准和期望包括以下内容
我们理解并非每个人都能分享确切的用户数量，但是更好的数据可以帮助我们确定特定版本的稳定性。我们要求应用承诺测试至少一定数量的用户小时数，目前为整个 Beta 周期内 10,000 小时。
您的应用程序的错误将被跟踪并进入核心 Electron 团队的雷达。您的反馈帮助 Electron 团队了解新的 Beta 版本的表现以及需要完成哪些工作。
不会，您的应用程序的信息不会与公众共享。信息保存在私有的 GitHub 代码库中，只有应用反馈计划成员和 Electron 治理 成员才能查看。所有成员都同意遵守 Electron 的 行为准则。
我们目前正在接受有限数量的报名。如果您有兴趣并且能够满足上述要求，请填写此 表单。
本周，我们采访了基于 Electron 的 GitHub 通知管理工具 Jasper 的开发者。
我是 Ryo Maruyama，一名日本软件开发者。我正在开发 Jasper 和 ESDoc。
Jasper 是一个灵活且强大的 GitHub 问题阅读器。它支持 github.com 和 GitHub Enterprise 上的问题和拉取请求。
当人们在工作或开源活动中使用 GitHub 时，他们往往每天都会收到许多通知。作为订阅通知的一种方式，GitHub 提供了电子邮件和 网页通知。我使用它们几年了，但遇到了以下问题
我花费了大量的时间和精力来解决这些问题，因此我决定为 GitHub 开发一个问题阅读器来有效地解决这些问题，并开始开发 Jasper。
几家使用 GitHub 的公司的开发人员、设计师和管理人员都在使用 Jasper。当然，一些开源开发者也在使用它。GitHub 的一些人也使用它！
配置好 Jasper 后，将出现以下屏幕。从左到右，您可以看到“流列表”、“问题列表”和“问题正文”。
此“流”是 Jasper 的核心功能。例如，如果您想查看“分配给 electron/electron 代码库中 @zeke 的问题”，您可以创建以下流
repo:electron/electron assignee:zeke is:issue
创建流并等待几秒钟后，您可以看到满足条件的问题。
我将介绍可以在流中使用哪些条件。
| 流 | 问题 |
|---|---|
mentions:cat mentions:dog | 提及用户cat或dog的问题 |
author:cat author:dog | 由用户cat或dog创建的问题 |
assignee:cat assignee:dog | 分配给cat或dog的问题 |
commenter:cat commenter:dog | cat或dog评论过的问题 |
involves:cat involves:dog | “涉及”cat或bob的问题 |
team:animal/white-cat team:animal/black-dog | 提及animal/white-cat或animal/black-dog的问题 |
involves表示mention、author、assignee或commenter
| 流 | 问题 |
|---|---|
repo:cat/jump repo:dog/run | cat/jump或dog/run中的问题 |
org:electron user:cat user:dog | electron、cat或dog中的问题 |
org与user相同
| 流 | 问题 |
|---|---|
repo:cat/jump milestone:v1.0.0 milestone:v1.0.1 | 在cat/jump中关联到v1.0.0或v1.0.1的问题 |
repo:cat/jump label:bug label:blocker | 在cat/jump中关联到bug**和**blocker的问题 |
electron OR atomshell | 包含electron或atomshell的问题 |
| 流 | 问题 |
|---|---|
is:pr review:required | 在cat/jump中需要审查的问题 |
is:pr review-requested:cat | 由cat请求审查的问题。但这些问题尚未被审查。 |
is:pr reviewed-by:cat | 由cat审查的问题 |
正如您可能已经注意到的，流可以使用 GitHub 的搜索查询。有关如何使用流和搜索查询的详细信息，请参阅以下网址。
Jasper 还具有未读问题管理、未读评论管理、标记星标、通知更新、问题过滤、键盘快捷键等功能。
Jasper 售价 12 美元。但是，您可以使用免费试用版 30 天。
我喜欢 Electron 的以下方面
这些特性使快速简单的桌面应用程序开发成为可能。太棒了！如果您有任何产品创意，您应该考虑使用 Electron。
我很难理解“流”的概念。最初我考虑使用 GitHub 的通知 API。但是我注意到它不支持某些用例。之后，我考虑使用问题 API和拉取请求 API，以及通知 API。但这从未成为我想要的样子。然后在思考各种方法时，我意识到轮询 GitHub 的搜索 API将提供最大的灵活性。我花了大约一个月的时间进行实验才达到这一点，然后我在两天内用流的概念实现了 Jasper 的原型。
注意：轮询最多每 10 秒限制一次。对于 GitHub API 的限制，这已经足够了。
我计划开发以下功能
关注@jasperappio 以获取更新。
本周，我们与@feross和@dcposch 进行了交流，讨论了 WebTorrent，这是一个基于 Web 的 torrent 客户端，它将用户连接在一起，形成一个分布式、去中心化的浏览器到浏览器的网络。
WebTorrent 是第一个在浏览器中运行的 torrent 客户端。它完全用 JavaScript 编写，可以使用 WebRTC 进行对等传输。无需浏览器插件、扩展程序或安装。
使用开放的 Web 标准，WebTorrent 将网站用户连接在一起，形成一个分布式、去中心化的浏览器到浏览器的网络，以实现高效的文件传输。
您可以在此处查看 WebTorrent 的演示：webtorrent.io。
想象一个像 YouTube 这样的视频网站，但访问者可以帮助托管该网站的内容。使用 WebTorrent 供电的网站的用户越多，它就越快、越有弹性。
浏览器到浏览器的通信消除了中间人，让人们能够根据自己的条件进行通信。不再有客户端/服务器——只是一个对等网络，所有节点都是平等的。WebTorrent 是重新去中心化 Web 之旅的第一步。
大约一年前，我们决定构建WebTorrent Desktop，这是一个作为桌面应用程序运行的 WebTorrent 版本。
我们创建 WebTorrent Desktop 有三个原因
首先，关于 WebTorrent 设计的一些背景信息。
在早期，BitTorrent 使用 TCP 作为其传输协议。后来，uTP 出现了，它承诺提供比 TCP 更好的性能和额外优势。每个主流 torrent 客户端最终都采用了 uTP，如今您可以通过任一协议使用 BitTorrent。WebRTC 协议是下一个合乎逻辑的步骤。它带来了与 Web 浏览器互操作性的承诺——一个由所有桌面 BitTorrent 客户端和数百万个 Web 浏览器组成的庞大 P2P 网络。
“Web 对等节点”（在 Web 浏览器中运行的 torrent 对等节点）通过添加数百万个新对等节点并将其扩展到数十个新的用例，使 BitTorrent 网络更加强大。WebTorrent 尽可能地遵循 BitTorrent 规范，以便现有的 BitTorrent 客户端可以轻松地添加对 WebTorrent 的支持。
一些 torrent 应用程序（如Vuze）已经支持 Web 对等节点，但我们不想等待其他应用程序添加支持。**所以基本上，WebTorrent Desktop 是我们加速 WebTorrent 协议采用的方式。**通过制作一个人们真正想使用的很棒的 torrent 应用程序，我们增加了网络中可以与 Web 对等节点（即网站上的用户）共享 torrent 的对等节点数量。
WebTorrent 最令人兴奋的用途之一是同行协助交付。像维基百科和互联网档案这样的非营利项目可以通过让访问者参与进来来降低带宽和托管成本。热门内容可以通过浏览器到浏览器快速廉价地提供。很少访问的内容可以通过 HTTP 从源服务器可靠地提供。
互联网档案实际上已经更新了他们的 torrent 文件，因此它们可以与 WebTorrent 完美配合。因此，如果您想在您的网站上嵌入互联网档案内容，您可以通过一种减少档案托管成本的方式来实现，从而让他们可以投入更多资金来实际存档 Web！
还有令人兴奋的商业用例，从 CDN 到通过 P2P 提供应用程序。
毫无疑问，使用 WebTorrent 构建的最酷的东西可能是盖亚 3D 星图。这是一个光滑的 3D 交互式模拟银河系。数据直接从 torrent 加载到您的浏览器中。在我们的星系中飞行并意识到我们人类与宇宙的浩瀚相比是多么渺小，这令人惊叹。
您可以在Torrenting The Galaxy中阅读有关它是如何制作的，作者 Charlie Hoey 在这篇文章中解释了他是如何使用 WebGL 和 WebTorrent 构建星图的。
我们也是Brave的忠实粉丝。Brave 是一款浏览器，它会自动阻止广告和跟踪器，使 Web 运行更快、更安全。Brave 最近添加了 torrent 支持，因此您可以查看传统 torrent 而无需使用单独的应用程序。此功能由 WebTorrent 提供支持。
就像大多数浏览器可以渲染 PDF 文件一样，Brave 也可以渲染磁力链接和种子文件。它们只是浏览器原生支持的另一种内容类型。
Brave 的联合创始人之一实际上是 Brendan Eich，他是 JavaScript 的创造者，我们用它编写了 WebTorrent，所以我们认为 Brave 选择集成 WebTorrent 非常酷。
有一个说法认为 Electron 应用“臃肿”，因为它们在每个应用中都包含了完整的 Chrome 内容模块。在某些情况下，这部分属实（Electron 应用安装程序通常约为 40MB，而特定于操作系统的应用安装程序通常约为 20MB）。
但是，对于 WebTorrent Desktop，我们在正常运行过程中使用了几乎所有 Electron 功能以及数十种 Chrome 功能。如果我们想为每个平台从头实现这些功能，那么构建应用将需要花费更长的时间（几个月甚至几年），或者我们只能为单个平台发布。
举个例子，我们使用了 Electron 的Dock 集成（显示下载进度）、菜单栏集成（在后台运行）、协议处理程序注册（打开磁力链接）、电源节电阻止程序（在视频播放期间防止休眠）以及自动更新程序。至于 Chrome 功能，我们也使用了大量功能：<video> 标签（播放多种不同的视频格式）、<track> 标签（支持隐藏式字幕）、拖放支持和 WebRTC（在原生应用中使用起来并非易事）。
更不用说：我们的种子引擎是用 JavaScript 编写的，并假设存在许多 Node API，尤其是用于 TCP 和 UDP 套接字支持的require('net') 和require('dgram')。
基本上，Electron 正是我们所需要的，它拥有我们快速发布一个稳定、完善的应用所需的功能集。
WebTorrent 库作为开源的副项目已经开发了两年。我们用四个星期开发了 WebTorrent Desktop。Electron 是我们能够如此快速地构建和发布应用的主要原因。
就像 Node.js 让一代使用 jQuery 的前端程序员能够轻松地进行服务器编程一样，Electron 使任何熟悉 Web 或 Node.js 开发的人都能轻松地进行原生应用开发。Electron 非常强大。
是的，webtorrent npm 包可以在 Node.js、浏览器和 Electron 中运行。完全相同的代码可以在所有环境中运行——这就是 JavaScript 的魅力所在。它是当今的通用运行时。Java Applet 承诺“一次编写，随处运行”的应用，但由于多种原因，这一愿景从未真正实现。Electron 比任何其他平台都更接近这一理想。
在早期版本的应用中，我们难以使 UI 达到良好的性能。我们将种子引擎放在与绘制主应用窗口相同的渲染器进程中，这会导致在种子引擎出现大量 CPU 活动（例如验证从对等节点接收到的种子片段）时出现速度缓慢。
我们通过将种子引擎移动到第二个不可见的渲染器进程并通过IPC与之通信来解决这个问题。这样，如果该进程短暂地使用了大量 CPU，UI 线程将不受影响。流畅的滚动和动画非常令人满意。
注意：我们必须将种子引擎放在渲染器进程中，而不是“主”进程中，因为我们需要访问 WebRTC（它只在渲染器中可用）。
我们希望看到的是关于如何构建和发布生产就绪型应用的更好文档，尤其是在代码签名和自动更新等棘手主题方面。我们不得不通过深入研究源代码并在 Twitter 上询问来了解最佳实践！
我们认为当前版本的 WebTorrent Desktop 非常出色，但总有改进的空间。我们目前正在努力改进外观、性能、字幕支持和视频编解码器支持。
如果你有兴趣参与项目，请查看我们的 GitHub 页面！
Feross，WebTorrent Desktop 的贡献者之一，最近在 NodeConf Argentina 上发表了题为“真实世界的 Electron：使用 JavaScript 构建跨平台桌面应用”的演讲，其中包含了发布完善的 Electron 应用的有用技巧。如果你已经拥有一个基本可用的应用，并且正在尝试将其提升到更高的水平，那么这个演讲尤其有用。
观看地址:
DC，另一位 WebTorrent 贡献者，写了一篇关于如何使你的 Electron 应用更美观的清单。它包含代码示例，涵盖了 macOS Dock 集成、拖放、桌面通知以及确保你的应用快速加载等内容。