- 著者の Felix Rieseberg は、Electron 開発に10年以上関わってきた co-maintainer
- Electron は Web 技術で UI を実装し、必要であればネイティブコードを自由に組み合わせて使えるようにしてくれる
- 多くのアプリ（Visual Studio Code、Slack、Discord、Figma、ChatGPT、Claude、Notion、1Password、Docker Desktop など）が Electron を採用している
- この文書では Electron に関する主な誤解を取り上げ、なぜそのような選択をしたのかを説明している
Electron が JavaScript とネイティブコードを対立させる
- よく「Electron は JavaScript しか使わないので、ネイティブより劣る」と言われることがある
- 実際には Electron では JavaScript に加えて、C++、Objective-C、Rust などのネイティブコードも一緒に使える
- たとえば 1Password はコードの大半を Rust で書き、UI には Electron を活用している
- Electron の強みは、必要なだけネイティブコードを組み合わせつつ、UI 領域では Web 技術を活用できる柔軟性にある
- SwiftUI、GTK、Win32 などを活用して部分的にネイティブ UI を提供するデモ例も存在する
Web アプリは悪い
- 「すべてのネイティブアプリが常に優れている」という見方もあるが、市場の状況はそれほど単純ではない
- NASA の Mission Control、Bloomberg Terminal、McDonald’s のキオスク、SpaceX の Dragon 2 なども Chromium ベースの Web 技術を活用している
- Web 技術は世界でもっとも幅広く使われており、よく実装された Web アプリは優れたユーザー体験を提供する
- 「Web アプリは実力の足りない人が作るもの」という主張は、利用環境の要件や開発者の選択状況を考慮していない単純化にすぎない
OS の WebView のほうが高性能だ
- macOS や Windows、Linux に組み込まれた WebView のほうが優れていると主張する人もいる
- 実際に Slack は初期には MacGap（WebView ベース）を使っていたが、性能上の問題から最終的に Electron（Chromium）を採用した
- 最新の Chromium エンジンはリソースを多く必要とする一方で、もっとも活発に最適化が行われている部分でもある
- OS に組み込まれた WebView は共有リソースによって小さなメモリ使用量を示すこともあるが、セキュリティや安定性の問題から実際には分離されていることが多い
- Electron では最新のエンジンバージョンを直接管理でき、その結果として安定性とセキュリティを独立して維持できる
バンドルサイズは重要だ
- 一般に Electron アプリは 100〜300MB 規模であり、この点を批判する見方がある
- しかしユーザーはアプリ容量よりも、機能、使いやすさ、安定性などほかの要素をより優先する傾向が強い
- たとえば 4K 品質の Netflix ストリーミングは1時間で数 GB を消費し、Call of Duty のアップデートは数百 GB に達することもある
- 結局のところ、実際のユーザー満足度と比べれば、アプリのサイズは相対的にそれほど重要でない要素になることが多い
Electron に勝て
- Electron は「良いデスクトップアプリを作ろう」という目標を持つ人々のオープンソースの取り組みとして始まった
- Electron は競合が少ない状況で始まり、今でも十分な機能と安定性を提供してきた
- Electron に「勝つ」には、Electron がしていることをよりうまく実現できるプラットフォームを作らなければならない
- Electron のメンテナーたちは、より良い代替が登場するなら喜んでそれを歓迎するだろう
15件のコメント
Call of Dutyと比較するのは、どうも話の主題から外れているように見えます。
Electronを捨ててWebViewへ乗り換えたTeamsを見る必要があります。
https://techcommunity.microsoft.com/discussions/microsoftteams/…
Tauriが早く成熟してほしいです。私はすでによく使っていますが。
Atom Shellだった頃が昨日のことのようですが……かなり進化しましたね
さまざまな批判点はありますが、日々使っている vscode アプリの完成度を見ると、Electron の功績は決して小さくないという考えは確かにあります。
PCにインストールされているElectronアプリだけで10個近くあるので、この程度なら別途インストールされるフレームワークになってもいいのではと思います
バンドルサイズもそうだし、
~~ Helperプロセスがメモリを食っているのを見るとため息しか出ません。Tauriを代替案として考えてはいるのですが、配布時に正常に動作しないような特殊なケースがあるのではないかと心配です。（以前、win32環境で
msxml.dllなど基本登録されているdllを参照するプログラムを配布して本当に苦労した記憶があるので、内包して配布したのですが……似たような問題が起きないかと）Electron側の意見どおり、単純にサイズは忘れてしまうのが正しいのでしょうが、バンドルサイズが大きすぎるんですよね。
tauriはそこが問題な気がします..
プラットフォームごとにWebViewと内蔵プログラムがそれぞれ異なるので、それがいちばん大きな問題ではあります。デプロイした後に何が起きるかわからないので。
だからといってtauriにWebView自体を内蔵しようとすると、Electronよりバンドルサイズが大きくなりますし..
なので、プロダクション向けのクロスプラットフォームアプリ開発において、tauriはまだ成熟していないと思います。
McDonald’sのキオスクは……うーん……良い例かどうか
私も同じことをふと思いました。海外のマクドナルドのキオスクは、それでも少し違うのだろうか？と一瞬疑問に思いましたね（笑）
www 私もまったく同じことを考えました
メモリ使用量を減らすことが最大の課題になりそうですが、利害関係者の誰にもそれを実行するだけの動機がなさそうなのが残念ですね
本文で実際のデモコードへのリンクが貼られていたので確認してみたのですが、かなり単純に一緒に使えるというレベルで簡単、という印象ではないですね。ひとまず可能である、という点に意義を置くべきかと…
たいていアプリが大きいというのは事実みたいですね..
そうですね、バンドルサイズについては素直に認めていますね