00:09
こんにちは、OSSのレキシラジオです。
このポッドキャストでは、エンジニアであるhentekoが、毎週一つのOSSプロジェクトを取り上げて、
そのプロジェクトにまつわるレキシを紹介する番組になります。
今週のテーマは、Electronのレキシについてです。
それでは見ていきましょう。
Electronの概要
それではまずはElectronについてなんですけど、
Electronはですね、現在OpenJS Foundationという、
特定の企業に依存しないOSSプロジェクトの持続可能性と忠実性を確保するということを目的とした非営利団体、
OpenJS Foundationという団体が管理しています。
こちらは元々はですね、GitHubが開発していたATOMというエディターで利用されていたフレームワークなんですけど、
元々は、なのでATOMシェルというような別の名前でした。
このElectronは何ができるのかというと、
JavaScriptとかTypeScriptのようなウェブの技術でですね、
MacOSやLinux、Windowsのようなクロスプラットフォーム向けのデスクトップアプリというのを簡単に開発が可能というようなフレームワークになっています。
ちなみに開発の内部ではChromiumというGoogleが開発しているChromeのOSS版を利用しています。
現時点でですね、様々なデスクトップアプリで利用されています。
Electronについては。
例えば有名なところだとVS CodeやSlack Discordなどです。
さてここからは実際にElectronの歴史について触れていけたらなと思うんですが、
Electronの歴史
まずはElectronが開発される前のお話ですね。
2000年代後半のところです。
2008年ぐらいの時代ですかね。
その頃にデスクトップアプリを開発しようとするとなかなか難しかったというような技術的な背景があります。
特にクロスプラットフォームのデスクトップアプリを開発しようとすると結構厳しいというものがありました。
具体的にクロスプラットフォームでデスクトップアプリが開発されているフレームワークというものは
実際にあったんですけど、JavaのSwingだったり、AdobeのAirだったりと存在していたんですけど、
そういったものを使用してもネイティブアプリ特有の操作感というのを再現するということはなかなか難しかったというのがあります。
さらにデスクトップアプリという文脈からは少しだけ違うんですけど、
2008年にGoogleがV8エンジンというのをリリースしました。
このV8エンジンというのが何かというと、JavaScriptの実行環境をサポートするようなツールなんですけど、
これによってJavaScriptの実行速度というのが景気的に速くなったという技術的な背景があります。
そのV8エンジンを使うような形で2009年にNode.jsというものが登場します。
このNode.jsを使うことでJavaScriptコードでファイルシステムにアクセスしてサーバーを起動してOSのプロセスを管理するみたいなことが可能になったりしました。
こういったツールのいろいろな様々なツールが登場したことがきっかけで、2011年にはNode WebKitというものが開発されます。
こちらのNode WebKitというものは、内部的にはElectronと一緒のアーキテクチャを持っていまして、
すごくざっくり言うとChromiumとNode.jsを組み合わせてデスクトップアプリが作れますよというようなフレームワークになっています。
ここだけ聞くとElectronとほぼほぼ一緒かなという形です。
ただ少しだけ違う点がありまして、Node WebKitの方ではHTMLファイルがリポイントとなるんですけど、
HTMLファイル内のスクリプトタグにNodeのモジュールなどを書くことによってデスクトップアプリというファイルシステムにアクセスしたりだったりとか、
そういったところができるような形になっていました。
これでですね、WebページがそのままデスクトップアプリになるというのがNode WebKitで実現できたんですけど、
問題点としてChromiumとNode.jsのコンテキストがバッティングしてしまうだったりとか、
あとはChromiumの内部にですね、パッチを当てているというような実際になっていたので、
Chromiumのリリースになかなか通知ができないというような問題もあったりしました。
そういった技術的な背景がありつつ、Atom Shell、後のElectronというものが開発されるんですけど、
ここでですね、2013年にGitHubのほうからWeb技術を用いて完全にカスタマイズ可能なテキスタエディターというのがGitHubの社内で開発のほうが開始されました。
これがAtomというエディターです。
このAtomというエディターなんですけど、開発の背景として既存の軽量なテキスタエディター、
その当時ですとサブライムテキスタやビームなどがあるんですけど、
こういった軽量なテキスタエディターは拡張性はあるにはあるんですけど、拡張機能の開発にですね、PythonやLispを利用しないといけないというものがありました。
PythonやLispを利用しないと拡張機能が開発できないというのは、なかなかWeb開発者にとってはハードルが高いというものがありまして、
そこでGitHubはGitHub自身の開発者の方々はWeb技術を使っているので、
そういった技術を使いながらテキスタエディターも作って拡張機能もWebの技術で作れれば、
自分たち自身で道具の改良ができると考えて、Atomというのを開発開始がされました。
技術的な障壁と進化
このAtomを動作させるランタイムとして開発されたのがAtom Shellであり、後のElectronになります。
このAtom Shellなんですけど、開発にあたってノードウェブキットというものは既に存在していたので、
そちらを使うという手もあったかなとは思うんですが、そちらは採用されなかったそうです。
ゼロから独自の設計をすることになって、そこで自主したのがメリーンプロセスとレンダラープロセスの明確な分離です。
このメインプロセスというのはノードJS環境として動作するんですけど、
アプリのエントリーポイント、ウィンドウの作成やライフサイクル、あとはメニューバーなどのネイティブUIとの連携など、
そういったところを制御するというようなものになっています。
さらにレンダラープロセスはChromiumのブラウザインスタンスとして動作するという形です。
HTMLやCSSなどのレンダリングを担当するというような形になっています。
このプロセスの明確な分離というのは、実はChromium自体も似たようなことをしてまして、
マルチプロセスアーキテクチャとして実装をChromiumの方がしています。
ブラウザのプロセスとレンダラープロセスというのがChromiumの方も実際に設計としては分かれているというような感じです。
そういったところが自然に適合して、Atom Shellとしてうまく動くというような形になっていたそうです。
このAtom Shellの明確なメインプロセスとレンダラープロセスの分離というような設計によってですね、
メリットとして一つのウィンドウがたとえクラッシュしたとしても、メインプロセスには影響せずにアプリ全体がクラッシュしなくなるというような形になっていました。
また、ノードウェブキットと違ってですね、エントリーポイントをHTMLではなくてNode.jsにしたことによって、
ウィンドウを持たないようなバックグラウンドの重い処理だったりとか、
そういったところを処理を構築しやすくなった、開発しやすくなったというようなメリットもあったりします。
こういった形でAtom Shellが開発されてきたんですけど、実際に2014年の4月にですね、
Atom Editorとしてパブリックベータとして公開されました。
それと同時にAtom Shellの方もオープンソースとして公開されたというような開発の経緯になっています。
そういった形でAtom Shellは開発されてリリースされたんですけど、
ここでAtom Shellの開発においてですね、最大の技術的な障壁というものが実はありました。
それがですね、Chromiumの巨大なコードベースのビルドでした。
Atom Shell自体はChromiumに依存しているので、Chromium自体のビルドというのも必要だったんですけど、
このChromiumの完全なビルドというのがですね、当時の高性能なサーバーでも、
数時間と数十ギガバイトのソースコードのダウンロードというのが必要でした。
ただこのままではですね、一般の開発者の方々がAtom Shellのコア開発に貢献するということができなくなって、
しまうというような問題点がありました。
そこで開発されたのがLibChromiumContentというコンポーネント管理手法です。
仕込みとしてはすごいざっくり言うと、Chromiumのコンテントモジュール部分というものがあるんですけど、
これがレンダリングエンジンのコア部分に当たるんですけど、
その部分のみ抽出して共有ライブラリとして事前にビルドしておくというような手法です。
これによってですね、Atom Shellはビルドするときに事前にビルドされたライブラリをリンクするだけで、
開発者はChromium全体をコンパイルする必要性がなくなったというのがあります。
これによってAtom Shell自体のビルド時間が短縮されることによって、
Atom Shellをオープンソースとして公開したときに、
Electronの誕生と発展
外部のコントリビューターが開発に参加するというようなハードルが大幅に下がったというメリットがありました。
そういった形でAtom Shellというのは開発されてきたんですけど、
2015年にですね、実はAtom Shellのリリースから1年程度経ったときにですね、
Atomとは関係がないようなスラックなどの企業がですね、
Atom Shellを使ってデスクトップアプリでの開発を開始し始めました。
もともとAtomのために開発されたものだったので、Atom Shellというような名前だったんですけど、
こういった形でサードパーティーの会社がAtom Shellを使ってデスクトップアプリを開発するというような流れが出てきたので、
実体に名前が伴わなくなってきたというのがあります。
そこで名前を変えるんですけど、Atomから独立してElectronというような名前に変更されました。
実際に2015年の4月にAtom ShellからElectronという名前に変わりました。
このElectronの名前の由来に関しては、物理学において電子Electronというんですけど、
Electronが原子であるAtomを構成する要素であることからElectronを命名するという形になりました。
名前は変わっても、Atomエディターを構成する基盤であるというようなことは意味が込められてElectronという名前になったそうです。
このリブランディングがElectronがAtomの部品からクロスプラットフォームなデスクトップアプリケーションのフレームワークへ変わるような大きな転換点でした。
さらに同年の2015年にMicrosoftがVS Codeというものを発表するんですけど、
そのVS CodeにElectronが採用されるというものがありました。
これがElectronの地位、現在の地位を確立する大きな転換点になりました。
市場というか様々な開発者の方が、あのMicrosoftが本気で採用した技術としてElectronというのが商用利用に耐えるような品質であるというような評価がされました、その時点で。
さらに1年経過して2016年の5月にはElectronはVersion 1.0として正式リリースされまして、
様々な会社、SlackやDiscordなどがデスクトップアプリをすべてElectronベースに統一するというような流れになりました。
技術的な挑戦と改善
この流れで2016年当時はElectronはデスクトップアプリを開発するときのデファクトスタンダードになったんじゃないかなと思います。
同時にデスクトップアプリを使うユーザーとしては、このアプリはElectronを内部で使っているからメモリが大量に消費するだったりとか、
そういったリソースを食い尽くすみたいなダメージにもなりつつありました。
そういった形でElectronというのはVersion 1.0としてリリースされて、デスクトップアプリの開発のデファクトスタンダードになってきたんですけど、
さっきも言った通りリソースを消費してしまうというような問題点もありました。
なのでElectronは技術的な挑戦としてパフォーマンスとメモリの最適化というものを進めてきました。
ネイティブアプリと比較してしまうと、Electron製のアプリというのはリソースを多く消費してしまうような傾向になりました。
その理由として、各レンダラープロセスが独立したメモリ空間を持つためです。
ウィンドウを開くたびにChromiumが複製されてメモリの消費が増えるというものがあります。
さらに各プロセスにNode.jsのランタイムがロードされてしまうので、さらにメモリの消費が増えるという形になります。
さらにさらにElectron製のアプリがどんどん増えていくことによって、
それらのアプリが同時に起動することで、実質的に複数のChromiumブラウザとNode.jsのインスタンスが同時に動作するというような形になってしまって、
相乗効果でメモリが消費されていくというような形になってしまっていました。
これらの対策として、開発チームとしてはV8エンジンの改良というものをしてきました。
どういったことをしたかというと、V8ポインターコンプレッションというものを実施して、
最大メモリ使用量を40%ほど削減するということを実現しました。
さらに独自のアーキテクチャパターンというものを提唱してきまして、
アプリ側で隠しウィンドウを1つ作成して、そちらで思い処理というのを集約するというような形で、
プロセスの数自体を減らしてしまうというようなアーキテクチャパターンを推奨して、
そういった形でメモリの消費をできる限り抑えていくというようなものを実施していました。
そういった形でパフォーマンス面、メモリの最適化のところはどんどん改善していったというような
技術的な挑戦がありました。
さらに問題点として、先ほども紹介したリブクロミウムコンテントというビルドシステムというところがあったんですけど、
メリットはもちろんあったんですが、そちらが限界を迎えてきたというものがあります。
エレクトロのバージョンアップが進むにつれて、独自のビルドシステムであるリブクロミウムコンテントの
メンテナンスコストというのがどんどん増加してきたというのがあります。
また、向かい風として、クロミウムのビルドシステム自体がGYPというビルドツールからGNというビルドツールに移行したというものがあります。
これによって、エレクトロもクロミウム標準のGNベースのビルドシステムに移行を強制させられるというものが発生しました。
こういった背景がある中で、2018年のエレクトロン4.0以降はリブクロミウムコンテントというものは全て廃止されて、
クロミウムのソースツリーの一部として統合的にビルドされる方式に変更がされました。
これによってビルドプロセスというのは複雑化したんですけど、クロミウムの最新機能だったりパッチの適用というのがしやすくなりました。
そういった形でエレクトロの開発というのはどんどん進んでいったんですけど、2018年に大きな転換点を迎えます。
マイクロソフトがGitHubを買収するというようなニュースです。
エレクトロンはGitHub生まれ、GitHubの開発チームの中で開発されているプロジェクトだったんですけど、
エレクトロの最大の利用者がVSコードであって、VSコード自体はマイクロソフトが開発しているものだったので、
GitHubがマイクロソフトに買収されるというようなことは、実質的にエレクトロンがマイクロソフトという一企業の管理下に置かれることになってしまいます。
これは何がいけないかというか、やばいかというと、スラックやディスコードといった競合を他社が利用するような基盤技術として、
もうすでにエレクトロンというのは存在していたので、これによって中立性が懸念されました。
中立性の確保と現在の状況
そういった背景があるので、2019年の12月には、ネオドJSやJQueryなどをホストする中立的な非営利団体であるオープンJSファンデーションに移行するということが発表されました。
これによって、特定の企業の持ち物ではなくて、パブリックな共有財産として地位を確立するためというような形で移行が実施されたんですけど、
2020年に正式に認定されて、エレクトロンの商標や知的財産というのをすべてオープンJSファンデーションに移管されることになりました。
これによって、複数企業が対等の立場で開発に貢献できるような持続可能な体制になったということが挙げられました。
こういったことで、マイクロソフトやGitHubを買収したとしても、エレクトロンというのは中立的な立場を持った開発というのが続けられるというような体制になって、
現在でも開発というのが非常に活発にされているというような形になっています。
ここまでエレクトロンの歴史について触れてきたんですけど、最後にまとめたいと思います。
エレクトロンの登場前は、クロスプラットフォームなデスクトップアプリというのを開発するのがなかなか難しい状況でした。
そういった背景がある中で、GitHubの方でエレクトロンというのが開発されたんですけど、
元々はAtomというテキストエディザインのために開発されたツールでした。
その後、Atomからリクエストし、エレクトロンという名前に正式に変わって、多数のプロジェクトで利用されるまでに成長するようなツールになりました。
エレクトロンの歴史については以上となります。
少しでも今回の話がいいねと思ったら、お聞きのプラットフォームでの高評価やフォローの方をお願いします。
また、XなどでハッシュタグOSSの歴史ラジオで感想などをつぶやいてもらえると励みになります。
次回はWeb開発者であれば絶対にお世話になっているであろうDockerの歴史について見ていきたいなと思っております。
それでは次回もよろしくお願いします。バイバイ。
