At OpenJS World this morning, we announced that Electron has officially graduated from the OpenJS Foundation's incubation program, and is now an OpenJS Foundation Impact Project.
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.
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.
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.
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.
At Node+JS Interactive in Montreal, the OpenJS Foundation announced that it accepted Electron into the Foundation's incubation program. The Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large.
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.
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.
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.
In Q3 2021, the Chrome team increased their release cadence
from every 6 weeks to every 4 weeks. Electron's releases have followed suit.
Please read the updated 8 week cadence blog post
for more up-to-date information!
🎉 Electron is moving to release a new major stable version every 12 weeks! 🎉
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.
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.
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.
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:
As Electron grows in popularity for desktop applications, the team working on it has also grown: we have more fulltime maintainers who work for different companies, live in different timezones, and have different interests. We're introducing a governance structure so we can keep growing smoothly.
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.
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.
The Electron team will discontinue support for 32-bit Linux (ia32 / i386) starting with Electron v4.0. The last version of Electron that supports 32-bit based installations of Linux is Electron v3.1, which will receive support releases until Electron v6 is released. Support for 64-bit based Linux and armv7l will continue unchanged.
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.
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.
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.
If you're having trouble using a native Node.js addon with Electron 5.0, there's a chance it needs to be updated to work with the most recent version of V8.
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.
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.
Electron now uses GN to build itself. Here's a discussion of why.
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.
Electron 1.4.12 contains an important patch that fixes an upstream Chrome
issue where some Symantec, GeoTrust, and Thawte SSL/TLS certificates
are incorrectly rejected 10 weeks from the build time of libchromiumcontent,
Electron's underlying Chrome library. There are no issues with the certificates
used on the affected sites and replacing these certificates will not help.
In Electron 1.4.0 — 1.4.11 HTTPS requests to sites using these affected
certificates will fail with network errors after a certain date.
This affects HTTPS requests made using Chrome's underlying networking APIs
such as window.fetch, Ajax requests, Electron's net API,
BrowserWindow.loadURL, webContents.loadURL, the src attribute on a
<webview> tag, and others.
Upgrading your applications to 1.4.12 will prevent these request failures from
occurring.
Note: This issue was introduced in Chrome 53 so Electron versions earlier
than 1.4.0 are not affected.
Below is a table of each Electron 1.4 version and the date when
requests to sites using these affected certificates will start to fail.
Electron Version
Impact Date
1.3.x
Unaffected
1.4.0
Already failing
1.4.1
Already failing
1.4.2
Already failing
1.4.3
December 10th, 2016 9:00 PM PST
1.4.4
December 10th, 2016 9:00 PM PST
1.4.5
December 10th, 2016 9:00 PM PST
1.4.6
January 14th, 2017 9:00 PM PST
1.4.7
January 14th, 2017 9:00 PM PST
1.4.8
January 14th, 2017 9:00 PM PST
1.4.9
January 14th, 2017 9:00 PM PST
1.4.10
January 14th, 2017 9:00 PM PST
1.4.11
February 11th, 2017 9:00 PM PST
1.4.12
Unaffected
You can verify your app's impact date by setting your computer's clock ahead
and then check to see if https://symbeta.symantec.com/welcome/
successfully loads from it.
If you've ever worked on an Electron app before, you've likely come across the
electron-prebuilt npm package. This package is an indispensable part of nearly
every Electron project. When installed, it detects your operating system
and downloads a prebuilt binary that is compiled to work on your system's
architecture.
The Electron installation process was often a stumbling block for new developers.
Many brave people tried to get started developing an Electron by app by running
npm install electron instead of npm install electron-prebuilt,
only to discover (often after much confusion) that it was not the electron
they were looking for.
This was because there was an existing electron project on npm,
created before GitHub's Electron project existed. To help make Electron
development easier and more intuitive for new developers, we reached out to the
owner of the existing electron npm package to ask if he'd be willing to let us use
the name. Luckily he was a fan of our project, and agreed to help us repurpose
the name.
As of version 1.3.1, we have begun publishing
electron and electron-prebuilt
packages to npm in tandem. The two packages are identical. We chose to continue publishing
the package under both names for a while so as not to inconvenience the
thousands of developers who are currently using electron-prebuilt in their projects.
We recommend updating your package.json files to use the new electron dependency,
but we will continue releasing new versions of electron-prebuilt until the
end of 2016.
We owe a special thanks to @mafintosh,
@maxogden, and many other contributors
for creating and maintaining electron-prebuilt, and for their tireless service
to the JavaScript, Node.js, and Electron communities.
And thanks to @logicalparadox for allowing
us to take over the electron package on npm.
We've worked with the community to update popular packages that are affected
by this change. Packages like
electron-packager,
electron-rebuild, and
electron-builder
have already been updated to work with the new name while continuing to support
the old name.
If you encounter any problems installing this new package, please let us know by
opening an issue on the
electron-userland/electron-prebuilt
repository.
For any other issues with Electron,
please use the electron/electron
repository.