Evolution of Electron(日本語)

(このトークは @kohei-takata が通訳しました。)


皆さんこんにちは。今日、私は、どのように Electron が生まれ、有名になっていったかについて話したいと思います。

Kohei TAKATAさんにトークの内容を翻訳してもらったので、私は日本語でこのトークを行う(おこなう)ことができます。ありがとうございます。


はじめに、自己紹介をしたいと思います。私は3つの名前を持っています。中国では、 ちょうせい と呼ばれています。アメリカでは、 Cheng Zhao と呼ばれています。これは、英語表記の名前です。しかし、日本では私の名前は ジャオ チェン になります。これは英語名のカタカナ表記になります。このように、私は同じ意味の3つの名前を持っています。

私は Electron の作者(さくしゃ)です。今は GitHub で働いています。今も Electron の開発を続けています。


Electron について話す前に、 Atom editor について話す必要があります。 Electron は Atom のおかげで生まれました。そして、 Electron の初期(しょき)の技術的(ぎじゅつてき)な選択(せんたく)は、 だいたい Atom の ニーズ に沿った(そった)ものでした。


Atom editor のファーストエディションは5年前に作られました。 GitHub の CEO がおもな開発者です。それは Electron は使っていませんでした。単純(たんじゅん)な Cocoa のアプリケーションで、組み込み(くみこむ)の webview を使っていました。


Atom の開発者がもう少し増えたあと、 Atom のネィティブ層(そう)は Chromium Embedded Framework に変更されました。そして、 Atom はプラットフォームとして、 Chromium と V8 と WebKit を使うようになりました。 CEF によって、 Atom はすべてのプラットフォームに提供(ていきょう)できるようになりました。また、モダンな web のプラットフォームを提供したので、開発が簡単になりました。


そうしている間に Node.js は人気になっていき、 node-webkit も生まれました。


Atom について、カスタム した ネイティブ層(そう)を node-webkit に移行したいという気持ちが強まりました。そして、 Atom editor の開発者は実際に node-webkit を使うように Atom を修正しようとしました。

Atom はその時 すでに 大きなコードベースになっていました。そのため、移行作業(いこうさぎょう)は莫大(ばくだい)でした。 Atom はたくさんの カスタム した ネイティブ バインディング を使っていたので、彼らはそれらのコードを Node.js の API と node-webkit を代(か)わりに使うように修正する必要がありました。

しかし、その挑戦(ちょうせん)は失敗に終わりました。


失敗の原因はたくさんありました。 node-webkit はそのとき安定しておらず、重要な機能がかけている こと も 多かったです。失敗の原因の多くは node-webkit がとても幼(おさな)かったことによります。そして、誰もが良い web のプラットフォームはどうあるべきか ということ を知らなかったのです。

また、 Atom が巨大(きょだい)なコードベースであり、一度で全てのコードを移行(いこう)することはとても難しいタスクであったことも原因でした。


しかし、それは Atom が node-webkit を捨てたという意味ではありません。代わりの解決法(かいけつほう)は node-webkit を改善し続けるために、 node-webkit の開発者を雇う(やとう)というものでした。すなわち、私を雇(やと)ったということです。そしてその間、私は Atom が新しいプラットフォームに移行するための更に革新的(かくしんてき)な方法を使うのを助ける必要がありました。


そして、 Atom の新しい移行プランはこのようなものでした。私の最初のタスクは CEF に Node.js のサポートを入れていくことでした。 そのため、 Atom はだんだんとコードを Node.js を使うように移行していきました。

その後、 Atom の開発者は Node.js の API を使って Atom を開発し始めました。そして同時(どうじ)に、私は node-webkit が Atom にとって よりよいプラットフォームになるよう 改善を続けていきました。 node-webkit が十分成熟(せいじゅく)した後、 node-webkit を使うように Atom を変更することは単純にできるでしょう。そして、うまくいけば、この移行は簡単なものになるでしょう。


しかし、 node-webkit の改善をしている過程(かてい)で、私 はこのアプローチの いくつかの 問題に気づき始めました。まず、 node-webkit のアーキテクチャは複数(ふくすう)ウィンドウのアプリケーションには向いていませんでした。アプリケーションはたった1つの メイン ウィンドウ しか持たないように想定(そうてい)され、1つのアプリケーションで複数(ふくすう)のウィンドウをサポートするためには、アプリケーションのコードがすぐに汚(きたな)くなると思われました。この問題を解決(かいけつ)するためには、 node-webkit の全ての API を再設計(さいせけい)する必要がありました。

他の問題として、 node-webkit はいずれかの組織(そしき)ではなく個人(こじん)プロジェクトであり、その作者(さくしゃ)はプロジェクトが有名になったあとに、私がプロジェクトのリーダーシップを取ることを望(のぞ)みませんでした。全ての技術的(ぎじゅつてき)な決定(けってい)を作者と議論(ぎろん)する必要がありました。


そのため、当然(とうぜん)ながら私に残(のこ)された解決法(かいけつほう)は、新しいプロジェクトを始めて、 node-webkit を最初から書き直すことでした。


そして atom-shell が生まれ、私たちは node-webkit を私達の計画(けいかく)でそれに置き換えました。書き直しは長い時間がかかりましたが、 Atom にとってよいものになりました。


atom-shell と node-webkit には大きな違いが いくつか あります。 atom-shell は メイン プロセス で JavaScript が動く(うごく)ことを許可(きょか)しています。これはアプリケーションのライフタイム自身(じしん)を制御(せいぎょ)する必要があります。

さらに、 atom-shell は Chromium のビルドをオンラインのサーバに分離(ぶんり)しています。そのため、開発者は端末(たんまつ)で Chromium 一式(いっしき)をビルドする必要がありません。これは開発を簡単で速いものにし、遅い端末を使っている開発者でも atom-shell にコントリビュートできるようになります。

そして最後に、私は Node.js を Chromium に統合(とうごう)する方法を改善しました。そのため、 Node.js の統合(とうごう)によって起こされた全てのクラッシュを取り除く(とりのぞく)ことができました。


要約(ようやく)すると、 atom-shell はよりよい設計(せっけい)になり、コントリビューターにとっても優しいものになりました。


物事(ものごと)はそれから高速(こうそく)に安定して進(すす)みました。

atom-shell を1年間(いちねんかん)開発した後、それは Atom と ともに オープンソース化(か)されました。そして更に(さらに)1年後、 atom-shell を よりよい名前である Electron に改名(かいめい)しました。そしてこの年(とし)に、 Electron 1.0 をリリースしました。


Electron はユーザーを増やしていき、 GitHub のスター数も2年で37,000以上に増えました。今や、新しい Electron のアプリケーションは ほとんど 毎日のように公開(こうかい)され、 Electron を使って製品(せいひん)を作っている企業(きぎょう)もたくさんあります。


今、25の コミュニティ が メンテナ となっていて、約(やく)500人のコントリビューターがいます。最近のリリースでは、半分以上の変更が GitHub の外のコントリビューターから行(おこな)われました。


Electron のチームも最初私だけだった ところ から開発者が4人に増え、 Electron のチームに更に多くの人々を採用(さいよう)しようと しています。


最後に、 Electron が大きく成長していった過程(かてい)を共有(きょうゆう)したい と思います。これがあなたのプロジェクトの助けになれば幸い(さいわい)です。

Electron は個人(こじん)プロジェクト として 始まりました。そして、最初はたった1人 しか ユーザーがいませんでした。それは、 Atom editor です。しかし、 Electron が育(そだ)って、より多くのユーザーに適用(てきよう)されていくと、副次的(ふくじてき)に、多くのコントリビューターを得る(える)ことができました。そしてそのコントリビューターの中の何人(なにびと)かは、長期間(ちょうきかん)のメンテナになってくれるでしょう。


より多くのメンテナを得(え)たとき、そのプロジェクトは大きく成長し、更に多くのユーザーを得ます。これは 雪(ゆき)だるま が大きくなっていくのに似ています。そして、成長の鍵となるのは、より多くのコントリビューターを得続けることです。もし新しいコントリビューターが得られなかったら、そのプロジェクトは小さいままであるか、終わってしまうでしょう。


コントリビューターをキープし続けるために、2つの鍵となるポイントがあると思っています。

はじめに、 issue や pull request にすぐに反応(はんのう)することです。そうしないとコントリビューターになりうる人々は、彼らの仕事が無視(むし)されたに ひとしい と感じてさってしまうでしょう。私は Electron がこの点においては素晴らしいと誇(ほこ)っています。統計(とうけい)によると、 issue や pull request は良い レスポンス をあたえてくれることが多いです。

2つ目に、開発を簡単にする努力(どりょく)がされる べき であることです。それを達成(たっせい)する方法はたくさんあります。開発環境(かんきょう)を自動で整える(ととのえる)スクリプトを提供(ていきょう)したり、コントリビューターがそのプロジェクトをより知ることができるように よりよい コードレビュー をしたり、コントリビューターが理解(りかい)しやすいように リファクタリング をし続けたりすることができます。多くのコントリビューターはあなたのプロジェクトを深く(ふかく)理解している わけ ではありません。コードに対する(たいする)コントリビュートを簡単にすると、より多くの人々がコントリビューターになってくれるでしょう。

私は今の Electron があるのは 私達がこのことをうまく行(おこな)えた から だと 信じています。


以上です。ご清聴(せいちょう)ありがとうございました。