Electron has once again been accepted as a mentoring organization for Google Summer of Code (GSoC) 2025! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more details about the program, visit Google’s Summer of Code homepage.

About us​

Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in C++.

Outside of the Electron core repository, we also maintain several projects to support the Electron ecosystem, including:

• Tools for end-user distribution (e.g. Electron Forge and update.electronjs.org).
• Learning materials for Electron developers (e.g. electronjs.org and Electron Fiddle).
• Internal tools to enhance developer productivity (e.g. Electron Build Tools and Sheriff).

As a GSoC contributor, you will have the opportunity to collaborate with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

Before applying​

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out some of the examples in Electron Fiddle.

To learn more about distributing Electron apps, try creating a sample application with Electron Forge:

npm init electron-app@latest my-app

After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

Project contributions​

We encourage you to take a look at any repositories that are relevant to the project ideas you are interested in. One way of doing your research is to make contributions by reporting bugs, triaging existing issues, or submitting pull requests. Doing so is an effective way of getting hands-on practice with our codebases, but is not mandatory for proposal submissions. A well-crafted proposal should be able to demonstrate your understanding of the code without needing to refer to past contributions.

Here are a few tips if you are looking to contribute to Electron before submitting your proposal:

1. Please provide descriptive issue or PR descriptions when submitting contributions. Regardless of the code itself, putting effort into the written part of a contribution shows us that you can be an effective communicator in a collaborative environment.
2. PRs are always welcome for open issues. You do not need to comment on an issue asking a maintainer if you can be assigned to it. Note that we still encourage you to discuss potential solutions on an issue if you need to refine an idea for a solution, but comments strictly asking if you can work on something are redundant and add noise to the issue tracker.
3. Low-effort project contributions (e.g. invalid issue reports, trivial wording changes in a repo README, or minor stylistic changes to front-end code) will negatively impact your final proposal, as they take up limited maintainer time and do not provide any net benefit to the Electron project.
4. While AI coding assistants can be an effective tool for debugging and understanding new concepts, we highly discourage contributions that are copy/pasted directly from AI-generated output. These often turn out to be of low quality, and it's often more effort for maintainers to clean up code generated from an LLM than for us to just reject a PR altogether.

Crafting your proposal​

Interested in collaborating with Electron? First, check out the seven project idea drafts we have prepared. All listed ideas are open for proposals.

If you have a unique idea not on the list, we are open to considering it, but ensure your proposal is detailed and thoroughly outlined. When in doubt, we recommend sticking with our listed ideas.

Your application should include:

• A detailed proposal outlining what you plan to achieve over the summer.
• Your background as a developer. If you have a resume, please include a copy. Otherwise, tell us about your past technical experience.
  • Lack of experience in certain areas won’t disqualify you, but it will help our mentors work out a plan to best support you and make sure your summer project is successful.

A detailed guide of what to submit as part of your Electron application is here. Submit proposals directly to the Google Summer of Code portal. Proposals emailed to the Electron team will not be considered as final submissions.

For more guidance on your proposal, we recommend you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 24th, 2025 and close on April 8th, 2025.

Questions?​

If you have questions we didn’t address in this blog post or inquiries about your proposal draft, please send us an email at summer-of-code@electronjs.org or check the GSoC FAQ. Please read our contributor guidance before emailing.

Resources​

• Electron Google Summer of Code 2025 Ideas List
• Electron Google Summer of Code 2025 Contributor Guidance
• Google Summer of Code Student/Contributor Guide

Electron 34.0.0 has been released! It includes upgrades to Chromium 132.0.6834.83, V8 13.2, and Node 20.18.1.

The Electron team is excited to announce the release of Electron 34.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.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

HTTP Compression Shared Dictionary Management APIs​

HTTP compression allows data to be compressed by a web server before being received by the browser. Modern versions of Chromium support Brotli and Zstandard, which are newer compression algorithms that perform better for text files than older schemes such as gzip.

Custom shared dictionaries further improve the efficiency of Brotli and Zstandard compression. See the Chrome for Developers blog on shared dictionaries for more information.

@felixrieseberg added the following APIs in #44950 to manage shared dictionaries at the Session level:

• session.getSharedDictionaryUsageInfo()
• session.getSharedDictionaryInfo(options)
• session.clearSharedDictionaryCache()
• session.clearSharedDictionaryCacheForIsolationKey(options)

Unresponsive Renderer JavaScript Call Stacks​

Electron's unresponsive event occurs whenever a renderer process hangs for an excessive period of time. The new WebFrameMain.collectJavaScriptCallStack() API added by @samuelmaddock in #44204 allows you to collect the JavaScript call stack from the associated WebFrameMain object (webContnets.mainFrame).

This API can be useful to determine why the frame is unresponsive in cases where there's long-running JavaScript events causing the process to hang. For more information, see the proposed web standard Crash Reporting API.

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

app.commandLine.appendSwitch(
  'enable-features',
  'DocumentPolicyIncludeJSCallStacksInCrashReports',
);

app.on('web-contents-created', (_, webContents) => {
  webContents.on('unresponsive', async () => {
    // Interrupt execution and collect call stack from unresponsive renderer
    const callStack = await webContents.mainFrame.collectJavaScriptCallStack();
    console.log('Renderer unresponsive\n', callStack);
  });
});

In early 2025, Electron’s npm ecosystem repos (under the @electron/ and @electron-forge/ namespaces) will move to Node.js 22 as the minimum supported version.

What does this mean?​

In the past, packages in Electron’s npm ecosystem (Forge, Packager, etc) have supported Node versions for as long as possible, even after a version has reached its End-Of-Life (EOL) date. This is done to make sure we don’t fragment the ecosystem—we understand that many projects depend on older versions of Node, and we don’t want to risk stranding those projects unless there was a pressing reason to upgrade.

Over time, using Node.js 14 as our minimum version has become increasingly difficult for a few reasons:

• Lack of official Node.js 14 macOS ARM64 builds requires us to maintain CI infrastructure workarounds to provide full test coverage.
• engines requirements for upstream package dependencies have moved forward, making it increasingly difficult to resolve supply chain security issues with dependency bumps.

Additionally, newer versions of Node.js have included many improvements that we would like to leverage, such as runtime-native common utilities (e.g. fs.glob and util.parseArgs) and entire new batteries-included modules (e.g. node:test, node:sqlite).

Why upgrade now?​

In July 2024, Electron’s Ecosystem Working Group decided to upgrade all packages to the earliest Node version where require()of synchronous ESM graphs will be supported (see nodejs/node#51977 and nodejs/node#53500) at a future point after that version reaches its LTS date.

We’ve decided to set that update time to January/February 2025. After this upgrade occurs, Node 22 will be the minimum supported version in existing ecosystem packages.

What action do I need to take?​

We’ll strive to maintain compatibility as much as possible. However, to ensure the best support, we encourage you to upgrade your apps to Node 22 or higher.

Note that the Node version running in your project is unrelated to the Node version embedded into your current version of Electron.

What's next​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

The Electron project will pause for the month of December 2024, then return to full speed in January 2025.

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. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

See you all in 2025!

BrowserView has been deprecated since Electron 30 and is replaced by WebContentView. Thankfully, migrating is fairly painless.

Electron is moving from BrowserView to WebContentsView to align with Chromium’s UI framework, the Views API. WebContentsView offers a reusable view directly tied to Chromium’s rendering pipeline, simplifying future upgrades and opening up the possibility for developers to integrate non-web UI elements to their Electron apps. By adopting WebContentsView, applications are not only prepared for upcoming updates but also benefit from reduced code complexity and fewer potential bugs in the long run.

Developers familiar with BrowserWindows and BrowserViews should note that BrowserWindow and WebContentsView are subclasses inheriting from the BaseWindow and View base classes, respectively. To fully understand the available instance variables and methods, be sure to consult the documentation for these base classes.

Migration steps​

1. Upgrade Electron to 30.0.0 or higher​

2. Familiarize yourself with where your application uses BrowserViews​

One way to do this is to search your codebase for new BrowserView(. This should give you a sense for how your application is using BrowserViews and how many call sites need to be migrated.

3. Migrate each usage of BrowserView​

1. Migrate the instantiation. This should be fairly straightforward because WebContentsView and BrowserView’s constructors have essentially the same shape. Both accept WebPreferences via the webPreferences param.

   - this.tabBar = new BrowserView({
   + this.tabBar = new WebContentsView({
   

   info

   By default, WebContentsView instantiates with a white background, while BrowserView instantiates with a transparent background. To get a transparent background in WebContentsView, set its background color to an RGBA hex value with an alpha (opaqueness) channel set to 00:

   + this.webContentsView.setBackgroundColor("#00000000");
   

2. Migrate where the BrowserView gets added to its parent window.

   - this.browserWindow.addBrowserView(this.tabBar)
   + this.browserWindow.contentView.addChildView(this.tabBar);
   

3. Migrate BrowserView instance method calls on the parent window.

   Old Method	New Method	Notes
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	Calling addChildView on an existing view reorders it to the top.
   win.getBrowserViews	win.contentView.children

4. Migrate the setAutoResize instance method to a resize listener.

   - this.browserView.setAutoResize({
   -   vertical: true,
   - })
   
   + this.browserWindow.on('resize', () => {
   +   if (!this.browserWindow || !this.webContentsView) {
   +     return;
   +   }
   +   const bounds = this.browserWindow.getBounds();
   +   this.webContentsView.setBounds({
   +     x: 0,
   +     y: 0,
   +     width: bounds.width,
   +     height: bounds.height,
   +    });
   +  });
   

   tip

   All existing usage of browserView.webContents and instance methods browserView.setBounds, browserView.getBounds , and browserView.setBackgroundColor do not need to be migrated and should work with a WebContentsView instance out of the box!

4. Test and commit your changes​

Running into issues? Check the WebContentsView tag on Electron's issue tracker to see if the issue you're encountering has been reported. If you don't see your issue there, feel free to add a new bug report. Including testcase gists will help us better triage your issue!

Congrats, you’ve migrated onto WebContentsViews! 🎉

Electron 33.0.0 has been released! It includes upgrades to Chromium 130.0.6723.44, V8 13.0, and Node 20.18.0.

The Electron team is excited to announce the release of Electron 33.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.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• Added a handler, app.setClientCertRequestPasswordHandler(handler), to help unlock cryptographic devices when a PIN is needed. #41205
• Extended navigationHistory API with 2 new functions for better history management. #42014
• Improved native theme transparency checking. #42862

Historical changes to Electron APIs will now be detailed in the docs.

Hi 👋, I'm Peter, the 2024 Google Summer of Code (GSoC) contributor to Electron.

Over the course of the GSoC program, I implemented an API history feature for the Electron documentation and its functions, classes, etc. in a similar fashion to the Node.js documentation: by allowing the use of a simple but powerful YAML schema in the API documentation Markdown files and displaying it nicely on the Electron documentation website.

Electron 32.0.0 has been released! It includes upgrades to Chromium 128.0.6613.36, V8 12.8, and Node 20.16.0.

The Electron team is excited to announce the release of Electron 32.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.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• Added new API version history in our documentation, a feature created by @piotrpdev as part of Google Summer of Code. You can learn more about it in this blog post. #42982
• Removed nonstandard File.path extension from the Web File API. #42053
• Aligned failure pathway in Web File System API with upstream when attempting to open a file or directory in a blocked path. #42993
• Added the following existing navigation-related APIs to webcontents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear. The previous navigation APIs are now deprecated. #41752

Electron 31.0.0 has been released! It includes upgrades to Chromium 126.0.6478.36, V8 12.6, and Node 20.14.0.

The Electron team is excited to announce the release of Electron 31.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.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• Extended WebContentsView to accept pre-existing webContents object. #42319
• Added support for NODE_EXTRA_CA_CERTS. #41689
• Updated window.flashFrame(bool) to flash continuously on macOS. #41391
• Removed WebSQL support #41868
• nativeImage.toDataURL will preserve PNG colorspace #41610
• Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432

Electron 30.0.0 has been released! It includes upgrades to Chromium 124.0.6367.49, V8 12.4, and Node.js 20.11.1.

The Electron team is excited to announce the release of Electron 30.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.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

• ASAR Integrity fuse now supported on Windows (#40504)
  • Existing apps with ASAR Integrity enabled may not work on Windows if not configured correctly. Apps using Electron packaging tools should upgrade to @electron/packager@18.3.1 or @electron/forge@7.4.0.
  • Take a look at our ASAR Integrity tutorial for more information.
• Added WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
  • BrowserView is now a shim over WebContentsView and the old implementation has been removed.
  • See our Web Embeds documentation for a comparison of the new WebContentsView API to other similar APIs.
• Implemented support for the File System API (#41827)