We'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.
This 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.
Looking 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.
For 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:
Electron 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.
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:
// Destructuring an array and skipping the second element const[first,, last]=findAll(); // Destructuring function parameters functionwhois({displayName: displayName,fullName:{firstName: name }}){ console.log(`${displayName} is ${name}`); } let user ={ displayName:'jdoe', fullName:{ firstName:'John', lastName:'Doe', }, }; whois(user);// "jdoe is John" // Destructuring an object let{ name, avatar }=getUser();
Building 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.
Since 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; varBrowserWindow=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; varBrowserWindow=require('electron').remote.BrowserWindow;
Instead of using a long require chain:
// Old way. var app =require('electron').remote.require('app'); varBrowserWindow=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:
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:
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.
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.
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.
Join 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.