ElectronとChromium Embedded Framework（CEF）は、デスクトップアプリケーションにChromiumを導入するための、実績ある2つの技術です。どちらも、macOS、Windows、Linuxで最新のウェブサイトやウェブインターフェースを表示するソフトウェアを開発できます。ただし、その目的は根本的に異なります。
Electronは、Chromium、Node.js、OSのネイティブAPIを組み合わせた、包括的なデスクトップアプリケーションフレームワークです。開発者は、ネイティブ開発の豊富な経験がなくても、JavaScript、TypeScript、HTML、CSSを使ってアプリケーション全体を構築できます。一方、CEFは、通常はC++などのネイティブ言語で記述された既存または新規のアプリケーションに、Chromiumを埋め込むためのフレームワークです。
どちらの技術も、実際の製品で広く使われています。ElectronはVisual Studio Code、Slack、Discord、Notionなどのアプリケーションを支えており、CEFはSpotify、Steam、OBS Studioなどの製品で使われています。WebCatalogでは、クロスプラットフォームのデスクトップアプリケーションを構築するためにElectronを採用しています。
では、両者にはどのような違いがあり、どのような場合にどちらを使うのが適切なのでしょうか。
ElectronとCEFの比較早見表
ElectronとCEFはどちらもChromiumを使用していますが、アーキテクチャ、開発体験、想定用途は大きく異なります。
| 項目 | Electron | Chromium Embedded Framework（CEF） |
|---|---|---|
| 初登場 | 2013年 | 2008年 |
| 主な目的 | デスクトップアプリ全体の構築 | 他のアプリケーションへのChromiumの埋め込み |
| ブラウザーエンジン | Chromium | Chromium |
| 主な言語 | JavaScript、TypeScript | C、C++。サードパーティ製バインディングも利用可能 |
| Node.jsの同梱 | あり | なし |
| ネイティブ連携 | Electron APIとNode.jsネイティブモジュール | ネイティブコードとの直接連携 |
| アプリケーション構成 | メインプロセスとレンダラープロセス | ホストアプリケーションとChromiumのサブプロセス |
| オフスクリーンレンダリング | 独自の実装で対応可能 | 標準APIで対応 |
| アプリケーションサイズ | 一般に大きい | 組み込み方によるが、Chromium自体のサイズは大きい |
| パフォーマンス | アプリケーションによる | アプリケーションと組み込み方による |
| クロスプラットフォーム対応 | macOS、Windows、Linux | macOS、Windows、Linux |
| パッケージ化のエコシステム | Electron Forge、electron-builder | 通常はホストアプリケーション側で管理 |
| 特に適した用途 | JavaScriptベースのデスクトップアプリ | ウェブコンテンツの埋め込みが必要なネイティブアプリ |
最も重要な違いは、Electronがアプリケーションフレームワークを提供するのに対し、CEFはブラウザーを埋め込むためのフレームワークを提供するという点です。抽象化のレベルが異なるため、必ずしもそのまま置き換えられる関係ではありません。
アーキテクチャ：包括的なフレームワークと埋め込みブラウザー
ElectronはChromiumとNode.jsを統合し、単一のアプリケーションランタイムとして提供します。開発者は、アプリケーションのウィンドウ、ライフサイクルイベント、ネイティブ機能を管理するメインプロセスを作成し、ウェブベースのインターフェースはレンダラープロセスが処理します。
このアーキテクチャにより、開発者は使い慣れたJavaScriptやTypeScriptのツールを使って、アプリケーションの大部分を記述できます。Electronには、ウィンドウの作成、ブラウザーセッションの管理、メニューの処理、通知の表示、システムダイアログへのアクセス、OSとの連携のためのAPIが用意されています。
CEFは異なるアプローチを採っています。デスクトップアプリケーション全体のフレームワークを提供するのではなく、開発者自身が構築・制御するアプリケーションにChromiumを組み込めるようにします。
たとえば、ネイティブのC++アプリケーションを開発している場合、CEFを使えば、既存のアプリケーションウィンドウ内にウェブコンテンツを表示できます。その周囲のインターフェース、アプリケーションのライフサイクル、バックグラウンドサービス、その他のネイティブ機能は、引き続き開発者が管理します。
CEFには、ブラウザーインスタンス、ナビゲーション、リソースの読み込み、JavaScriptの実行、ブラウザーとネイティブアプリケーション間の通信を管理するAPIが用意されています。また、Chromiumのマルチプロセスアーキテクチャを使用しており、レンダリングやその他のブラウザー機能を別々のプロセスで処理します。
この違いは、アプリケーションの構成方法に影響します。Electronでは、一般にChromiumとNode.jsを中心にアプリケーションを構築します。CEFでは、Chromiumは通常、より大きなアプリケーションを構成する1つのコンポーネントです。
CEFを使って、インターフェースの大部分がウェブベースのアプリケーションを構築することもできます。ただし、その周囲に必要なアプリケーション基盤は、開発者自身でより多く実装する必要があります。
歴史的に興味深い点として、初期のElectronとNW.jsはCEFを使用していました。その後Electronは、Chromiumとより直接的に統合する方式へ移行しました。CEFの抽象化により、特にNode.jsとの深い統合など、一部の機能の実装が難しかったためです。
ウェブ技術を使ってデスクトップアプリケーションを構築するための包括的なフレームワークを求める開発者にとって、Electronは一般に、より取り組みやすい出発点となります。すでにネイティブアプリケーションがあり、ウェブ機能を追加したい開発者には、CEFのほうが自然な選択肢かもしれません。
開発体験：JavaScriptとネイティブ開発
Electronの最大の利点の1つは、導入のしやすさです。現代的なウェブ開発に慣れた開発者なら、C++やプラットフォーム固有のUIフレームワークを学ばなくても、既存のスキルを活かしてデスクトップアプリケーションを構築できます。
ElectronはNode.jsと統合されているため、ファイルシステム操作、ネットワーク通信、データベース、バックグラウンドプロセスなど、さまざまな機能に対応する豊富なパッケージを利用できます。React、Vue、Svelte、Angularなどの主要なフロントエンド技術も、アーキテクチャを大きく変更することなく使用できます。
CEFは、主にCとC++のAPIを中心に設計されています。C#、Java、Python、Delphiなどの言語向けにサードパーティ製バインディングが存在するものの、開発者はネイティブアプリケーションのアーキテクチャに加え、CEFのプロセス、スレッド、ライフサイクルに関する要件を理解する必要があります。
すでにネイティブアプリケーションを保守しているチームにとって、これは欠点ではなく利点になることがあります。CEFを使えば、既存のネイティブコードを書き直したり、まったく新しいアプリケーションフレームワークを導入したりせずに、現代的なウェブインターフェースを追加できます。
ただし、JavaScriptを中心とするチームが新しいデスクトップアプリケーションの開発を始める場合、CEFでは一般に、より多くのセットアップやネイティブ連携の作業が必要になります。
違いはツールにも及びます。Electronでは、Electron Forgeやelectron-builderなどの定評あるツールを利用でき、パッケージ化、コード署名、アプリケーションの配布、更新を簡素化できます。CEFはバイナリ配布物やサンプルを提供していますが、通常、開発者はフレームワークを自分たちのビルド・デプロイシステムに組み込む責任を負います。
これは、CEFの能力が劣るという意味ではありません。完全なアプリケーション開発プラットフォームではなく、埋め込み可能なコンポーネントであるという目的の違いを反映しているにすぎません。
パフォーマンス、メモリ使用量、アプリケーションサイズ
ElectronとCEFはどちらもChromiumを使用するため、最新のブラウザーエンジンを動かす際のリソース上のオーバーヘッドが、どちらかを使うだけで解消されるわけではありません。
どちらの技術も、レンダリング、GPUアクセラレーション、ネットワーク通信、その他のブラウザー機能に複数のプロセスを使用する場合があります。メモリ消費量とCPU使用率は、表示するコンテンツ、稼働中のブラウザーインスタンス数、アプリケーションのリソース管理方法に大きく左右されます。
CEFを既存のネイティブアプリケーションに組み込む場合、より柔軟な構成が可能になります。開発者は、ウェブ技術が必要なインターフェースの部分にだけChromiumを使い、それ以外の機能をネイティブコードで直接実装できます。
たとえば、グラフィックスアプリケーションでは、設定パネルや埋め込みウェブインターフェースにCEFを使いながら、レンダリングエンジン、ドキュメント処理、その他の性能が重視される機能はネイティブのまま維持できます。
Electronアプリケーションでも、Node.jsアドオン、外部プロセス、ネイティブモジュールを通じてネイティブコードを実行できます。ただし、Electronのアーキテクチャは一般に、アプリケーション自体をウェブ技術で構築することを中心に据えています。
CEFの特に便利な機能の1つが、オフスクリーンレンダリングです。CEFは、通常のブラウザーウィンドウにウェブコンテンツを表示する代わりに、ホストアプリケーションが独自に処理・表示するバッファーへコンテンツを描画できます。これは、ゲームエンジン、配信ソフトウェア、独自のレンダリングシステムを持つツールなどで役立ちます。
Electronも追加の連携によって特殊なレンダリングワークフローに対応できますが、CEFではオフスクリーンレンダリングが埋め込みAPIの確立された機能として提供されています。
パフォーマンスを評価する際、特に有用な測定項目は次のとおりです。
- 起動時間： アプリケーションが使用可能になるまでの速さ。
- メモリ使用量： 典型的なブラウザーコンテンツやネイティブ機能を使用した際のリソース消費量。
- CPU使用率： レンダリング、ナビゲーション、バックグラウンド処理中のパフォーマンス。
- アプリケーションサイズ： ダウンロードサイズとインストール後のディスク使用量。
- レンダリング要件： 通常のウィンドウが必要なのか、独自のオフスクリーンレンダリングが必要なのか。
CEFとシステムのWebViewを利用するフレームワークを区別することも重要です。CEFは、OSにインストールされたブラウザーエンジンに依存せず、Chromiumを同梱します。そのため、ElectronからCEFに切り替えても、アプリケーションが自動的に大幅に小さくなるわけではありません。
アプリケーションパッケージの小型化を最優先する開発者は、システム提供のWebViewを使用するTauriなどの代替技術を検討してもよいでしょう。
実際の実装でベンチマークを行わずに、ElectronかCEFのどちらかが一律に高速だと考えるべきではありません。
セキュリティとブラウザーの更新
ElectronとCEFはどちらもChromiumのブラウザーアーキテクチャとセキュリティ機構に依存していますが、アプリケーションを適切に設定する責任は開発者にあります。
Electronは、レンダラーのサンドボックス化、コンテキスト分離、特権を持つアプリケーション機能とウェブコンテンツの間のIPCベースの通信などを提供しています。セキュリティに関するドキュメントでは、Node.jsへのアクセスを制限すること、IPCメッセージを慎重に検証すること、リモートから読み込むコンテンツを信頼できないものとして扱うことが推奨されています。
CEFも、Chromiumのマルチプロセスアーキテクチャとセキュリティ分離をサポートしています。ただし、CEFは開発者が制御するアプリケーションに組み込まれるため、どのブラウザー機能、権限、ネイティブ機能を公開するかは、ホストアプリケーション側で決める必要があります。
CEFはJavaScriptバインディングとネイティブ通信をサポートしており、開発者はウェブコンテンツとアプリケーション機能を結び付けられます。特に第三者のウェブサイトを表示する場合、これらのインターフェースは慎重に設計する必要があります。
| セキュリティ上の検討事項 | Electron | CEF |
|---|---|---|
| Chromiumのサンドボックス化 | 対応 | 対応 |
| 特権を持つネイティブ機能へのアクセス | Node.jsとElectron API | ホストアプリケーションのネイティブAPI |
| JavaScriptとネイティブ間の通信 | プリロードスクリプトとIPC | V8バインディングとプロセス間メッセージング |
| リモートコンテンツの分離 | レンダラーのサンドボックス化とコンテキスト分離 | Chromiumのプロセス分離とホスト側の制御 |
| ブラウザーのセキュリティ更新 | Electronのバージョンアップ | CEFのバージョンアップ |
| アプリケーションのセキュリティ責任 | アプリケーション開発者 | アプリケーション開発者 |
もう1つの重要な検討事項は、ブラウザーの保守です。ElectronとCEFはどちらも通常、独自にChromiumランタイムを配布するため、セキュリティ修正が提供されたら、開発者はアプリケーションの更新を配布する必要があります。
CEFは、Chromiumに追随するリリースブランチと、この作業を簡素化するバイナリ配布物を提供しています。Electronも同様に、ChromiumとNode.jsの更新を取り込んだリリースを継続的に提供しています。
どちらの方法でも、継続的な保守が不要になるわけではありません。古いChromiumバージョンを使用するアプリケーションには、上流ではすでに修正された脆弱性が残っている可能性があります。
任意のウェブサイトを表示するソフトウェアを開発するチームは、セキュリティ保守を、たまに行う作業ではなく、アプリケーションのライフサイクルに不可欠な要素として扱うべきです。
採用事例：ElectronとCEFを使う主要アプリケーション
ElectronとCEFはどちらも実際の製品で広く採用されていますが、使われ方には違いがあります。
Electronは特に、一般的なデスクトップ向けの生産性向上、コミュニケーション、開発者向けアプリケーションで目立っています。MicrosoftはVisual Studio CodeにElectronを採用しており、ほかにもSlack、Discord、Notion、Figma、Signal Desktop、GitHub Desktopなどの著名なElectron製品があります。
CEFも大手ソフトウェア企業で使われており、特に既存のネイティブアーキテクチャを持つアプリケーションにウェブインターフェースを組み込む際に採用されています。
具体例は次のとおりです。
| アプリケーション | 技術 | 主な用途 |
|---|---|---|
| Visual Studio Code | Electron | クロスプラットフォームのコードエディター |
| Slack | Electron | チームコミュニケーション |
| Discord | Electron | コミュニケーションとコミュニティのプラットフォーム |
| Notion | Electron | メモと生産性向上 |
| Figma Desktop | Electron | デザインアプリケーション |
| Spotify Desktop | CEF | デスクトップクライアント内のウェブ技術によるインターフェース |
| Steam | CEF | デスクトップクライアント内の埋め込みウェブインターフェース |
| OBS Studio | CEF | ブラウザーソース、オーバーレイ、ブラウザードック |
Spotifyは、CEFの採用状況が特に明確に公開されている事例です。公式オープンソースページでは、Spotify Desktopの各リリースに対応するCEFとChromiumのバージョンが公開されています。
OBS Studioも、開発者がCEFを選ぶ理由を示す明確な例です。obs-browser連携では、CEFを使ってブラウザーソースを提供しており、ユーザーは配信シーン内にウェブベースのオーバーレイやその他のコンテンツを表示できます。CEFはOBS Studioの構成要素であり、アプリケーション全体を構築するフレームワークではありません。
Steamもデスクトップクライアント内でChromiumベースの埋め込みウェブコンポーネントを使用し、ウェブインターフェースを、より広範なネイティブアプリケーション基盤と統合しています。
これらの例は、両技術の違いをよく表しています。Electronはデスクトップアプリケーション全体の構築によく使われる一方、CEFは、すでに多くのネイティブコンポーネントを持つアプリケーションにウェブ機能を追加するためによく使われます。
CEFを、知名度の低い、あるいは時代遅れの代替技術と見なすべきではありません。Electronより前の2008年に誕生し、長年にわたり商用ソフトウェアで広く使用されてきました。その長い歴史と主要製品での継続的な利用は、Chromiumの埋め込みがデスクトップ開発において今なお重要なアプローチであることを示しています。
一方、ElectronはJavaScriptベースのデスクトップアプリケーションを中心に、特に強力なエコシステムを築いてきました。幅広い採用実績、確立されたツール、大手テクノロジー企業の参画により、ウェブ技術で新製品を開発するチームにとって魅力的な選択肢となっています。
両フレームワークの強みが異なるのは、対象とするアーキテクチャ上の要件が異なるためです。
WebCatalogがElectronを選ぶ理由
WebCatalogでは、製品の要件に非常によく合致しているため、クロスプラットフォームのデスクトップアプリケーションにElectronを採用しています。
WebCatalogを使うと、ウェブサイトをデスクトップアプリケーションに変換し、複数のアカウントを個別に管理し、macOS、Windows、Linuxでアプリケーションを整理できます。私たちのソフトウェアは、数千もの異なる開発者が作成したウェブサイトに対応する必要があります。それぞれのサイトは、異なる認証システム、ストレージ機構、ブラウザーAPI、JavaScriptフレームワークを使用しています。
ElectronとCEFはどちらも一貫したChromiumランタイムを提供しており、これは互換性の面で重要です。システムのWebViewに基づくフレームワークとは異なり、サポート対象のデスクトッププラットフォームすべてで、既知のChromiumバージョンを使用できます。
ただし、WebCatalogは、埋め込みブラウザーコンポーネントを必要とするネイティブアプリケーションが主体の製品ではありません。ブラウザー機能こそが製品の中心です。ウィンドウ、セッション、ストレージ、権限、ナビゲーション、アプリケーションのライフサイクルに関する動作を、幅広く制御する必要があります。
Electronは、こうした要件に対応する成熟したAPIを提供しています。BrowserWindow、webContents、sessionの各インターフェースにより、JavaScriptとTypeScriptを使ってブラウザーに似た機能を構築できます。特に重要なのが永続的なセッションパーティションです。これにより、同じウェブサイトの複数アカウントについて、それぞれ独立したログインセッションを維持できます。
CEFも、ブラウザーインスタンス、リクエスト、ストレージ、ネイティブ連携を管理するAPIを提供しています。原理的には、同様の機能の多くをCEFで実装できます。ただし、その場合は、より多くのネイティブ基盤を自分たちで構築・保守する必要があります。
ElectronとNode.jsの統合も、私たちの技術スタックに合っています。デスクトップアプリケーションのロジックの大部分をTypeScriptで実装し、製品間でコードを共有し、JavaScriptのエコシステムを活用できます。
クロスプラットフォーム開発も検討事項の1つです。WebCatalogはmacOS、Windows、Linuxをサポートしており、プラットフォーム固有のアプリケーションパッケージ化、連携、システム動作にも対応しています。Electronの確立されたAPIと配布ツールにより、保守が必要なネイティブコードの量を減らせます。
Electronにオーバーヘッドが伴うことは認識しています。Chromiumを同梱するとアプリケーションサイズが増え、ブラウザーベースのアプリケーションでは慎重なリソース管理が必要です。私たちはElectronを置き換えるのではなく、その使い方を改善することに注力してきました。
たとえば、生成したMacアプリケーションのディスク使用量を減らすためにAPFSクローンを導入し、Chromiumとの互換性を維持しながら、重複するストレージ使用を削減しました。
私たちがElectronを選んだことは、Electronがあらゆる場面でCEFより優れていることを意味しません。WebCatalogが、少数の埋め込みウェブインターフェースを備えたネイティブアプリケーションを主体としていたなら、CEFは非常に優れた選択肢になり得ます。しかし、私たちの製品は根本的にウェブアプリケーションとブラウザー機能を中心に構築されているため、Electronのほうが生産性と保守性に優れた基盤になります。
CEFが優位に立つ場面
WebCatalogではElectronを選んでいますが、ネイティブソフトウェアとのより深い統合が必要なアプリケーションにとって、CEFには重要な利点があります。
CEFは、すでに確立されたC++アプリケーションがあり、既存のアーキテクチャを置き換えずに現代的なウェブインターフェースを導入したい場合に、特に魅力的です。
オフスクリーンレンダリングへの対応も、大きな利点です。配信ソフトウェアやゲームエンジンなどのアプリケーションでは、一般的なデスクトップウィンドウではなく、独自のグラフィックスパイプラインへウェブコンテンツを直接描画する必要がある場合があります。CEFは、こうした用途に対応する確立されたAPIを提供しています。
また、CEFを使えば、ブラウザーの組み込み方を細かく制御できます。開発者は、リクエスト処理、ナビゲーション、JavaScriptバインディング、リソースの読み込み、ブラウザーインスタンスとネイティブアプリケーションのコンポーネントとのやり取りをカスタマイズできます。
ネイティブ開発の高度な専門知識を持つチームにとって、この柔軟性はElectronの手軽さを上回る価値を持つことがあります。
次のような場合は、CEFを検討する価値があります。
- 既存のネイティブアプリケーションにウェブインターフェースを追加する場合。 現在のアプリケーションアーキテクチャを維持し、必要な箇所にChromiumを埋め込めます。
- 独自のレンダリング要件を持つソフトウェアを構築する場合。 オフスクリーンレンダリングにより、ウェブコンテンツをグラフィックスパイプラインや特殊なインターフェースに組み込めます。
- ネイティブのC++機能と深く統合する場合。 CEFはネイティブAPIを公開し、ブラウザーの動作を細かく制御できます。
- 既存のCEFアプリケーションを保守する場合。 Electronへの移行では、有意義な利点を得られないまま、大幅なアーキテクチャ変更が必要になる可能性があります。
- ネイティブとウェブのインターフェースを組み合わせる場合。 アプリケーションの一部にChromiumを使い、それ以外ではネイティブUIコンポーネントを維持できます。
CEFでは、アプリケーション基盤に対してより多くの責任を負う必要があります。開発者は、パッケージ化、更新、ウィンドウ管理、プラットフォーム固有の連携を独自に実装しなければならない場合があります。
すでにネイティブアプリケーションを保守できる体制が整ったチームにとっては、これは十分に妥当かもしれません。一方、ウェブ開発を中心とするチームが新しいデスクトップ製品を構築する場合には、不必要な複雑さを招くことがあります。
ElectronとCEF：どちらを選ぶべきか
どちらも成熟しており、活発に開発が続けられ、高度なデスクトップソフトウェアを支えられる技術です。より適切な選択肢は主に、ウェブ技術を中心に新しいデスクトップアプリケーションを構築するのか、それとも既存のネイティブアプリケーションにウェブ機能を埋め込むのかによって決まります。
| 優先事項 | より適した出発点 | 理由 |
|---|---|---|
| JavaScriptまたはTypeScriptを使った新しいデスクトップアプリ | Electron | 包括的なアプリケーションフレームワーク |
| 既存のネイティブC++アプリケーション | CEF | ネイティブアーキテクチャに統合できる |
| ネイティブ開発を最小限に抑える | Electron | Node.jsとJavaScriptのAPI |
| ネイティブウィンドウへのウェブコンテンツの埋め込み | CEF | 埋め込みに特化した設計 |
| オフスクリーンレンダリングと独自のグラフィックスパイプライン | CEF | 専用のレンダリングAPI |
| 充実したデスクトップ向けパッケージ化・更新ツール | Electron | 確立された配布エコシステム |
| ネイティブC++コードとの直接統合 | CEF | ネイティブのCおよびC++インターフェース |
| デスクトッププラットフォーム間でのChromiumの一貫性 | どちらでも可 | どちらもChromiumを同梱 |
| 複雑なブラウザーセッション管理 | どちらでも可 | どちらもブラウザー管理機能を提供 |
| 小さなアプリケーションパッケージ | どちらにも本質的な優位性はない | どちらもChromiumを配布 |
| 既存のJavaScript開発チーム | Electron | 使い慣れた開発スタック |
| 既存のCEFベースの製品 | CEF | 不要な移行を回避できる |
新しいクロスプラットフォームのデスクトップアプリケーションを開発する多くのウェブ開発者にとって、Electronは一般に、より実用的な選択肢です。アプリケーションのアーキテクチャ、ネイティブ連携、開発ツール、配布エコシステムが提供されており、すべてをゼロから開発せずに完成した製品を構築できます。
すでにネイティブアプリケーションがある開発者や、特殊なブラウザー埋め込み機能が必要な開発者には、CEFのほうが適していることが多いでしょう。その柔軟性とネイティブとの直接連携は、ゲームエンジン、配信ツール、産業用アプリケーション、埋め込みウェブインターフェースを持つ複雑なネイティブ製品などで特に役立ちます。
どちらかの技術が本質的に高速、あるいは安全というわけではありません。そうした特性は、アプリケーション、そのアーキテクチャ、実装の品質に大きく左右されます。
まとめ
ElectronとChromium Embedded Frameworkは、基盤となるブラウザー技術は同じですが、解決する課題が異なります。
Electronは、ウェブ開発者がデスクトップアプリケーション開発に取り組みやすくなるよう設計されています。Chromium、Node.js、ネイティブのデスクトップAPIを1つのフレームワークにまとめ、JavaScriptとTypeScriptを使って高度なアプリケーションを構築できるようにします。
CEFは、他のアプリケーションにChromiumを埋め込むために設計されています。ブラウザー統合をより低レベルで制御でき、ウェブベースのインターフェースや特殊なレンダリング機能が必要なネイティブアプリケーションで、特に価値を発揮します。
どちらも主要な製品でその価値を実証してきました。ElectronはVisual Studio Code、Slack、Discord、Notionなどのアプリケーションを支え、CEFはSpotify、Steam、OBS Studioなどの製品で使用されています。
WebCatalogでは、製品が根本的にブラウザー機能を中心に構築されているため、Electronを採用しています。一貫したChromiumランタイム、成熟したブラウザー管理API、JavaScriptのエコシステムにより、クロスプラットフォームのデスクトップアプリケーションを効率よく開発・保守できます。
CEFは、ネイティブアプリケーションに取り組む開発者にとって、引き続き優れた選択肢です。特に、Chromiumを製品全体の基盤とするのではなく、既存のアーキテクチャに埋め込む必要がある場合に適しています。
最終的な判断は、何を作るかによって決まります。ウェブ技術を使ってデスクトップアプリケーション全体を作りたいなら、通常はElectronのほうが適した出発点です。ネイティブアプリケーションにChromiumを追加したいなら、CEFのほうが適切なツールである可能性が高いでしょう。
