Evolution of Electron

皆さんこんにちは, today I’m going to talk about how Electron was born, and how it grows popular.

And with special thanks to Kohei TAKATA’s translation, I can give this talk in Japanese.

First I’m introducing myself a bit. I have three names, in China people would call me ちょうせい in Chinese, in America I’m called Cheng Zhao, which is the English representation of my name. However in Japan my name becomes ジャオ チェン, which is the カタカナ of my English name. So I have three names even though they all mean the same thing.

I created Electron, and currently I’m working at GitHub, still developing Electron.

Before I talk about Electron, I have to talk about the Atom editor first. Electron was born because of Atom, and the early technical choices of Electron were made mostly to fit Atom’s needs.

The first edition of Atom editor was born 5 years ago, GitHub’s CEO was its major developer. It was not using Electron, it was a simple Cocoa app that uses embedded webview.

It only worked on OS X, but it didn’t take lots of disk space and did not try to eat all of computer’s memory.

After a few more developers started to work on Atom, the native layer of Atom was switched to Chromium Embedded Framework, and Atom started to use Chromium with V8 and WebKit as platform. CEF made it possible to port Atom to all platforms, it also provided a modern web platform to make development much easier.

In the meanwhile, Node.js was starting to get popular, and node-webkit was also born.

node-webkit was going through a very similar path with Atom. The first edition of node-webkit was a Node.js module that insert Node.js symbols into a WebKit browser. After I took the development of node-webkit, it also became a platform based on Chromium.

So for Atom, it was very tempting to migrate from its custom native layer to node-webkit, and developers of Atom editor actually tried to port Atom to use node-webkit.

Atom had become a large codebase at that time, so the porting work was huge, Atom was using lots of custom native bindings, and they have to convert all of those code to use APIs of Node.js and node-webkit instead.

However, the try failed in the end.

There were many reasons to the failure: node-webkit was not stable at that time, and it lacked lots of critical features. This was mainly because node-webkit was very young, and no one knew how a good web platform should look like.

Also because Atom was a huge codebase, converting all the code at once was a very difficult task.

However that didn’t mean Atom was throwing node-webkit away, instead the solution was to hire the developer of node-webkit to keep improving node-webkit, i.e. hire me. And in the meanwhile I needed to help Atom use a more progressive way to port to the new platform.

So Atom’s new plan became like this: my first task was to add Node.js support to CEF, so Atom can gradually migrate existing code to use Node.js. The project was called cefode, which is a combination of CEF and Node, and you can find the project under my GitHub account.

After that, the developers of Atom started to work on developing Atom with Node.js APIs, and in parallel I kept improving node-webkit to make it a better platform for Atom . Once node-webkit became mature enough we could simply switch Atom to use node-webkit, and hopefully this time the port could be easy and work out of box.

However when working on improving node-webkit, I started to realize a few problems with this approach. First, node-webkit’s architecture was not suitable for multi-windows apps, it assumed every app has and only has one main window, app’s code would soon become a mess when supporting multiple windows in one app. It would need a redesign of whole node-webkit’s APIs to solve this.

The other problem was, node-webkit was a personal project instead of an organization, and the its original author did not want to handle the leadership of the project to me after the project got popular. I had to discuss with the original author on every technical decisions, even though all of its code were written by me.

So obviously the only solution left for me, was to start a new project and rewrite node-webkit from scratch.

Then atom-shell was born, we replaced node-webkit with it in our plan. Though it took a longer time to rewrite, it was working pretty well for Atom.

There were some major differences between atom-shell and node-webkit. atom-shell allows running JavaScript in the main process, which is critical for serious apps that need to manage app’s lifetime themselves.

Also atom-shell separates the building of Chromium into online servers, so developers do not have to build the whole Chromium on the local machine. This makes the development much easier and faster, and allows developers with slow machines to contribute to atom-shell.

And finally, I improved the way of integrating Node.js into Chromium, so we no longer needed to patch lots of places of Chromium, and got rid of all crashes caused by Node.js integration.

So in summary, atom-shell had a better design, and was friendly to contributors.

Things went fast and steady then.

After developing atom-shell for one year, it was open sourced along with Atom. And one year later, we renamed atom-shell to Electron for a better name. And this year we released Electron 1.0.

Electron keeps getting more users, the stars number on GitHub has increased by more than 37 thousands in two years. Now there are new Electron apps published for almost every day, and companies are building their products on Electron.

We also get of of contributors. Today we have 25 community maintainers, about 500 contributors. In recent releases, more than half of the changes were from contributors outside GitHub.

Electron’s team also grows from just me, to 4 developers, and we are going to hire more people to Electron team.

At last I want to share how Electron grows big, hopefully it would be helpful for your own projects.

Electron started as a one-person project, and at first there was only one user: Atom editor. But as Electron grew, it attracted more users, and as bonus it started to get some more contributors. And in those contributors, some of them will become long time maintainers.

When we have more maintainers, the project will grow bigger and we will get much more users, it is like a snowball keeps growing. And the key for growth is keep getting more contributors, if you can not get new contributors, the project either stays at small scale, or dies in the end.

To keep the contributors, I think there are two key points.

First, we should be responsive to issues and pull requests, otherwise possible contributors may just turn away since their work would very likely be ignored. I’m proud that Electron does a very good job on this, according to the statistics, most issues and pull requests have been give good responses.

Second, efforts should be made to make development easier. There are many ways to achieve that, we can provide automated scripts to setup the building environment, we can use good code review to help contributors know the project better, we can keep refactoring the code to make it easier for contributors to understand. Most contributors do not have good understand of your project, we make it easier for people to contribute code, and more people will become contributors.

I believe Electron can get today because we did this very well.

This is all of it, thanks for listening.