Hacker NewsやRedditを長く見ていれば、いずれ同じ批判を目にするでしょう。Electronは肥大化している、メモリを使いすぎる、本格的なデスクトップアプリケーションはネイティブであるべきだ、というものです。
その批判には一理あります。ElectronアプリケーションはChromiumとNode.jsを同梱するため、通常、基本的なリソース使用量が大きくなります。入念に設計されたネイティブアプリケーションなら、メモリ使用量を抑え、起動を速くし、オペレーティングシステムとより深く統合できます。
しかし、この議論はコンピューターに注目しすぎていて、ソフトウェアを作る企業には十分な目を向けていません。
ほとんどのユーザーにとって、アプリケーションの背後にある技術はほぼ重要ではありません。気にするのは、きちんと動くか、操作に対する反応がよいか、バグが修正されるか、便利な機能が追加され続けるかです。したがって、ソフトウェア企業にとって技術スタックの最も重要な特性の一つは、ベンチマーク表にはめったに登場しないものです。チームはどれだけ速く製品を作り、リリースし、学び、改善できるのか？
現代の多くのデスクトップアプリケーションにおいて、Electronはこの点で非常に優れています。
希少なリソースはエンジニアの時間
理想的なデスクトップアプリ開発企業には、優秀なmacOSチーム、Windowsアプリケーションを開発する別のチーム、そしておそらくLinuxをサポートするさらに別のチームがいます。各アプリケーションはそのプラットフォーム向けに入念に最適化され、すべてのエンジニアが担当するオペレーティングシステムを深く理解しています。
ほとんどの企業に、そんな余裕はありません。
デスクトップ製品を担当するエンジニアは5人かもしれません。2人かもしれません。その同じエンジニアたちが、機能開発、バグ修正、パフォーマンス改善、顧客対応、インフラの保守、OSの変更への対応を行い、製品を前進させ続けなければなりません。
ネイティブ開発では、これがより難しくなります。macOS、Windows、Linuxは、本当に異なるプラットフォームだからです。UIフレームワーク、API、権限システム、ライフサイクルの挙動、インストーラー、更新の仕組み、通知システム、ウィンドウ管理、アクセシビリティAPIが異なり、長年にわたって積み重なったプラットフォーム固有の癖もあります。
Electronは、この構図を変えます。Chromium、Node.js、デスクトップAPIを組み合わせ、macOS、Windows、Linuxに共通のアプリケーションモデルを提供します。同じTypeScriptエンジニアが、インターフェースからアプリケーションロジックまで一つの機能を実装し、すべてのデスクトッププラットフォームでリリースできることも珍しくありません。本当に必要な場合にはネイティブコードも利用できますが、それは製品の基盤ではなく、例外になります。Electron自身も、主要な3つのデスクトッププラットフォームすべてで一つのJavaScriptコードベースを使えることを、中心的な利点の一つとして挙げています。
この違いは、年月とともに積み重なります。重要な機能を作るたびにMac版とWindows版を別々に実装しなければならないなら、企業はその「プラットフォーム税」を繰り返し支払うことになります。機能追加、再設計、実験、バグ修正、アクセシビリティ改善、パフォーマンス最適化のたびにです。
Electronなら、その作業の多くは一度で済みます。
Electronは改善サイクルの速さを重視する
最初の実装が完璧だったから製品が優れたものになる、ということはめったにありません。製品は、改善を重ねることで優れたものになります。
チームが何かをリリースする。顧客が使う。チームが学ぶ。機能を変更する。さらに多くの人が使う。別の問題が見えてくる。チームがまた改善する。
アイデア、実装、フィードバック、改善をつなぐサイクルが短いほど、製品は速く良くなります。
Electronは、このサイクルを短くする点で際立っています。ソフトウェア企業がすでにあらゆるところで使っている技術、つまりJavaScript、TypeScript、HTML、CSS、React、Chromium、Node.js、npmを中心に構築されているからです。
そのため、企業はソースコード以外にも、はるかに多くのものを共有できます。エンジニア、UIコンポーネント、開発ツール、ライブラリ、インフラ、テスト手法、組織に蓄積された知識を、Web製品とデスクトップ製品の間で共有できるのです。
Windowsクライアントの開発に助けが必要になったからといって、フロントエンドエンジニアが突然役に立たなくなるわけではありません。デスクトップエンジニアもWebアプリケーションに貢献できます。フルスタックのTypeScriptエンジニアは、優先順位の変化に応じて製品間を移動できます。
小規模や中規模の企業にとって、その柔軟性はRAMを100 MB節約することよりも、はるかに大きな価値を持ち得ます。
実際に誰がElectronを使っているかを見てみる
Electronは、「ちゃんとした」デスクトップアプリケーションへの投資を惜しむ企業のための近道だと表現されることがあります。しかし、Electronで作られた製品を見ると、その主張を維持することはますます難しくなっています。
Electronプロジェクト自身が、Slack、Discord、Signal、ChatGPT、Claude、Visual Studio Code、Notion、Docker、Loom、Canvaといった製品を紹介しています。これらは単純なユーティリティではありません。その多くは、世界でも特に高度で広く使われている生産性向上アプリケーションです。
Visual Studio Codeは、特に参考になる例です。Microsoftは、自社の主力コードエディターを、望むならほぼどんなWindows技術でも使って構築できるはずです。それでもVS Codeは、Windows、macOS、LinuxでElectronを使用しています。ターミナル、デバッグ、言語サーバー、Git統合、リモート開発、ノートブック、拡張機能、高度にカスタマイズされたエディターを備えています。
興味深い問いは、Microsoftが3つの独立したネイティブ版を作ればメモリを節約できるかどうかではありません。当然、できるでしょう。
より重要なのは、主要な機能ごとに複数の独立した実装が必要だったとしたら、VS Codeはこれほど速く進化し、プラットフォーム間で一貫性を保ち、これほど大きなエコシステムを育てられただろうか、という問いです。
ChatGPTとClaudeに見るアプローチの違い
ChatGPTとClaudeの対比も示唆に富んでいます。
OpenAIは当初、ChatGPT専用のネイティブmacOSアプリケーションを開発しました。対照的にAnthropicは、Claude DesktopをElectronで構築し、最初からプラットフォーム間で共通のデスクトップ基盤を持っていました。
製品が拡張されるにつれて、この違いはより重要になりました。Claude Desktopは、MCP連携、拡張機能、Claude Codeなどの機能を、同じクロスプラットフォームアプリケーションに追加し続けることができました。現在Anthropicは、複数のローカルセッションやリモートセッションも含め、デスクトップ環境内でClaude Codeを直接利用できるようにしています。
その後OpenAIも、新たなクロスプラットフォームのデスクトップ展開をElectronへと移し、現在Electronは、ChatGPTとClaudeの両方を主要なElectronアプリケーションとして掲載しています。
製品開発の速度の違いをElectronだけで説明できる、と断言するのは言いすぎでしょう。チームの規模、優先順位、製品戦略、社内組織もすべて影響します。しかし、アーキテクチャ上の利点は明快です。共通のクロスプラットフォーム基盤があれば、別々の実装を保守することなく、複数のOSに機能を届けやすくなります。
これはまさに、デスクトップ製品が成長するほど価値が高まる種類の利点です。
Evernoteが学んだ、個別のクライアントを保守するコスト
Evernoteは、この問題を示す歴史的な事例の中でも、特にわかりやすいものの一つです。
長年にわたり、EvernoteはMac、Windows、モバイル、Webで異なるアプリケーションを保守していました。時間がたつにつれ、それらの製品には挙動の違い、表示の違い、過去の設計上の前提、同期の問題が蓄積していきました。
2020年、EvernoteはWindows版とMac版のアプリケーションを共通のコードベースに基づいて作り直しました。同社は、新しい基盤によってアプリの安定性が高まり、バグをより速く修正でき、機能をより頻繁にリリースでき、プラットフォーム間の同期も改善できると説明しました。
その移行は順調なことばかりではなく、当初プラットフォーム固有の機能が失われたことを嫌う長年のユーザーもいました。しかし、移行に伴う問題そのものより興味深いのは、Evernoteがなぜ、これほど費用のかかる全面的な書き直しに踏み切ったのかという点です。
製品が高機能なエディター、オフラインストレージ、検索、添付ファイル、共同作業、タスク、カレンダー、複雑な同期を備えるようになると、複数の独立した実装を保守するコストはますます大きくなります。バグの現れ方が異なります。表示も異なります。同期ロジックは、異なるローカルアーキテクチャと相互に作用します。重要な製品変更を行うたびに、複数のクライアントへ反映しなければなりません。
共通のアーキテクチャにしても、難しい問題が消えるわけではありません。しかし、より多くの問題を一度の対応で解決できるようになります。
Linux対応は、Electronの最も過小評価されている利点かもしれない
Linuxを考慮すると、Electronを選ぶ理由はさらに強くなります。
Linuxを適切にサポートするのは困難です。macOSやWindowsとは違い、「Linuxデスクトップ」は厳密に管理された単一のプラットフォームではありません。開発者は、さまざまなディストリビューション、パッケージ形式、デスクトップ環境、グラフィックススタック、システムライブラリ、ディスプレイプロトコルに対応しなければなりません。
多くのソフトウェア企業にとって、合理的な経営判断は、単にLinuxをサポートしないことになるでしょう。
Electronは、その採算を変えます。
ElectronはmacOS、Windows、Linuxに共通のランタイムを提供するため、Linux対応の追加は、独立したネイティブLinux実装を保守するよりも大幅に容易になり得ます。現在のLinuxユーザーが、かつてなら公式Linuxクライアントが提供されなかったかもしれない多くの主要なデスクトップアプリケーションを使えるのは、これが一つの理由です。
Visual Studio Code、Slack、Discord、Signal、1Password、Postman、Obsidianをはじめとする多くのツールは、完全に別個のGTKやQtのアプリケーションを保守せずにLinuxをサポートできます。
Electronはまた、アプリケーション開発者に代わって、Linux固有の複雑さの多くを引き受けています。よい例が、X11からWaylandへの移行です。Electronのメンテナーは、ChromiumのWayland移行によってElectronアプリケーションも実質的に一緒に移行でき、各アプリケーションチームが独自に行う必要のあるディスプレイスタック関連の作業が減ったことを説明しています。
Electronのようなフレームワークがなければ、多くの企業はネイティブLinuxクライアントを作らないでしょう。macOSとWindowsだけをサポートし、Linuxユーザーにはブラウザーのタブで使ってもらうだけになるはずです。
Electronは、おそらく世間で評価されている以上に、商用Linuxデスクトップソフトウェアに貢献してきました。
Microsoftでさえ、Web技術を選ぶことが増えている
本格的なWindowsソフトウェアは常にWindowsのネイティブUIフレームワークを使うべきだ、という考えに対する最も強力な反例は、Microsoftかもしれません。
MicrosoftはWindowsを管理しています。Win32、.NET、WinUI、WebView2、そして開発者が利用するプラットフォームの多くも管理しています。完全なネイティブWindows開発が常に明白な正解なら、Microsoftほど、それをあらゆる場所で採用しやすい立場にある企業はないでしょう。
しかし、そうしてはいません。
Visual Studio CodeはElectronを使っています。Teamsは、MicrosoftがElectronをより最適化されたWebView2ホストに置き換えた後も、React、TypeScript、Chromiumを中心に構築されています。新しいOutlook for WindowsもWeb技術に大きく依存しており、Microsoftはそのアーキテクチャについて、俊敏性を高め、機能をより速く提供し、より一貫した体験を実現するための手段だと明確に説明しています。
Teamsは特に示唆に富む事例です。Microsoftは、パフォーマンスを改善し、リソース消費を減らすために、アーキテクチャを変更しました。しかし、UIを従来型のWindowsネイティブアプリケーションとして書き直したわけではありません。
Web技術のスタックを維持し、それを中心に最適化したのです。
この違いは重要です。Microsoftは、パフォーマンスを積極的に改善しつつも、React、TypeScript、Chromiumが組織にもたらす利点は維持する価値があると判断しました。
ここには、もう一つの教訓もあります。Microsoft自身が長年にわたり、Win32、WPF、UWP、WinUIなど、何世代ものWindowsアプリケーション技術を導入してきました。「ネイティブWindows」を選ぶ企業が、必ずしも時代に左右されないプラットフォームを選んでいるわけではありません。多くの場合、Microsoftが推奨するフレームワークのある世代に賭けているのです。
いささか皮肉なことに、Webプラットフォームは、利用可能なアプリケーションの実行基盤の中でも、比較的安定したものの一つになっています。
採用もアーキテクチャの一部
フレームワークの選択は、どのような人材を採用できるかも左右します。
JavaScriptとTypeScriptの開発者は、業界でも最大級のエンジニア人材層を形成しています。Electronで開発する企業は、経験豊富なmacOS、Windows、Linuxの専門家をそれぞれ別のチームとして揃えるのではなく、その人材層から採用できます。
ネイティブ開発の専門家は依然として貴重です。本格的なデスクトップ製品には、OSを深く理解するエンジニアが引き続き必要です。しかし、Electronは、必要な専門家の人数を変えます。
アプリケーションの大部分をプラットフォームの専門家に作ってもらう必要はなく、ネイティブ連携コードを比較的少量にとどめ、チームの大半が共通の製品部分に取り組めるようにできます。
これは、企業がすでにWebアプリケーションを持っている場合に、さらに重要になります。Reactコンポーネントを共有できることもあります。TypeScriptライブラリは再利用できます。製品のロジックをWebとデスクトップの間で移せます。エンジニアは、まったく異なるエコシステムを学ばずにチームを移れます。
採用面での脆弱性も下がります。ネイティブWindowsクライアントを深く理解している唯一のエンジニアが退職した場合、その専門知識を補うのは困難かもしれません。Electronなら、コードベースのより多くの部分が、組織のほかのメンバーにもなじみのある技術で書かれています。
つまり、フレームワークはインターフェースをどう描画するかを決めるだけではありません。エンジニアリング組織そのものをどう構成できるかにも影響します。
ネイティブだからといって、自動的に優れたソフトウェアになるわけではない
開発者はしばしば、「ネイティブ」をほとんど「高速」の同義語のように使います。
しかし、同じではありません。
ネイティブAPIは、非常に効率的なアプリケーションを作る機会を開発者に与えます。最終的な製品が実際にそれを達成するかどうかは、アーキテクチャ、チーム、予算、そして企業がどれだけ最適化作業に時間と費用をかけられるかによって決まります。
ネイティブアプリケーションでも、遅い、バグが多い、メモリを大量に使う、一貫性がない、十分に保守されていない、といったことは起こり得ます。
さらに重要なのは、限られたチームを複数のネイティブ実装に分散させると、各実装に割り当てられる開発時間が減るということです。
ある企業が、デスクトップ製品に6人のエンジニアを充てられるとしましょう。一つの選択肢は、MacとWindowsに分け、おそらくLinuxはサポートしないことです。もう一つは、ほぼ6人全員を、3つのプラットフォームすべてに対応する一つの共通Electronアプリケーションに配置することです。
起動時間を改善し、メモリリークを修正し、操作感を磨き、アクセシビリティを改善し、クラッシュを減らし、ユーザーに対応するための開発力を、より多く確保できるのはどちらでしょうか？
ネイティブアプリケーションのほうが優れた製品になるとは、必ずしも言えません。
ここに興味深い逆説が生まれます。マシンのリソースを多少多く消費するフレームワークでも、開発リソースの消費を大幅に抑えられるため、企業はかえって、よりよく最適化された製品を作れる可能性があります。
Electronは、管理可能なプラットフォームを提供する
Electronには、見過ごされがちなもう一つの利点もあります。アプリケーションの開発とテストで使用したChromiumランタイムを、そのまま同梱して配布することです。
これにより、クロスプラットフォーム開発の大きな変動要因が一つなくなります。
OSのWebViewを利用するフレームワークなら、アプリケーションを小さくできます。しかし、その代わりに、同じフロントエンドがWindowsではWebView2、macOSではWKWebView、LinuxではWebKitGTK上で動くことになります。これらのエンジンは、機能、バグ、リリーススケジュール、描画の挙動が異なります。
Electronは、別のトレードオフを選びます。ランタイムを同梱し、アプリケーションの一部にするのです。
確かに、それにはディスク容量が必要です。
しかし、開発者は、まったく異なる3つのOSにまたがって、はるかに一貫した開発対象を得られます。
一貫性には、エンジニアリング上の非常に大きな価値があります。
Electronだけでは足りないときも、ネイティブを使える
Electronを選ぶことは、ネイティブ機能へのアクセスを諦めることではありません。
Electronアプリケーションは、必要に応じてネイティブモジュールやプラットフォーム固有のコードを利用できます。つまり、アーキテクチャ上の選択肢は、実際には次の二択ではありません。
100%ネイティブか、100%JavaScriptか。
多くの製品にとって、よりよいモデルは次のようなものです。
アプリケーションの大部分を共通化し、OSが本当に必要とする部分だけに少量のネイティブコードを使う。
ネイティブコードは、製品全体の基盤ではなく、必要なときに使う逃げ道になります。
多くの企業にとって、それは開発労力のはるかに適切な配分です。
ユーザーが気にするのは製品であって、フレームワークではない
技術に詳しいユーザーの中には、アクティビティモニタを開き、複数のChromiumプロセスに気づくと、アプリケーションがElectronを使っていることに即座に不満を言う人が少数います。
ほとんどのユーザーは、そうではありません。
SlackがElectronを使っていても気にしません。VS CodeがWeb技術で作られていても気にしません。Claudeがどのフレームワークを使っているかも知りません。気にするのは、そのソフトウェアが仕事を進めるのに役立つかどうかです。
アプリケーションが十分に速く起動し、反応がよく、めったにクラッシュせず、ユーザーの問題を解決するなら、その実装技術はほとんど意識されません。
逆も同じです。ネイティブアプリケーションは、SwiftやWinUIを使っているというだけで、自動的に優れた製品になるわけではありません。
ソフトウェアが競争するのは、フレームワークのレベルではなく、製品のレベルです。
バイナリだけでなく、企業を最適化する
Electronには確かなコストがあります。より多くのディスク容量を使います。基本的なメモリ使用量は、通常、小さなネイティブアプリケーションよりも多くなります。そのコストゆえにElectronが不適切な選択になる製品は、間違いなく存在します。
小さなメニューバーユーティリティに、おそらくChromiumは必要ありません。デバイスドライバーには、確実に不要です。ゲーム、プロ向けオーディオソフトウェア、遅延に極めて敏感なアプリケーションには、それぞれ異なる要件があります。また、製品が将来にわたって一つのOSでしか動かないのであれば、ネイティブ開発を選ぶ理由はずっと明確になります。
しかし、現代のデスクトップソフトウェアの非常に大きな割合は、そうした分類には当てはまりません。
それらは、クラウドサービスにつながる複雑なインターフェースで構成されています。WindowsとmacOSで動作する必要があり、Linux対応を期待するユーザーも増えています。継続的に進化する必要があります。毎週変更をリリースする製品と競争しています。そして通常、限られた人数のエンジニアしかいない企業によって作られています。
そうした製品にとって、開発者の生産性はアプリケーションのパフォーマンスの一部です。
Electronを使えば、企業ははるかに大きな人材層から採用でき、Webとデスクトップの間でエンジニアを共有でき、複数ではなく一つの主要アプリケーションを保守でき、JavaScriptのエコシステムを再利用でき、複数のOSへより一貫して機能を届けられます。また、それ以外の方法では採算が合いにくいことも多いLinux対応を実現し、並行する実装の保守ではなく、製品の改善により多くの開発時間を使えます。
Electronのコストは、メガバイト単位で簡単に測れます。
別の方法を選んだ場合のコストは、もっと見えにくいものです。追加のエンジニア、重複した実装、長いリリースサイクル、プラットフォーム固有のバグ、採用の難しさ、組織の縦割り、サポートされないLinuxユーザー、そしてすべての人に届くまでに何か月も余計にかかる機能として現れます。
それらのコストは、アクティビティモニタには表示されません。
しかし、ソフトウェアを作る企業にとっては、そちらのほうがはるかに大きいかもしれません。
ソフトウェア開発の目標は、最小のバイナリを作ることではありません。
自分たちの組織がリリースし、保守し、継続的に改善できる、最高の製品を作ることです。
驚くほど幅広い種類のデスクトップアプリケーションにとって、Electronは今もなお、それを実現する最も効率的な方法の一つです。