The Electron team is excited to announce the release of Electron 18.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release and please share any feedback you have!

Notable Changes​

Electron Release Cadence Change​

As of Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes​

• Chromium 100
  • New in Chrome 100
• Node.js 16.13.2
  • Node 16.13.2 blog post
• V8 10.0

Highlighted Features​

• Added ses.setCodeCachePath() API for setting code cache directory. #33286
• Removed the old BrowserWindowProxy-based implementation of window.open. This also removes the nativeWindowOpen option from webPreferences. #29405
• Added 'focus' and 'blur' events to WebContents. #25873
• Added Substitutions menu roles on macOS: showSubstitutions, toggleSmartQuotes, toggleSmartDashes, toggleTextReplacement. #32024
• Added first-instance-ack event to the app.requestSingleInstanceLock() flow, so that users can pass some data back from the second instance to the first instance. #31460
• Added support for more color formats in setBackgroundColor. #33364

See the 18.0.0 release notes for a full list of new features and changes.

Breaking & API Changes​

Below are breaking changes introduced in Electron 18. More information about these and future changes can be found on the Planned Breaking Changes page.

Removed: nativeWindowOpen​

Prior to Electron 15, window.open was by default shimmed to use BrowserWindowProxy. This meant that window.open('about:blank') did not work to open synchronously scriptable child windows, among other incompatibilities. Since Electron 15, nativeWindowOpen has been enabled by default.

See the documentation for window.open in Electron for more details. Removed in #29405

End of Support for 14.x.y​

Electron 14.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

As of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

What is Google Summer of Code?​

Google Summer of Code (GSoC) is a yearly mentoring program connecting open source software projects with potential contributors. Previously open only to students, anyone ages 18 and up can now register for GSoC.

For more information, check out the Summer of Code homepage.

How do I sign up?​

Are you interested in collaborating with Electron? If you are a new or beginner open source contributor, we welcome you to apply!

In order to be selected as an Electron contributor for Google Summer of Code, you will need to submit an application. Applications will open on April 4th, 2022 and close on April 19th, 2022. You can follow updates for Google: Summer of Code application guidelines here.

Want to apply? First, check out the five project idea drafts that we have prepared. All of the listed ideas are currently open for proposals. We are also open to accepting new ideas that are not on the proposed project list.

Your application should include:

• Your proposal, which is a written document that describes in detail what you plan to achieve over the course of the summer.
• Your background as a developer. If you have a resume, please include a copy, otherwise tell us about your past experience with an emphasis on relevant technical experience.

A detailed guide of what to submit as part of your Electron application is here.

You can also read through the official GSoC student/contributor guide for important tips on preparing your proposal.

If you want to discuss project proposals or have questions, come hang out in our #gsoc-general Discord channel!

References​

• Electron Proposal Guide
• Electron GitHub
• Project Ideas Document
• Google Summer of Code Student/Contributor Guide

The Electron team is excited to announce the release of Electron 17.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release and please share any feedback you have!

Notable Changes​

Electron Release Cadence Change​

As of Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes​

• Chromium 98
  • New in Chrome 98
• Node.js 16.13.0
  • Node 16.13.0 blog post
• V8 9.8

Highlighted Features​

• Added webContents.getMediaSourceId(), can be used with getUserMedia to get a stream for a WebContents. #31204
• Deprecates webContents.getPrinters() and introduces webContents.getPrintersAsync(). #31023
• desktopCapturer.getSources is now only available in the main process. #30720

See the 17.0.0 release notes for a full list of new features and changes.

Breaking Changes​

Below are breaking changes introduced in Electron 17. More information about these and future changes can be found on the Planned Breaking Changes page.

desktopCapturer.getSources in the renderer​

The desktopCapturer.getSources API is now only available in the main process. This has been changed in order to improve the default security of Electron apps.

API Changes​

There were no API changes in Electron 17.

Removed/Deprecated Changes​

• Usage of the desktopCapturer.getSources API in the renderer has been removed. See here for details on how to replace this API in your app.

End of Support for 13.x.y​

Electron 13.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

As of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

Beginning in February 2022, Spectron will be officially deprecated by the Electron team.

Why Deprecate Spectron?​

While Spectron has consistently put out new releases for each new version of Electron, the project has had very little maintenance and improvements for well over a year, and currently has no full-time maintainers. With the remote module moving outside of Electron core and into an external module in Electron 14, Spectron will require a major rewrite to continue working reliably.

After reviewing several available options for Spectron's continued maintenance, the Electron team has decided to deprecate Spectron in 2022.

Deprecation Timeline​

The following is our planned deprecation timeline:

• November 2021 - January 2022: The Electron team will continue to accept pull requests from the community.
• January 2022: A final version of announcement warning about Spectron's deprecation will be released.
• February 1, 2022: Spectron's repo will be marked as "archived". No more pull requests will be accepted.

Following February 1st, 2022, Electron will continue to leave the Spectron repo up indefinitely, so that others are welcome to fork or use the existing code for their projects. We hope this will help provide a longer transition to any projects that may still depend on Spectron.

Alternatives to Spectron​

If you're currently using Spectron in your project and would like to migrate to an alternative testing solution, you can read our guide for automated testing here.

We currently have several other recommended alternatives to Spectron, including Playwright and WebDriverIO. Official tutorials for each option can be found in our Automated Testing documentation.

What's Next​

We here on the Electron team appreciate you using Spectron and Electron. We understand that many of you depend on Spectron for testing your apps, and we want to make this transition as painless for you as possible. Thank you for choosing Electron!

The Electron team is excited to announce the release of Electron 16.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release and please share any feedback you have!

Notable Changes​

Electron Release Cadence Change​

As of Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes​

• Chromium 96
  • New in Chrome 96
• Node.js 16.9.1
  • Node 16.9.1 blog post
• V8 9.6
  • V8 9.6 blog post

Highlighted Features​

• Now supports the WebHID API. #30213
• Add data parameter to app.requestSingleInstanceLock to share data between instances. #30891
• Pass securityOrigin to media permissions request handler. #31357
• Add commandLine.removeSwitch. #30933

See the 16.0.0 release notes for a full list of new features and changes.

Breaking Changes​

Below are breaking changes introduced in Electron 16. More information about these and future changes can be found on the Planned Breaking Changes page.

Building Native Modules​

If your project uses node-gyp to build native modules, you may need to call it with --force-process-config depending on your project's setup and your Electron version. More information about this change can be found at #2497.

Behavior Changed: crashReporter implementation switched to Crashpad on Linux​

The underlying implementation of the crashReporter API on Linux has changed from Breakpad to Crashpad, bringing it in line with Windows and Mac. As a result of this, child processes are now automatically monitored, and calling process.crashReporter.start in Node child processes is no longer needed (and is not advisable, as it will start a second instance of the Crashpad reporter).

There are also some subtle changes to how annotations will be reported on Linux, including that long values will no longer be split between annotations appended with __1, __2 and so on, and instead will be truncated at the (new, longer) annotation value limit.

API Changes​

There were no API changes in Electron 16.

Removed/Deprecated Changes​

• Usage of the desktopCapturer.getSources API in the renderer has been deprecated and will be removed. This change improves the default security of Electron apps. See here for details on how to replace this API in your app.

End of Support for 12.x.y​

Electron 12.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

As of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. No new Beta or Stable releases in December. No Nightly releases for the last two weeks of December.
2. With few exceptions, no pull request reviews or merges.
3. No issue tracker updates on any repositories.
4. No Discord debugging help from maintainers.
5. No social media content updates.

Why is this happening?​

In short, while maintainers are happy and engaged with the project, THE WORLD IS TIRED. December is a quiet month for most companies, so we want to give our maintainers a chance to recharge. We encourage other projects to consider similar measures.

Should I be worried about the future of Electron?​

No. We are able to take this step because the project is in good shape. Everyone is looking forward to 2022, and we expect good things to come!

The Electron team is excited to announce the release of Electron 15.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release and please share any feedback you have!

Notable Changes​

Electron Release Cadence Change​

Starting with Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here.

Additionally, Electron will be changing supported versions from latest three versions to latest four versions until May 2022. See our versioning documentfor more detailed information about versioning in Electron.

Stack Changes​

• Chromium 94
  • New in Chrome 94
• Node.js 16.5.0
  • Node 16.5.0 blog post
• V8 9.4
  • V8 9.4 blog post

Highlight Features​

• nativeWindowOpen: true is no longer experimental, and is now the default.
• Added safeStorage string encryption API. #30430
• Added 'frame-created' event to WebContents which emits when a frame is created in the page. #30801
• Added resize edge info to BrowserWindow's will-resize event. #29199

See the 15.0.0 release notes for a full list of new features and changes.

Breaking Changes​

Below are breaking changes introduced in Electron 15. More information about these and future changes can be found on the Planned Breaking Changes page.

Default Changed: nativeWindowOpen defaults to true​

Prior to Electron 15, window.open was by default shimmed to use BrowserWindowProxy. This meant that window.open('about:blank') did not work to open synchronously scriptable child windows, among other incompatibilities. nativeWindowOpen: true is no longer experimental, and is now the default.

See the documentation for window.open in Electron for more details.

API Changes​

• Added 'frame-created' event to WebContents which emits when a frame is created in the page. #30801
• Added safeStorage string encryption API. #30430
• Added signal option to dialog.showMessageBox. #26102
• Added an Electron Fuse for enforcing code signatures on the app.asar file your application loads. Requires the latest asar module (v3.1.0 or higher). #30900
• Added fuses to disable NODE_OPTIONS and --inspect debug arguments in packaged apps. #30420
• Added new MenuItem.userAccelerator property to read user-assigned macOS accelerator overrides. #26682
• Added new app.runningUnderARM64Translation property to detect when running under Rosetta on Apple Silicon, or WOW on Windows for ARM. #29168
• Added new imageAnimationPolicy web preference to control how images are animated. #29095
• Added support for sending Blobs over the context bridge. #29247

Removed/Deprecated Changes​

No APIs have been removed or deprecated.

Supported Versions​

Starting in Electron 15, we will change supported versions from latest three versions to latest four versions until May 2022 with Electron 19. After Electron 19, we will return to supporting the latest three versions. This version support change is part of our new cadence change. Please see our blog post for full details here.

Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

The Electron team is excited to announce the release of Electron 14.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release and please share any feedback you have!

Notable Changes​

Electron Release Cadence Change​

Beginning in September 2021 with Electron 15, Electron will release a new major stable version every 8 weeks. You can read the full details here. Electron 15 will begin beta on September 1, 2021 and stable release will be on September 21, 2021. You can find Electron's public timeline here.

Additionally, Electron will be changing supported versions from latest three versions to latest four versions until May 2022. See see our versioning document for more detailed information about versioning in Electron.

Stack Changes​

• Chromium 93
  • New in Chrome 93
  • New in Chrome 92
• Node.js 14.17.0
  • Node 14.17.0 blog post
• V8 9.3
  • V8 9.3 blog post
  • V8 9.2 blog post

Highlight Features​

• Default Changed: nativeWindowOpen now defaults to true. (see docs)
• Child windows no longer inherit BrowserWindow construction options from their parents. #28550
• Added new session.storagePath API to get the path on disk for session-specific data. #28665
• Added process.contextId used by @electron/remote. #28007
• Added experimental cookie encryption support behind an Electron Fuse. #29492

See the 14.0.0 release notes for a full list of new features and changes.

Breaking Changes​

Below are breaking changes introduced in Electron 14. More information about these and future changes can be found on the Planned Breaking Changes page.

Removed: app.allowRendererProcessReuse​

The app.allowRendererProcessReuse property has been removed as part of our plan to more closely align with Chromium's process model for security, performance and maintainability.

For more detailed information see #18397.

Removed: Browser Window Affinity​

The affinity option when constructing a new BrowserWindow has been removed as part of our plan to more closely align with Chromium's process model for security, performance and maintainability.

For more detailed information see #18397.

API Changed: window.open()​

The optional parameter frameName no longer sets the title of the window. This behavior now follows the specification described by the native documentation for the windowName parameter.

If you were using this parameter to set the title of a window, you can instead use the win.setTitle(title) method.

Removed: worldSafeExecuteJavaScript​

worldSafeExecuteJavaScript has been removed with no alternative. Please ensure your code works with this property enabled. It has been enabled by default since Electron 12.

You will be affected by this change if you use either webFrame.executeJavaScript or webFrame.executeJavaScriptInIsolatedWorld. You will need to ensure that values returned by either of those methods are supported by the Context Bridge API as these methods use the same value passing semantics.

Default Changed: nativeWindowOpen defaults to true​

Prior to Electron 14, window.open was by default shimmed to use BrowserWindowProxy. This meant that window.open('about:blank') did not work to open synchronously scriptable child windows, among other incompatibilities. nativeWindowOpen is no longer experimental, and is now the default.

See the documentation for window.open in Electron for more details.

Removed: BrowserWindowConstructorOptions inheriting from parent windows​

Prior to Electron 14, windows opened with window.open would inherit BrowserWindow constructor options such as transparent and resizable from their parent window. Beginning with Electron 14, this behavior has been removed and windows will not inherit any BrowserWindow constructor options from their parents.

Instead, explicitly set options for the new window with setWindowOpenHandler:

webContents.setWindowOpenHandler((details) => {
  return {
    action: 'allow',
    overrideBrowserWindowOptions: {
      // ...
    }
  }
})

Removed: additionalFeatures​

The deprecated additionalFeatures property in the new-window and did-create-window events of WebContents has been removed. Since new-window uses positional arguments, the argument is still present, but will always be the empty array []. (Note: the new-window event itself is already deprecated and has been replaced by setWindowOpenHandler.) Bare keys in window features will now present as keys with the value true in the options object.

// Removed in Electron 14
// Triggered by window.open('...', '', 'my-key')
webContents.on('did-create-window', (window, details) => {
  if (details.additionalFeatures.includes('my-key')) {
    // ...
  }
})

// Replace with
webContents.on('did-create-window', (window, details) => {
  if (details.options['my-key']) {
    // ...
  }
})

Removed: remote module​

Deprecated in Electron 12, the remote module has now been removed from Electron itself and extracted into a separate package, @electron/remote. The @electron/remote module bridges JavaScript objects from the main process to the renderer process. This lets you access main-process-only objects as if they were available in the renderer process. This is a direct replacement for the remote module. See the module's readme for migration instructions and reference.

API Changes​

• Added BrowserWindow.isFocusable() method to determine whether a window is focusable. #28642
• Added WebFrameMain.visibilityState instance property. #28706
• Added disposition, referrer and postBody to the details object passed to the window open handler registered with setWindowOpenHandler. #28518
• Added process.contextId used by @electron/remote. #28007
• Added experimental cookie encryption support behind an Electron Fuse. #29492
• Added missing resourceType conversions for webRequest listener details: font, ping, cspReport, media, webSocket. #30050
• Added new session.storagePath API to get the path on disk for session-specific data. #28665
• Added support for Windows Control Overlay on macOS. #29986
• Added support for directing Chromium logging to a file with --log-file=.../path/to/file.log. Also, it's now possible to enable logging from JavaScript by appending command-line switches during the first JS tick. #29963
• Added support for the des-ede3 cipher in node crypto. #27897
• Added a ContextBridgeMutability feature that allows context bridge objects to be mutated. #27348

Removed/Deprecated Changes​

The following APIs have been removed or are now deprecated:

• The remote module has been removed after being deprecated in Electron 12. #25734
• Child windows no longer inherit BrowserWindow construction options from their parents. #28550
• Removed deprecated additionalFeatures property from new-window and did-create-window WebContents events. #28548
• Removed the deprecated app.allowRendererProcessReuse and BrowserWindow affinity options. #26874
• The submitURL option for crashReporter.start is no longer a required argument when uploadToServer is false. #28105

End of Support for 11.x.y​

Electron 11.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes.

Both teams have the expressed goal of making web-tech the best it can be on the Desktop, and a shared comprehensive comparison is being discussed.

Electron and WebView2 are fast-moving and constantly evolving projects. We have assembled a brief snapshot of similarities and differences between Electron and WebView2 as they exist today.

Architecture Overview​

Electron and WebView2 both build from the Chromium source for rendering web content. Strictly speaking, WebView2 builds from the Edge source, but Edge is built using a fork of the Chromium source. Electron does not share any DLLs with Chrome. WebView2 binaries hard link against Edge (Stable channel as of Edge 90), so they share disk and some working set. See Evergreen distribution mode for more info.

Electron apps always bundle and distribute the exact version of Electron with which they were developed. WebView2 has two options in distribution. You can bundle the exact WebView2 library your application was developed with, or you can use a shared-runtime version that may already be present on the system. WebView2 provides tools for each approach, including a bootstrapping installer in case the shared runtime is missing. WebView2 is shipped inbox starting with Windows 11.

Applications that bundle their frameworks are responsible for updating those frameworks, including minor security releases. For apps using the shared WebView2 runtime, WebView2 has its own updater, similar to Chrome or Edge, that runs independent of your application. Updating the application's code or any of its other dependencies is still a responsibility for the developer, same as with Electron. Neither Electron nor WebView2 is managed by Windows Update.

Both Electron and WebView2 inherit Chromium’s multi-process architecture - namely, a single main process that communicates with one-or-more renderer processes. These processes are entirely separate from other applications running on the system. Every Electron application is a separate process tree, containing a root browser-process, some utility processes, and zero or more render processes. WebView2 apps that use the same user data folder (like a suite of apps would do), share non-renderer processes. WebView2 apps using different data folders do not share processes.

• ElectronJS Process Model:

  

• WebView2 Based Application Process Model:

  

Read more about WebView2’s process model and Electron’s process model here.

Electron provides APIs for common desktop application needs such as menus, file system access, notifications, and more. WebView2 is a component meant to be integrated into an application framework such as WinForms, WPF, WinUI, or Win32. WebView2 does not provide operating system APIs outside the web standard via JavaScript.

Node.js is integrated into Electron. Electron applications may use any Node.js API, module, or node-native-addon from the renderer and main processes. A WebView2 application does not assume which language or framework the rest of your application is written in. Your JavaScript code must proxy any operating system access through the application-host process.

Electron strives to maintain compatibility with the web API, including APIs developed from the Fugu Project. We have a snapshot of Electron’s Fugu API compatibility. WebView2 maintains a similar list of API differences from Edge.

Electron has a configurable security model for web content, from full-access to full-sandbox. WebView2 content is always sandboxed. Electron has comprehensive security documentation on choosing your security model. WebView2 also has security best practices.

The Electron source is maintained and available on GitHub. Applications can modify can build their own brands of Electron. The WebView2 source is not available on GitHub.

Quick Summary:

Performance Discussion​

When it comes to rendering your web content, we expect little performance difference between Electron, WebView2, and any other Chromium-based renderer. We created scaffolding for apps built using Electron, C++ + WebView2, and C# + WebView2 for those interested to investigate potential performance differences.

There are a few differences that come into play outside of rendering web content, and folks from Electron, WebView2, Edge, and others have expressed interest in working on a detailed comparison including PWAs.

Inter-Process Communication (IPC)​

There is one difference we want to highlight immediately, as we believe it is often a performance consideration in Electron apps.

In Chromium, the browser process acts as an IPC broker between sandboxed renderers and the rest of the system. While Electron allows unsandboxed render processes, many apps choose to enable the sandbox for added security. WebView2 always has the sandbox enabled, so for most Electron and WebView2 apps IPC can impact overall performance.

Even though Electron and WebView2 have a similar process models, the underlying IPC differs. Communicating between JavaScript and C++ or C# requires marshalling, most commonly to a JSON string. JSON serialization/parsing is an expensive operation, and IPC-bottlenecks can negatively impact performance. Starting with Edge 93, WV2 will use CBOR for network events.

Electron supports direct IPC between any two processes via the MessagePorts API, which utilize the structured clone algorithm. Applications which leverage this can avoid paying the JSON-serialization tax when sending objects between processes.

Summary​

Electron and WebView2 have a number of differences, but don't expect much difference with respect to how they perform rendering web content. Ultimately, an app’s architecture and JavaScript libraries/frameworks have a larger impact on memory and performance than anything else because Chromium is Chromium regardless of where it is running.

Special thanks to the WebView2 team for reviewing this post, and ensuring we have an up-to-date view of the WebView2 architecture. They welcome any feedback on the project.

In 2019, Electron moved to a 12 week release cycle to match Chromium's 6 week release cycle. Recently, both Chrome and Microsoft announced changes that made us reconsider Electron's current release cadence:

1. Chromium plans to release a new milestone every 4 weeks, starting with Chrome 94 on September 21st, 2021. This release cadence also adds a new Extended Stable option every 8 weeks, which will contain all updated security fixes.

2. The Microsoft Store will require Chromium-based apps to be no older than within 2 major versions. As an example, if the latest released major version of Chromium is 85, any browser based on Chromium must be on at least Chromium version 83 or higher. This rule includes Electron apps.

Beginning in September 2021, Electron will release a new major stable version every 8 weeks, to match Chromium's 8 week Extended Stable releases.

Our first release with Chromium Extended Stable will be Electron 15 on September 21st, 2021.

Knowing that a release cadence change will impact other downstream applications, we wanted to let our developer community know as soon as possible. Read on for more details about our 2021 release schedule.

Electron 15: Temporary Alpha​

Given that our original Electron 15 release targeted a non-Extended Stable version (Chromium's Extended Stable versions are based on their even-numbered versions), we needed to change our original target release date. However, an Electron app must use the most recent 2 major versions of Chromium to be accepted to the Microsoft Store, which made waiting for two Chromium versions untenable.

With these two requirements, our team faced a timing dilemma. Moving Electron 15 to include Chromium M94 would allow app developers to get on the very first Extended Stable version of Chromium; however, it would also shorten the beta-to-stable cycle to only 3 weeks.

To help with this switchover, Electron will offer a temporary alpha build, only for the Electron 15 release. This alpha build will allow developers more time to test and plan for an Electron 15 release, with a more stable build than our current nightlies.

The alpha channel build will ship for Electron 15 on July 20th, 2021. It will transition to a beta release on September 1st, 2021 with a stable release target of September 21st, 2021. Subsequent Electron releases will not have alpha releases.

2021 Plan for Releases​

Below is our current release schedule for 2021:

Adding the alpha channel extends the development time before Electron 15's launch from 3 weeks to 9 weeks - closer to our new 8 week cycle, while still meeting the requirements for Windows Store submission.

To further help app developers, for the remainder of 2021 until May 2022, we will also be extending our supported versions policy from the latest 3 versions to the latest 4 versions of Electron. That means that even if you can't immediately alter your upgrade schedule, older versions of Electron will still receive security updates and fixes.

Addressing Concerns​

There's a reason we're publishing this post well before this release cycle change is scheduled. We know that a faster release cycle will have a real impact on Electron apps - some of which may already find our major release cadence aggressive.

We've tried to address common concerns below:

❓ Why even make this change? Why not keep the 12 week release cadence?​

To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

Additionally, the current 12 week release cadence would be untenable with the Microsoft Store's new submission requirements. Even apps on the latest stable version of Electron would experience a roughly two week period where their app may be rejected under the new security requirements.

Every new Chromium release contains new features, bug fixes / security fixes, and V8 improvements. We want you, as app developers, to have these changes in a timely manner, so our stable release dates will continue to match every other Chromium stable release. As an app developer, you'll have access to new Chromium and V8 features and fixes sooner than before.

❓ The existing 12 week release schedule already moves quickly. What steps are the team taking to make upgrading easier?​

One advantage of more frequent releases is having smaller releases. We understand that upgrading Electron's major versions can be difficult. We hope that smaller releases will introduce fewer major Chromium and Node changes, as well as fewer breaking changes, per release.

❓ Will there been an alpha release available for future Electron versions?​

There are no plans to support a permanent alpha release at this time. This alpha is only intended for Electron 15, as a way to help developers upgrade more easily in the shortened release period.

❓ Will Electron extend the number of supported versions?​

We will be extending our supported version policy from the latest three versions to the latest four versions of Electron until May 2022, with the release of Electron 19. After Electron 19 is released, we'll return to supporting the latest three major versions, as well as the beta and nightly releases.

Questions?​

📨 If you have questions or concerns, please mail us at info@electronjs.org or join our Discord. We know this is a change that will impact many apps and developers, and your feedback is very important to us. We want to hear from you!

The Electron team is excited to announce the release of Electron 13.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 91
  • New in Chrome 91
  • New in Chrome 90
• Node.js 14.16.0
  • Node 14.16.0 blog post
  • Node 14.0.0 blog post
• V8 9.1
  • V8 9.1 blog post
  • V8 9.0 blog post

Highlight Features​

• Added process.contextIsolated property that indicates whether the current renderer context has contextIsolation enabled. #28252
• Added new session.storagePath API to get the path on disk for session-specific data. #28866
• Deprecated the new-window event of WebContents. It is replaced by webContents.setWindowOpenHandler()
• Added process.contextId used by @electron/remote. #28251

See the 13.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• window.open() parameter frameName is no longer set as window title. #27481
• Changed session.setPermissionCheckHandler(handler) to allow for handler's first parameter, webContents to be null. #19903

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Added roundedCorners option for BrowserWindow. #27572
• Added new session.storagePath API to get the path on disk for session-specific data.28866
• Added support for passing DOM elements over the context bridge. #26776
• Added process.uptime() to sandboxed renderers. #26684
• Added missing fields to the parameters emitted as part of the context-menu event.#26788
• Added support for registering Manifest V3 extension service workers.
• Added ‘registration-completed’ event to ServiceWorkers. #27562

Removed/Deprecated Changes​

The following APIs have been removed or are now deprecated:

• Deprecated the new-window event of WebContents. It is replaced by webContents.setWindowOpenHandler()

• Removed deprecated shell.moveItemToTrash(). #26723

• Removed the following deprecated BrowserWindow extension APIs:

  • BrowserWindow.addExtension(path)

  • BrowserWindow.addDevToolsExtension(path)

  • BrowserWindow.removeExtension(name)

  • BrowserWindow.removeDevToolsExtension(name)

  • BrowserWindow.getExtensions()

  • BrowserWindow.getDevToolsExtensions()

    Use the session APIs instead:

  • ses.loadExtension(path)

  • ses.removeExtension(extension_id)

  • ses.getAllExtensions()

• The following systemPreferences methods have been deprecated:

  • systemPreferences.isDarkMode()

  • systemPreferences.isInvertedColorScheme()

  • systemPreferences.isHighContrastColorScheme()

    Use the following nativeTheme properties instead:

  • nativeTheme.shouldUseDarkColors

  • nativeTheme.shouldUseInvertedColorScheme

  • nativeTheme.shouldUseHighContrastColors

End of Support for 10.x.y​

Electron 10.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 14.0.0 schedule maps out key dates in the Electron 14.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

The Electron team is excited to announce the release of Electron 12.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 89
  • New in Chrome 88
  • New in Chrome 89
• Node.js 14.16
  • Node 14.16.0 blog post
  • Node 14.0.0 blog post
• V8 8.9
  • V8 8.8 blog post
  • V8 8.9 blog post

Highlight Features​

• The ContextBridge exposeInMainWorld method can now expose non-object APIs. #26834
• Upgraded from Node 12 to Node 14. #23249
• Added a new webFrameMain API for accessing sub-frames of a WebContents instance from the main process. #25464
• The default values of contextIsolation and worldSafeExecuteJavaScript are now true. #27949 #27502

See the 12.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Deprecated the remote module. It is replaced by @electron/remote. #25293
  • If you are currently using the remote module, we've written a guide to migrating to @electron/remote here.
• Changed the default value of contextIsolation to true. #27949
• Changed the default value of worldSafeExecuteJavaScript to true. #27502
• Changed the default of crashReporter.start({ compress }) from false to true. #25288
• Removed Flash support: Chromium has removed support for Flash, which was also removed in Electron 12. See Chromium's Flash Roadmap for more details.
• Required SSE3 for Chrome on x86: Chromium has removed support for older x86 CPUs that do not meet a minimum of SSE3 (Streaming SIMD Extensions 3) support. This support was also removed in Electron 12.

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Added webFrameMain API: The webFrameMain module can be used to look up frames across existing WebContents instances. This is the main process equivalent of the existing webFrame API. More information about this new API can be found here, and in our documentation.
• app API changes:
  • Added non-localized serviceName to 'child-process-gone' / app.getAppMetrics(). #25975
  • Added new app.runningUnderRosettaTranslation property to detect when running under rosetta on Apple silicon. #26444
  • Added exitCode to render-process-gone details (app & webContents). #27677
• BrowserWindow API changes:
  • Added BrowserWindow.isTabletMode() API. #25209
  • Added resized (Windows/macOS) and moved (Windows) events to BrowserWindow. #26216
  • Added new system-context-menu event to allow preventing and overriding the system context menu. #25795
  • Added win.setTopBrowserView() so that BrowserViews can be raised. #27713
  • Added webPreferences.preferredSizeMode to allow sizing views according to their document's minimum size. #25874
• contextBridge API changes:
  • Allowed ContextBridge exposeInMainWorld method to expose non-object APIs. #26834
• display API changes:
  • Added displayFrequency property to the Display object to allow getting information about the refresh rate on Windows. #26472
• extensions API changes:
  • Added support for some chrome.management APIs. #25098
• MenuItem API changes:
  • Added support for showing macOS share menu. #25629
• net API changes:
  • Added a new credentials option for net.request(). #25284
  • Added net.online for detecting whether there is currently internet connection. #21004
• powerMonitor API changes:
  • Added powerMonitor.onBatteryPower. #26494
  • Added fast user switching event to powerMonitor on macOS. #25321
• session API changes:
  • Added allowFileAccess option to ses.loadExtension() API. #27702
  • Added display-capture API for session.setPermissionRequestHandler. #27696
  • Added a disabledCipherSuites option to session.setSSLConfig. #25818
  • Added extension-loaded, extension-unloaded, and extension-ready events to session. #25385
  • Added session.setSSLConfig() to allow configuring SSL. #25461
  • Added support for explicitly specifying direct, auto_detect or system modes in session.setProxy(). #24937
  • Added Serial API support. #25237
  • Added APIs to enable/disable spell checker. #26276
• shell API changes:
  • Added a new asynchronous shell.trashItem() API, replacing the synchronous shell.moveItemToTrash(). #25114
• webContents API changes:
  • Added a small console hint to console to help debug renderer crashes. #25317
  • Added frame and webContents properties to the details object in webRequest handlers. #27334
  • Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer. #25580
  • Added setWindowOpenHandler API for renderer-created child windows, and deprecate new-window event. #24517
• webFrame API changes:
  • Added spellcheck API to renderer. #25060

Removed/Deprecated Changes​

The following APIs have been removed or are now deprecated:

• Deprecated the remote module. It is replaced by @electron/remote. #25293
• Removed deprecated crashReporter APIs. #26709
• Removed links to the Electron website from the default 'Help' menu in packaged apps. #25831

End of Support for 9.x.y​

Electron 9.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 13.0.0 schedule maps out key dates in the Electron 13.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

The Electron team is excited to announce the release of Electron 11.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new support for Apple's M1 hardware.

We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 87.0.4280.47
  • New in Chrome 86
  • New in Chrome 87
• Node.js 12.18.3
  • Node 12.18.3 blog post
  • Node 12.7.0 blog post
• V8 8.7
  • V8 8.6 blog post
  • V8 8.7 blog post

Highlight Features​

• Support for Apple M1: On November 10, Apple announced their new M1 chips, which will be included in their upcoming hardware. Beginning in Electron 11, Electron will be shipping separate versions of Electron for Intel Macs (x64) and Apple's upcoming M1 hardware (arm64). You can learn more about how to get your Electron app running on Apple's M1 hardware here. #24545
• Added V8 crash message and location information to crashReport parameters. #24771
• Improved the performance of sending wide objects over the context bridge. #24671

See the 11.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Removed experimental APIs: BrowserView.{fromId, fromWebContents, getAllViews} and the id property of BrowserView. #23578

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Added app.getApplicationInfoForProtocol() API that returns detailed information about the app that handles a certain protocol. #24112
• Added app.createThumbnailFromPath() API that returns a preview image of a file given its file path and a maximum thumbnail size. #24802
• Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer. #25756

End of Support for 8.x.y​

Electron 8.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately quarterly. The tentative 12.0.0 schedule maps out key dates in the Electron 12.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Continued Work for Deprecation of remote Module​

We started work to remove the remote module in Electron 9. We plan to remove the remote module itself in Electron 14.

Read and follow this issue for full plans and details for deprecation.

Final Step for Requiring Native Node Modules to be Context Aware or N-API (in Electron 12)​

From Electron 6 onwards, we've been laying the groundwork to require native Node modules loaded in the renderer process to be either N-API or Context Aware. Enforcing this change allows for stronger security, faster performance, and reduced maintenance workload. The final step of this plan is to remove the ability to disable render process reuse in Electron 12.

Read and follow this issue for full details, including the proposed timeline.

With the release of Electron 11.0.0-beta.1, the Electron team is now shipping builds of Electron that run on the new Apple Silicon hardware that Apple plans on shipping later this year. You can grab the latest beta with npm install electron@beta or download it directly from our releases website.

How does it work?​

As of Electron 11, we will be shipping separate versions of Electron for Intel Macs and Apple Silicon Macs. Prior to this change, we were already shipping two artifacts, darwin-x64 and mas-x64, with the latter being for Mac App Store compatibility usage. We are now shipping another two artifacts, darwin-arm64 and mas-arm64, which are the Apple Silicon equivalents of the aforementioned artifacts.

What do I need to do?​

You will need to ship two versions of your app: one for x64 (Intel Mac) and one for arm64 (Apple Silicon). The good news is that electron-packager, electron-rebuild and electron-forge already support targeting the arm64 architecture. As long as you're running the latest versions of those packages, your app should work flawlessly once you update the target architecture to arm64.

In the future, we will release a package that allows you to "merge" your arm64 and x64 apps into a single universal binary, but it's worth noting that this binary would be huge and probably isn't ideal for shipping to users.

Update: This package is now available at @electron/universal. You can use it to merge two packaged x64 and arm64 apps into a single binary.

Potential Issues​

Native Modules​

As you are targeting a new architecture, you'll need to update several dependencies which may cause build issues. The minimum version of certain dependencies are included below for your reference.

As a result of these dependency version requirements, you may have to fix/update certain native modules. One thing of note is that the Xcode upgrade will introduce a new version of the macOS SDK, which may cause build failures for your native modules.

How do I test it?​

Currently, Apple Silicon applications only run on Apple Silicon hardware, which isn't commercially available at the time of writing this blog post. If you have a Developer Transition Kit, you can test your application on that. Otherwise, you'll have to wait for the release of production Apple Silicon hardware to test if your application works.

What about Rosetta 2?​

Rosetta 2 is Apple's latest iteration of their Rosetta technology, which allows you to run x64 Intel applications on their new arm64 Apple Silicon hardware. Although we believe that x64 Electron apps will run under Rosetta 2, there are some important things to note (and reasons why you should ship a native arm64 binary).

• Your app's performance will be significantly degraded. Electron / V8 uses JIT compilation for JavaScript, and due to how Rosetta works, you will effectively be running JIT twice (once in V8 and once in Rosetta).
• You lose the benefit of new technology in Apple Silicon, such as the increased memory page size.
• Did we mention that the performance will be significantly degraded?

Electron Community Discord Launch

Electron’s Outreach Working Group is excited to announce the launch of our official community Discord server!

Why a new Discord server?​

In its early days as the backbone of the Atom text editor, community discussion on the Electron framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the Slack channel declined in the same manner.

Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were frequenting the channel.

We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest news on all things Electron.

Get in here!​

So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other developers. We’ve got a handy invite for you that’ll give you access to the server!

Hacktoberfest 2020

As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the contributions from its community, from code submissions to bug reports to documentation changes, and much more. That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers of all skill levels into the project.

Odds and ends​

This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute across the Electron JavaScript ecosystem.

Look out for issues tagged hacktoberfest across our various repositories, including the main electron/electron repository, the electron/electronjs.org website, electron/fiddle, and electron-userland/electron-forge!

P.S. If you're feeling particularly adventurous, we also have a backlog of issues marked with help wanted tags if you're looking for more of a challenge.

Stuck? Come chat with us!​

Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. In case you missed it, here's the invite link again!

The Electron team is excited to announce the release of Electron 10.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features.

In the Electron 10 release, we also made a change to our release notes. To make it easier to tell what's brand new in Electron 10 and what may have changed between Electron 10 and past releases, we now also include changes that were introduced to Electron 10, but backported to previous releases. We hope this makes it easier to apps to find new features and bug fixes when upgrading Electron.

We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 85.0.4183.84
  • New in Chrome 84
  • New in Chrome 85
• Node.js 12.16.3
  • Node 12.16.3 blog post
• V8 8.5
  • V8 8.4 blog post
  • V8 8.5 blog post

Highlight Features​

• Added contents.getBackgroundThrottling() method and contents.backgroundThrottling property. [#21036]
• Exposed the desktopCapturer module in the main process. #23548
• Can now check if a given session is persistent by calling the ses.isPersistent() API. #22622
• Resolve network issues that prevented RTC calls from being connected due to network IP address changes and ICE. (Chromium issue 1113227). #24998

See the 10.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Changed the default value of enableRemoteModule to false. #22091
  • This is part of our plans for deprecating the remote module and moving it to userland. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
• Changed the default value of app.allowRendererProcessReuse to true. #22336 (Also in Electron 9)
  • This will prevent loading of non-context-aware native modules in renderer processes.
  • You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
• Fixed the positioning of window buttons on macOS when the OS locale is set to an RTL language (like Arabic or Hebrew). Frameless window apps may have to account for this change while styling their windows. #22016

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• Session: Can now check if a given session is persistent by calling the ses.isPersistent() API. #22622
• Contents: Added contents.getBackgroundThrottling() method and contents.backgroundThrottling property. #21036

Deprecated APIs​

The following APIs are now deprecated or removed:

• Removed the deprecated currentlyLoggingPath property of netLog. Additionally, netLog.stopLogging no longer returns the path to the recorded log. #22732
• Deprecated uncompressed crash uploads in crashReporter. #23598

End of Support for 7.x.y​

Electron 7.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 11.0.0 schedule maps out key dates in the Electron 11.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Continued Work for Deprecation of remote Module (in Electron 11)​

We started work to remove the remote module in Electron 9 and we're continuing plans to remove the remote module. In Electron 11, we plan to continue refactor work for implementing WeakRef as we have done in Electron 10. Please read and follow this issue for full plans and details for deprecation.

Final Step for Requiring Native Node Modules to be Context Aware or N-API (in Electron 12)​

Edit: Originally, this blog post stated that we would disable renderer process reuse in Electron 11. Disabling renderer process reuse has now been pushed to Electron 12.

From Electron 6 onwards, we've been laying the groundwork to require native Node modules loaded in the renderer process to be either N-API or Context Aware. Enforcing this change allows for stronger security, faster performance, and reduced maintenance workload. The final step of this plan is to remove the ability to disable render process reuse in Electron 12. Read this issue for full details including the proposed timeline.

Electron entered incubation in December of 2019, at the last OpenJS Foundation global conference in Montreal. We're excited to take a larger role in the JavaScript community as an Impact Project, and continue our partnership with the OpenJS Foundation.

Learning more​

You can read up on the foundation, its mission, and its members on the OpenJSF website. The OpenJS Foundation is host to a number of open source JavaScript projects including jQuery, Node.js, and webpack. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft.

Electron is an open–source framework for building cross-platform desktop applications with web technologies. To learn more about the humans behind Electron and how they work together, take a look at our Governance page.

To get started with Electron itself, take a peek at our documentation.

What is Season of Docs?

Season of Docs is a program that fosters collaboration between technical writers and open source communities to the benefit of both parties. Open source maintainers utilize the writer's technical writing expertise to improve the structure and content of their documentation, while the technical writer is introduced to an open-source community under the guidance of its mentors. Learn more about it on the Google's Season of Docs website.

For our first time participating in the program, we'll be mentoring a single technical writer who will be working alongside Electron's Ecosystem Working Group to reshape large parts of our documentation. You can learn more about the timeline of the whole project here.

How do I sign up?

Are you interested in collaborating with us as a technical writer? First, get familiar with Google's tech writer guide for this year's program, and check out the two project idea drafts that we have prepared.

In order to be selected as Electron's technical writer for Season of Docs, candidates will need to apply on the Google Season of Docs website during the Technical Writer Application phase that is running from June 8 to July 9..

Your application should include a proposal, which is a written document that describes in detail what you plan to achieve on the Electron docs over the course of 3 months. This proposal can either develop on one of the starting points mentioned in our Project Idea doc, or can be something entirely new. Don't know where to start? You can check out last year's list of accepted proposals for inspiration.

Aside from the proposal, we'll also be looking at your background as a technical writer. Please include a copy of your resume with an emphasis on relevant writing experience, as well as technical writing samples (these samples could be existing documentation, tutorial, blog posts, etc.)

If you want to discuss project proposals, shoot us an email at season-of-docs@electronjs.org and we can chat from there!

References

• Electron documentation
• Project ideas document
• Season of Docs tech writer guide

The Electron team is excited to announce the release of Electron 9.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 83.0.4103.64
  • New in Chrome 81
  • Chrome 82 was skipped
  • New in Chrome 83
• Node.js 12.14.1
  • Node 12.14.1 blog post
• V8 8.3
  • V8 8.1 blog post
  • V8 8.3 blog post

Highlight Features​

• Multiple improvements to the spellchecker feature. See more details in #22128 and #22368.
• Improved window events handler efficiency on Linux. #23260.
• Enable PDF viewer. #22131.

See the 9.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Deprecation warning when using remote without enableRemoteModule: true. #21546
  • This is the first step in our plans for deprecating the remote module and moving it to userland. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
• Set app.enableRendererProcessReuse to true by default. #22336
  • This is continued work for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. Full info and proposed timeline is detailed in this issue.
• Sending non-JavaScript objects over IPC now throws an exception. #21560
  • This behavior was depreciated in Electron 8.0. In Electron 9.0, the old serialization algorithm has been removed, and sending such non-serializable objects will now throw an "object could not be cloned" error.

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• shell API changes:
  • The shell.openItem API has been replaced with an asynchronous shell.openPath API. proposal
• sessionAPI changes:
  • Added session.listWordsFromSpellCheckerDictionary API to list custom words in the dictionary. #22128
  • Added session.removeWordFromSpellCheckerDictionary API to remove custom words in the dictionary. #22368
  • Added session.serviceWorkerContext API to access basic service worker info and receive console logs from service workers. #22313
• app API changes:
  • Added a new force parameter to app.focus() on macOS to allow apps to forcefully take focus. #23447
• BrowserWindow API changes:
  • Added support for property access to some getter/setter pairs on BrowserWindow. #23208

Deprecated APIs​

The following APIs are now deprecated or removed:

• shell.openItem API is now depreciated, and replaced with an asynchronous shell.openPath API.
• <webview>.getWebContents, which was deprecated in Electron 8.0, is now removed.
• webFrame.setLayoutZoomLevelLimits, which was deprecated in Electron 8.0, is now removed.

End of Support for 6.x.y​

Electron 6.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 10.0.0 schedule maps out key dates in the Electron 10.0 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Change the default of contextIsolation from false to true (Starting in Electron 10)​

Without contextIsolation, any code running in a renderer process can quite easily reach into Electron internals or an app's preload script. That code can then perform privileged actions that Electron wants to keep restricted.

Changing this default improves the default security of Electron apps, so that apps will need to deliberately opt in to the insecure behaviour. Electron will depreciate the current default of contextIsolation in Electron 10.0, and change to the new default (true) in Electron 12.0.

For more information on contextIsolation, how to enable it easily and it's security benefits please see our dedicated Context Isolation Document.

What's Happening?​

Our major release cadence schedule moves in lockstep with that of Chromium, and the Chromium project has made the recent decision to pause its releases due to adjusted work schedules. This means that for the duration of Chromium's altered cadence, Electron will also temporarily pause new major releases.

We feel that our best choice is to follow in Chromium's footsteps, and so in the interim the Electron team will shift to full-time work on bugfixes, security, performance, and stability.

We want to ensure that both our maintainers and our consumers' wellbeing is prioritized during this time, so we welcome your feedback and look forward to returning to our regular release schedule.

For more updates, please follow our Twitter account.

Edit (2020-03-30): Electron 9 stable will target Chromium M83 and be released on May 19, 2020, in response to Chromium's announcement of skipping the M82 stable date and adjusting the M83 stable date.

The Electron team is excited to announce the release of Electron 8.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

Stack Changes​

• Chromium 80.0.3987.86
  • New in Chrome 79
  • New in Chrome 80
• Node.js 12.13.0
  • Node 12.13.0 blog post
• V8 8.0
  • V8 7.9 blog post
  • V8 8.0 blog post

Highlight Features​

• Implemented usage of Chrome's built-in spellchecker feature. See more details in #20692 and #21266.
• IPC communication now uses v8's Structured Clone Algorithm. This is faster, more featureful, and less surprising than the existing logic, and brings about a 2x performance boost for large buffers and complex objects. Latency for small messages is not significantly affected. See more details in #20214.

See the 8.0.0 release notes for a full list of new features and changes.

Breaking Changes​

• Show module name in deprecation warning for context-aware modules. #21952
  • This is continued work for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. Full info and proposed timeline is detailed in this issue.
• Values sent over IPC are now serialized with Structured Clone Algorithm. #20214
• Offscreen Rendering is currently disabled due to lack of a maintainer to work on this feature. It broke during the Chromium upgrade and was subsequently disabled. #20772

More information about these and future changes can be found on the Planned Breaking Changes page.

API Changes​

• app API changes:
  • Added app.getApplicationNameForProtocol(url). #20399
  • Added app.showAboutPanel() and app.setAboutPanelOptions(options) support on Windows. #19420
• BrowserWindow API changes:
  • Updated docs to note that BrowserWindow options hasShadow is available on all platforms #20038
  • Added trafficLightPosition option to BrowserWindow options to allow custom positioning for traffic light buttons. #21781
  • Added accessibleTitle option to BrowserWindow for setting the accessible window title #19698
  • BrowserWindow.fromWebContents() can now return null #19983
  • Added BrowserWindow.getMediaSourceId() and BrowserWindow.moveAbove(mediaSourceId). #18926
  • Added support for will-move event on macOS. #19641
• Documented previously undocumented crashReporter.getCrashesDirectory(). #20417
• dialog API changes:
  • Added dontAddToRecent property to dialog.showOpenDialog and dialog.showOpenDialogSync to prevent documents from being added to recent documents on Windows in open dialogs. #19669
  • Added property customization to dialog.showSaveDialog and dialog.showSaveDialogSync. #19672
• Notification API changes:
  • Added timeoutType option to allow Linux/Windows users to set the type of notification timeout. #20153
  • Added urgency option to set urgency on Linux notifications. #20152
• session API changes:
  • Updated documentation on session.setProxy(config) and session.setCertificateVerifyProc(proc) to note optional options. #19604
  • Added session.downloadURL(url) to allow to triggering downloads without a BrowserWindow. #19889
  • Added support for HTTP preconnect resource hints via session.preconnect(options) and the preconnect event. #18671
  • Added session.addWordToSpellCheckerDictionary to allow custom words in the dictionary #21297
• Added option to shell.moveItemToTrash(fullPath[, deleteOnFail]) on macOS to specify what happens when moveItemToTrash fails. #19700
• systemPreferences API changes:
  • Updated systemPreferences.getColor(color) documentation for macOS. #20611
  • Added screen media type to systemPreferences.getMediaAccessStatus(). #20764
• Added nativeTheme.themeSource to allow apps to override Chromium and the OS's theme choice. #19960
• TouchBar API changes:
  • Added accessibilityLabel property to TouchBarButton and TouchBarLabel to improve TouchBarButton/TouchBarLabel accessibility. #20454
  • Updated TouchBar related documentation #19444
• tray API changes:
  • Added new options to tray.displayBalloon(): iconType, largeIcon, noSound and respectQuietTime. #19544
  • Added tray.removeBalloon(), which removes an already displayed balloon notification. #19547
  • Added tray.focus(), which returns focus to the taskbar notification area. feat: add tray.focus() #19548
• webContents API changes:
  • Added contents.executeJavaScriptInIsolatedWorld(worldId, scripts[, userGesture]) to expose executeJavaScriptInIsolatedWorld on the webContents API. #21190
  • Added methods to capture a hidden webContents. #21679
  • Added options to webContents.print([options], [callback]) to enable customization of print page headers and footers. #19688
  • Added ability to inspect specific shared workers via webContents.getAllSharedWorkers() and webContents.inspectSharedWorkerById(workerId). #20389
  • Added the support of fitToPageEnabled and scaleFactor options in WebContents.printToPDF(). #20436
• Updated webview.printToPDF documentation to indicate return type is now Uint8Array. #20505

Deprecated APIs​

The following APIs are now deprecated:

• Deprecated the nonfunctional visibleOnFullScreen option within BrowserWindow.setVisibleOnAllWorkspaces prior to its removal in the next major release version. #21732
• Deprecated alternate-selected-control-text on systemPreferences.getColor(color) for macOS. #20611
• Deprecated setLayoutZoomLevelLimits on webContents, webFrame, and <webview> Tag because Chromium removed this capability. #21296
• The default value of false for app.allowRendererProcessReuse is now deprecated. #21287
• Deprecated <webview>.getWebContents() as it depends on the remote module. #20726

End of Support for 5.x.y​

Electron 5.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

App Feedback Program​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 9.0.0 schedule maps out key dates in the Electron 9 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Deprecation of remote Module (Starting in Electron 9)​

Due to serious security liabilities, we are beginning plans to deprecate the remote module starting in Electron 9. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.

The OpenJS Foundation is host to a number of open source JavaScript projects including jQuery, Node.js, and webpack. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. Electron is an open–source framework for building cross-platform desktop applications with web technologies.

This is an exciting move for Electron, and we see it as a next step in our evolution as an open-source project.

What this means for developers​

Electron joining the OpenJS Foundation does not change how Electron is made, released, or used — and does not directly affect developers building applications with Electron. Even though Electron was originally created at GitHub in 2013, it is currently maintained by a number of organizations and individuals. In 2019, Electron codified its governance structure and invested heavily into formalizing how decisions affecting the entire project are made. We believe that having multiple organizations and developers investing in and collaborating on Electron makes the project stronger.

Lifting Electron up from being owned by a single corporate entity and moving it into a neutral foundation focused on supporting the web and JavaScript ecosystem is a natural next step as we mature as an open-source project.

Learning more​

You can read up on the foundation, its mission, and its members on the OpenJSF website. For more information and quotes about the acceptance of Electron into the OpenJSF incubation program, check out the official press release. To learn more about the humans behind Electron and how they work together, take a look at our Governance page.

To get started with Electron itself, take a peek at our documentation.

This vulnerability has been assigned CVE-2019-13720. You can read more about it in the Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron as soon as possible.

Scope​

This affects any Electron application that may run third-party or untrusted JavaScript.

Mitigation​

Affected apps should upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

• 6.1.4

Electron 7.0.1 automatically included the fix from upstream, before the announcement was made. Electron 8 is similarly unaffected. The vulnerability did not exist in Electron 5, so that version is also unaffected.

Further Information​

This vulnerability was discovered by Anton Ivanov and Alexey Kulaev at Kaspersky Labs and reported to the Chrome team. The Chrome blog post can be found here.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

The Electron team is excited to announce the release of Electron 7.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

• Stack Upgrades:

  Stack	Version in Electron 6	Version in Electron 7	What's New
  Chromium	76.0.3809.146	78.0.3905.1	77, 78
  V8	7.6	7.8	7.7, 7.8
  Node.js	12.4.0	12.8.1	12.5, 12.6, 12.7, 12.8, 12.8.1

• Added Windows on Arm (64 bit) release. #18591, #20112

• Added ipcRenderer.invoke() and ipcMain.handle() for asynchronous request/response-style IPC. These are strongly recommended over the remote module. See this "Electron’s ‘remote’ module considered harmful" blog post for more information. #18449

• Added nativeTheme API to read and respond to changes in the OS's theme and color scheme. #19758, #20486

• Switched to a new TypeScript Definitions generator. The resulting definitions are more precise; so if your TypeScript build fails, this is the likely cause. #18103

See the 7.0.0 release notes for a longer list of changes.

Breaking Changes​

More information about these and future changes can be found on the Planned Breaking Changes page.

• Removed deprecated APIs:
  • Callback-based versions of functions that now use Promises. #17907
  • Tray.setHighlightMode() (macOS). #18981
  • app.enableMixedSandbox() #17894
  • app.getApplicationMenu(),
  • app.setApplicationMenu(),
  • powerMonitor.querySystemIdleState(),
  • powerMonitor.querySystemIdleTime(),
  • webFrame.setIsolatedWorldContentSecurityPolicy(),
  • webFrame.setIsolatedWorldHumanReadableName(),
  • webFrame.setIsolatedWorldSecurityOrigin() #18159
• Session.clearAuthCache() no longer allows filtering the cleared cache entries. #17970
• Native interfaces on macOS (menus, dialogs, etc.) now automatically match the dark mode setting on the user's machine. #19226
• Updated the electron module to use @electron/get. The minimum supported node version is now Node 8. #18413
• The file electron.asar no longer exists. Any packaging scripts that depend on its existence should be updated. #18577

End of Support for 4.x.y​

Electron 4.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

App Feedback Program​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 8.0.0 schedule maps out key dates in the Electron 8 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

What's New​

Today marks a first for the Electron project: this is the first time we've made a stable Electron release on the same day as the corresponding Chrome stable release! 🎉

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 6:

• Chromium 76.0.3809.88
  • New in 74
  • New in 75
  • New in 76
• Node.js 12.4.0
  • Node 12.4.0 blog post
• V8 7.6.303.22
  • V8 7.6 blog post

This release also includes improvements to Electron's APIs. The release notes have a more complete list, but here are the highlights:

Promisification​

Electron 6.0 continues the modernization initiative started in 5.0 to improve Promise support.

These functions now return Promises and still support older callback-based invocation:

• contentTracing.getCategories() #16583
• contentTracing.getCategories() #16583
• contentTracing.getTraceBufferUsage() #16600
• contents.executeJavaScript() #17312
• cookies.flushStore() #16464
• cookies.get() #16464
• cookies.remove() #16464
• cookies.set() #16464
• dialog.showCertificateTrustDialog() #17181
• inAppPurchase.getProducts() #17355
• inAppPurchase.purchaseProduct()#17355
• netLog.stopLogging() #16862
• session.clearAuthCache() #17259
• session.clearCache() #17185
• session.clearHostResolverCache() #17229
• session.clearStorageData() #17249
• session.getBlobData() #17303
• session.getCacheSize() #17185
• session.resolveProxy() #17222
• session.setProxy() #17222
• webContents.hasServiceWorker() #16535
• webContents.printToPDF() #16795
• webContents.savePage() #16742
• webFrame.executeJavaScript() #17312
• webFrame.executeJavaScriptInIsolatedWorld() #17312
• webviewTag.executeJavaScript() #17312

These functions now have two forms, synchronous and Promise-based asynchronous:

• dialog.showMessageBox()/dialog.showMessageBoxSync() #17298
• dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973
• dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054

These functions now return Promises:

• app.dock.show() #16904

Electron Helper (Renderer).app, Electron Helper (GPU).app and Electron Helper (Plugin).app​

In order to enable the hardened runtime, which restricts things like writable-executable memory and loading code signed by a different Team ID, special code signing entitlements needed to be granted to the Helper.

To keep these entitlements scoped to the process types that require them, Chromium added three new variants of the Helper app: one for renderers (Electron Helper (Renderer).app), one for the GPU process (Electron Helper (GPU).app) and one for plugins (Electron Helper (Plugin).app).

Folks using electron-osx-sign to codesign their Electron app shouldn't have to make any changes to their build logic. If you're codesigning your app with custom scripts, you should ensure that the three new Helper applications are correctly codesigned.

In order to package your application correctly with these new helpers you need to be using electron-packager@14.0.4 or higher. If you are using electron-builder you should follow this issue to track support for these new helpers.

Breaking Changes​

• This release begins laying the groundwork for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. The reasons for this change are faster performance, stronger security, and reduced maintenance workload. Read the full details including the proposed timeline in this issue. This change is expected to be completed in Electron v11.

• net.IncomingMessage headers have changed slightly to more closely match Node.js behavior, particularly with the value of set-cookie and how duplicate headers are handled. #17517.

• shell.showItemInFolder() now returns void and is an asynchronous call. #17121

• Apps must now explicitly set a log path by calling the new function app.setAppLogPath() before using app.getPath('log'). #17841

End of Support for 3.x.y​

Per our support policy, 3.x.y has reached end of life. Developers and applications are encouraged to upgrade to a newer version of Electron.

App Feedback Program​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 7.0.0 schedule maps out key dates in the Electron 7 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

🎉 Electron is moving to release a new major stable version every 12 weeks! 🎉

⚡️ Wow that's quick! But why?​

Simply put, Chromium doesn't stop shipping so Electron is not going to slow down either.

Chromium releases on a consistent 6-week schedule. To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

🚀 Why every 12 weeks?​

Every 6 weeks, a new Chromium release comes out with new features, bug fixes / security fixes, and V8 improvements. Electron's users have been loud and clear about wanting these changes in a timely manner, so we've adjusted our stable release dates to match every other Chromium stable release. Up first, Electron v6.0.0 will include M76 and is scheduled for stable release on July 30, 2019, the same release day as Chromium M76.

🚧 What does this mean for me and my Electron app?​

You'll have access to new Chromium and V8 features and fixes sooner than before. Importantly, you'll also know when those new changes are coming, so you'll be able to plan with better information than before.

The Electron team will continue to support the latest three major versions. For example, when v6.0.0 goes stable on July 30, 2019, we will support v6.x, v5.x, and v4.x, while v3.x will reach End-Of-Life.

💬 App Feedback Program​

Please consider joining our App Feedback Program to help us with testing our beta releases and stabilization. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release.

📝 A brief history of Electron releases​

The decisions around stable releases before v3.0.0 did not follow a schedule. We added internal schedules to the project with v3.0.0 and v4.0.0. Earlier this year, we decided to publicize our stable release date for the first time for Electron v5.0.0. Announcing our stable release dates was positively received overall and we're excited to continue doing that for future releases.

In order to better streamline these upgrade-related efforts, our Upgrades and Releases Working Groups were created within our Governance system. They have allowed us to better prioritize and delegate this work, which we hope will become more apparent with each subsequent release.

Here is where our new cadence will put us in comparison to Chromium's cadence:

📨 If you have questions, please mail us at info@electronjs.org.

What's New?​

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:

• Chromium 73.0.3683.119
  • New in 70
  • New in 71
  • New in 72
  • New in 73
• Node.js 12.0.0
  • Node 12 Blog Post
• V8 7.3.492.27.
  • New JS Features

Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the Electron v5.0.0 release notes.

Promisification​

Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:

• app.getFileIcon
• contentTracing.getCategories
• contentTracing.startRecording
• contentTracing.stopRecording
• debugger.sendCommand
• Cookies API
• shell.openExternal
• webContents.loadFile
• webContents.loadURL
• webContents.zoomLevel
• webContents.zoomFactor
• win.capturePage

System colors access for macOS​

These functions were changed or added to systemPreferences to access macOS systems' colors:

• systemPreferences.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystemColor

Process memory information​

The function process.getProcessMemoryInfo has been added to get memory usage statistics about the current process.

Additional filtering for remote APIs​

To improve security in the remote API, new remote events have been added so that remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents and <webview>.getWebContents can be filtered.

Multiple BrowserViews on BrowserWindow​

BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.

Breaking Changes​

Defaults for packaged apps​

Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the window-all-closed event will be automatically handled unless the app handles the event.

Mixed sandbox​

Mixed sandbox mode is now enabled by default. Renderers launched with sandbox: true will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.

Security improvements​

The default values of nodeIntegration and webviewTag are now false to improve security.

Spellchecker now asynchronous​

The SpellCheck API has been changed to provide asynchronous results.

Deprecations​

The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:

Mksnapshot binaries for arm and arm64​

Native binaries of mksnapshot for arm and arm64 are deprecated and will be removed in 6.0.0. Snapshots can be created for arm and arm64 using the x64 binaries.

ServiceWorker APIs on WebContents​

Deprecated ServiceWorker APIs on WebContents in preparation for their removal.

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

Automatic modules with sandboxed webContents​

In order to improve security, the following modules are being deprecated for use directly via require and will instead need to be included via remote.require in a sandboxed webcontents:

• electron.screen
• child_process
• fs
• os
• path

webFrame Isolated World APIs​

webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.

Mixed sandbox​

enableMixedSandbox and the --enable-mixed-sandbox command-line switch still exist for compatibility, but are deprecated and have no effect.

End of support for 2.0.x​

Per our supported versions policy, 2.0.x has reached end of life.

App Feedback Program​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 6.0.0 schedule maps out key dates in the Electron 6 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Background​

Electron is a JavaScript platform whose primary purpose is to lower the barrier to entry for developers to build robust desktop apps without worrying about platform-specific implementations. However, at its core, Electron itself still needs platform-specific functionality to be written in a given system language.

In reality, Electron handles the native code for you so that you can focus on a single JavaScript API.

How does that work, though? How do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?

To trace this pathway, let's start with the app module.

By opening the app.ts file inside our lib/ directory, you'll find the following line of code towards the top:

const binding = process.electronBinding('app')

This line points directly to Electron's mechanism for binding its C++/Objective-C modules to JavaScript for use by developers. This function is created by the header and implementation file for the ElectronBindings class.

process.electronBinding​

These files add the process.electronBinding function, which behaves like Node.js’ process.binding. process.binding is a lower-level implementation of Node.js' require() method, except it allows users to require native code instead of other code written in JS. This custom process.electronBinding function confers the ability to load native code from Electron.

When a top-level JavaScript module (like app) requires this native code, how is the state of that native code determined and set? Where are the methods exposed up to JavaScript? What about the properties?

native_mate​

At present, answers to this question can be found in native_mate: a fork of Chromium's gin library that makes it easier to marshal types between C++ and JavaScript.

Inside native_mate/native_mate there's a header and implementation file for object_template_builder. This is what allow us to form modules in native code whose shape conforms to what JavaScript developers would expect.

mate::ObjectTemplateBuilder​

If we look at every Electron module as an object, it becomes easier to see why we would want to use object_template_builder to construct them. This class is built on top of a class exposed by V8, which is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. V8 implements the JavaScript (ECMAScript) specification, so its native functionality implementations can be directly correlated to implementations in JavaScript. For example, v8::ObjectTemplate gives us JavaScript objects without a dedicated constructor function and prototype. It uses Object[.prototype], and in JavaScript would be equivalent to Object.create().

To see this in action, look to the implementation file for the app module, atom_api_app.cc. At the bottom is the following:

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

In the above line, .SetMethod is called on mate::ObjectTemplateBuilder. .SetMethod can be called on any instance of the ObjectTemplateBuilder class to set methods on the Object prototype in JavaScript, with the following syntax:

.SetMethod("method_name", &function_to_bind)

This is the JavaScript equivalent of:

function App{}
App.prototype.getGPUInfo = function () {
  // implementation here
}

This class also contains functions to set properties on a module:

.SetProperty("property_name", &getter_function_to_bind)

or

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

These would in turn be the JavaScript implementations of Object.defineProperty:

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

and

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

It’s possible to create JavaScript objects formed with prototypes and properties as developers expect them, and more clearly reason about functions and properties implemented at this lower system level!

The decision around where to implement any given module method is itself a complex and oft-nondeterministic one, which we'll cover in a future post.

Why are things changing?​

People in the Electron project coordinate in timezones around the world with volunteers, with full-time maintainers, and with several companies who all rely on Electron. Until now, we've been successful with informal coordination; but as the team has grown, we've found that the approach doesn't scale. We also want to make it easier for new contributors to find a place to call home in the project.

Working Groups​

Electron governance includes working groups that are responsible for different parts of the project. We're starting out with seven groups:

• Community & Safety: Handles Code of Conduct issues.
• Docs & Tooling: Oversees externally-focused tooling (e.g. Fiddle, Forge) and the Electron documentation.
• Outreach: Helps grow the Electron community.
• Releases: Ensures releases are stable and on schedule.
• Security: Performs security testing and responds to security issues.
• Upgrades: Integrates upstream upgrades, such as new versions of V8, Chromium, and Node.
• Website: Maintains and improves the Electron website.

These groups will coordinate with each other, but each has their own meeting schedules and agendas to be productive on their own. More details on these groups are available at the governance repository.

Does this change the Electron project's direction?​

This shouldn't have any direct effect on Electron's direction. If our strategy is successful, working groups will make it easier for new contributors to find topics that interest them, and make maintainers' lives simpler by moving discussion unrelated to their day-to-day work to other groups. If that happens, it may indirectly affect things by having more unblocked people working together.

Where can I learn more?​

• The governance repo and charter have information about the new governance structure.
• Each working group has its own page: Community, Docs & Tools, Outreach, Releases, Security, Upgrades, and Website.
• You can contact the maintainers by opening an issue or mailing us at info@electronjs.org.

This vulnerability has been assigned CVE-2019-5786. You can read more about it in the Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron ASAP.

Scope​

This affects any Electron application that may run third-party or untrusted JavaScript.

Mitigation​

Affected apps should upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

The latest beta of Electron 5 was tracking Chromium 73 and therefore is already patched:

• 5.0.0-beta.5

Further Information​

This vulnerability was discovered by Clement Lecigne of Google's Threat Analysis Group and reported to the Chrome team. The Chrome blog post can be found here.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

What exactly is Electron no longer supporting?​

You may have seen the description "64-bit" and "32-bit" as stickers on your computer or as options for downloading software. The term is used to describe a specific computer architecture. Most computers made in the 1990s and early 2000s were made with CPUs that were based on the 32-bit architecture, while most computers made later were based on the newer and more powerful 64-bit architecture. The Nintendo 64 (get it?) and the PlayStation 2 were the first widely available consumer devices with the new architecture, computers sold after 2010 contained almost exclusively 64-bit processors. As a result, support has been shrinking: Google stopped releasing Chrome for 32-bit Linux in March 2016, Canonical stopped providing 32-bit desktop images in 2017 and dropped support for 32-bit altogether with Ubuntu 18.10. Arch Linux, elementary OS, and other prominent Linux distributions have already dropped support for the aging processor architecture.

Until now, Electron has provided and supported builds that run on the older 32-bit architecture. From release v4.0 onwards, the Electron team will no longer be able to provide binaries or support for 32-bit Linux.

Electron has always been a vibrant open source project and we continue to support and encourage developers interested in building Electron for exotic architectures.

What does that mean for developers?​

If you are not currently providing 32-bit distributions of your app for Linux, no action is required.

Projects which ship 32-bit Linux Electron applications will need to decide how to proceed. 32-bit Linux will be supported on Electron 3 until the release of Electron 6, which gives some time to make decisions and plans.

What does that mean for users?​

If you are a Linux user and not sure whether or not you're running a 64-bit based system, you are likely running on a 64-bit based architecture. To make sure, you can run the lscpu or uname -m commands in your terminal. Either one will print your current architecture.

If you are using Linux on a 32-bit processor, you have likely already encountered difficulties finding recently released software for your operating system. The Electron team joins other prominent members in the Linux community by recommending that you upgrade to a 64-bit based architecture.

Opening a BrowserView with sandbox: true or nativeWindowOpen: true and nodeIntegration: false results in a webContents where window.open can be called and the newly opened child window will have nodeIntegration enabled. This vulnerability affects all supported versions of Electron.

Mitigation​

We've published new versions of Electron which include fixes for this vulnerability: 2.0.17, 3.0.15, 3.1.3, 4.0.4, and 5.0.0-beta.2. We encourage all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can mitigate this issue by disabling all child web contents:

view.webContents.on('-add-new-contents', e => e.preventDefault());

Further Information​

This vulnerability was found and reported responsibly to the Electron project by PalmerAL.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

Goodbye v8::Handle, Hello v8::Local​

In 2014, the V8 team deprecated v8::Handle in favor of v8::Local for local handles. Electron 5.0 includes a version of V8 that has finally removed v8::Handle for good, and native Node.js addons that still use it will need to be updated before they can be used with Electron 5.0.

The required code change is minimal, but every native Node module that still uses v8::Handle will fail to build with Electron 5.0 and will need to be modified. The good news is that Node.js v12 will also include this V8 change, so any modules that use v8::Handle will need to be updated anyway to work with the upcoming version of Node.

I maintain a native addon, how can I help?​

If you maintain a native addon for Node.js, ensure you replace all occurrences of v8::Handle with v8::Local. The former was just an alias of the latter, so no other changes need to be made to address this specific issue.

You may also be interested in looking into N-API, which is maintained separately from V8 as a part of Node.js itself, and aims to insulate native addons from changes in the underlying JavaScript engine. You can find more information in the N-API documentation on the Node.js website.

Help! I use a native addon in my app and it won't work!​

If you're consuming a native addon for Node.js in your app and the native addon will not build because of this issue, check with the author of the addon to see if they've released a new version that fixes the problem. If not, reaching out to the author (or opening a Pull Request!) is probably your best bet.

As mentioned in our v4.0.0 stable release blog post, we are planning to release approximately quarterly to maintain closer cadence with Chromium releases. Chromium releases a new version very quickly -- every 6 weeks.

Take a look at progression in Electron versus Chromium side-by-side:

In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.

We would love to promise future dates like Node.js and Chromium do, but we are not at that place yet. We are optimistic that we will reach a long-term timeline in the future.

With that in mind, we are taking first steps by publicly posting our release schedule for v5.0.0. You can find that here.

To help us with testing our beta releases and stabilization, please consider joining our App Feedback Program.

What's New?​

A large part of Electron's functionality is provided by Chromium, Node.js, and V8, the core components that make up Electron. As such, a key goal for the Electron team is to keep up with changes to these projects as much as possible, providing developers who build Electron apps access to new web and JavaScript features. To this end, Electron 4 features major version bumps to each of these components; Electron v4.0.0 includes Chromium 69.0.3497.106, Node 10.11.0, and V8 6.9.427.24.

In addition, Electron 4 includes changes to Electron-specific APIs. You can find a summary of the major changes in Electron 4 below; for the full list of changes, check out the Electron v4.0.0 release notes.

Disabling the remote Module​

You now have the ability to disable the remote module for security reasons. The module can be disabled for BrowserWindows and for webview tags:

// BrowserWindow
new BrowserWindow({
  webPreferences: {
    enableRemoteModule: false
  }
})

// webview tag
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

See the BrowserWindow and <webview> Tag documentation for more information.

Filtering remote.require() / remote.getGlobal() Requests​

This feature is useful if you don't want to completely disable the remote module in your renderer process or webview but would like additional control over which modules can be required via remote.require.

When a module is required via remote.require in a renderer process, a remote-require event is raised on the app module. You can call event.preventDefault() on the the event (the first argument) to prevent the module from being loaded. The WebContents instance where the require occurred is passed as the second argument, and the name of the module is passed as the third argument. The same event is also emitted on the WebContents instance, but in this case the only arguments are the event and the module name. In both cases, you can return a custom value by setting the value of event.returnValue.

// Control `remote.require` from all WebContents:
app.on('remote-require', function (event, webContents, requestedModuleName) {
  // ...
})

// Control `remote.require` from a specific WebContents instance:
browserWin.webContents.on('remote-require', function (event, requestedModuleName) {
  // ...
})

In a similar fashion, when remote.getGlobal(name) is called, a remote-get-global event is raised. This works the same way as the remote-require event: call preventDefault() to prevent the global from being returned, and set event.returnValue to return a custom value.

// Control `remote.getGlobal` from all WebContents:
app.on('remote-get-global', function (event, webContents, requrestedGlobalName) {
  // ...
})

// Control `remote.getGlobal` from a specific WebContents instance:
browserWin.webContents.on('remote-get-global', function (event, requestedGlobalName) {
  // ...
})

For more information, see the following documentation:

• remote.require
• remote.getGlobal
• app
• WebContents

JavaScript Access to the About Panel​

On macOS, you can now call app.showAboutPanel() to programmatically show the About panel, just like clicking the menu item created via {role: 'about'}. See the showAboutPanel documentation for more information

Controlling WebContents Background Throttling​

WebContents instances now have a method setBackgroundThrottling(allowed) to enable or disable throttling of timers and animations when the page is backgrounded.

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

See the setBackgroundThrottling documentation for more information.

Breaking Changes​

No More macOS 10.9 Support​

Chromium no longer supports macOS 10.9 (OS X Mavericks), and as a result Electron 4.0 and beyond does not support it either.

Single Instance Locking​

Previously, to make your app a Single Instance Application (ensuring that only one instance of your app is running at any given time), you could use the app.makeSingleInstance() method. Starting in Electron 4.0, you must use app.requestSingleInstanceLock() instead. The return value of this method indicates whether or not this instance of your application successfully obtained the lock. If it failed to obtain the lock, you can assume that another instance of your application is already running with the lock and exit immediately.

For an example of using requestSingleInstanceLock() and information on nuanced behavior on various platforms, see the documentation for app.requestSingleInstanceLock() and related methods and the second-instance event.

win_delay_load_hook​

When building native modules for windows, the win_delay_load_hook variable in the module's binding.gyp must be true (which is the default). If this hook is not present, then the native module will fail to load on Windows, with an error message like Cannot find module. See the native module guide for more information.

Deprecations​

The following breaking changes are planned for Electron 5.0, and thus are deprecated in Electron 4.0.

Node.js Integration Disabled for nativeWindowOpen-ed Windows​

Starting in Electron 5.0, child windows opened with the nativeWindowOpen option will always have Node.js integration disabled.

webPreferences Default Values​

When creating a new BrowserWindow with the webPreferences option set, the following webPreferences option defaults are deprecated in favor of new defaults listed below:

Please note: there is currently a known bug (#9736) that prevents the webview tag from working if contextIsolation is on. Keep an eye on the GitHub issue for up-to-date information!

Learn more about context isolation, Node integration, and the webview tag in the Electron security document.

Electron 4.0 will still use the current defaults, but if you don't pass an explicit value for them, you'll see a deprecation warning. To prepare your app for Electron 5.0, use explicit values for these options. See the BrowserWindow docs for details on each of these options.

webContents.findInPage(text[, options])​

The medialCapitalAsWordStart and wordStart options have been deprecated as they have been removed upstream.

App Feedback Program​

The App Feedback Program we instituted during the development of Electron 3.0 was successful, so we've continued it during the development of 4.0 as well. We'd like to extend a massive thank you to Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp, and the other program members for their involvement during the 4.0 beta cycle. To learn more about the App Feedback Program and to participate in future betas, check out our blog post about the program.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. See our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

Scope​

Electron applications using Web SQL are impacted.

Mitigation​

Affected apps should stop using Web SQL or upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

• 4.0.0-beta.11
• 3.1.0-beta.4
• 3.0.13
• 2.0.16

There are no reports of this in the wild; however, affected applications are urged to mitigate.

Further Information​

This vulnerability was discovered by the Tencent Blade team, who have published a blog post that discusses the vulnerability.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

Edit (2020-05-21): This program has been retired.

Who can join?​

Our criteria and expectations for apps joining this program include the following items:

• Test your app during the beta period for 10,000+ user-hours
• Have a single point-person who will check in weekly to discuss your app's Electron bugs and app blockers
• You agree to abide by Electron's Code of Conduct
• You are willing to share the following information listed in the next question

What info does my Electron app have to share?​

• Total user-hours your app has been running with any beta release
• Version of Electron that your app is testing with (e.g., 4.0.0-beta.3)
• Any bugs preventing your application from upgrading to the release line being beta tested

User-hours​

We understand not everyone can share exact user numbers, however better data helps us decide how stable a particular release is. We ask that apps commit to testing a minimum number of user-hours, currently 10,000 across the beta cycle.

• 10 user-hours could be 10 people testing for one hour, or one person testing for 10 hours
• You can split the testing between beta releases, for example test for 5,000 user-hours on 3.0.0-beta.2 and then test for 5,000 user-hours on 3.0.0-beta.5. More is better, but we understand that some applications cannot test every beta release
• CI or QA hours do not count towards the total; however, internal releases do count

Why should my Electron app join?​

Your app's bugs will be tracked and be on the core Electron team's radar. Your feedback helps the Electron team to see how the new betas are doing and what work needs to be done.

Will my application's info be shared publicly? Who gets to see this info?​

No, your application's information will not be shared with the general public. Information is kept in a private GitHub repo that is only viewable to members of the App Feedback Program and Electron Governance. All members have agreed to follow Electron's Code of Conduct.

Sign up​

We are currently accepting a limited number of signups. If you are interested and are able to fulfill the above requirements, please fill out this form.

Release Process​

As we undertook development of v3.0.0, we sought to more empirically define criteria for a stable release by formalizing the feedback progress for progressive beta releases. v3.0.0 would not have been possible without our App Feedback Program partners, who provided early testing and feedback during the beta cycle. Thanks to Atlassian, Atom, Microsoft Teams, Oculus, OpenFin, Slack, Symphony, VS Code, and other program members for their work. If you'd like to participate in future betas, please mail us at info@electronjs.org.

Changes / New Features​

Major bumps to several important parts of Electron's toolchain, including Chrome v66.0.3359.181, Node v10.2.0, and V8 v6.6.346.23.

• [#12656] feat: app.isPackaged
• [#12652] feat: app.whenReady()
• [#13183] feat: process.getHeapStatistics()
• [#12485] feat: win.moveTop() to move window z-order to top
• [#13110] feat: TextField and Button APIs
• [#13068] feat: netLog API for dynamic logging control
• [#13539] feat: enable webview in sandbox renderer
• [#14118] feat: fs.readSync now works with massive files
• [#14031] feat: node fs wrappers to make fs.realpathSync.native and fs.realpath.native available

Breaking API changes​

• [#12362] feat: updates to menu item order control
• [#13050] refactor: removed documented deprecated APIs
  • See docs for more details
• [#12477] refactor: removed did-get-response-details and did-get-redirect-request events
• [#12655] feat: default to disabling navigating on drag/drop
• [#12993] feat: Node v4.x or greater is required use the electron npm module
• [#12008 #12140 #12503 #12514 #12584 #12596 #12637 #12660 #12696 #12716 #12750 #12787 #12858] refactor: NativeWindow
• [#11968] refactor: menu.popup()
• [#8953] feat: no longer use JSON to send the result of ipcRenderer.sendSync
• [#13039] feat: default to ignore command line arguments following a URL
• [#12004] refactor: rename api::Window to api::BrowserWindow
• [#12679] feat: visual zoom now turned off by default
• [#12408] refactor: rename app-command media-play_pause to media-play-pause

macOS​

• [#12093] feat: workspace notifications support
• [#12496] feat: tray.setIgnoreDoubleClickEvents(ignore) to ignore tray double click events.
• [#12281] feat: mouse forward functionality on macOS
• [#12714] feat: screen lock / unlock events

Windows​

• [#12879] feat: added DIP to/from screen coordinate conversions

Nota Bene: Switching to an older version of Electron after running this version will require you to clear out your user data directory to avoid older versions crashing. You can get the user data directory by running console.log(app.getPath("userData")) or see docs for more details.

Bug Fixes​

• [#13397] fix: issue with fs.statSyncNoException throwing exceptions
• [#13476, #13452] fix: crash when loading site with jquery
• [#14092] fix: crash in net::ClientSocketHandle destructor
• [#14453] fix: notify focus change right away rather not on next tick

MacOS​

• [#13220] fix: issue allowing bundles to be selected in <input file="type"> open file dialog
• [#12404] fix: issue blocking main process when using async dialog
• [#12043] fix: context menu click callback
• [#12527] fix: event leak on reuse of touchbar item
• [#12352] fix: tray title crash
• [#12327] fix: non-draggable regions
• [#12809] fix: to prevent menu update while it's open
• [#13162] fix: tray icon bounds not allowing negative values
• [#13085] fix: tray title not inverting when highlighted
• [#12196] fix: Mac build when enable_run_as_node==false
• [#12157] fix: additional issues on frameless windows with vibrancy
• [#13326] fix: to set mac protocol to none after calling app.removeAsDefaultProtocolClient
• [#13530] fix: incorrect usage of private APIs in MAS build
• [#13517] fix: tray.setContextMenu crash
• [#14205] fix: pressing escape on a dialog now closes it even if defaultId is set

Linux​

• [#12507] fix: BrowserWindow.focus() for offscreen windows

Other Notes​

• PDF Viewer is currently not working but is being worked on and will be functional once again soon
• TextField and Button APIs are experimental and are therefore off by default
  • They can be enabled with the enable_view_api build flag

What's Next

The Electron team continues to work on defining our processes for more rapid and smooth upgrades as we seek to ultimately maintain parity with the development cadences of Chromium, Node, and V8.

GYP and GN

When Electron was first released in 2013, Chromium's build configuration was written with GYP, short for "Generate Your Projects".

In 2014, the Chromium project introduced a new build configuration tool called GN (short for "Generate Ninja") Chromium's build files were migrated to GN and GYP was removed from the source code.

Electron has historically kept a separation between the main Electron code and libchromiumcontent, the part of Electron that wraps Chromium's 'content' submodule. Electron has carried on using GYP, while libchromiumcontent -- as a subset of Chromium -- switched to GN when Chromium did.

Like gears that don't quite mesh, there was friction between using the two build systems. Maintaining compatibility was error-prone, from compiler flags and #defines that needed to be meticulously kept in sync between Chromium, Node, V8, and Electron.

To address this, the Electron team has been working on moving everything to GN. Today, the commit to remove the last of the GYP code from Electron was landed in master.

What this means for you

If you're contributing to Electron itself, the process of checking out and building Electron from master or 4.0.0 is very different than it was in 3.0.0 and earlier. See the GN build instructions for details.

If you're developing an app with Electron, there are a few minor changes you might notice in the new Electron 4.0.0-nightly; but more than likely, Electron's change in build system will be totally transparent to you.

What this means for Electron

GN is faster than GYP and its files are more readable and maintainable. Moreover, we hope that using a single build configuration system will reduce the work required to upgrade Electron to new versions of Chromium.

• It's already helped development on Electron 4.0.0 substantially because Chromium 67 removed support for MSVC and switched to building with Clang on Windows. With the GN build, we inherit all the compiler commands from Chromium directly, so we got the Clang build on Windows for free!

• It's also made it easier for Electron to use BoringSSL in a unified build across Electron, Chromium, and Node -- something that was problematic before.

Affected Platforms​

You are impacted if:

1. You embed any remote user content, even in a sandbox
2. You accept user input with any XSS vulnerabilities

Details

You are impacted if any user code runs inside an iframe / can create an iframe. Given the possibility of an XSS vulnerability it can be assumed that most apps are vulnerable to this case.

You are also impacted if you open any of your windows with the nativeWindowOpen: true or sandbox: true option. Although this vulnerability also requires an XSS vulnerability to exist in your app, you should still apply one of the mitigations below if you use either of these options.

Mitigation​

We've published new versions of Electron which include fixes for this vulnerability: 3.0.0-beta.7, 2.0.8, 1.8.8, and 1.7.16. We urge all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can protect your app by blanket-calling event.preventDefault() on the new-window event for all webContents'. If you don't use window.open or any child windows at all then this is also a valid mitigation for your app.

mainWindow.webContents.on('new-window', e => e.preventDefault())

If you rely on the ability of your child windows to make grandchild windows, then a third mitigation strategy is to use the following code on your top level window:

const enforceInheritance = (topWebContents) => {
  const handle = (webContents) => {
    webContents.on('new-window', (event, url, frameName, disposition, options) => {
      if (!options.webPreferences) {
        options.webPreferences = {}
      }
      Object.assign(options.webPreferences, topWebContents.getLastWebPreferences())
      if (options.webContents) {
        handle(options.webContents)
      }
    })
  }
  handle(topWebContents)
}

enforceInheritance(mainWindow.webContents)

This code will manually enforce that the top level windows webPreferences is manually applied to all child windows infinitely deep.

Further Information​

This vulnerability was found and reported responsibly to the Electron project by Matt Austin of Contrast Security.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

Learning a new technology or framework like Electron can be intimidating. Once you get past the quick-start phase, it can be difficult to learn best practices, find the right APIs, or discover the tools that will help you build the app of your dreams. We want the Electron website to be a better tool for finding the resources you need to build apps faster and more easily.

Visit any page on electronjs.org and you'll find the new search input at the top of the page.

The Search Engine​

When we first set about adding search to the website, we rolled our own search engine using GraphQL as a backend. GraphQL was fun to work with and the search engine was performant, but we quickly realized that building a search engine is not a trivial task. Things like multi-word search and typo detection require a lot of work to get right. Rather than reinventing the wheel, we decided to use an existing search solution: Algolia.

Algolia is a hosted search service that has quickly become the search engine of choice among popular open source projects like React, Vue, Bootstrap, Yarn, and many others.

Here are some of the features that made Algolia a good fit for the Electron project:

• InstantSearch.js provides results as you type, usually in about 1ms.
• Typo tolerance means you'll still get results even when you type widnow.
• Advanced query syntax enables "exact quoted matches" and -exclusion.
• API clients are open source and with well-documented.
• Analytics tell us what people are searching for most, as well as what they're searching for but not finding. This will give us valuable insight into how Electron's documentation can be improved.
• Algolia is free for open source projects.

API Docs​

Sometimes you know what you want to accomplish, but you don't know exactly how to do it. Electron has over 750 API methods, events, and properties. No human can easily remember all of them, but computers are good at this stuff. Using Electron's JSON API docs, we indexed all of this data in Algolia, and now you can easily find the exact API you're looking for.

Trying to resize a window? Search for resize and jump straight to the method you need.

Tutorials​

Electron has an ever-growing collection of tutorials to complement its API documentation. Now you can more easily find tutorials on a given topic, right alongside related API documentation.

Looking for security best practices? Search for security.

npm Packages​

There are now over 700,000 packages in the npm registry and it's not always easy to find the one you need. To make it easier to discover these modules, we've created electron-npm-packages, a collection of the 3400+ modules in the registry that are built specifically for use with Electron.

The folks at Libraries.io have created SourceRank, a system for scoring software projects based on a combination of metrics like code, community, documentation, and usage. We created a sourceranks module that includes the score of every module in the npm registry, and we use these scores to sort the package results.

Want alternatives to Electron's built-in IPC modules? Search for is:package ipc.

Electron Apps​

It's easy to index data with Algolia, so we added the existing apps list from electron/apps.

Try a search for music or homebrew.

Filtering Results​

If you've used GitHub's code search before, you're probably aware of its colon-separated key-value filters like extension:js or user:defunkt. We think this filtering technique is pretty powerful, so we've added an is: keyword to Electron's search that lets you filter results to only show a single type:

• is:api thumbnail
• is:tutorial security
• is:package ipc
• is:app graphql

Keyboard Navigation​

People love keyboard shortcuts! The new search can be used without taking your fingers off the keyboard:

• / focuses the search input
• esc focuses the search input and clears it
• down moves to the next result
• up moves to the previous result, or the search input
• enter opens a result

We also open-sourced the module that enables this keyboard interaction. It's designed for use with Algolia InstantSearch, but is generalized to enable compatibility with different search implementations.

We want your feedback​

If you encounter any issues with the new search tool, we want to hear about it!

The best way to submit your feedback is by filing an issue on GitHub in the appropriate repository:

• electron/electronjs.org is the Electron website. If you don't know where to file an issue, this your best bet.
• electron/algolia-indices is where all the searchable Electron data is compiled.
• electron/search-with-your-keyboard makes the search interface navigable by keyboard.
• algolia/instantsearch.js is the browser-side client that enables find-as-you-type search.
• algolia/algoliasearch-client-javascript is the Node.js client for uploading data to Algolia's servers.

Thanks​

Special thanks to Emily Jordan and Vanessa Yuen for building these new search capabilities, to Libraries.io for providing SourceRank scores, and to the team at Algolia for helping us get started. 🍹

So here we are with some exciting i18n updates!

🌐 Language Toggle​

Did you know that many people who read translated documentation often cross reference that with the original English documentation? They do this to familiarize themselves with English docs, and to avoid outdated or inaccurate translations, which is one caveat of internationalized documentations.

To make cross-referencing to English docs easier, we recently shipped a feature that allows you to seamlessly toggle a section of the Electron documentation between English and whatever language you're viewing the website in. The language toggle will show up as long as you have a non-English locale selected on the website.

⚡️ Quick Access to Translation Page​

Notice a typo or an incorrect translation while you're reading the documentation? You no longer have to log in to Crowdin, pick your locale, find the file you'd like the fix, etc etc. Instead, you can just scroll down to the bottom of the said doc, and click "Translate this doc" (or the equivalent in your language). Voila! You are brought straight to the Crowdin translation page. Now apply your translation magic!

📈 Some Statistics​

Ever since we have publicized the Electron documentation i18n effort, we have seen huge growth in translation contributions from Electron community members from all around the world. To date, we have 1,719,029 strings translated, from 1,066 community translators, and in 25 languages.

Here is a fun graph showing the approximate amount of time needed to translate the project into each language if the existing tempo (based on the project activity during the last 14 days at the time of writing) is preserved.

📃 Translator Survey​

We would like to give a huge ❤️ thank you ❤️ to everyone who has contributed their time to help improving Electron! In order to properly acknowledge the hard work of our translator community, we have created a survey to collect some information (namely the mapping between their Crowdin and Github usernames) about our translators.

If you are one of our incredible translators, please take a few minutes to fill this out: https://goo.gl/forms/b46sjdcHmlpV0GKT2.

🙌 Node's Internationalization Effort​

Because of the success of Electron's i18n initiative, Node.js decided to model their revamped i18n effort after the pattern we use as well! 🎉 The Node.js i18n initiative has now been launched and gained great momentum, but you can stil read about the early proposal and reasoning behind it here.

🔦 Contributing Guide​

If you're interested in joining our effort to make Electron more international friendly, we have a handy-dandy contributing guide to help you get started. Happy internationalizing! 📚

Release Process​

Starting with 2.0.0, Electron's releases will follow semantic versioning. This means the major version will bump more often and will usually be a major update to Chromium. Patch releases should be more stable because they will contain only high-priority bug fixes.

Electron 2.0.0 also represents an improvement to how Electron is stabilized before a major release. Several large scale Electron apps have included 2.0.0 betas in staged rollouts, providing the best feedback loop Electron's ever had for a beta series.

Changes / New Features​

• Major bumps to several important parts of Electron's toolchain, including Chrome 61, Node 8.9.3, V8 6.1.534.41, GTK+ 3 on Linux, updated spellchecker, and Squirrel.
• In-app purchases are now supported on MacOS. #11292
• New API for loading files. #11565
• New API to enable/disable a window. #11832
• New API app.setLocale(). #11469
• New support for logging IPC messages. #11880
• New menu events. #11754
• Add a shutdown event to powerMonitor. #11417
• Add affinity option for gathering several BrowserWindows into a single process. #11501
• Add the ability for saveDialog to list available extensions. #11873
• Support for additional notification actions #11647
• The ability to set macOS notification close button title. #11654
• Add conditional for menu.popup(window, callback)
• Memory improvements in touchbar items. #12527
• Improved security recommendation checklist.
• Add App-Scoped Security scoped bookmarks. #11711
• Add ability to set arbitrary arguments in a renderer process. #11850
• Add accessory view for format picker. #11873
• Fixed network delegate race condition. #12053
• Drop support for the mips64el arch on Linux. Electron requires the C++14 toolchain, which was not available for that arch at the time of the release. We hope to re-add support in the future.

Breaking API changes​

• Removed deprecated APIs, including:
  • Changed menu.popup signature. #11968
  • Removed deprecated crashReporter.setExtraParameter #11972
  • Removed deprecated webContents.setZoomLevelLimits and webFrame.setZoomLevelLimits. #11974
  • Removed deprecated clipboard methods. #11973
  • Removed support for boolean parameters for tray.setHighlightMode. #11981

Bug Fixes​

• Changed to make sure webContents.isOffscreen() is always available. #12531
• Fixed BrowserWindow.getFocusedWindow() when DevTools is undocked and focused. #12554
• Fixed preload not loading in sandboxed render if preload path contains special chars. #12643
• Correct the default of allowRunningInsecureContent as per docs. #12629
• Fixed transparency on nativeImage. #12683
• Fixed issue with Menu.buildFromTemplate. #12703
• Confirmed menu.popup options are objects. #12330
• Removed a race condition between new process creation and context release. #12361
• Update draggable regions when changing BrowserView. #12370
• Fixed menubar toggle alt key detection on focus. #12235
• Fixed incorrect warnings in webviews. #12236
• Fixed inheritance of 'show' option from parent windows. #122444
• Ensure that getLastCrashReport() is actually the last crash report. #12255
• Fixed require on network share path. #12287
• Fixed context menu click callback. #12170
• Fixed popup menu position. #12181
• Improved libuv loop cleanup. #11465
• Fixed hexColorDWORDToRGBA for transparent colors. #11557
• Fixed null pointer dereference with getWebPreferences api. #12245
• Fixed a cyclic reference in menu delegate. #11967
• Fixed protocol filtering of net.request. #11657
• WebFrame.setVisualZoomLevelLimits now sets user-agent scale constraints #12510
• Set appropriate defaults for webview options. #12292
• Improved vibrancy support. #12157 #12171 #11886
• Fixed timing issue in singleton fixture.
• Fixed broken production cache in NotifierSupportsActions()
• Made MenuItem roles camelCase-compatible. #11532
• Improved touch bar updates. #11812, #11761.
• Removed extra menu separators. #11827
• Fixed Bluetooth chooser bug. Closes #11399.
• Fixed macos Full Screen Toggle menu item label. #11633
• Improved tooltip hiding when a window is deactivated. #11644
• Migrated deprecated web-view method. #11798
• Fixed closing a window opened from a browserview. #11799
• Fixed Bluetooth chooser bug. #11492
• Updated to use task scheduler for app.getFileIcon API. #11595
• Changed to fire console-message event even when rendering offscreen. #11921
• Fixed downloading from custom protocols using WebContents.downloadURL. #11804
• Fixed transparent windows losing transparency when devtools detaches. #11956
• Fixed Electron apps canceling restart or shutdown. #11625

macOS​

• Fixed event leak on reuse of touchbar item. #12624
• Fixed tray highlight in darkmode. #12398
• Fixed blocking main process for async dialog. #12407
• Fixed setTitle tray crash. #12356
• Fixed crash when setting dock menu. #12087

Linux​

• Better Linux desktop notifications. #12229 #12216 #11965 #11980
• Better GTK+ theme support for menus. #12331
• Exit gracefully on linux. #12139
• Use the app’s name as the tray icon's default tooltip. #12393

Windows​

• Added Visual Studio 2017 support. #11656
• Fixed passing of exception to the system crash handler. #12259
• Fixed hiding tooltip from minimized window. #11644
• Fixed desktopCapturer to capture the correct screen. #11664
• Fixed disableHardwareAcceleration with transparency. #11704

What's Next

The Electron team is hard at work to support newer versions of Chromium, Node, and v8. Expect 3.0.0-beta.1 soon!

Making life easier​

Electron has an autoUpdater API that gives apps the ability to consume metadata from a remote endpoint to check for updates, download them in the background, and install them automatically.

Enabling these updates has been a cumbersome step in the deployment process for many Electron app developers because it requires a web server to be deployed and maintained just to serve app version history metadata.

Today we are announcing a new drop-in solution for automatic app updates. If your Electron app is in a public GitHub repository and you're using GitHub Releases to publish builds, you can use this service to deliver continuous app updates to your users.

Using the new module​

To minimize configuration on your part, we've created update-electron-app, an npm module which integrates with the new update.electronjs.org webservice.

Install the module:

npm install update-electron-app

Call it from anywhere in your app's main process:

require('update-electron-app')()

That's it! The module will check for updates at app startup, then every ten minutes. When an update is found it will download automically in the background, and a dialog will be displayed when the update is ready.

Migrating existing apps​

Apps already using Electron's autoUpdater API can use this service too. To do so, you can customize the update-electron-app module or integrate directly with update.electronjs.org.

Alternatives​

If you're using electron-builder to package your app, you can use its built-in updater. For details, see electron.build/auto-update.

If your app is private, you may need to run your own update server. There are a number of open-source tools for this, including Zeit's Hazel and Atlassian's Nucleus. See the Deploying an Update Server tutorial for more info.

Thanks​

Thanks to Julian Gruber for helping design and build this simple and scalable web service. Thanks to the folks at Zeit for their open-source Hazel service, from which we drew design inspiration. Thanks to Samuel Attard for the code reviews. Thanks to the Electron community for helping test this service.

🌲 Here's to an evergreen future for Electron apps!

In-app purchases enable content or subscriptions to be purchased directly from within apps. This gives developers an easy way to embrace the freemium business model, wherein users pay nothing to download an app and are offered optional in-app purchases for premium features, additional content, or subscriptions.

The new API was added to Electron by community contributor Adrien Fery to enable in-app purchases in Amanote, a note-taking Electron app for lectures and conferences. Amanote is free to download and allows clear and structured notes to be added to PDFs, with features like mathematical formulae, drawings, audio recording, and more.

Since adding in-app purchase support to the Mac version of Amanote, Adrien has noted a 40% increase in sales!

Getting Started​

The new inAppPurchase API has already landed in the latest Electron beta:

npm i -D electron@beta

The docs for the API can be found on GitHub, and Adrien has been kind enough to write a tutorial on how to use the API. To get started adding in-app purchases to your app, see the tutorial.

More improvements to the API are in the works, and will soon be landing in an upcoming Electron beta release.

Windows Could Be Next​

Up next, Adrien is hoping to open a new revenue channel for Amanote by adding support for Microsoft Store in-app purchases in Electron. Stay tuned for developments on that!

Affected Applications​

An application is affected if all of the following are true:

1. Runs on Electron 1.7, 1.8, or a 2.0.0-beta
2. Allows execution of arbitrary remote code
3. Disables Node.js integration
4. Does not explicitly declare webviewTag: false in its webPreferences
5. Does not enable the nativeWindowOption option
6. Does not intercept new-window events and manually override event.newGuest without using the supplied options tag

Although this appears to be a minority of Electron applicatons, we encourage all applications to be upgraded as a precaution.

Mitigation​

This vulnerability is fixed in today's 1.7.13, 1.8.4, and 2.0.0-beta.5 releases.

Developers who are unable to upgrade their application's Electron version can mitigate the vulnerability with the following code:

app.on('web-contents-created', (event, win) => {
  win.on('new-window', (event, newURL, frameName, disposition,
                        options, additionalFeatures) => {
    if (!options.webPreferences) options.webPreferences = {};
    options.webPreferences.nodeIntegration = false;
    options.webPreferences.nodeIntegrationInWorker = false;
    options.webPreferences.webviewTag = false;
    delete options.webPreferences.preload;
  })
})

// and *IF* you don't use WebViews at all,
// you might also want
app.on('web-contents-created', (event, win) => {
  win.on('will-attach-webview', (event, webPreferences, params) => {
    event.preventDefault();
  })
})

Further Information​

This vulnerability was found and reported responsibly to the Electron project by Brendan Scarvell of Trustwave SpiderLabs.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

To report a vulnerability in Electron, please email security@electronjs.org.

Please join our email list to receive updates about releases and security updates.

To prevent this kind of downtime in the future, we've enabled Heroku threshold alerts on our app. Any time our web server accumulates failed requests or slow responses beyond a certain threshold, our team will be notified so we can address the problem quickly.

Offline Docs in Every Language​

The next time you're developing an Electron app on a plane or in a subterranean coffee shop, you might want to have a copy of the docs for offline reference. Fortunately, Electron's docs are available as Markdown files in over 20 languages.

git clone https://github.com/electron/electron-i18n
ls electron-i18n/content

Offline Docs with a GUI​

devdocs.io/electron is a handy website that stores docs for offline use, not just for Electron but many other projects like JavaScript, TypeScript, Node.js, React, Angular, and many others. And of course there's an Electron app for that, too. Check out devdocs-app on the Electron site.

If you like to install apps without using your mouse or trackpad, give Electron Forge's install command a try:

npx electron-forge install egoist/devdocs-app

Affected Platforms​

Electron apps designed to run on Windows that register themselves as the default handler for a protocol, like myapp://, are vulnerable.

Such apps can be affected regardless of how the protocol is registered, e.g. using native code, the Windows registry, or Electron's app.setAsDefaultProtocolClient API.

macOS and Linux are not vulnerable to this issue.

Mitigation​

We've published new versions of Electron which include fixes for this vulnerability: 1.8.2-beta.5, 1.7.12, and 1.6.17. We urge all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can append -- as the last argument when calling app.setAsDefaultProtocolClient, which prevents Chromium from parsing further options. The double dash -- signifies the end of command options, after which only positional parameters are accepted.

app.setAsDefaultProtocolClient(protocol, process.execPath, [
  '--your-switches-here',
  '--'
])

See the app.setAsDefaultProtocolClient API for more details.

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

If you wish to report a vulnerability in Electron, email security@electronjs.org.

This change means you'll see the major version bump more often, and it will usually be a major update to Chromium. Patch releases will also be more stable, as they will now only contain bug fixes with no new features.

Major Version Increments

• Chromium version updates
• Node.js major version updates
• Electron breaking API changes

Minor Version Increments

• Node.js minor version updates
• Electron non-breaking API changes

Patch Version Increments

• Node.js patch version updates
• fix-related chromium patches
• Electron bug fixes

Because Electron's semver ranges will now be more meaningful, we recommend installing Electron using npm's default --save-dev flag, which will prefix your version with ^, keeping you safely up to date with minor and patch updates:

npm install --save-dev electron

For developers interested only in bug fixes, you should use the tilde semver prefix e.g. ~2.0.0, which which will never introduce new features, only fixes to improve stability.

For more details, see electronjs.org/docs/tutorial/electron-versioning.

🌍 Translations​

We've begun the process of internationalizing the website with the goal of making Electron app development accessible to a global audience of developers. We're using a localization platform called Crowdin that integrates with GitHub, opening and updating pull requests automatically as content is translated into different languages.

Though we've been working quietly on this effort so far, over 75 Electron community members have already discovered the project organically and joined in the effort to internationalize the website and translate Electron's docs into over 20 languages. We are seeing daily contributions from people all over the world, with translations for languages like French, Vietnamese, Indonesian, and Chinese leading the way.

To choose your language and view translation progress, visit electronjs.org/languages

If you're multilingual and interested in helping translate Electron's docs and website, visit the electron/electron-i18n repo, or jump right into translating on Crowdin, where you can sign in using your GitHub account.

There are currently 21 languages enabled for the Electron project on Crowdin. Adding support for more languages is easy, so if you're interested in helping translate but you don't see your language listed, let us know and we'll enable it.

Raw Translated Docs​

If you prefer to read documentation in raw markdown files, you can now do that in any language:

git clone https://github.com/electron/electron-i18n
ls electron-i18n/content

App Pages​

As of today, any Electron app can easily have its own page on the Electron site. For a few examples, check out Etcher, 1Clipboard, or GraphQL Playground, pictured here on the Japanese version of the site:

There are some incredible Electron apps out there, but they're not always easy to find, and not every developer has the time or resources to build a proper website to market and distribute their app.

Using just a PNG icon file and a small amount of app metadata, we're able to collect a lot of information about a given app. Using data collected from GitHub, app pages can now display screenshots, download links, versions, release notes, and READMEs for every app that has a public repository. Using a color palette extracted from each app's icon, we can produce bold and accessible colors to give each app page some visual distinction.

The apps index page now also has categories and a keyword filter to find interesting apps like GraphQL GUIs and p2p tools.

If you've got an Electron app that you'd like featured on the site, open a pull request on the electron/electron-apps repository.

One-line Installation with Homebrew​

The Homebrew package manager for macOS has a subcommand called cask that makes it easy to install desktop apps using a single command in your terminal, like brew cask install atom.

We've begun collecting Homebrew cask names for popular Electron apps and are now displaying the installation command (for macOS visitors) on every app page that has a cask:

To view all the apps that have homebrew cask names, visit electronjs.org/apps?q=homebrew. If you know of other apps with casks that we haven't indexed yet, please add them!

🌐 A New Domain​

We've moved the site from electron.atom.io to a new domain: electronjs.org.

The Electron project was born inside Atom, GitHub's open-source text editor built on web technologies. Electron was originally called atom-shell. Atom was the first app to use it, but it didn't take long for folks to realize that this magical Chromium + Node runtime could be used for all kinds of different applications. When companies like Microsoft and Slack started to make use of atom-shell, it became clear that the project needed a new name.

And so "Electron" was born. In early 2016, GitHub assembled a new team to focus specifically on Electron development and maintenance, apart from Atom. In the time since, Electron has been adopted by thousands of app developers, and is now depended on by many large companies, many of which have Electron teams of their own.

Supporting GitHub's Electron projects like Atom and GitHub Desktop is still a priority for our team, but by moving to a new domain we hope to help clarify the technical distinction between Atom and Electron.

🐢🚀 Node.js Everywhere​

The previous Electron website was built with Jekyll, the popular Ruby-based static site generator. Jekyll is a great tool for building static websites, but the website had started to outgrow it. We wanted more dynamic capabilities like proper redirects and dynamic content rendering, so a Node.js server was the obvious choice.

The Electron ecosystem includes projects with components written in many different programming languages, from Python to C++ to Bash. But JavaScript is foundational to Electron, and it's the language used most in our community.

By migrating the website from Ruby to Node.js, we aim to lower the barrier to entry for people wishing to contribute to the website.

⚡️ Easier Open-Source Participation​

If you've got Node.js (8 or higher) and git installed on your system, you can easily get the site running locally:

git clone https://github.com/electron/electronjs.org
cd electronjs.org
npm install
npm run dev

The new website is hosted on Heroku. We use deployment pipelines and the Review Apps feature, which automatically creates a running copy of the app for every pull request. This makes it easy for reviewers to view the actual effects of a pull request on a live copy of the site.

🙏 Thanks to Contributors​

We'd like to give special thanks to all the folks around the world who have contributed their own time and energy to help improve Electron. The passion of the open-source community has helped immeasurably in making Electron a success. Thank you!

We've published two new versions of electron 1.7.8 and 1.6.14, both of which include a fix for this vulnerability. We urge all Electron developers to update their apps to the latest stable version immediately:

npm i electron@latest --save-dev

To learn more about best practices for keeping your Electron apps secure, see our security tutorial.

Please contact security@electronjs.org if you wish to report a vulnerability in Electron.

TypeScript is an open-source programming language created by Microsoft. It's a superset of JavaScript that extends the language by adding support for static types. The TypeScript community has grown quickly in recent years, and TypeScript was ranked among the most loved programming languages in a recent Stack Overflow developer survey. TypeScript is described as "JavaScript that scales", and teams at GitHub, Slack, and Microsoft are all using it to write scalable Electron apps that are used by millions of people.

TypeScript supports many of the newer language features in JavaScript like classes, object destructuring, and async/await, but its real differentiating feature is type annotations. Declaring the input and output datatypes expected by your program can reduce bugs by helping you find errors at compile time, and the annotations can also serve as a formal declaration of how your program works.

When libraries are written in vanilla Javascript, the types are often vaguely defined as an afterthought when writing documentation. Functions can often accept more types than what was documented, or a function can have invisible constraints that are not documented, which can lead to runtime errors.

TypeScript solves this problem with definition files. A TypeScript definition file describes all the functions of a library and its expected input and output types. When library authors bundle a TypeScript definition file with their published library, consumers of that library can explore its API right inside their editor and start using it right away, often without needing to consult the library's documentation.

Many popular projects like Angular, Vue.js, node-github (and now Electron!) compile their own definition file and bundle it with their published npm package. For projects that don't bundle their own definition file, there is DefinitelyTyped, a third-party ecosystem of community-maintained definition files.

Installation​

Starting at version 1.6.10, every release of Electron includes its own TypeScript definition file. When you install the electron package from npm, the electron.d.ts file is bundled automatically with the installed package.

The safest way to install Electron is using an exact version number:

npm install electron --save-dev --save-exact

Or if you're using yarn:

yarn add electron --dev --exact

If you were already using third-party definitions like @types/electron and @types/node, you should remove them from your Electron project to prevent any collisions.

The definition file is derived from our structured API documentation, so it will always be consistent with Electron's API documentation. Just install electron and you'll always get TypeScript definitions that are up to date with the version of Electron you're using.

Usage​

For a summary of how to install and use Electron's new TypeScript annotations, watch this short demo screencast:

If you're using Visual Studio Code, you've already got TypeScript support built in. There are also community-maintained plugins for Atom, Sublime, vim, and other editors.

Once your editor is configured for TypeScript, you'll start to see more context-aware behavior like autocomplete suggestions, inline method reference, argument checking, and more.

Getting started with TypeScript​

If you're new to TypeScript and want to learn more, this introductory video from Microsoft provides a nice overview of why the language was created, how it works, how to use it, and where it's headed.

There's also a handbook and a playground on the official TypeScript website.

Because TypeScript is a superset of JavaScript, your existing JavaScript code is already valid TypeScript. This means you can gradually transition an existing JavaScript project to TypeScript, sprinkling in new language features as needed.

Thanks​

This project would not have been possible without the help of Electron's community of open-source maintainers. Thanks to Samuel Attard, Felix Rieseberg, Birunthan Mohanathas, Milan Burda, Brendan Forster, and many others for their bug fixes, documentation improvements, and technical guidance.

Support​

If you encounter any issues using Electron's new TypeScript definition files, please file an issue on the electron-typescript-definitions repository.

Happy TypeScripting!

Hello! Who are you?​

I'm Ryo Maruyama, a software developer in Japan. I am developing Jasper and ESDoc.

What is Jasper?​

Jasper is a flexible and powerful issue reader for GitHub. It supports issues and pull requests on github.com and GitHub Enterprise.

Why did you make it?​

When people use GitHub in their job or OSS activities, they tend to receive many notifications on a daily basis. As a way to subscribe to the notifications, GitHub provides email and web notifications. I used these for a couple of years, but I faced the following problems:

• It's easy to overlook issues where I was mentioned, I commented, or I am watching.
• I put some issues in a corner of my head to check later, but I sometimes forget about them.
• To not forget issues, I keep many tabs open in my browser.
• It's hard to check all issues that are related to me.
• It's hard to grasp all of my team's activity.

I was spending a lot of time and energy trying to prevent those problems, so I decided to make an issue reader for GitHub to solve these problems efficiently, and started developing Jasper.

Who's using Jasper?​

Jasper is used by developers, designers, and managers in several companies that are using GitHub. Of course, some OSS developers also are using it. And it is also used by some people at GitHub!

How does Jasper work?​

Once Jasper is configured, the following screen appears. From left to right, you can see "streams list", "issues list" and "issue body".

This "stream" is the core feature of Jasper. For example, if you want to see "issues that are assigned to @zeke in the electron/electron repository", you create the following stream:

repo:electron/electron assignee:zeke is:issue

After creating the stream and waiting for a few seconds, you can see the issues that meet the conditions.

What can we do with streams?​

I will introduce what kind of conditions can be used for stream.

Users and Teams​

involves means mention, author, assignee or commenter

Repositories and Organizations​

org is same as user

Attributes​

Review Status​

As you may have noticed by looking at these, streams can use GitHub's search queries. For details on how to use streams and search queries, see the following URLs.

• jasperapp.io/doc.html#stream
• help.github.com/articles/searching-issues
• help.github.com/articles/search-syntax

Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.

Is Jasper a paid product? How much does it cost?​

Jasper is $12. However you can use the free trial edition for 30 days.

Why did you choose to build Jasper on Electron?​

I like the following aspects of Electron:

• Apps can be developed with JavaScript/CSS/HTML.
• Apps can be built for Windows, Mac, and Linux platforms.
• Electron is actively developed and has a large community.

These features enable rapid and simple desktop application development. It is awesome! If you have any product idea, you should consider using Electron by all means.

What are some challenges you've faced while developing Jasper?​

I had a hard time figuring out the "stream" concept. At first I considered using GitHub's Notifications API. However I noticed that it does not support certain use cases. After that I considered using the Issues API and Pull Requests API, in addition to the Notification API. But it never became what I wanted. Then while thinking about various methods, I realized that polling GitHub's Search API would offer the most flexibility. It took about a month of experimentation to get to this point, then I implemented a prototype of Jasper with the stream concept in two days.

Note: The polling is limited to once every 10 seconds at most. This is acceptable enough for the restriction of GitHub API.

What's coming next?​

I have a plan to develop the following features:

• A filtered stream: A stream has some filtered stream that filter issues in the stream. It is like as view of SQL.
• Multiple accounts: you will be able to use both github.com and GHE
• Improve performance: For now the loading a issue in WebView is low speed than normal browser.

Follow @jasperappio on Twitter for updates.

What is WebTorrent?​

WebTorrent is the first torrent client that works in the browser. It's written completely in JavaScript and it can use WebRTC for peer-to-peer transport. No browser plugin, extension, or installation is required.

Using open web standards, WebTorrent connects website users together to form a distributed, decentralized browser-to-browser network for efficient file transfer.

You can see a demo of WebTorrent in action here: webtorrent.io.

Why is this cool?​

Imagine a video site like YouTube, but where visitors help to host the site's content. The more people that use a WebTorrent-powered website, the faster and more resilient it becomes.

Browser-to-browser communication cuts out the middle-man and lets people communicate on their own terms. No more client/server – just a network of peers, all equal. WebTorrent is the first step in the journey to re-decentralize the Web.

Where does Electron come into the picture?​

About one year ago, we decided to build WebTorrent Desktop, a version of WebTorrent that runs as a desktop app.

We created WebTorrent Desktop for three reasons:

1. We wanted a clean, lightweight, ad-free, open source torrent app
2. We wanted a torrent app with good streaming support
3. We need a "hybrid client" that connects the BitTorrent and WebTorrent networks

If we can already download torrents in my web browser, why a desktop app?​

First, a bit of background on the design of WebTorrent.

In the early days, BitTorrent used TCP as its transport protocol. Later, uTP came along promising better performance and additional advantages over TCP. Every mainstream torrent client eventually adopted uTP, and today you can use BitTorrent over either protocol. The WebRTC protocol is the next logical step. It brings the promise of interoperability with web browsers – one giant P2P network made up of all desktop BitTorrent clients and millions of web browsers.

“Web peers” (torrent peers that run in a web browser) make the BitTorrent network stronger by adding millions of new peers, and spreading BitTorrent to dozens of new use cases. WebTorrent follows the BitTorrent spec as closely as possible, to make it easy for existing BitTorrent clients to add support for WebTorrent.

Some torrent apps like Vuze already support web peers, but we didn't want to wait around for the rest to add support. So basically, WebTorrent Desktop was our way to speed up the adoption of the WebTorrent protocol. By making an awesome torrent app that people really want to use, we increase the number of peers in the network that can share torrents with web peers (i.e. users on websites).

What are some interesting use cases for torrents beyond what people already know they can do?​

One of the most exciting uses for WebTorrent is peer-assisted delivery. Non-profit projects like Wikipedia and the Internet Archive could reduce bandwidth and hosting costs by letting visitors chip in. Popular content can be served browser-to-browser, quickly and cheaply. Rarely-accessed content can be served reliably over HTTP from the origin server.

The Internet Archive actually already updated their torrent files so they work great with WebTorrent. So if you want to embed Internet Archive content on your site, you can do it in a way that reduces hosting costs for the Archive, allowing them to devote more money to actually archiving the web!

There are also exciting business use cases, from CDNs to app delivery over P2P.

What are some of your favorite projects that use WebTorrent?​

The coolest thing built with WebTorrent, hands down, is probably Gaia 3D Star Map. It's a slick 3D interactive simulation of the Milky Way. The data loads from a torrent, right in your browser. It's awe-inspiring to fly through our star system and realize just how little we humans are compared to the vastness of our universe.

You can read about how this was made in Torrenting The Galaxy, a blog post where the author, Charlie Hoey, explains how he built the star map with WebGL and WebTorrent.

We're also huge fans of Brave. Brave is a browser that automatically blocks ads and trackers to make the web faster and safer. Brave recently added torrent support, so you can view traditional torrents without using a separate app. That feature is powered by WebTorrent.

So, just like how most browsers can render PDF files, Brave can render magnet links and torrent files. They're just another type of content that the browser natively supports.

One of the co-founders of Brave is actually Brendan Eich, the creator of JavaScript, the language we wrote WebTorrent in, so we think it's pretty cool that Brave chose to integrate WebTorrent.

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

There is a meme that Electron apps are "bloated" because they include the entire Chrome content module in every app. In some cases, this is partially true (an Electron app installer is usually ~40MB, where an OS-specific app installer is usually ~20MB).

However, in the case of WebTorrent Desktop, we use nearly every Electron feature, and many dozens of Chrome features in the course of normal operation. If we wanted to implement these features from scratch for each platform, it would have taken months or years longer to build our app, or we would have only been able to release for a single platform.

Just to get an idea, we use Electron's dock integration (to show download progress), menu bar integration (to run in the background), protocol handler registration (to open magnet links), power save blocker (to prevent sleep during video playback), and automatic updater. As for Chrome features, we use plenty: the <video> tag (to play many different video formats), the <track> tag (for closed captions support), drag-and-drop support, and WebRTC (which is non-trivial to use in a native app).

Not to mention: our torrent engine is written in JavaScript and assumes the existence of lots of Node APIs, but especially require('net') and require('dgram') for TCP and UDP socket support.

Basically, Electron is just what we needed and had the exact set of features we needed to ship a solid, polished app in record time.

What are your favorite things about Electron?​

The WebTorrent library has been in development as an open source side project for two years. We made WebTorrent Desktop in four weeks. Electron is the primary reason that we were able to build and ship our app so quickly.

Just as Node.js made server programming accessible to a generation of jQuery-using front-end programmers, Electron makes native app development accessible to anyone familiar with Web or Node.js development. Electron is extremely empowering.

Do the website and the Desktop client share code?​

Yes, the webtorrent npm package works in Node.js, in the browser, and in Electron. The exact same code can run in all environments – this is the beauty of JavaScript. It's today's universal runtime. Java Applets promised "Write Once, Run Anywhere" apps, but that vision never really materialized for a number of reasons. Electron, more than any other platform, actually gets pretty darn close to that ideal.

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

In early versions of the app, we struggled to make the UI performant. We put the torrent engine in the same renderer process that draws the main app window which, predictably, led to slowness anytime there was intense CPU activity from the torrent engine (like verifying the torrent pieces received from peers).

We fixed this by moving the torrent engine to a second, invisible renderer process that we communicate with over IPC. This way, if that process briefly uses a lot of CPU, the UI thread will be unaffected. Buttery-smooth scrolling and animations are so satisfying.

Note: we had to put the torrent engine in a renderer process, instead of a "main" process, because we need access to WebRTC (which is only available in the renderer.)

In what areas should Electron be improved?​

One thing we'd love to see is better documentation about how to build and ship production-ready apps, especially around tricky subjects like code signing and auto-updating. We had to learn about best practices by digging into source code and asking around on Twitter!

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

We think the current version of WebTorrent Desktop is excellent, but there's always room for improvement. We're currently working on improving polish, performance, subtitle support, and video codec support.

If you're interested in getting involved in the project, check out our GitHub page!

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

Feross, one of the WebTorrent Desktop contributors, recently gave a talk "Real world Electron: Building Cross-platform desktop apps with JavaScript" at NodeConf Argentina that contains useful tips for releasing a polished Electron app. The talk is especially useful if you're at the stage where you have a basic working app and you're trying to take it to the next level of polish and professionalism.

Watch here:

Slides here:

DC, another WebTorrent contributor, wrote a checklist of things you can do to make your app feel polished and native. It comes with code examples and covers things like macOS dock integration, drag-and-drop, desktop notifications, and making sure your app loads quickly.

The new Touch Bar API allows you to add buttons, labels, popovers, color pickers, sliders, and spacers. These elements can be dynamically updated and also emit events when they are interacted with.

This is the first release of this API so it will be evolving over the next few Electron releases. Please check out the release notes for further updates and open issues for any problems or missing functionality.

You can install this version via npm install electron@beta and learn more about it in the TouchBar and BrowserWindow Electron docs.

Big thanks to @MarshallOfSound for contributing this to Electron. 🎉

Touch Bar Example​

Below is an example of creating a simple slot machine game in the touch bar. It demonstrates how to create a touch bar, style the items, associate it with a window, handle button click events, and update the labels dynamically.

const {app, BrowserWindow, TouchBar} = require('electron')

const {TouchBarButton, TouchBarLabel, TouchBarSpacer} = TouchBar

let spinning = false

// Reel labels
const reel1 = new TouchBarLabel()
const reel2 = new TouchBarLabel()
const reel3 = new TouchBarLabel()

// Spin result label
const result = new TouchBarLabel()

// Spin button
const spin = new TouchBarButton({
  label: '🎰 Spin',
  backgroundColor: '#7851A9',
  click: () => {
    // Ignore clicks if already spinning
    if (spinning) {
      return
    }

    spinning = true
    result.label = ''

    let timeout = 10
    const spinLength = 4 * 1000 // 4 seconds
    const startTime = Date.now()

    const spinReels = () => {
      updateReels()

      if ((Date.now() - startTime) >= spinLength) {
        finishSpin()
      } else {
        // Slow down a bit on each spin
        timeout *= 1.1
        setTimeout(spinReels, timeout)
      }
    }

    spinReels()
  }
})

const getRandomValue = () => {
  const values = ['🍒', '💎', '7️⃣', '🍊', '🔔', '⭐', '🍇', '🍀']
  return values[Math.floor(Math.random() * values.length)]
}

const updateReels = () => {
  reel1.label = getRandomValue()
  reel2.label = getRandomValue()
  reel3.label = getRandomValue()
}

const finishSpin = () => {
  const uniqueValues = new Set([reel1.label, reel2.label, reel3.label]).size
  if (uniqueValues === 1) {
    // All 3 values are the same
    result.label = '💰 Jackpot!'
    result.textColor = '#FDFF00'
  } else if (uniqueValues === 2) {
    // 2 values are the same
    result.label = '😍 Winner!'
    result.textColor = '#FDFF00'
  } else {
    // No values are the same
    result.label = '🙁 Spin Again'
    result.textColor = null
  }
  spinning = false
}

const touchBar = new TouchBar([
  spin,
  new TouchBarSpacer({size: 'large'}),
  reel1,
  new TouchBarSpacer({size: 'small'}),
  reel2,
  new TouchBarSpacer({size: 'small'}),
  reel3,
  new TouchBarSpacer({size: 'large'}),
  result
])

let window

app.once('ready', () => {
  window = new BrowserWindow({
    frame: false,
    titleBarStyle: 'hidden-inset',
    width: 200,
    height: 200,
    backgroundColor: '#000'
  })
  window.loadURL('about:blank')
  window.setTouchBar(touchBar)
})

What is Voltra?​

Voltra is a music player for people who want to own their music. It’s also a store where you can discover and buy new music based on what you already own. It’s ad-free, cross-platform for desktop and mobile. It also doesn’t spy on you.

Who is Voltra for?​

Anyone who listens to music.

What motivated you to create Voltra?​

Radio has has always had a big share of listeners. It’s moving off the airwaves and onto the Internet. Now you can rent music on demand — it’s a radio revival! A lot of new products and services have emerged because of this, but streaming radio still leaves someone else in control of your music and how you experience it.

We wanted a product that was entirely focused on music you own. Something that made it easy to discover and buy new music directly from artists or labels.

Is there a free version?​

The desktop player is completely free. Selling your music is also free! We are not ad-supported.

Since the app is free, we may open source it later on. Right now we don’t have the bandwidth to manage that. We also have very specific ideas for features and the direction we want to take things. We have an active beta community and we take our feedback to heart.

How do you make money?​

We have premium features!

Our Voltra Audio Archive is a cloud-backup service designed specifically for music. We don’t compress or share data blocks. Your music collection is physically backed up for you.

For artists and labels, our Pro Membership offers tools to help them reach more relevant audiences, such as analytics and professional artist webpages.

What makes Voltra different?​

Design and usability are incredibly important to us. We want to give listeners a distraction-free listening experience! There are a some interesting music players and stores out there. But many of them are more advanced and harder to use than their creators realize. We want to make Voltra accessible to as many people as possible.

We also don't take a cut from the artist or the label. That’s a key differentiator for us. It’s really important because it lowers the barrier for artists to get their music to market.

What are some design & technical decisions you made?​

While designing Voltra, we considered UI conventions from native apps and the web, we also thought a lot about what we could remove. We have an active private beta group who have given us critical feedback over the last few months.

We found that album art and photography are really important to people. Many players are just lists of files. One of the cool things about owning physical albums is the album art, and we wanted to put emphasis on this in the Voltra desktop app.

We also made sure not to mess with people's files. We use file watching so you can put your files wherever you want, and we don't rename them or move them for you. We have an embedded database to track the state of the watched directories so that we can track what's new, even when the process isn't running.

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

We spend a lot of time focused on performance. We started with frameworks but moved to vanilla Javascript. In our experience, the generalized abstractions they provide outweigh the performance penalties and ceremony that they introduce.

We handle very large collections pretty well at this point. Large collections means possibly tens of thousands of images! Having Node.js’ file system module directly available from the render process made it really easy to lazy load and unload lots of images super quickly based on DOM events.

In general setImmediate and requestIdleCallback have been super important tools for performing lots of processing while keeping the UI responsive. More specifically, distributing CPU-bound tasks into separate processes really helps to keep the user interface responsive. For example, we moved the actual audio context into a separate process, communicating with it over IPC to avoid potential interruptions from a busy UI.

Why did you choose to build Voltra on Electron?​

The browser’s sandbox is too restricted for our app. But we are also developing a web player. So it’s a huge win that we can share almost 100% of the code between the two implementations.

We actually started by building a native app with Swift. The main problem we found was that we were reinventing a lot of things. The web has the world’s largest open source eco-system. So we pretty quickly switched to Electron.

Also, and most importantly, with Electron you develop once and it should Just Work™ on all the major platforms. It’s not guaranteed, but the cost of coding natively for each platform definitely outweighs any other costs that electron introduces.

What are your favorite things about Electron?​

GTD!: Having Node.js’ networking stack and Chromium’s presentation layer packaged together is a recipe for getting things done.

Competency: It’s just the web stack, so literally our whole team is involved in actually building the product.

Community: There is a highly organized community that knows how to communicate really well! We feel pretty great about developing with support like that.

In what areas could Electron be improved?​

We would like to see Electron endorse a single packager. The packager is as important to Electron what the package manager is to Node. There are multiple packagers in user-land, each with interesting features but each with bugs. Consensus by the community would help to direct the energy being spent by contributors.

What's coming next?​

We‘re currently developing a mobile app, and working with artists and labels to add their music to the Voltra shop. Hey! If you’re an artist or label, sign up now! We plan on opening up the shop when we reach our goal of 10 million tracks.

Using CEF​

The Chromium Embedded Framework (CEF) is a project that turns Chromium into a library, and provides stable APIs based on Chromium's codebase. Very early versions of Atom editor and NW.js used CEF.

To maintain a stable API, CEF hides all the details of Chromium and wraps Chromium's APIs with its own interface. So when we needed to access underlying Chromium APIs, like integrating Node.js into web pages, the advantages of CEF became blockers.

So in the end both Electron and NW.js switched to using Chromium's APIs directly.

Building as part of Chromium​

Even though Chromium does not officially support outside projects, the codebase is modular and it is easy to build a minimal browser based on Chromium. The core module providing the browser interface is called Content Module.

To develop a project with Content Module, the easiest way is to build the project as part of Chromium. This can be done by first checking out Chromium's source code, and then adding the project to Chromium's DEPS file.

NW.js and very early versions of Electron are using this way for building.

The downside is, Chromium is a very large codebase and requires very powerful machines to build. For normal laptops, that can take more than 5 hours. So this greatly impacts the number of developers that can contribute to the project, and it also makes development slower.

Building Chromium as a single shared library​

As a user of Content Module, Electron does not need to modify Chromium's code under most cases, so an obvious way to improve the building of Electron is to build Chromium as a shared library, and then link with it in Electron. In this way developers no longer need to build all off Chromium when contributing to Electron.

The libchromiumcontent project was created by @aroben for this purpose. It builds the Content Module of Chromium as a shared library, and then provides Chromium's headers and prebuilt binaries for download. The code of the initial version of libchromiumcontent can be found in this link.

The brightray project was also born as part of libchromiumcontent, which provides a thin layer around Content Module.

By using libchromiumcontent and brightray together, developers can quickly build a browser without getting into the details of building Chromium. And it removes the requirement of a fast network and powerful machine for building the project.

Apart from Electron, there were also other Chromium-based projects built in this way, like the Breach browser.

Filtering exported symbols​

On Windows there is a limitation of how many symbols one shared library can export. As the codebase of Chromium grew, the number of symbols exported in libchromiumcontent soon exceeded the limitation.

The solution was to filter out unneeded symbols when generating the DLL file. It worked by providing a .def file to the linker, and then using a script to judge whether symbols under a namespace should be exported.

By taking this approach, though Chromium kept adding new exported symbols, libchromiumcontent could still generate shared library files by stripping more symbols.

Component build​

Before talking about the next steps taken in libchromiumcontent, it is important to introduce the concept of component build in Chromium first.

As a huge project, the linking step takes very long in Chromium when building. Normally when a developer makes a small change, it can take 10 minutes to see the final output. To solve this, Chromium introduced component build, which builds each module in Chromium as separated shared libraries, so the time spent in the final linking step becomes unnoticeable.

Shipping raw binaries​

With Chromium continuing to grow, there were so many exported symbols in Chromium that even the symbols of Content Module and Webkit were more than the limitation. It was impossible to generate a usable shared library by simply stripping symbols.

In the end, we had to ship the raw binaries of Chromium instead of generating a single shared library.

As introduced earlier there are two build modes in Chromium. As a result of shipping raw binaries, we have to ship two different distributions of binaries in libchromiumcontent. One is called static_library build, which includes all static libraries of each module generated by the normal build of Chromium. The other is shared_library, which includes all shared libraries of each module generated by the component build.

In Electron, the Debug version is linked with the shared_library version of libchromiumcontent, because it is small to download and takes little time when linking the final executable. And the Release version of Electron is linked with the static_library version of libchromiumcontent, so the compiler can generate full symbols which are important for debugging, and the linker can do much better optimization since it knows which object files are needed and which are not.

So for normal development, developers only need to build the Debug version, which does not require a good network or powerful machine. Though the Release version then requires much better hardware to build, it can generate better optimized binaries.

The gn update​

Being one of the largest projects in the world, most normal systems are not suitable for building Chromium, and the Chromium team develops their own build tools.

Earlier versions of Chromium were using gyp as a build system, but it suffers from being slow, and its configuration file becomes hard to understand for complex projects. After years of development, Chromium switched to gn as a build system, which is much faster and has a clear architecture.

One of the improvements of gn is to introduce source_set, which represents a group of object files. In gyp, each module was represented by either static_library or shared_library, and for the normal build of Chromium, each module generated a static library and they were linked together in the final executable. By using gn, each module now only generates a bunch of object files, and the final executable just links all the object files together, so the intermediate static library files are no longer generated.

This improvement however made great trouble to libchromiumcontent, because the intermediate static library files were actually needed by libchromiumcontent.

The first try to solve this was to patch gn to generate static library files, which solved the problem, but was far from a decent solution.

The second try was made by @alespergl to produce custom static libraries from the list of object files. It used a trick to first run a dummy build to collect a list of generated object files, and then actually build the static libraries by feeding gn with the list. It only made minimal changes to Chromium's source code, and kept Electron's building architecture still.

Summary​

As you can see, compared to building Electron as part of Chromium, building Chromium as a library takes greater efforts and requires continuous maintenance. However the latter removes the requirement of powerful hardware to build Electron, thus enabling a much larger range of developers to build and contribute to Electron. The effort is totally worth it.

Everyone knows about WordPress, but what is WordPress Desktop?​

The WordPress.com Desktop app provides a seamless cross-platform experience that allows you to focus on your content and design with no browser tabs to distract you — or to keep your sites sidelined but accessible. In combination with our browser support and mobile app you can build your site anywhere, in whatever way helps you get your work done.

Why build a Desktop app for managing WordPress sites? Couldn't it all be web-based?​

It's actually using exactly the same technology you get when visiting WordPress.com in your browser. However, it's all locally hosted, so it has minimal load times. With the benefit of native features such as being in your dock, notifications, etc., you really can focus on your WordPress sites and blogging.

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

At the end of 2015 we rebuilt much of WordPress.com in the form of Calypso, an open-source modern JavaScript app using React. We started looking at Electron and with some changes to Calypso were able to get it running locally. It was a compelling experience and we thought there was a lot of value in developing it further.

We had several teams working on Calypso. To make a full multi-platform GUI client that matched this using traditional desktop technologies would have taken more work. By using Electron, a small team of 2-4 of us were able to leverage the other team’s efforts and build the Desktop app in a couple of months.

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

We got an initial version of the app running very quickly, but tuning it to behave optimally as a desktop app took a lot more time. One big challenge with the app is that you're actually running a copy of Calypso on your own machine - it’s purely an API driven UI. There was a lot of bridging work involved in this, and changes were fed back to Calypso itself.

Additionally a lot of effort was spent packaging the app for different platforms - we provide Windows, macOS, and Linux versions - and there are sufficient differences to make this tricky.

At the time Electron was relatively new and we kept running into issues that were shortly fixed (sometimes the same day!)

In what areas should Electron be improved?​

Electron already provides most of what we need for the Desktop app, and it's progressed rapidly since we started using it. That said, there are some areas that are taken for granted in a desktop app, such as spell checking and find/replace, that are harder to replicate with Electron as-is.

We’d also love to see some of the newer Chrome technologies filtering down into Electron too. We’re particularly keen on experimenting with WebVR.

What are your favorite things about Electron?​

The main reason we chose Electron, and it's biggest strength, is the very active and open community. Automattic has always believed in open source. It is one of our core tenets, and the Electron project and community follows a lot of the core beliefs of being very open and positive.

What's coming next in WordPress Desktop?​

The great thing about our model is that the Desktop app benefits from any new Calypso feature - there are constant improvements. We’re hoping we can add additional features to the app such as offline support, which would really take the app into native territory, and better system notifications.

Are there any teams at Automattic working on other Electron apps?​

Yes, after our efforts on the Desktop app, the Simplenote team decided to use Electron to build desktop apps for Windows and Linux (a native Mac client already exists). The Simplenote Electron app is also open source and available on Github.

We've also got an upcoming Raspberry Pi integration that uses Electron.

If any of that sounds interesting then we'd love to hear from you!

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

The process of shipping signed desktop software is relatively new to us, especially for Windows. we wrote up an article for Code Signing a Windows App which includes the process and a few of the hurdles we went through to do it right.

First off what is Dat?​

We wanted to bring the best parts of peer to peer and distributed systems to data sharing. We started with scientific data sharing and then began branching out into research institutions, government, public service, and open source teams as well.

Another way to think about it is a sync and upload app like Dropbox or BitTorrent Sync, except Dat is open source. Our goal is to be a a powerful, open source, non-profit data sharing software for big, small, medium, small-batch and big-batch data.

To use the dat CLI tool, all you have to type is:

dat share path/to/my/folder

And dat will create a link that you can use to send that folder to someone else -- no central servers or third parties get access to your data. Unlike BitTorrent, it's also impossible to sniff who is sharing what (see the Dat Paper draft for more details).

Now we know what Dat is. How does Dat Desktop fit in?​

Dat Desktop is a way to make Dat accessible to people who can't or don't want to use the command line. You can host multiple dats on your machine and serve the data over your network.

Can you share some cool use cases?​

DataRefuge + Project Svalbard​

We're working on a thing codenamed Project Svalbard that is related to DataRefuge, a group working to back up government climate data at risk of disappearing. Svalbard is named after the Svalbard Global Seed Vault in the Arctic which has a big underground backup library of plant DNA. Our version of it is a big version controlled collection of public scientific datasets. Once we know and can trust the metadata, we can build other cool projects like a distributed volunteer data storage network.

California Civic Data Coalition​

CACivicData is an open-source archive serving up daily downloads from CAL-ACCESS, California's database tracking money in politics. They do daily releases, which means hosting a lot of duplicate data across their zip files. We're working on hosting their data as a Dat repository which will reduce the amount of hassle and bandwidth needed to refer to specific version or update to a newer version.

Electron Updates​

This one isn't concrete yet, but we think a fun use case would be putting a compiled Electron app in a Dat repository, then using a Dat client in Electron to pull the latest deltas of the built app binary, to save on download time but also to reduce bandwidth costs for the server.

Who should be using Dat Desktop?​

Anyone who wants to share and update data over a p2p network. Data scientists, open data hackers, researchers, developers. We're super receptive to feedback if anyone has a cool use case we haven't thought of yet. You can drop by our Gitter Chat and ask us anything!

What's coming next in Dat and Dat Desktop?​

User accounts and metadata publishing. We are working on a Dat registry web app to be deployed at datproject.org which will basically be an 'NPM for datasets', except the caveat being we are just going to be a metadata directory and the data can live anywhere online (as opposed to NPM or GitHub where all the data is centrally hosted, because source code is small enough you can fit it all in one system). Since many datasets are huge, we need a federated registry (similar to how BitTorrent trackers work). We want to make it easy for people to find or publish datasets with the registry from Dat Desktop, to make the data sharing process frictionless.

Another feature is multi-writer/collaborative folders. We have big plans to do collaborative workflows, maybe with branches, similar to git, except designed around dataset collaboration. But we're still working on overall stability and standardizing our protocols right now!

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

Dat is built using Node.js, so it was a natural fit for our integration. Beyond this, our users use a variety of machines since scientists, researchers and government officials may be forced to use certain setups for their institutions -- this means we need to be able to target Windows and Linux as well as Mac. Dat Desktop gives us that quite easily.

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

Figuring out what people want. 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.

In what areas should Electron be improved?​

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?​

The APIs seem fairly well thought out, it's relatively stable, and it does a pretty good job at keeping up to date with upstream Node releases, not much else we can ask for!

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

If you use native modules, give prebuild a shot!

What's the best way to follow Dat developments?​

Follow @dat_project on Twitter, or subscribe to our email newsletter.

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. Simple things like common writing shortcuts can't be realized in a browser, but are available in our desktop app. It allows other applications to communicate directly with the blog via 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.

In what areas should Electron be improved?​

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.

👻

What is Beaker and why did you create it?​

Beaker is a participatory browser. It's a browser for indie hackers.

The Web is closed source. If you want to influence how social media works, you have to work at Facebook or Twitter. For search, Google. Control is in the hands of companies, rather than the users themselves.

With Beaker, we have a new Web protocol: the Decentralized Archive Transport. "Dat." It creates sites on demand, for free, and then shares them from the device. No servers required. That's our innovation.

When you visit a Dat site in Beaker, you download the files. The site is yours, forever. You can save it, fork it, modify it, and share your new version for free. It's all open-source.

So that's what it's about: We're making a browser for open-source Websites. We want it to be a toolkit for social hacking.

Who should be using Beaker?​

Hackers. Modders. Creative types. People who like to tinker.

How do I create a new project that uses Dat?​

We've got a command-line tool called bkr that's kind of like git + npm. Here's creating a site:

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

And here's forking a site:

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

Those sites then get hosted out of your browser. It's a little like BitTorrent; you share the sites in a P2P mesh.

If you want a GUI, we have some basic tools built into the browser, but we're pushing those tools into userland. It's all going to be moddable user apps.

Why did you choose to build Beaker on Electron?​

It was obvious for this project. If I forked Chrome myself, I'd be writing C++ right now! Nobody wants to do that. I know the Web stack, and I can work quickly with it. It's a no-brainer.

The truth is, I'm not sure I could do any of this without Electron. It's a great piece of software.

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

Half of it is poking at the tools and figuring out how much I can get away with.

Making the browser itself was pretty easy. Electron is practically a toolkit for making browsers. ...Except for the browser tabs; that took me forever to get right. I finally broke down and learned how to do SVGs. It's much better looking, but it took 3 or 4 iterations before I got that right.

In what areas should Electron be improved?​

It'd be really great if I could dock the devtools inside a webview.

What's coming next in Beaker?​

Secure DNS names for Dat sites. A socially configurable URL scheme, called the "app scheme." More Dat APIs.

For folks who may be interested in contributing to the project, in what areas does Beaker need help?​

We have lots of open issues. Don't be afraid to ping me. #beakerbrowser on freenode. We keep a page for contributors and we'll add you to it. And if you visit Austin, I'll buy you a beer.

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

1. Use the build tooling that's out there. You don't want to wrestle with your own solutions, trust me. Use electron-builder. Use a boilerplate repo.
2. If you need to open an issue in the Electron repo, go the extra mile to make it easy to reproduce. You'll get a response much more quickly, and the team will appreciate it. Even better, try fixing it yourself. It's actually pretty interesting to see the innards.
3. Read through all the guides and advanced docs at least once.
4. Don't build a browser, it's a saturated market.

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.

We've seen people of all ages and backgrounds use it in educational settings, screencasts, tutorials... the list goes on. 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. Problem? 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.

In what areas should Electron be improved?​

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!

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.

Hash​

Shows the hash values of entered text using different algorithms.

Mirror​

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.

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. This design philosophy allows Electron to remain a flexible tool without being overly prescriptive about how it should be used.

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: