https://electronjs.org/Electron2020-02-08T18:57:16.201ZElectron websiteBuild cross platform desktop apps with JavaScript, HTML, and CSS.<![CDATA[Electron 8.0.0]]>https://electronjs.org/blog/electron-8-02020-02-04T00:00:00.000ZElectron 8.0.0 has been released! It includes upgrades to Chromium 80, V8 8.0, and Node.js 12.13.0. We've added Chrome's built-in spellchecker, and much more!
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!
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.
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.
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
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 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
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.
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.
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.
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.
]]>2020-02-04T00:00:00.000Z<![CDATA[Electron joins the OpenJS Foundation]]>https://electronjs.org/blog/electron-joins-openjsf2019-12-11T00:00:00.000ZAt 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.
]]>2019-12-11T00:00:00.000Z<![CDATA[Chromium WebAudio Vulnerability Fix (CVE-2019-13720)]]>https://electronjs.org/blog/cve-2019-137202019-11-04T00:00:00.000ZA High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.
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.
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.
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.
]]>2019-11-04T00:00:00.000Z<![CDATA[Electron 7.0.0]]>https://electronjs.org/blog/electron-7-02019-10-22T00:00:00.000ZElectron 7.0.0 has been released! It includes upgrades to Chromium 78, V8 7.8, and Node.js 12.8.1. We've added a Window on Arm 64 release, faster IPC methods, a new nativeTheme API, and much more!
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!
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
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.
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.
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.
]]>2019-10-22T00:00:00.000Z<![CDATA[Electron 6.0.0]]>https://electronjs.org/blog/electron-6-02019-07-30T00:00:00.000ZThe Electron team is excited to announce the release of Electron 6.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!
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:
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.
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
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.
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.
]]>2019-07-30T00:00:00.000Z<![CDATA[New Electron Release Cadence]]>https://electronjs.org/blog/12-week-cadence2019-05-13T00:00:00.000Z🎉 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.
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:
]]>2019-05-13T00:00:00.000Z<![CDATA[Electron 5.0.0]]>https://electronjs.org/blog/electron-5-02019-04-23T00:00:00.000ZThe Electron team is excited to announce the release of Electron 5.0.0! You can install it with npm via npm install electron@latest or download the tarballs from our releases page. 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!
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:
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.
Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:
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.
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 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.
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.
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:
webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.
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.
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.
]]>2019-04-23T00:00:00.000Z<![CDATA[From native to JavaScript in Electron]]>https://electronjs.org/blog/from-native-to-js2019-03-19T00:00:00.000ZHow do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?
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.
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?
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.
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:
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:
functionApp{}
App.prototype.getGPUInfo = function () {
// implementation here
}
This class also contains functions to set properties on a module:
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.
]]>2019-03-19T00:00:00.000Z<![CDATA[Electron Governance]]>https://electronjs.org/blog/governance2019-03-18T00:00:00.000ZAs 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.
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.
]]>2019-03-18T00:00:00.000Z<![CDATA[Chromium FileReader Vulnerability Fix]]>https://electronjs.org/blog/filereader-fix2019-03-07T00:00:00.000ZA High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.
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.
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.
]]>2019-03-07T00:00:00.000Z<![CDATA[Discontinuing support for 32-bit Linux]]>https://electronjs.org/blog/linux-32bit-support2019-03-04T00:00:00.000ZThe 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.
]]>2019-03-04T00:00:00.000Z<![CDATA[BrowserView window.open() Vulnerability Fix]]>https://electronjs.org/blog/window-open-fix2019-02-03T00:00:00.000ZA code vulnerability has been discovered that allows Node to be re-enabled in child windows.
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.
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());
]]>2019-02-03T00:00:00.000Z<![CDATA[Node.js Native Addons and Electron 5.0]]>https://electronjs.org/blog/nodejs-native-addons-and-electron-52019-02-01T00:00:00.000ZIf 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.
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.
]]>2019-02-01T00:00:00.000Z<![CDATA[Electron v5.0.0 Timeline]]>https://electronjs.org/blog/electron-5-0-timeline2019-01-25T00:00:00.000ZFor the first time ever, Electron is excited to publicize our release schedule starting with v5.0.0. This is our first step in having a public, long-term timeline.
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.
]]>2019-01-25T00:00:00.000Z<![CDATA[Electron 4.0.0]]>https://electronjs.org/blog/electron-4-02018-12-20T00:00:00.000ZThe Electron team is excited to announce that the stable release of Electron 4 is now available! You can install it from electronjs.org or from npm via npm install electron@latest. The release is packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Read more for details about this release, and please share any feedback you have as you explore!
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.
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:
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
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)
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.
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.
When creating a new BrowserWindow with the webPreferences option set, the following webPreferences option defaults are deprecated in favor of new defaults listed below:
Property
Deprecated Default
New Default
contextIsolation
false
true
nodeIntegration
true
false
webviewTag
value of nodeIntegration if set, otherwise true
false
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!
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.
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.
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.
]]>2018-12-20T00:00:00.000Z<![CDATA[SQLite Vulnerability Fix]]>https://electronjs.org/blog/magellan-fix2018-12-18T00:00:00.000ZA remote code execution vulnerability, "Magellan," has been discovered affecting software based on SQLite or Chromium, including all versions of Electron.
]]>2018-12-18T00:00:00.000Z<![CDATA[Electron App Feedback Program]]>https://electronjs.org/blog/app-feedback-program2018-10-02T00:00:00.000ZElectron is working on making its release cycles faster and more stable. To make that possible, we've started the App Feedback Program for large-scale Electron apps to test our beta releases and report app-specific issues to us. This helps us to prioritize work that will get applications upgraded to our next stable release sooner.
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
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.
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.
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.
]]>2018-10-02T00:00:00.000Z<![CDATA[Electron 3.0.0]]>https://electronjs.org/blog/electron-3-02018-09-18T00:00:00.000ZThe Electron team is excited to announce that the first stable release of Electron 3 is now
available from electronjs.org and via npm install electron@latest! It's jam-packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Below are details about this release, and we welcome your feedback as you explore.
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.
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.
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.
]]>2018-09-18T00:00:00.000Z<![CDATA[Using GN to Build Electron]]>https://electronjs.org/blog/gn2018-09-05T00:00:00.000ZElectron now uses GN to build itself. Here's a discussion of why.
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.
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.
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.
]]>2018-09-05T00:00:00.000Z<![CDATA[WebPreferences Vulnerability Fix]]>https://electronjs.org/blog/web-preferences-fix2018-08-22T00:00:00.000ZA remote code execution vulnerability has been discovered affecting apps with the ability to open nested child windows on Electron versions (3.0.0-beta.6, 2.0.7, 1.8.7, and 1.7.15). This vulnerability has been assigned the CVE identifier CVE-2018-15685.
You embed any remote user content, even in a sandbox
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.
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:
]]>2018-08-22T00:00:00.000Z<![CDATA[Search]]>https://electronjs.org/blog/search2018-06-21T00:00:00.000ZThe Electron website has a new search engine that delivers instant results for
API docs, tutorials, Electron-related npm packages, and more.
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.
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.
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.
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.
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.
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.
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:
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.
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. 🍹
]]>2018-06-21T00:00:00.000Z<![CDATA[Internationalization Updates]]>https://electronjs.org/blog/i18n-updates2018-06-20T00:00:00.000ZEver since the launch of the new internationalized Electron website, we have been working hard to make the Electron development experience even more accessible to developers outside of the English speaking world.
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.
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!
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.
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.
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.
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! 📚
]]>2018-06-20T00:00:00.000Z<![CDATA[Electron 2.0.0]]>https://electronjs.org/blog/electron-2-02018-05-02T00:00:00.000ZAfter more than four months of development, eight beta releases, and worldwide
testing from many apps' staged rollouts, the release of Electron 2.0.0 is now
available from electronjs.org.
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.
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.
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.
The Electron team is hard at work to support newer versions of Chromium, Node, and v8. Expect 3.0.0-beta.1 soon!
]]>2018-05-02T00:00:00.000Z<![CDATA[Easier AutoUpdating for Open-Source Apps]]>https://electronjs.org/blog/autoupdating-electron-apps2018-05-01T00:00:00.000ZToday we're releasing a free, open-source, hosted
updates webservice and companion
npm package
to enable easy automatic updates for open-source Electron apps. This is a step
toward empowering app developers to think less about
deployment and more about developing high-quality experiences for their users.
The new updater module in action
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.
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.
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 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!
]]>2018-05-01T00:00:00.000Z<![CDATA[New in Electron 2: In-App Purchases]]>https://electronjs.org/blog/in-app-purchases2018-04-04T00:00:00.000ZThe new Electron 2.0 release line is packed with new features and fixes. One of the highlights from this new major version is a new
inAppPurchase API
for Apple's Mac App Store.
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!
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.
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!
]]>2018-04-04T00:00:00.000Z<![CDATA[Webview Vulnerability Fix]]>https://electronjs.org/blog/webview-fix2018-03-21T00:00:00.000ZA vulnerability has been discovered which allows Node.js integration to be re-enabled in some Electron applications that disable it. This vulnerability has been assigned the CVE identifier CVE-2018-1000136.
Please join our email list to receive updates about releases and security updates.
]]>2018-03-21T00:00:00.000Z<![CDATA[Website Hiccups]]>https://electronjs.org/blog/website-hiccups2018-02-12T00:00:00.000ZLast week the electronjs.org site had a few minutes
of downtime. If you were affected by these brief outages, we're sorry
for the inconvenience. After a bit of investigation today, we've diagnosed
the root cause and have deployed a fix.
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.
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
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
]]>2018-02-12T00:00:00.000Z<![CDATA[Protocol Handler Vulnerability Fix]]>https://electronjs.org/blog/protocol-handler-fix2018-01-22T00:00:00.000ZA remote code execution vulnerability has been discovered affecting
Electron apps that use custom protocol handlers. This vulnerability has been
assigned the CVE identifier CVE-2018-1000006.
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.
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.
]]>2018-01-22T00:00:00.000Z<![CDATA[Electron 2.0 and Beyond - Semantic Versioning]]>https://electronjs.org/blog/electron-2-semantic-boogaloo2017-12-06T00:00:00.000ZA new major version of Electron is in the works, and with it some changes to our versioning strategy. As of version 2.0.0, Electron will strictly adhere to Semantic Versioning.
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.
]]>2017-12-06T00:00:00.000Z<![CDATA[Electron's New Internationalized Website]]>https://electronjs.org/blog/new-website2017-11-13T00:00:00.000ZElectron has a new website at electronjs.org! We've replaced
our static Jekyll site with a Node.js webserver, giving us flexibility to
internationalize the site and paving the way for more exciting new features.
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.
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.
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 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:
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.
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.
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.
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!
]]>2017-11-13T00:00:00.000Z<![CDATA[Chromium RCE Vulnerability Fix]]>https://electronjs.org/blog/chromium-rce-vulnerability2017-09-27T00:00:00.000ZA remote code execution vulnerability has been discovered in Google Chromium
that affects all recent versions of Electron. Any Electron app that accesses
remote content is vulnerable to this exploit, regardless of whether the
sandbox option is enabled.
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.
]]>2017-09-27T00:00:00.000Z<![CDATA[Announcing TypeScript support in Electron]]>https://electronjs.org/blog/typescript2017-06-01T00:00:00.000ZThe electron npm package now includes a TypeScript definition file that provides detailed annotations of the entire Electron API. These annotations can improve your Electron development
experience even if you're writing vanilla JavaScript. Just
npm install electron to get up-to-date Electron typings in your project.
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.
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:
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.
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.
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.
If you encounter any issues using Electron's new TypeScript definition files,
please file an issue on the
electron-typescript-definitions repository.
Happy TypeScripting!
]]>2017-06-01T00:00:00.000Z<![CDATA[Project of the Week: Jasper]]>https://electronjs.org/blog/jasper2017-03-21T00:00:00.000ZThis week we interviewed the creator of Jasper, an Electron-based tool for
managing GitHub notifications.
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.
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!
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.
Issues that are requested review by cat. But these are not reviewed yet.
is:pr reviewed-by:cat
Issues that are reviewed by cat
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.
Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.
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.
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.
]]>2017-03-21T00:00:00.000Z<![CDATA[Project of the Week: WebTorrent]]>https://electronjs.org/blog/webtorrent2017-03-14T00:00:00.000ZThis week we caught up with @feross and @dcposch to talk about WebTorrent, the web-powered torrent client that connects users together to form a distributed, decentralized browser-to-browser network.
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.
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.
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).
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.
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.
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.
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.
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.
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.)
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!
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!
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.
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.
]]>2017-03-14T00:00:00.000Z<![CDATA[Touch Bar Support]]>https://electronjs.org/blog/touch-bar-support2017-03-08T00:00:00.000ZThe Electron 1.6.3 beta release contains initial support for the macOS Touch Bar.
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. 🎉
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 labelsconst reel1 = new TouchBarLabel()
const reel2 = new TouchBarLabel()
const reel3 = new TouchBarLabel()
// Spin result labelconst result = new TouchBarLabel()
// Spin buttonconst spin = new TouchBarButton({
label: '🎰 Spin',
backgroundColor: '#7851A9',
click: () => {
// Ignore clicks if already spinningif (spinning) {
return
}
spinning = true
result.label = ''let timeout = 10const spinLength = 4 * 1000// 4 secondsconst 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 = newSet([reel1.label, reel2.label, reel3.label]).size
if (uniqueValues === 1) {
// All 3 values are the same
result.label = '💰 Jackpot!'
result.textColor = '#FDFF00'
} elseif (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
])
letwindow
app.once('ready', () => {
window = new BrowserWindow({
frame: false,
titleBarStyle: 'hidden-inset',
width: 200,
height: 200,
backgroundColor: '#000'
})
window.loadURL('about:blank')
window.setTouchBar(touchBar)
})
]]>2017-03-08T00:00:00.000Z<![CDATA[Project of the Week: Voltra]]>https://electronjs.org/blog/voltra2017-03-07T00:00:00.000ZThis week we met with Aprile Elcich and
Paolo Fragomeni to talk about Voltra, an
Electron-powered music player.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
]]>2017-03-07T00:00:00.000Z<![CDATA[Electron Internals: Building Chromium as a Library]]>https://electronjs.org/blog/electron-internals-building-chromium-as-a-library2017-03-03T00:00:00.000ZElectron is based on Google's open-source Chromium, a project that is not
necessarily designed to be used by other projects. This post introduces
how Chromium is built as a library for Electron's use, and how the build
system has evolved over the years.
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.
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.
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.
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.
By taking this approach, though Chromium kept adding new exported symbols,
libchromiumcontent could still generate shared library files by stripping more
symbols.
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.
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.
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.
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 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.
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.
]]>2017-03-03T00:00:00.000Z<![CDATA[Project of the Week: WordPress Desktop]]>https://electronjs.org/blog/wordpress2017-02-28T00:00:00.000ZThis week we caught up with folks at Automattic to
talk about WordPress Desktop, an
open-source desktop client for managing WordPress content.
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.
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.
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.
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!)
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.
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.
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.
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.
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.
]]>2017-02-28T00:00:00.000Z<![CDATA[Project of the Week: Dat]]>https://electronjs.org/blog/dat2017-02-21T00:00:00.000ZThis week's featured project is Dat, a
grant-funded, open source, decentralized tool
for distributing data sets. Dat is built and maintained by a
geodistributed team, many of whom helped
write this post.
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).
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.
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.
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.
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.
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!
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!
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.
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.
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.
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!
]]>2017-02-21T00:00:00.000Z<![CDATA[Project of the Week: Ghost]]>https://electronjs.org/blog/ghost2017-02-14T00:00:00.000ZThis week we chatted with Felix Rieseberg, desktop engineer at Slack and maintainer of Ghost Desktop, an Electron client for the Ghost publishing platform.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
]]>2017-02-14T00:00:00.000Z<![CDATA[Project of the Week: Beaker Browser]]>https://electronjs.org/blog/beaker-browser2017-02-07T00:00:00.000ZThis week we caught up with Paul Frazee, creator
of Beaker Browser. Beaker is an experimental
peer-to-peer web browser that uses the Dat protocol to host sites from users’
devices.
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.
$ 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.
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.
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.
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.
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.
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.
Read through all the guides and advanced docs at least once.
Don't build a browser, it's a saturated market.
]]>2017-02-07T00:00:00.000Z<![CDATA[Project of the Week: Kap]]>https://electronjs.org/blog/kap2017-01-31T00:00:00.000ZThe Electron community is growing quickly, and people are creating powerful
new apps and tools at an astounding rate. To celebrate this creative momentum
and keep the community informed of some of these new projects, we've decided to
start a weekly blog series featuring noteworthy Electron-related projects.
This post is the first in the series, and features Kap,
an open-source screen recording app built by Wulkano,
a geodistributed team of freelance designers and developers.
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.
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.
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).
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.
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.
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.
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!
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!
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!).
]]>2017-01-31T00:00:00.000Z<![CDATA[Electron Simple Samples]]>https://electronjs.org/blog/simple-samples2017-01-19T00:00:00.000ZWe recently hosted an Electron hackathon at GitHub HQ for members of Hackbright Academy, a coding school for women founded in San Francisco. To help attendees get a head start on their projects, our own Kevin Sawicki created a few sample Electron applications.
If you're new to Electron development or haven't yet tried it out, these
sample applications are a great place to start. They are small, easy to read,
and the code is heavily commented to explain how everything works.
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.
awesome-electron - A GitHub repository that collects the latest and greatest Electron-related tutorials, books, videos, etc.
]]>2017-01-19T00:00:00.000Z<![CDATA[Electron Userland]]>https://electronjs.org/blog/userland2016-12-20T00:00:00.000ZWe've added a new userland section to
the Electron website to help users discover the people, packages, and apps that make
up our flourishing open-source ecosystem.
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.
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.
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:
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.
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:
Thanks to you, the Electron community, for making userland what it is today!
]]>2016-12-20T00:00:00.000Z<![CDATA[Certificate Transparency Fix]]>https://electronjs.org/blog/certificate-transparency-fix2016-12-09T00:00:00.000ZElectron 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.
]]>2016-12-09T00:00:00.000Z<![CDATA[September 2016: New Apps]]>https://electronjs.org/blog/september-2016-roundup2016-10-06T00:00:00.000ZHere are the new Electron apps and talks that were added to the site in September.
This site is updated with new apps and meetups through pull requests from the community. You can watch the repository to get notifications of new additions or if you're not interested in all of the site's changes, subscribe to the blog RSS feed.
If you've made an Electron app or host a meetup, make a pull request to add it to the site and it will make the next roundup.
In September, GitHub held its GitHub Universe conference billed as the event for people building the future of software. There were a couple of interesting Electron talks at the event.
]]>2016-10-06T00:00:00.000Z<![CDATA[Electron's API Docs as Structured Data]]>https://electronjs.org/blog/api-docs-json-schema2016-09-27T00:00:00.000ZToday we're announcing some improvements to Electron's documentation. Every new
release now includes a
JSON file
that describes all of Electron's public APIs in detail. We created this file to
enable developers to use Electron's API documentation in interesting new ways.
Each API is an object with properties like name, description, type, etc.
Classes such as BrowserWindow and Menu have additional properties describing
their instance methods, instance properties, instance events, etc.
Here's an excerpt from the schema that describes the BrowserWindow class:
To make it easy for developers to use this structured data in their projects,
we've created electron-docs-api, a small
npm package that is published automatically whenever there's a new Electron
release.
npm install electron-api-docs --save
For instant gratification, try out the module in your Node.js REPL:
npm i -g trymodule && trymodule electron-api-docs=apis
The electron-docs-linter
is a new development dependency of the electron/electron repository.
It is a command-line tool that lints all the markdown files and enforces the
rules of the styleguide. If errors are found, they are listed and the release
process is halted. If the API docs are valid, the electron-json.api file
is created and
uploaded to GitHub
as part of the Electron release.
Earlier this year, Electron's codebase was updated to use the
standard linter for all JavaScript. Standard's
README sums up the reasoning behind this choice:
Adopting standard style means ranking the importance of code clarity and community conventions higher than personal style. This might not make sense for 100% of projects and development cultures, however open source can be a hostile place for newbies. Setting up clear, automated contributor expectations makes a project healthier.
We also recently created
standard-markdown to verify that
all the JavaScript code snippets in our documentation are valid and consistent
with the style in the codebase itself.
Together these tools help us use continuous integration (CI) to automatically
find errors in pull requests. This reduces the burden placed on humans doing code
review, and gives us more confidence about the accuracy of our documentation.
Electron's documentation is constantly improving, and we have our awesome
open-source community to thank for it. As of this writing, nearly 300 people
have contributed to the docs.
We're excited to see what people do with this new structured data. Possible uses
include:
]]>2016-09-27T00:00:00.000Z<![CDATA[Electron Internals: Weak References]]>https://electronjs.org/blog/electron-internals-weak-references2016-09-20T00:00:00.000ZAs a language with garbage collection, JavaScript frees users from managing
resources manually. But because Electron hosts this environment, it has to be
very careful avoiding both memory and resources leaks.
This post introduces the concept of weak references and how they are used to
manage resources in Electron.
In JavaScript, whenever you assign an object to a variable, you are adding a
reference to the object. As long as there is a reference to the object, it will
always be kept in memory. Once all references to the object are gone, i.e. there
are no longer variables storing the object, the JavaScript engine will recoup
the memory on next garbage collection.
A weak reference is a reference to an object that allows you to get the object
without effecting whether it will be garbage collected or not. You will also get
notified when the object is garbage collected. It then becomes possible to
manage resources with JavaScript.
Using the NativeImage class in Electron as an example, every time you call the
nativeImage.create() API, a NativeImage instance is returned and it is
storing the image data in C++. Once you are done with the instance and the
JavaScript engine (V8) has garbage collected the object, code in C++ will be
called to free the image data in memory, so there is no need for users manage
this manually.
Another example is the window disappearing problem, which
visually shows how the window is garbage collected when all the references to it
are gone.
There is no way to directly test weak references in raw JavaScript since the
language doesn't have a way to assign weak references. The only API in
JavaScript related to weak references is WeakMap, but since it only
creates weak-reference keys, it is impossible to know when an object has been
garbage collected.
In versions of Electron prior to v0.37.8, you can use the internal
v8Util.setDestructor API to test weak references, which adds a weak reference
to the passed object and calls the callback when the object is garbage collected:
// Code below can only run on Electron < v0.37.8.var v8Util = process.atomBinding('v8_util')
var object = {}
v8Util.setDestructor(object, function () {
console.log('The object is garbage collected')
})
// Remove all references to the object.
object = undefined// Manually starts a GC.
gc()
// Console prints "The object is garbage collected".
Note that you have to start Electron with the --js-flags="--expose_gc" command
switch to expose the internal gc function.
The API was removed in later versions because V8 actually does not allow running
JavaScript code in the destructor and in later versions doing so would cause
random crashes.
Apart from managing native resources with C++, Electron also needs weak
references to manage JavaScript resources. An example is Electron's remote
module, which is a Remote Procedure Call (RPC) module
that allows using objects in the main process from renderer processes.
One key challenge with the remote module is to avoid memory leaks. When users
acquire a remote object in the renderer process, the remote module must
guarantee the object continues to live in the main process until the references
in the renderer process are gone. Additionally, it also has to make sure the
object can be garbage collected when there are no longer any reference to it in
renderer processes.
For example, without proper implementation, following code would cause memory
leaks quickly:
const {remote} = require('electron')
for (let i = 0; i < 10000; ++i) {
remote.nativeImage.createEmpty()
}
The resource management in the remote module is simple. Whenever an object is
requested, a message is sent to the main process and Electron will store
the object in a map and assign an ID for it, then send the ID back to the
renderer process. In the renderer process, the remote module will receive
the ID and wrap it with a proxy object and when the proxy object is garbage
collected, a message will be sent to the main process to free the object.
Using remote.require API as an example, a simplified implementation looks
like this:
remote.require = function (name) {
// Tell the main process to return the metadata of the module.const meta = ipcRenderer.sendSync('REQUIRE', name)
// Create a proxy object.const object = metaToValue(meta)
// Tell the main process to free the object when the proxy object is garbage// collected.
v8Util.setDestructor(object, function () {
ipcRenderer.send('FREE', meta.id)
})
return object
}
In the main process:
const map = {}
const id = 0
ipcMain.on('REQUIRE', function (event, name) {
const object = require(name)
// Add a reference to the object.
map[++id] = object
// Convert the object to metadata.
event.returnValue = valueToMeta(id, object)
})
ipcMain.on('FREE', function (event, id) {
delete map[id]
})
With the previous simple implementation, every call in the remote module will
return a new remote object from the main process, and each remote object
represents a reference to the object in the main process.
The design itself is fine, but the problem is when there are multiple calls to
receive the same object, multiple proxy objects will be created and for
complicated objects this can add huge pressure on memory usage and garbage
collection.
For example, the following code:
const {remote} = require('electron')
for (let i = 0; i < 10000; ++i) {
remote.getCurrentWindow()
}
It first uses a lot of memory creating proxy objects and then occupies
the CPU (Central Processing Unit) for garbage collecting them and sending IPC
messages.
An obvious optimization is to cache the remote objects: when there is already
a remote object with the same ID, the previous remote object will be returned
instead of creating a new one.
This is not possible with the API in JavaScript core. Using the normal map
to cache objects will prevent V8 from garbage collecting the objects, while the
WeakMap class can only use objects as weak keys.
To solve this, a map type with values as weak references is added, which is
perfect for caching objects with IDs. Now the remote.require looks like
this:
const remoteObjectCache = v8Util.createIDWeakMap()
remote.require = function (name) {
// Tell the main process to return the meta data of the module.
...
if (remoteObjectCache.has(meta.id))
return remoteObjectCache.get(meta.id)
// Create a proxy object.
...
remoteObjectCache.set(meta.id, object)
return object
}
Note that the remoteObjectCache stores objects as weak references, so there
is no need to delete the key when the object is garbage collected.
]]>2016-09-20T00:00:00.000Z<![CDATA[August 2016: New Apps]]>https://electronjs.org/blog/august-2016-roundup2016-09-06T00:00:00.000ZHere are the new Electron apps that were added to the site in August.
The site is updated with new apps and meetups through pull requests from the community. You can watch the repository to get notifications of new additions or if you're not interested in all of the site's changes, subscribe to the blog RSS feed.
If you've made an Electron app or host a meetup, make a pull request to add it to the site and it will make the next roundup.
]]>2016-09-06T00:00:00.000Z<![CDATA[Accessibility Tools]]>https://electronjs.org/blog/accessibility-tools2016-08-23T00:00:00.000ZMaking accessible applications is important and we're happy to introduce new functionality to Devtron and Spectron that gives developers the opportunity to make their apps better for everyone.
Accessibility concerns in Electron applications are similar to those of websites because they're both ultimately HTML. With Electron apps, however, you can't use the online resources for accessibility audits because your app doesn't have a URL to point the auditor to.
These new features bring those auditing tools to your Electron app. You can choose to add audits to your tests with Spectron or use them within DevTools with Devtron. Read on for a summary of the tools or checkout our accessibility documentation for more information.
In Devtron there is a new accessibility tab which will allow you to audit a page in your app, sort and filter the results.
Both of these tools are using the Accessibility Developer Tools library built by Google for Chrome. You can learn more about the accessibility audit rules this library uses on that repository's wiki.
If you know of other great accessibility tools for Electron, add them to the accessibility documentation with a pull request.
]]>2016-08-23T00:00:00.000Z<![CDATA[npm install electron]]>https://electronjs.org/blog/npm-install-electron2016-08-16T00:00:00.000ZAs of Electron version 1.3.1, you can npm install electron --save-dev to
install the latest precompiled version of Electron in your app.
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.
]]>2016-08-16T00:00:00.000Z<![CDATA[Electron Internals: Using Node as a Library]]>https://electronjs.org/blog/electron-internals-using-node-as-a-library2016-08-08T00:00:00.000ZThis is the second post in an ongoing series explaining the internals of
Electron. Check out the first post about event loop integration
if you haven't already.
Most people use Node for server-side applications, but because of Node's rich
API set and thriving community, it is also a great fit for an embedded library.
This post explains how Node is used as a library in Electron.
The node.gyp file in Node's source code directory describes how Node
is built, along with lots of GYP variables controlling which parts of
Node are enabled and whether to open certain configurations.
To change the build flags, you need to set the variables in the .gypi file of
your project. The configure script in Node can generate some common
configurations for you, for example running ./configure --shared will generate
a config.gypi with variables instructing Node to be built as a shared library.
Electron does not use the configure script since it has its own build scripts.
The configurations for Node are defined in the common.gypi file
in Electron's root source code directory.
In Electron, Node is being linked as a shared library by setting the GYP
variable node_shared to true, so Node's build type will be changed from
executable to shared_library, and the source code containing the Node's main
entry point will not be compiled.
Since Electron uses the V8 library shipped with Chromium, the V8 library
included in Node's source code is not used. This is done by setting both
node_use_v8_platform and node_use_bundled_v8 to false.
When linking with Node, there are two options: you can either build Node as a
static library and include it in the final executable, or you can build it as a
shared library and ship it alongside the final executable.
In Electron, Node was built as a static library for a long time. This made the
build simple, enabled the best compiler optimizations, and allowed Electron to
be distributed without an extra node.dll file.
However, this changed after Chrome switched to use BoringSSL. BoringSSL is a
fork of OpenSSL that removes several unused APIs and changes many existing
interfaces. Because Node still uses OpenSSL, the compiler would generate numerous
linking errors due to conflicting symbols if they were linked together.
Electron couldn't use BoringSSL in Node, or use OpenSSL in Chromium, so the only
option was to switch to building Node as a shared library, and
hide the BoringSSL and OpenSSL symbols in the components of each.
This change brought Electron some positive side effects. Before this
change, you could not rename the executable file of Electron on Windows if you
used native modules because the name of the executable was hard coded in the
import library. After Node was built as a shared library, this limitation was gone
because all native modules were linked to node.dll, whose name didn't need to
be changed.
Native modules in Node work by defining an entry function for Node to load,
and then searching the symbols of V8 and libuv from Node. This is a bit
troublesome for embedders because by default the symbols of V8 and libuv are
hidden when building Node as a library and native modules will fail to load
because they cannot find the symbols.
After all the work of building and linking with Node, the final step is to run
Node in your app.
Node doesn't provide many public APIs for embedding itself into other apps.
Usually, you can just call node::Start and node::Init to start
a new instance of Node. However, if you are building a complex app based on Node,
you have to use APIs like node::CreateEnvironment to precisely control every
step.
In Electron, Node is started in two modes: the standalone mode that runs in the
main process, which is similar to official Node binaries, and the embedded mode
which inserts Node APIs into web pages. The details of this will be explained
in a future post.
]]>2016-08-08T00:00:00.000Z<![CDATA[July 2016: New Apps and Meetups]]>https://electronjs.org/blog/jully-2016-roundup2016-08-04T00:00:00.000ZWe're starting a monthly roundup to highlight activity in the Electron community. Each roundup will feature things like new apps, upcoming meetups, tools, videos, etc.
This site is updated with new apps and meetups through pull requests from the community. You can watch the repository to get notifications of new additions or if you're not interested in all of the site's changes, subscribe to the blog RSS feed.
If you've made an Electron app or host a meetup, make a pull request to add it to the site and it will make the next roundup.
{: .table .table-ruled .table-full-width .table-with-spacious-first-column .mb-7}
| | | |
| --- | --- | -- |
| | Demio | A Webinar platform built for inbound sales and marketing |
| | Electorrent | A remote client app for uTorrent server |
| | PhoneGap | The open source framework that gets you building amazing mobile apps using web technology |
| | WordMark | A lightweight blog publishing editor for Markdown writers |
| | UbAuth | App to help developers create access tokens for Uber applications with OAuth 2.0 |
| | HyperTerm | HTML/JS/CSS terminal |
| | Marp | Markdown presentation writer |
| | Glyphr Studio | A free, web based font designer, focusing on font design for hobbyists |
| | BitCrypt | A simple file encryption application for Windows Encrypt your bits |
| | Trym | Beautiful small app for macOS to help you view, optimize and convert SVG icons |
| | Booker | Text editor with the power of Markdown |
| | PhonePresenter | The smartest presentation clicker |
| | Yout | The new way to watch your playlists from YouTube on desktop |
{: .table .table-ruled .table-full-width .table-with-spacious-first-column .mb-7}
| | |
| --- | -- |
| Electron Open Source Desktop Framework | London, UK |
]]>2016-08-04T00:00:00.000Z<![CDATA[July 2016: New Apps and Meetups]]>https://electronjs.org/blog/july-2016-roundup2016-08-04T00:00:00.000ZWe're starting a monthly roundup to highlight activity in the Electron community. Each roundup will feature things like new apps, upcoming meetups, tools, videos, etc.
This site is updated with new apps and meetups through pull requests from the community. You can watch the repository to get notifications of new additions or if you're not interested in all of the site's changes, subscribe to the blog RSS feed.
If you've made an Electron app or host a meetup, make a pull request to add it to the site and it will make the next roundup.
{: .table .table-ruled .table-full-width .table-with-spacious-first-column .mb-7}
| | | |
| --- | --- | -- |
| | Demio | A Webinar platform built for inbound sales and marketing |
| | Electorrent | A remote client app for uTorrent server |
| | PhoneGap | The open source framework that gets you building amazing mobile apps using web technology |
| | WordMark | A lightweight blog publishing editor for Markdown writers |
| | UbAuth | App to help developers create access tokens for Uber applications with OAuth 2.0 |
| | HyperTerm | HTML/JS/CSS terminal |
| | Marp | Markdown presentation writer |
| | Glyphr Studio | A free, web based font designer, focusing on font design for hobbyists |
| | BitCrypt | A simple file encryption application for Windows Encrypt your bits |
| | Trym | Beautiful small app for macOS to help you view, optimize and convert SVG icons |
| | Booker | Text editor with the power of Markdown |
| | PhonePresenter | The smartest presentation clicker |
| | Yout | The new way to watch your playlists from YouTube on desktop |
{: .table .table-ruled .table-full-width .table-with-spacious-first-column .mb-7}
| | |
| --- | -- |
| Electron Open Source Desktop Framework | London, UK |
]]>2016-08-04T00:00:00.000Z<![CDATA[Electron Internals: Message Loop Integration]]>https://electronjs.org/blog/electron-internals-node-integration2016-07-28T00:00:00.000ZThis is the first post of a series that explains the internals of Electron. This
post introduces how Node's event loop is integrated with Chromium in Electron.
There had been many attempts to use Node for GUI programming, like
node-gui for GTK+ bindings, and node-qt for QT bindings.
But none of them work in production because GUI toolkits have their own message
loops while Node uses libuv for its own event loop, and the main thread can only
run one loop at the same time. So the common trick to run GUI message loop in
Node is to pump the message loop in a timer with very small interval, which
makes GUI interface response slow and occupies lots of CPU resources.
During the development of Electron we met the same problem, though in a
reversed way: we had to integrate Node's event loop into Chromium's message
loop.
Before we dive into the details of message loop integration, I'll first explain
the multi-process architecture of Chromium.
In Electron there are two types of processes: the main process and the renderer
process (this is actually extremely simplified, for a complete view please see
Multi-process Architecture). The main process is responsible
for GUI work like creating windows, while the renderer process only deals with
running and rendering web pages.
Electron allows using JavaScript to control both the main process and renderer
process, which means we have to integrate Node into both processes.
My first try was reimplementing Chromium's message loop with libuv.
It was easy for the renderer process, since its message loop only listened to
file descriptors and timers, and I only needed to implement the interface with
libuv.
However it was significantly more difficult for the main process. Each platform
has its own kind of GUI message loops. macOS Chromium uses NSRunLoop,
whereas Linux uses glib. I tried lots of hacks to extract the
underlying file descriptors out of the native GUI message loops, and then fed
them to libuv for iteration, but I still met edge cases that did not work.
So finally I added a timer to poll the GUI message loop in a small interval. As
a result the process took a constant CPU usage, and certain operations had
long delays.
As libuv matured, it was then possible to take another approach.
The concept of backend fd was introduced into libuv, which is a file descriptor
(or handle) that libuv polls for its event loop. So by polling the backend fd it
is possible to get notified when there is a new event in libuv.
So in Electron I created a separate thread to poll the backend fd, and since I
was using the system calls for polling instead of libuv APIs, it was thread
safe. And whenever there was a new event in libuv's event loop, a message would
be posted to Chromium's message loop, and the events of libuv would then be
processed in the main thread.
In this way I avoided patching Chromium and Node, and the same code was used in
both the main and renderer processes.
You can find the implemention of the message loop integration in the
node_bindings files under electron/atom/common/. It can be
easily reused for projects that want to integrate Node.
]]>2016-07-28T00:00:00.000Z<![CDATA[Electron Podcasts]]>https://electronjs.org/blog/electron-podcasts2016-07-26T00:00:00.000ZLooking for an introduction to Electron? Two new podcasts have just been released that give a great overview of what it is, why it was built, and how it is being used.
Is Electron "just Chrome in a frame" or is it so much more? Jessica sets Scott on the right path and explains exactly where the Electron platform fits into your development world.
Electron is becoming more and more of a relevant and popular way of building multi-platform desktop apps with web technologies. Let's get a dive into this awesome tech and see how we can use it to enhance our own experience and our user's experience on the desktop.
If you're looking for an introduction to Electron, give the first a listen. The second goes into more detail about building apps with great tips from Nylas's Evan Morikawa.
We are currently working on two more podcasts that should come out next month, keep an eye on the @ElectronJS Twitter account for updates.
]]>2016-07-26T00:00:00.000Z<![CDATA[Electron 1.0]]>https://electronjs.org/blog/electron-1-02016-05-11T00:00:00.000ZFor the last two years, Electron has helped developers build cross platform
desktop apps using HTML, CSS, and JavaScript. Now we're excited to share a major
milestone for our framework and for the community that created it. The release
of Electron 1.0 is now available from electronjs.org.
Electron 1.0 represents a major milestone in API stability and maturity. This
release allows you to build apps that act and feel truly native on Windows,
Mac, and Linux. Building Electron apps is easier than ever with new docs,
new tools, and a new app to walk you through the Electron APIs.
If you're ready to build your very first Electron app, here's a quick start guide
to help you get started.
We are excited to see what you build next with Electron.
We released Electron when we launched Atom a little over two years ago.
Electron, then known as Atom Shell, was the framework we'd built Atom on top of.
In those days, Atom was the driving force behind the features and functionalities
that Electron provided as we pushed to get the initial Atom release out.
In these last two years we've seen both companies and open source projects
choose Electron as the foundation for their apps. Just in the past year, Electron
has been downloaded over 1.2 million times. Take a tour of some
of the amazing Electron apps and add your own if it isn't already there.
Along with the 1.0 release, we're releasing a new app to help you explore the
Electron APIs and learn more about how to make your Electron app feel native.
The Electron API Demos app contains code snippets to help
you get your app started and tips on effectively using the Electron APIs.
We've also added a new extension to help you debug your Electron
apps. Devtron is an open-source extension to the Chrome Developer Tools
designed to help you inspect, debug, and troubleshoot your Electron app.
Require graph that helps you visualize your app's internal and external
library dependencies in both the main and renderer processes
IPC monitor that tracks and displays the messages sent and received
between the processes in your app
Event inspector that shows you the events and listeners that are registered
in your app on the core Electron APIs such as the window, app, and processes
App Linter that checks your apps for common mistakes and missing
functionality
Finally, we're releasing a new version of Spectron, the integration
testing framework for Electron apps.
Spectron 3.0 has comprehensive support for the entire Electron API allowing you
to more quickly write tests that verify your application's behavior in various
scenarios and environments. Spectron is based on ChromeDriver
and WebDriverIO so it also has full APIs for page navigation, user
input, and JavaScript execution.
Electron 1.0 is the result of a community effort by hundreds of developers.
Outside of the core framework, there have been hundreds of libraries and tools
released to make building, packaging, and deploying Electron apps easier.
There is now a new community page that lists many of the awesome
Electron tools, apps, libraries, and frameworks being developed. You can also
check out the Electron and Electron Userland
organizations to see some of these fantastic projects.
New to Electron? Watch the Electron 1.0 intro video:
]]>2016-05-11T00:00:00.000Z<![CDATA[What's new in Electron 0.37]]>https://electronjs.org/blog/electron-372016-03-25T00:00:00.000ZElectron 0.37 was recently released and included a major upgrade from Chrome 47 to Chrome 49 and also several new core APIs. This latest release brings in all the new features shipped in Chrome 48 and Chrome 49. This includes CSS custom properties, increased ES6 support, KeyboardEvent improvements, Promise improvements, and many other new features now available in your Electron app.
If you've used preprocessed languages like Sass and Less, you're probably familiar with variables, which allow you to define reusable values for things like color schemes and layouts. Variables help keep your stylesheets DRY and more maintainable.
CSS custom properties are similar to preprocessed variables in that they are reusable, but they also have a unique quality that makes them even more powerful and flexible: they can be manipulated with JavaScript. This subtle but powerful feature allows for dynamic changes to visual interfaces while still benefitting from CSS's hardware acceleration, and reduced code duplication between your frontend code and stylesheets.
Let's walk through a simple variable example that can be tweaked live in your app.
:root {
--awesome-color: #A5ECFA;
}
body {
background-color: var(--awesome-color);
}
The variable value can be retrieved and changed directly in JavaScript:
// Get the variable value ' #A5ECFA'let color = window.getComputedStyle(document.body).getPropertyValue('--awesome-color')
// Set the variable value to 'orange'document.body.style.setProperty('--awesome-color', 'orange')
The variable values can be also edited from the Styles section of the development tools for quick feedback and tweaks:
Chrome 48 added the new code property available on KeyboardEvent events that will be the physical key pressed independent of the operating system keyboard layout.
This should make implementing custom keyboard shortcuts in your Electron app more accurate and consistent across machines and configurations.
window.addEventListener('keydown', function(event) {
console.log(`${event.code} was pressed.`)
})
The version of V8 now in Electron incorporates 91% of ES2015. Here are a few interesting additions you can use out of the box—without flags or pre-compilers:
These events are emitted when the scroll wheel event phase has begun or has ended.
const {BrowserWindow} = require('electron')
letwindow = new BrowserWindow({width: 500, height: 500})
window.on('scroll-touch-begin', function () { console.log('Scroll touch started') })
window.on('scroll-touch-end', function () { console.log('Scroll touch ended') })
]]>2016-03-25T00:00:00.000Z<![CDATA[Use V8 and Chromium Features in Electron]]>https://electronjs.org/blog/latest-v8-chromium-features2016-01-07T00:00:00.000ZBuilding an Electron application means you only need to create one codebase and design for one browser, which is pretty handy. But because Electron stays up to date with Node.js and Chromium as they release, you also get to make use of the great features they ship with. In some cases this eliminates dependencies you might have previously needed to include in a web app.
There are many features and we'll cover some here as examples, but if you're interested in learning about all features you can keep an eye on the Google Chromium blog and Node.js changelogs. You can see what versions of Node.js, Chromium and V8 Electron is using at electronjs.org/#electron-versions.
Electron combines Chromium's rendering library with Node.js. The two share the same JavaScript engine, V8. Many ECMAScript 2015 (ES6) features are already built into V8 which means you can use them in your Electron application without any compilers.
Below are a few examples but you can also get classes (in strict mode), block scoping, promises, typed arrays and more. Check out this list for more information on ES6 features in V8.
Arrow Functions
findTime () => {
console.log(newDate())
}
String Interpolation
var octocat = "Mona Lisa";
console.log(`The octocat's name is ${octocat}`);
Thanks to all the hard work Google and contributors put into Chromium, when you build Electron apps you can also use cool things like (but not limited to):
Follow along with the Google Chromium blog to learn about features as new versions ship and again, you can check the version of Chromium that Electron uses here.
Tweet to us @ElectronJS with your favorite features built into V8 or Chromium.
]]>2016-01-07T00:00:00.000Z<![CDATA[API Changes Coming in Electron 1.0]]>https://electronjs.org/blog/electron-api-changes2015-11-17T00:00:00.000ZSince the beginning of Electron, starting way back when it used to be called Atom-Shell, we have been experimenting with providing a nice cross-platform JavaScript API for Chromium's content module and native GUI components. The APIs started very organically, and over time we have made several changes to improve the initial designs.
Now with Electron gearing up for a 1.0 release, we'd like to take the opportunity for change by addressing the last niggling API details. The changes described below are included in 0.35.x, with the old APIs reporting deprecation warnings so you can get up to date for the future 1.0 release. An Electron 1.0 won't be out for a few months so you have some time before these changes become breaking.
By default, warnings will show if you are using deprecated APIs. To turn them off you can set process.noDeprecation to true. To track the sources of deprecated API usages, you can set process.throwDeprecation to true to throw exceptions instead of printing warnings, or set process.traceDeprecation to true to print the traces of the deprecations.
Built-in modules are now grouped into one module, instead of being separated into independent modules, so you can use them without conflicts with other modules:
var app = require('electron').app
var BrowserWindow = require('electron').BrowserWindow
The old way of require('app') is still supported for backward compatibility, but you can also turn if off:
Because of the way using built-in modules has changed, we have made it easier to use main-process-side modules in renderer process. You can now just access remote's attributes to use them:
// New way.var app = require('electron').remote.app
var BrowserWindow = require('electron').remote.BrowserWindow
Instead of using a long require chain:
// Old way.var app = require('electron').remote.require('app')
var BrowserWindow = require('electron').remote.require('BrowserWindow')
The ipc module existed on both the main process and renderer process and the API was different on each side, which is quite confusing for new users. We have renamed the module to ipcMain in the main process, and ipcRenderer in the renderer process to avoid confusion:
// In main process.var ipcMain = require('electron').ipcMain
// In renderer process.var ipcRenderer = require('electron').ipcRenderer
And for the ipcRenderer module, an extra event object has been added when receiving messages, to match how messages are handled in ipcMain modules:
ipcRenderer.on('message', function (event) {
console.log(event)
})
The BrowserWindow options had different styles based on the options of other APIs, and were a bit hard to use in JavaScript because of the - in the names. They are now standardized to the traditional JavaScript names:
new BrowserWindow({ minWidth: 800, minHeight: 600 })
The API names in Electron used to prefer camelCase for all API names, like Url to URL, but the DOM has its own conventions, and they prefer URL to Url, while using Id instead of ID. We have done the following API renames to match the DOM's styles:
Url is renamed to URL
Csp is renamed to CSP
You will notice lots of deprecations when using Electron v0.35.0 for your app because of these changes. An easy way to fix them is to replace all instances of Url with URL.
The style of Tray event names was a bit different from other modules so a rename has been done to make it match the others.
clicked is renamed to click
double-clicked is renamed to double-click
right-clicked is renamed to right-click
]]>2015-11-17T00:00:00.000Z<![CDATA[Mac App Store and Windows Auto Updater on Electron]]>https://electronjs.org/blog/electron-updates-mac-app-store-and-windows-auto-updater2015-11-05T00:00:00.000ZRecently Electron added two exciting features: a Mac App Store compatible build and a built-in Windows auto updater.
As of v0.34.0 each Electron release includes a build compatible with the Mac App Store. Previously an application built on Electron would not comply with Apple's requirements for the Mac App Store. Most of these requirements are related to the use of private APIs. In order to sandbox Electron in such a way that it complies with the requirements two modules needed to be removed:
crash-reporter
auto-updater
Additionally some behaviors have changed with respect to detecting DNS changes, video capture and accessibility features. You can read more about the changes and submitting your app to the Mac App store in the documentation. The distributions can be found on the Electron releases page, prefixed with mas-.
In Electron v0.34.1 the auto-updater module was improved in order to work with Squirrel.Windows. This means that Electron ships with easy ways for auto updating your app on both OS X and Windows. You can read more on setting up your app for auto updating on Windows in the documentation.
]]>2015-11-05T00:00:00.000Z<![CDATA[What's New in Electron]]>https://electronjs.org/blog/2015-whats-new-in-electron2015-10-15T00:00:00.000ZThere have been some interesting updates and talks given on Electron recently, here's a roundup.
We have restructured and standardized the documentation to look better and read better. There are also community-contributed translations of the documentation, like Japanese and Korean.
A patch by @jaanus has been merged that, like the other built-in OS X apps, allows creating frameless windows with system traffic lights integrated on OS X Yosemite and later.
]]>2015-10-15T00:00:00.000Z<![CDATA[Electron Meetup at GitHub HQ]]>https://electronjs.org/blog/electron-meetup2015-09-17T00:00:00.000ZJoin us September 29th at GitHub's HQ for an Electron meetup hosted by Atom team members @jlord and @kevinsawicki. There will be talks, food to snack on, and time to hangout and meet others doing cool things with Electron. We'll also have a bit of time to do lightning talks for those interested. Hope to see you there!
Talks
Jonathan Ross and Francois Laberge from Jibo will share how they use Electron to animate a robot.
Jessica Lord will talk about building a teaching tool, Git-it, on Electron.
Tom Moor will talk about the pros and cons of building video and screen sharing on Electron with speak.io.
Ben Gotow will preview N1: The Nylas Mail Client and talk about developing it on Electron.
]]>2015-09-17T00:00:00.000Z<![CDATA[Electron Documentation]]>https://electronjs.org/blog/electron-doumentation2015-06-04T00:00:00.000ZThis week we've given Electron's documentation a home on electronjs.org. You can visit /docs/latest for the latest set of docs. We'll keep versions of older docs, too, so you're able to visit /docs/vX.XX.X for the docs that correlate to the version you're using.
You can visit /docs to see what versions are available or /docs/all to see the latest version of docs all on one page (nice for cmd + f searches).
If you'd like to contribute to the docs content, you can do so in the Electron repository, where the docs are fetched from. We fetch them for each minor release and add them to the Electron site repository, which is made with Jekyll.
If you're interested in learning more about how we pull the docs from one repository to another continue reading below. Otherwise, enjoy the docs!
We're preserving the documentation within the Electron core repository as is. This means that electron/electron will always have the latest version of the docs. When new versions of Electron are released, we duplicate them over on the Electron website repository, electron/electronjs.org.
To fetch the docs we run a script with a command line interface of script/docs vX.XX.X with or without the --latest option (depending on if the version you're importing is the latest version). Our script for fetching docs uses a few interesting Node modules:
For Jekyll to render each page it needs at least empty front matter. We're going to make use of front matter on all of our pages so while we're streaming out the /docs directory we check to see if a file is the README.md file (in which case it receives one front matter configuration) or if it is any other file with a markdown extension (in which case it receives slightly different front matter).
Each page receives this set of front matter variables:
In the site's _config.yml file a variable latest_version is set every time the --latest flag is used when fetching docs. We also add a list of all the versions that have been added to the site as well as the permalink we'd like for the entire docs collection.
The file latest.md in our site root is empty except for this front matter which allows users to see the index (aka README) of the latest version of docs by visiting this URL, electron.atom.io/docs/latest, rather than using the latest version number specifically (though you can do that, too).
To create a page showing the versions that are available we just loop through the list in our config on a file, versions.md, in the site's root. Also we give this page a permalink: /docs/
{% raw %}
{% for version in site.available_versions %}
- [{{ version }}](/docs/{{ version }})
{% endfor %}
{% endraw %}
Hope you enjoyed these technical bits! If you're interested in more information on using Jekyll for documentation sites, checkout how GitHub's docs team publishes GitHub's docs on Jekyll.
]]>2015-06-04T00:00:00.000Z<![CDATA[Atom Shell is now Electron]]>https://electronjs.org/blog/electron2015-04-23T00:00:00.000ZAtom Shell is now called Electron. You can learn more about Electron and what people are building with it at its new home electronjs.org.
Electron is the cross-platform application shell we originally built for the Atom editor to handle the Chromium/Node.js event loop integration and native APIs.
When we got started, our goal wasn't just to support the needs of a text editor. We also wanted to create a straightforward framework that would allow people to use web technologies to build cross-platform desktop apps with all of the native trimmings.
In two years, Electron has grown immensely. It now includes automatic app updates, Windows installers, crash reporting, notifications, and other useful native app features — all exposed through JavaScript APIs. And we have more in the works. We plan to extract even more libraries from Atom to make building a native app with web technologies as easy as possible.
So far, individual developers, early-stage startups, and large companies have built apps on Electron. They've created a huge range of apps — including chat apps, database explorers, map designers, collaborative design tools, and mobile prototyping apps.
Check out the new electronjs.org to see more of the apps people have built on Electron or take a look at the docs to learn more about what else you can make.
If you've already gotten started, we'd love to chat with you about the apps you're building on Electron. Email info@electronjs.org to tell us more. You can also follow the new @ElectronJS Twitter account to stay connected with the project.
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
{: .screenshot }
