本周的精选项目是 Dat，一个用于分发数据集的开源分布式 拨款资助的 工具。 Dat 由一个分布在世界各地的的团队编写和运营，团队中的许多人帮助撰写了这篇文章。

首先，什么是 Dat？​

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

另一种想法是 Dropbox 或 BitTorrent Sync 等同步和上传软件，但 Dat 是 开源的。 我们的目标是成为一个强大的、开源的、非营利的数据共享软件，用于不同大小的数据。

要使用 dat CLI 工具，你需要输入：

dat share path/to/my/folder

然后 Dat 会创建一个可以用来将该文件夹发送给他人的链接 —— 没有中央服务器或第三方可以访问您的数据。 与 BitTorrent不同的是，他人也不可能嗅探到谁在分享什么(查看 Dat 白皮书了解更多详情)。

现在我们知道什么是Dat。 Dat 桌面如何适应？​

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

你能分享一些很酷的使用案例吗？​

DataRefuge 和 Svalbard 项目​

我们正致力于一个代号为 Svalbard 的与 DataRefuge 有关的项目， 一个致力于备份有消失危险的政府气候数据的小组。 Svalbard 以北极的斯瓦尔巴全球种子库命名，该库有一个位于地下的植物DNA大型备份库。 我们的版本是一个大型的有版本控制的公共科学数据集。 一旦我们知道并可以信任元数据，我们就可以建立其他很酷的项目，例如 分布式志愿数据存储网络。

加利福尼亚公民数据联盟​

CACivicData 是一个开源的存档，每天从加利福尼亚的CAL-ACCESS数据库中下载，追踪政治活动中的资金。 他们进行 每日发布，这意味着在他们的 zip 文件中储存大量重复的数据。 我们正在将他们的数据托管为一个 Dat 存储库，减少检索特定版本或更新到更新的版本所需的带宽和复杂度。

Electron 更新​

虽然还没有明确是否实现，但我们认为一个有趣的使用案例是把编译后的 Electron 应用程序放入一个 Dat 储存库，然后使用 Electron 内的 Dat 客户端下载已完成编译的应用程序的最新更新变化文件，以节省下载时间并同时减少服务器的带宽成本。

谁应该使用 Dat Desktop？​

任何想要通过 P2P 网络分享和更新数据的人。 包括数据科学家、开放数据黑客、研究人员、开发人员。 如果任何人都有我们尚未想到的很酷的使用情况，我们完全愿意接受反馈。 你可以进入我们的Gitter 聊天并问我们任何事情！

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

用户账户和元数据的发布。 我们正在开发一个 Dat 注册表网络应用，部署在 datproject.org，基本上将成为数据集中的 “npm”， 但应注意的是，我们只是一个元数据目录，而数据可以在任何线上服务存放（而不是像 npm 或像 GitHub 因为源代码太小而可以在一个系统中存放全部而选择在中央服务器上存放数据）。 由于许多数据集是巨大的，我们需要一个联合注册表（类似于BitTorrent 追踪器的工作原理）。 我们想让人们更容易从Dat Desktop找到或发布注册表中的数据集， 尽可能减少数据共享进程中的阻碍。

另一个功能是多作者/协作文件夹。 我们有开展协作工作流的大计划，或许包括围绕数据集协作设计的类 git 式的分支管理。 当然，我们目前仍在为提升总体稳定度和使我们的协议标准化而工作！

为何选择在 Electron 上构建 Dat 桌面？​

Dat是使用Node.js建造的，所以它对我们的集成来说是十分自然和合适的。 除此之外，我们的用户使用各种机器，因为科学家， 研究人员和政府官员可能被迫为其机构使用某些设置——这意味着我们需要能够服务 Windows 和 Linux 以及 Mac。 Dat Desktop 让我们很容易做到这一点。

建造 Dat 和 Dat Desktop 时你面临什么挑战？​

搞清楚人们想要什么。 We started with tabular datasets, but we realized that it was a bit of a complicated problem to solve and that most people don't use databases. So half way through the project, we redesigned everything from scratch to use a filesystem and haven't looked back.

We also ran into some general Electron infrastructure problems, including:

• Telemetry - how to capture anonymous usage statistics
• Updates - It's kind of piecemeal and magic to set up automatic updates
• Releases - XCode signing, building releases on Travis, doing beta builds, all were challenges.

We also use Browserify and some cool Browserify Transforms on the 'front end' code in Dat Desktop (which is kind of weird because we still bundle even though we have native require -- but it's because we want the Transforms). To better help manage our CSS we switched from Sass to using sheetify. It's greatly helped us modularize our CSS and made it easier to move our UI to a component oriented architecture with shared dependencies. For example dat-colors contains all of our colors and is shared between all our projects.

We've always been a big fan of standards and minimal abstractions. Our whole interface is built using regular DOM nodes with just a few helper libraries. We've started to move some of these components into base-elements, a library of low-level reusable components. As with most of our technology we keep iterating on it until we get it right, but as a team we have a feeling we're heading in the right direction here.

应在哪些领域改进Electron？​

We think the biggest pain point is native modules. Having to rebuild your modules for Electron with npm adds complexity to the workflow. Our team developed a module called prebuild which handles pre-built binaries, which worked well for Node, but Electron workflows still required a custom step after installing, usually npm run rebuild. It was annoying. To address this we recently switched to a strategy where we bundle all compiled binary versions of all platforms inside the npm tarball. This means tarballs get larger (though this can be optimized with .so files - shared libraries), this approach avoids having to run post-install scripts and also avoids the npm run rebuild pattern completely. It means npm install does the right thing for Electron the first time.

What are your favorite things about Electron?​

它的API似乎相当深思熟虑，它相对稳定。而且它在做到实时跟进上游 Node 发布的最新版本这方面做得不错，我们也没别的要求了！

Any Electron tips that might be useful to other developers?​

If you use native modules, give prebuild a shot!

关注 Dat 开发的最佳途径是什么？​

在 Twitter 上关注 @dat_project 或者 订阅我们的 电子邮箱。

This week we chatted with Felix Rieseberg, desktop engineer at Slack and maintainer of Ghost Desktop, an Electron client for the Ghost publishing platform.

What is Ghost?​

Ghost is a fully open source, hackable platform for building and running a modern online publication. We power blogs, magazines and journalists from Zappos to Sky News.

What makes it different from other publishing platforms?​

Ghost was founded in April 2013, after a very successful Kickstarter campaign to create a new platform focused solely on professional publishing. Our mission is to create the best open source tools for independent journalists and writers across the world, and have a real impact on the future of online media. It offers a simpler, more focussed experience: Our editor is designed solely around providing the best possible writing experience.

Compared to the all-time classic WordPress, it offers a simpler, more streamlined experience - it is easier to setup and maintain, comes with all important features out-of-the-box, and is dramatically faster. Compared to other online platforms, Ghost gives writers full ownership and control over their content, allows full customization, and enables authors to build a business around their publication.

Is Ghost a for-profit company?​

This one is important to us: Ghost is an independent non-profit organisation. We build publishing tools for modern journalism & blogging because we believe freedom of speech is important. Our software is released under a free open source license, our business model is completely transparent, and our legal structure means that 100% of the money we make is reinvested into making Ghost better.

What is Ghost Desktop?​

Ghost Desktop allows writers to manage multiple blogs at once - and to focus on their writing. 像常见的写作快捷方式这样的简单东西无法在浏览器中实现，但我们的桌面应用程序中可以使用。 它允许其他应用程序通过 deeplinks 与博客直接联系

What is Ghost for Journalism?​

This year we're very excited to be dedicating our entire 10 person full-time Ghost team to helping grow three independent publications, along with $45,000 in resources toward their efforts. We're calling it Ghost for Journalism.

We've been building Ghost as the web's next great platform for independent publishers for about three and half years now, and we've now reached a really interesting inflection point. We started this journey to create a simple, well designed blogging platform which could be used by just about anyone. That was always going to be step one.

Long term, we want Ghost to be an incredible platform for the world's best journalism, and that means we need to build features to attract exactly those people. This year we're making a very conscious decision to focus on just that.

Why did you choose to build Ghost Desktop on Electron?​

Ghost uses JavaScript and Node.js on both the backend and frontend, so being able to utilize the same technology and skillset enables our team to move faster, build more, and ultimately deliver a better experience. In addition, being able to share more than 95% of code between the macOS, Windows, and Linux version of the app allows us to focus on building a great core user experience, without having to maintain one code base for each platform.

What are some challenges you've faced while building Ghost Desktop?​

Spellchecking is likely still one of the most difficult services offered - we could easily utilize one of the many online services, but correctly spellchecking text in multiple languages while guarding the privacy and autonomy of our users is not an easy task.

应在哪些领域改进Electron？​

We would love to see Electron bring the operating system's native spellchecking capabilities to their apps. We're dreaming about a world in which an <input> field receives the same services as a NSTextView, but we are also intimately aware how difficult that is.

What are your favorite things about Electron?​

JavaScript is famous for being a vast ecosystem, involving countless tools and frameworks - but the convenience it affords us is hard to overstate. Building an app with Electron is only slightly harder than building a web app, which is an amazing feat.

Is Ghost done? If not, what's coming next?​

Ghost Desktop is also an ongoing project - we're pretty far from being done. We have been talking for a while about bringing a full offline mode to our users, and we're getting fairly close. Other notable work areas are the extension and integration with other text editing apps (like Word or Atom), ultimately allowing people to write posts using their favorite tools. In general, once we've shipped the offline mode feature, we're looking for deeper integration with the operating system. If that sounds interesting to you, join us!

What are some of your favorite Electron apps?​

I'm a big fan of Kap, Felony, and Visual Studio Code.

👻

本周我们约见了Paul Frazee，Beaker浏览器的创始人 。 Beaker是一个实验性的，在客户端使用Dat协议托管网站的对等网络浏览器。

Beaker是什么以及创造它的理由？​

Beaker是一个参与式浏览器。 它是为独立骇客们打造的浏览器。

互联网是一个封闭的信息源。 如果你想对社交媒体的运转方式施加影响的话，你必须要在Facebook或Twitter里工作。 对搜索引擎巨头Google来说， 控制权掌握在公司而不是用户自己手中。

通过Beaker，我们有了一个新的Web协议： Decentralized Archive Transport。 "Dat"协议 免费创建站点，然后从设备中共享它们， 无需服务器。 这就是我们的革新之处。

当你用Beaker访问一个Dat站点时，你会下载该站点的文件。 这个站点会永远是你的。 你可以保存它，复刻它，修改它，并自由地分享你的新版本。 这些都是开源的。

所以这是我们的目的：我们正在打造一个支持开放式网站的浏览器。 我们希望它成为社交骇客的一个工具。

谁会使用Beaker？​

骇客们。 改装者。 创意者们。 喜欢折腾的人。

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

我们有个类似于git加npm的 命令行工具bkr 以下是如何创建一个站点：

$ bkr fork dat://0ff7d4c7644d0aa19914247dc5dbf502d6a02ea89a5145e7b178d57db00504cd/ ~/my-fork
$ cd ~/my-fork
echo "我的叉不考虑上一个索引。 tml!" > index.html
$ bkr 发布

以下是如何复刻一个站点：

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

这些网站随后用你的浏览器进行托管。 这有点像BitTorren；你在一个P2P网格中分享网站。

如果你想要一个用户界面，我们在浏览器中内置了一些基础工具，但我们正在将这些工具推送到用户手中。 这些以后都将成为可更改的用户应用程序。

为何选择使用Electron来构建Beaker？​

对这个项目来说是显而易见的。 如果我独自复刻了Chrome，我这会儿就应该在写C++了！ 没人想要那么做。 我了解整个Web技术栈，并且我可以很快速地用它来工作。 这是个不用多想就能做出的选择。

事实是，我不太确定在没有Electron的情况下我能做这件事。 这是一个伟大的软件。

在构建Beaker的过程中遇到过哪些难题？​

其中一半都是在捣鼓工具，我能解决的都尽量解决了。

构建一个浏览器是非常容易的。 Electron基本上就是个构建浏览器的工具包。 ...除了浏览器的页签；这花了我很长时间才改正过来。 我最终奔溃了，并且学会了如何创建SVG。 这看起来好多了，但花了我3，4次迭代才弄好。

应在哪些领域改进Electron？​

如果我可以将devtools停靠在一个webview中，那真是太好了。

Beaker的后续进展？​

用于Dat站点的安全DNS域名。 一个名为"app scheme."的公共配置化URL方案。更多Dat的API。

对于那些可能有兴趣为本项目作出贡献的人们来说，Beaker在哪些方面需要帮助？​

我们有很多未解决的问题。 不要害怕联系我。 在freenode的#beakerbrowser频道上。 我们为贡献者保留了一个页面，同时我们将会把你添加进来。 并且如果你访问奥斯汀，我会为你买一杯啤酒。

Any Electron tips that might be useful to other developers?​

1. 使用现成的构建工具。 相信我，你不会想纠结于你自身的解决方案中。 使用electron-builder。 使用样板仓库。
2. 如果你需要在Electron仓库中创建一个issue，请花些功夫使其易于复现。 你将会更快地得到响应，团队也会对此表示感谢。 如果你能试着自己去修复它，那是更好的。 事实上，看到问题的核心是非常有意思的一件事。
3. 至少阅读一次所有的指南和进阶文档。
4. 不要构造浏览器，这是一个已经饱和的市场。

The Electron community is growing quickly, and people are creating powerful new apps and tools at an astounding rate. To celebrate this creative momentum and keep the community informed of some of these new projects, we've decided to start a weekly blog series featuring noteworthy Electron-related projects.

This post is the first in the series, and features Kap, an open-source screen recording app built by Wulkano, a geodistributed team of freelance designers and developers.

What is Kap?​

Kap is an open-source screen recorder built primarily for designers and developers to easily capture their work. People use it to share animated prototypes, document bugs, create silly GIFs and everything in-between.

我们已经看到不同年龄和背景的人在教育设置、屏幕、教程中使用它... 这个清单还在继续。 Even to create production assets! We're completely blown away by how well received our little side project has been.

Why did you build it?​

That's a very good question, it's not like there's a lack of screen recorders out there! We felt the alternatives were either too complex, too expensive or too limited. Nothing felt just right for our everyday needs. We also think it's great when the tools we use to do our work are open-source, that way everyone can help shape them. Building Kap ended up being just as much about what we didn't do. It's all in the details, an accumulation of small improvements that became the outline of a tool we wanted to use.

However, and maybe most importantly, Kap has become a place for us to leave our worries at the door and just have fun building something for ourselves and people like us. It's so important to create an environment where you get to just vent, try new thins and enjoy your craft. No requirements, no pressure, no expectations. Should designers and developers side project? Why, yes. Yes, they should.

Why did you choose to build Kap on Electron?​

There were a number of reasons:

• Web tech
• Most of the team are web developers
• We're invested in JavaScript
• It opens the door for more people to contribute
• Electron itself is open-source
• The power and easily maintainable modularity of node_modules
• Cross-platform possibilities

We think the future of apps are in the browser, but we're not quite there yet. Electron is an important step in the journey towards that future. It not only makes the apps themselves more accessible, but also the code they're built with. An interesting thought is imagining a future where the OS is a browser, and the tabs are essentially Electron apps.

Additionally, being primarily web developers, we're big fans of the isomorphic nature of JavaScript, in that you can run JS on the client, server, and now the desktop. With web tech (HTML, CSS and JS), many things are much simpler than native: Faster prototyping, less code, flexbox > auto-layout (macOS/iOS).

What are some challenges you've faced while building Kap?​

Using the resources Electron has available to record the screen was the biggest challenge. They simply weren't performant enough to meet our requirements and would render the project a failure in our eyes. Though at no fault of Electron itself, there's still a gap between native development and building desktop apps with web tech.

We spent a lot of time trying to work around the poor performance of the getUserMedia API, an issue originating in Chromium. One of our main goals when we set out to make Kap was to build the entire app with web tech. After trying everything we could to get it working (the minimum requirement being 30 FPS on a Retina screen), we eventually had to find another solution.

I see some Swift code in the repo. What's that about?​

Being forced to look for alternatives to getUserMedia, we started experimenting with ffmpeg. Besides being one of the best tools for audio and video conversion it has the functionality of recording the screen in almost any OS, and we were able to record crispy video meeting our minimum requirement of 30 FPS on a Retina screen. 问题? The performance was "😩", the CPU usage was going haywire. So we went back to the drawing board, discussed our options and realised that we had to make a compromise. That resulted in Aperture, our own screen recording library for macOS written in Swift.

应在哪些领域改进Electron？​

We all know that Electron apps can have a thing for using RAM, but again, that's really a Chromium thing. It's part of how it works and it really depends on what you're running, for example Kap and Hyper typically use less than 100MB of memory.

One of the biggest areas of improvement that we see is payload, particularly how Electron distributes Chromium. One idea would be to have a shared Electron core and make app installers check if it's already present on the system.

Creating cross-platform Electron apps could be a better experience. Right now there are too many inconsistencies, platform-specific APIs, and missing features between platforms, making your codebase littered with if-else statements. For example, vibrancy is only supported on macOS, the auto-updater works differently on macOS and Windows, and is not even supported on Linux. Transparency is a hit or miss on Linux, usually miss.

It should also be easier to call native system APIs. Electron comes with a very good set of APIs, but sometimes you need functionality it doesn't provide. Creating a native Node.js addon is an option, but it's painful to work with. Ideally Electron would ship with a good FFI API, like fastcall. This would have enabled us to write the Swift part in JavaScript instead.

What are your favorite things about Electron?​

Our favorite thing is easily the fact that anyone with knowledge of creating for the web can build and contribute to multi-platform native experiences. Not to mention the ease and joy of developing on it, the excellent documentation and the thriving ecosystem.

From a front-end perspective, building Kap felt no different than building a simple website using browser APIs. Electron does a really great job of making app development similar (basically identical) to web development. So simple in fact that there was no need for frameworks or similar to help us, just clean and modular JS and CSS.

We are also huge fans of the team building it, their dedication and support, and the active and friendly community they maintain. Hugs to all of you!

What's coming next in Kap?​

The next step for us is to review the app in preparation for our 2.0.0 milestone, which includes a React re-write in addition to support for plugins, allowing developers to extend the functionality of Kap! We invite everyone to follow to project and contribute on our GitHub repository. We're listening and want to hear from as many of you as possible, let us know how we can make Kap the best possible tool it can be for you!

What is Wulkano?​

Wulkano is a design studio and digital collective, a team of remote technologists who love working together on both client gigs and our own projects. We're a distributed but tight knit group of people from different places and backgrounds, sharing knowledge, ideas, experiences, but most importantly silly GIFs and memes, in our virtual office (which happens to be the Electron based Slack!).

Any Electron tips that might be useful to other developers?​

Take advantage of and get involved in the fantastic community, check out Awesome Electron, look at examples and make use of the great docs!

We recently hosted an Electron hackathon at GitHub HQ for members of Hackbright Academy, a coding school for women founded in San Francisco. To help attendees get a head start on their projects, our own Kevin Sawicki created a few sample Electron applications.

If you're new to Electron development or haven't yet tried it out, these sample applications are a great place to start. They are small, easy to read, and the code is heavily commented to explain how everything works.

To get started, clone this repository:

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

To run any of the apps below, change into the app's directory, install dependencies, then start:

cd activity-monitor
npm install
npm start

Activity Monitor​

Shows a doughnut chart of the CPU system, user, and idle activity time.

哈希​

Shows the hash values of entered text using different algorithms.

镜像​

Plays a video of the computer's camera at a maximized size like looking into a mirror. Includes an optional rainbow filter effect that uses CSS animations.

Prices​

Shows the current price of oil, gold, and silver using the Yahoo Finance API.

URL​

Loads a URL passed on the command line in a window.

Other Resources​

We hope these apps help you get started using Electron. Here are a handful other resources for learning more:

• electron-quick-start: A minimal Electron application boilerplate.
• Electron API Demos: An interactive app that demonstrates the core features of the Electron API
• electronjs.org/docs/all: All of the Electron documentation together on a single searchable page.
• hokein/electron-sample-apps: Another collection of sample applications for Electron, compiled by Electron maintainer Haojian Wu.
• awesome-electron - A GitHub repository that collects the latest and greatest Electron-related tutorials, books, videos, etc.

We've added a new userland section to the Electron website to help users discover the people, packages, and apps that make up our flourishing open-source ecosystem.

Origins of Userland​

Userland is where people in software communities come together to share tools and ideas. The term originated in the Unix community, where it referred to any program that ran outside of the kernel, but today it means something more. When people in today's Javascript community refer to userland, they're usually talking about the npm package registry. This is where the majority of experimentation and innovation happens, while Node and the JavaScript language (like the Unix kernel) retain a relatively small and stable set of core features.

Node and Electron​

Like Node, Electron has a small set of core APIs. These provide the basic features needed for developing multi-platform desktop applications. 这个设计理念让 Electron 能够保持灵活而不被过多的规定有关于如何应该被使用。

Userland is the counterpart to "core", enabling users to create and share tools that extend Electron's functionality.

Collecting data​

To better understand the trends in our ecosystem, we analyzed metadata from 15,000 public GitHub repositories that depend on electron or electron-prebuilt

We used the GitHub API, the libraries.io API, and the npm registry to gather info about dependencies, development dependencies, dependents, package authors, repo contributors, download counts, fork counts, stargazer counts, etc.

We then used this data to generate the following reports:

• App Development Dependencies: Packages most often listed as devDependencies in Electron apps.
• GitHub Contributors: GitHub users who have contributed to numerous Electron-related GitHub repositories.
• Package Dependencies: Electron-related npm packages that are frequently depended on by other npm packages.
• Starred Apps: Electron apps (that are not npm packages) with numerous stargazers.
• Most Downloaded Packages: Electron-related npm packages that are downloaded a lot.
• App Dependencies: Packages most often listed as dependencies in Electron apps.
• Package Authors: The most prolific authors of Electron-related npm packages.

Filtering Results​

Reports like app dependencies and starred apps which list packages, apps, and repos have a text input that can be used to filter the results.

As you type into this input, the URL of the page is updated dynamically. This allows you to copy a URL representing a particular slice of userland data, then share it with others.

More to come​

This first set of reports is just the beginning. We will continue to collect data about how the community is building Electron, and will be adding new reports to the website.

All of the tools used to collect and display this data are open-source:

• electron/electronjs.org: The Electron website.
• electron/electron-userland-reports: Slices of data about packages, repos, and users in Electron userland.
• electron/repos-using-electron: All public repositories on GitHub that depend on electron or electron-prebuilt
• electron/electron-npm-packages: All npm packages that mention electron in their package.json file.

If you have ideas about how to improve these reports, please let us know opening an issue on the website repository or any of the above-mentioned repos.

Thanks to you, the Electron community, for making userland what it is today!

Electron 1.4. 2 包含一个重要的补丁，修复了一些Smantec、GeoTrust的上游Chrome 问题。 和 Thawte SSL/TLS 证书 被错误地拒绝了从 libchromiumcontent生成时间起10周内的 Chrome 库 Electron。 在受影响的网站上使用的 证书没有问题，替换这些证书并不会做什么。

在 Electron 1.4.0 — 1.4.11 对使用这些受影响的 证书的站点的HTTPS 请求将在某个日期之后由于网络错误而失败。 This affects HTTPS requests made using Chrome's underlying networking APIs such as window.fetch, Ajax requests, Electron's net API, BrowserWindow.loadURL, webContents.loadURL, the src attribute on a <webview> tag, and others.

将你的应用程序升级到1.4.12以防止请求失败。

**注意：**这个版本是在 Chrome 53 版本引入的，所以早入 1.4.0 版本之前的 Electron 版本不受影响。

Impact Dates​

Below is a table of each Electron 1.4 version and the date when requests to sites using these affected certificates will start to fail.

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

更多資料​

您可以在以下链接阅读有关此主题、原始问题以及问题修复的更多信息：

• 什么是证书透明度？
• Symtantec knowledge base article
• Chrome issue 664177
• Chrome fix for issue 664177
• libchromiumcontent patch for issue 664177

Here are the new Electron apps and talks that were added to the site in September.

This site is updated with new apps and meetups through pull requests from the community. 你可以查看库以获取新添加内容的通知，或如果你对_所有_更新不感兴趣，关注博客的RSS订阅。

如果您已经制作了一个 Electron 应用程序或主办了一次会议，提交一个 拉取请求 添加到站点，它将被包括进下一次统计。

New Talks​

In September, GitHub held its GitHub Universe conference billed as the event for people building the future of software. There were a couple of interesting Electron talks at the event.

• Making Electron Development Simpler, More Pleasant, and More Productive by Machisté Quintana, a Software Engineer at Slack.
• Electron: Desktop Apps with Web Languages by Zeke Sikelianos, an Electron Developer at GitHub.

Also, if you happen to be in Paris on December 5, Zeke will be giving an Electron talk at dotJS 2016.

新应用​

	Pexels	Search for completely free photos and copy them into your clipboard
	时间戳	A better macOS menu bar clock with a customizable date/time display and a calendar
	Harmony	Music player compatible with Spotify, Soundcloud, Play Music and your local files
	uPhone	WebRTC Desktop Phone
	SealTalk	Instant-messaging App powered by RongCloud IM Cloud Service and IM SDK
	Infinity	An easy way to make presentation
	Cycligent Git Tool	Straightforward, graphic GUI for your Git projects
	Foco	Stay focused and boost productivity with Foco
	Strawberry	Win Diners for Life Know and serve them better with the all-in-one restaurant software suite.
	Mixmax	See every action on your emails in real-time Compose anywhere.
	Firebase Admin	A Firebase data management tool
	ANote	A Simple Friendly Markdown Note
	Temps	A simple but smart menubar weather app
	Amium	A work collaboration product that brings conversation to your files
	Soube	Simple music player
	(Un)colored	Next generation desktop rich content editor that saves documents with themes HTML & Markdown compatible. For Windows, OS X & Linux.
	quickcalc	Menubar Calculator
	Forestpin Analytics	Financial data analytics tool for businesses
	Ling	REST Client
	Shortexts	Shortcuts for texts you copy frequently, folders and emojis
	Front-End Box	Set of front-end-code generators

今天我们正式宣布对Electron文档的一些改进。 现在，每个新的发布版本都将包括一份对Electron公共API详细描述的JSON文件 我们创建该文件，以此让开发者能够用新潮有趣的方式来访问Electron的API文档。

架构概述​

每个 API 都是一个对象，具有名称、描述、类型等属性。 BrowserWindow 和 Menu 类具有描述其实例方法、实例属性、实例事件等 附加属性。

下面是描述 BrowserWindow 类的架构摘录：

{
  name: 'BrowserWindow',
  description: 'Create and control browser windows.',
  process: {
    main: true,
    renderer: false
  },
  type: 'Class',
  instanceName: 'win',
  slug: 'browser-window',
  websiteUrl: 'https://electronjs.org/docs/api/browser-window',
  repoUrl: 'https://github.com/electron/electron/blob/v1.4.0/docs/api/browser-window.md',
  staticMethods: [...],
  instanceMethods: [...],
  instanceProperties: [...],
  instanceEvents: [...]
}
}

下面是一个方法描述的示例，在本例中为 apis.BrowserWindow.instanceMethods.setMaximumSize 实例方法：

{
  name: 'setMaximumSize',
  signature: '(width, height)',
  description: 'Sets the maximum size of window to width and height.',
  parameters: [{
    name: 'width',
    type: 'Integer'
  }, {
    name: 'height',
    type: 'Integer'
  }]
}

使用新数据​

为了让开发人员能够轻松地在他们的项目中使用这些结构化数据， 我们创建了 electron-docs-api，一个小型 npm包，每当有新的Electron 发布时，它都会自动发布。

npm install electron-api-docs --save

为了及时尝试，请尝试Node.js REPL中的模块：

npm i -g trymodule && trymodule electron-api-docs=apis

如何收集数据​

Electron的API文档遵循 Electron 编码风格 和 Electron 风格指南， 因此其内容可以通过编程方式解析。

electron-docs-linter 是 electron/electron 库的新开发依赖项。 它是一个命令行工具，会校验所有Markdown文件并强制执行styleguid中的规则。 如果发现错误，则会列出这些错误，并暂停发布 过程。 如果 API 文档有效，则会创建 electron-json.api 文件 ，并作为 Electron 版本的一部分上传到 GitHub。

标准 Javascript 和标准 Markdown​

今年早些时候，Electron的代码库进行了更新，以在所有JavaScript中使用 standard 代码纠错工具（linter）。 Standard的 README文件总结了这一选择背后的原因：

采用标准风格意味着代码清晰度和社区约定的重要性比个人风格更高。 也许这对所有项目和发展文化来说是难以理解的，但对新手来说开源可能是一个令人生畏的地方。 设定明确、自动的代码贡献者期望能使一个项目更加健康。

我们最近还创建了[standard-markdown](https://github. com/zeke/standard-markdown) ，以验证文档中所有JavaScript代码片段是否有效且与代码库本身的样式一致。

这些工具一起帮助我们使用连续集成 (CI) 来自动找到 拉取请求（Pull Request）中的错误。 这减轻了人类在代码 审查方面的负担，并使我们对文档的准确性更有信心。

社区的努力​

因我们可敬的开源社区的不懈努力，Electron的文档在不断改进。 在撰写本文时， 近300人为文档做出了贡献。

我们很期待看到人们如何处理这个新的结构化数据。 可能的用途包括：

• 对https://electronjs.org/docs/的改进
• 一个 TypeScript 定义文件 用于简化 使用 TypeScript 进行 Electron 开发的项目。
• 为Dash.app和devdocs.io等工具提供可搜索的离线技术文档

As a language with garbage collection, JavaScript frees users from managing resources manually. But because Electron hosts this environment, it has to be very careful avoiding both memory and resources leaks.

This post introduces the concept of weak references and how they are used to manage resources in Electron.

Weak references​

In JavaScript, whenever you assign an object to a variable, you are adding a reference to the object. As long as there is a reference to the object, it will always be kept in memory. Once all references to the object are gone, i.e. there are no longer variables storing the object, the JavaScript engine will recoup the memory on next garbage collection.

A weak reference is a reference to an object that allows you to get the object without effecting whether it will be garbage collected or not. You will also get notified when the object is garbage collected. It then becomes possible to manage resources with JavaScript.

Using the NativeImage class in Electron as an example, every time you call the nativeImage.create() API, a NativeImage instance is returned and it is storing the image data in C++. Once you are done with the instance and the JavaScript engine (V8) has garbage collected the object, code in C++ will be called to free the image data in memory, so there is no need for users manage this manually.

另一个例子是 窗口消失的问题， 哪些 视觉显示当所有引用都消失时窗口是如何收集垃圾的

Testing weak references in Electron​

There is no way to directly test weak references in raw JavaScript since the language doesn't have a way to assign weak references. The only API in JavaScript related to weak references is WeakMap, but since it only creates weak-reference keys, it is impossible to know when an object has been garbage collected.

In versions of Electron prior to v0.37.8, you can use the internal v8Util.setDestructor API to test weak references, which adds a weak reference to the passed object and calls the callback when the object is garbage collected:

// 下面的代码只能在 Electron < v0.37.8. 上运行。
var v8Util = process.atomBinding('v8_util');

var object = {};
v8Util.setDestructor(object, function () {
  console.log('The object is garbage collected');
});

// Remove all references to the object.
object = undefined;
// Manually starts a GC.
gc();
// Console prints "The object is garbage collected".

Note that you have to start Electron with the --js-flags="--expose_gc" command switch to expose the internal gc function.

The API was removed in later versions because V8 actually does not allow running JavaScript code in the destructor and in later versions doing so would cause random crashes.

Weak references in the remote module​

Apart from managing native resources with C++, Electron also needs weak references to manage JavaScript resources. Electron的 远程 模块就是一个例子。 这是一个 远程程序调用 (RPC) 模块 允许在主进程中使用渲染器进程中的物体。

One key challenge with the remote module is to avoid memory leaks. When users acquire a remote object in the renderer process, the remote module must guarantee the object continues to live in the main process until the references in the renderer process are gone. Additionally, it also has to make sure the object can be garbage collected when there are no longer any reference to it in renderer processes.

For example, without proper implementation, following code would cause memory leaks quickly:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.nativeImage.createEmpty();
}

The resource management in the remote module is simple. Whenever an object is requested, a message is sent to the main process and Electron will store the object in a map and assign an ID for it, then send the ID back to the renderer process. In the renderer process, the remote module will receive the ID and wrap it with a proxy object and when the proxy object is garbage collected, a message will be sent to the main process to free the object.

Using remote.require API as an example, a simplified implementation looks like this:

remote.require = function (name) {
  // Tell the main process to return the metadata of the module.
  const meta = ipcRenderer.sendSync('REQUIRE', name);
  // Create a proxy object.
  const object = metaToValue(meta);
  // Tell the main process to free the object when the proxy object is garbage
  // collected.
  v8Util.setDestructor(object, function () {
    ipcRenderer.send('FREE', meta.id);
  });
  return object;
};

在主进程：

const map = {};
const id = 0;

ipcMain.on('REQUIRE', function (event, name) {
  const object = require(name);
  // Add a reference to the object.
  map[++id] = object;
  // 将对象转换为元数据
  event.returnValue = valueToMeta(id, object);
});

ipcMain.on('FREE', function (event, id) {
  delete map[id];
});

Maps with weak values​

With the previous simple implementation, every call in the remote module will return a new remote object from the main process, and each remote object represents a reference to the object in the main process.

The design itself is fine, but the problem is when there are multiple calls to receive the same object, multiple proxy objects will be created and for complicated objects this can add huge pressure on memory usage and garbage collection.

For example, the following code:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.getCurrentWindow();
}

It first uses a lot of memory creating proxy objects and then occupies the CPU (Central Processing Unit) for garbage collecting them and sending IPC messages.

An obvious optimization is to cache the remote objects: when there is already a remote object with the same ID, the previous remote object will be returned instead of creating a new one.

This is not possible with the API in JavaScript core. 使用普通的Map对象保存对象将会防止被V8垃圾回收机制回收，但是，WeakMap 只能将对象作为弱引用。

To solve this, a map type with values as weak references is added, which is perfect for caching objects with IDs. Now the remote.require looks like this:

const remoteObjectCache = v8Util.createIDWeakMap()

remote.require = function (name) {
  // Tell the main process to return the meta data of the module.
  ...
  if (remoteObjectCache.has(meta.id))
    return remoteObjectCache.get(meta.id)
  // Create a proxy object.
  ...
  remoteObjectCache.set(meta.id, object)
  return object
}

Note that the remoteObjectCache stores objects as weak references, so there is no need to delete the key when the object is garbage collected.

Native code​

For people interested in the C++ code of weak references in Electron, it can be found in following files:

The setDestructor API:

• object_life_monitor.cc
• object_life_monitor.h

The createIDWeakMap API:

• key_weak_map.h
• atom_api_key_weak_map.h