CEFへの賭け：Deno Desktopの中庸

2026年6月、Denoはv2.9.0で deno desktop を正式にリリースした——任意のTypeScriptプロジェクト（単一ファイルスクリプト、Next.jsアプリケーション、さらにはHTTPサーバー）をmacOS .app、Windows .exe、Linux AppImage にパッケージ化する単一のコマンドである。HNでは997ポイント、365コメント、Lobstersでは△34を獲得した。高スコアはDenoの人気だけが理由ではない——コメント欄で最も激しい議論は、Denoが行った技術的選択に向けられていた：システムWebViewに依存するTauriとは異なり、デフォルトでCEF（Chromium Embedded Framework）をバンドルすること。

この選択はコミュニティで同時に喝采と疑問を集めた。喝采はLinuxでwebkitgtkに苦しめられた開発者から。疑問は「システム標準のブラウザエンジンがあるのに、なぜそれを使わないのか」と考える人々から。どちらの声にも道理があり、Denoの選択はまさにその中間に位置している。

Electronの200MBの呪い

Electronがデスクトップアプリ開発を支配している理由は単純だ：HTML/CSS/JSでUIを書き、Node.jsでシステムAPIを呼び出し、同一コードでWindows/macOS/Linuxで動作する。代償もまた単純：各Electronアプリは独立したChromiumブラウザのコピーにNode.jsランタイムを加えたもので、最低150MB、最大250MBに達する。 Slack、VS Code、Discord、Figma——あなたのハードディスクにはおそらく5つのElectronアプリがあり、それは5つのChromiumコピーを保存していることを意味する。

これは単なるディスク容量の無駄ではない。各Electronアプリは独自にブラウザプロセス——GPUプロセス、レンダラープロセス、ネットワークプロセス——を起動し、メモリ使用量は線形に積み上がる。一つのChromeタブのメモリ消費は約100MBだが、3つのElectronアプリを同時に実行すれば、軽く1.5GB以上を消費する。ユーザーは「なぜメモ帳アプリがIDEよりメモリを食うのか」と感じるが、真相はあなたのメモ帳アプリがIDEレベルのブラウザホストであり、ただの<textarea>を動かしているにすぎないということだ。

Electronチームがこの問題を知らないわけではない。彼らはelectron-shared-libraryの実験を行い、複数のElectronアプリが一つのChromium動的ライブラリを共有できるようにしようとしたが、結局実装されなかった。根本的な障壁は技術面ではなく——アプリ各々のバージョン依存性地獄にある。 アプリAはElectron 28に依存し、アプリBはElectron 31に依存する——Chromiumの更新頻度（4週間ごとにメジャーバージョンアップ）の下では、共有ライブラリのABI互換性を維持することはほぼ不可能である。Linuxディストリビューションのパッケージマネージャは「ディストリビューション全体を一つのバージョンスナップショットに固定する」ことでこの問題を解決しているが、デスクトップアプリにはその贅沢は許されない——DiscordのアップデートのためにVS Codeも強制アップグレードするようユーザーに要求することはできない。

TauriのシステムWebView路線：理念は正しくとも、現実は残酷

Tauriは別の道を選んだ。その核となる洞察は：OSが既にブラウザエンジンを内蔵しているなら、なぜもう一つ配布する必要があるのか？ macOSにはWKWebView、WindowsにはWebView2、Linuxにはwebkit2gtkがある。Tauriのバイナリサイズは極めて小さい——最低でも10MB未満——なぜならレンダリングエンジンを完全にOSに外部委託しているからだ。バックエンドはRustで記述され、フロントエンドは任意のJSフレームワーク、IPCはTauri独自のブリッジを介して行われる。

この理念はWindowsではうまく機能している。WebView2はEdge Chromiumベースで、MicrosoftがWindows Updateを通じて更新をプッシュし、バージョンも比較的新しく互換性も良い。問題はmacOSとLinuxにある。

macOSのWKWebViewはOSバージョンに束縛されている。つまり、ユーザーがまだmacOS 13を使っている場合、TauriアプリはmacOS 13対応のWebKitバージョンで動作する——これは最新のSafariより2〜3メジャーバージョン遅れている可能性がある。 新しいCSS機能はサポートされず、新しいWeb APIは公開されず、一部のCanvas/WebGLの挙動はChromeと一致しない。Tauri開発者にはどうすることもできない——彼らにはユーザーのマシン上のシステムWebKitを置き換える能力も権限もない。AppleのWKWebViewの更新リズムはアプリ開発者のコントロールの埒外にある。

Linuxの状況はさらに悪い。Linuxには「システムブラウザエンジン」という概念がない——デスクトップ環境ごと、GTKバージョンごと、ディストリビューションごとにパッケージングされたwebkit2gtkのバージョンが異なる。HNのDeno Desktopコメント欄で、長年Tauriを使用してきた開発者echelonが頻繁に引用される評価を書いている：webkitgtkは「遅くてメモリを食う」。これは個人の不満ではない——TauriのGitHub Issue #3988および#7021には、大量のDOM要素があるシナリオでのwebkit2gtkの深刻なパフォーマンス劣化が記録されている。スクロールのカクつき、レンダリングのフレーム落ち、そしてWebKit 2.40で導入された既知のパフォーマンスリグレッションなどである。

TauriがLinuxで直面する真の問題は、信頼できるレンダリングエンジンがそもそも選択肢として存在しないことだ。 webkit2gtkはWebKitGTKコミュニティによってメンテナンスされており、開発リソースはChromiumチームのそれには遠く及ばない——ChromiumにはGoogleのフルタイムエンジニアチームとセキュリティ研究者がいるが、WebKitGTKのコアメンテナは片手で数えられる。これはWebKitGTK開発者の能力を貶めるものではない——彼らは尊敬すべき仕事をしている——しかし兵力の差は客観的事実である。

Denoの選択：CEFをバンドルするが、独占はしない

Deno Desktopは第三の道を選んだ。デフォルトでCEF（Chromium Embedded Framework）を使用する——Electronと同じくChromiumベースだが、2つの重要な違いがある。

第一に、CEFは純粋なブラウザエンジンであり、Node.jsを含まない。 ElectronのバンドルはChromiumレンダリングエンジンとNode.jsランタイムの両方を含み、両者はlibnodeで深く結合している。Deno Desktopのアーキテクチャは異なる：Deno自体がJS/TSランタイム（V8ベース）であり、CEFはHTML/CSS/JSフロントエンドページのレンダリングのみを担当する。DenoプロセスはCEF内部では動作しない——独立したプロセスとしてローカルHTTPサーバーを起動し、CEFウィンドウは http://localhost:<port> をロードしてUIをレンダリングする。フロントエンドとバックエンドの通信は通常のHTTP/WebSocketを介して行われ、ElectronのようなipcMain/ipcRendererによるプロセス内ブリッジではない。

このアーキテクチャ選択の直接的な結果は：Deno Desktopアプリは他のレンダリングバックエンドに切り替えることができる。 Denoは3種類のバックエンドをサポートしている：cef（デフォルト）、webview（システムWebView）、winit（純Rustウィンドウ、ゲーム/グラフィックアプリ向け）。CEFは公式推奨のデフォルトだが、互換性を気にしないのであればwebviewに切り替えてより小さなバイナリサイズを享受できる。この柔軟性はElectronにはない——ElectronのChromiumバインディングは深すぎて「切り離す」ことは不可能である。

第二に、Denoの公開ロードマップには明確に記されている：共有CEFランタイム。 現在、各Deno Desktopアプリは依然として個別にCEF動的ライブラリをバンドルしているが、Denoチームは将来「ホスト型共有ランタイム」を実装する計画である——複数のDeno Desktopアプリがマシン上の単一のCEFインストールを共有する。この路線はElectronが試みて断念したshared-library実験と同じ方向性だが、DenoにはElectronにない利点がある：すべてのDeno Desktopアプリは同一のランタイムバージョン管理フレームワークの下で動作する。 Denoのバージョン更新メカニズムは、「あなたのマシンに2つのDeno Desktopアプリがインストールされている場合、それらが使用するCEFバージョンはDenoによって一元管理される」ことを保証できる——システムレベルのパッケージマネージャが共有ライブラリバージョンを管理するのと同じように。これはすでに解決された問題ではない——ロードマップ上の項目は納品物と等価ではない——しかし方向性は正しい。

CEFの技術的特徴

CEF自体は非常に成熟度の高いプロジェクトである。Spotifyのデスクトップクライアント、AdobeのCreative Cloudコンポーネントの一部、Epic Games Launcher、OBS Studioのブラウザソース——これらはすべてCEFを使用してChromiumを埋め込んでいる。そのマルチプロセスアーキテクチャはChromeと同一である：browserプロセスがウィンドウとネットワークを管理し、各ページインスタンスは独立したrendererプロセスで動作し、GPUプロセスがコンポジションとハードウェアアクセラレーションを担当する。このアーキテクチャによる分離は、Denoのセキュリティモデルと相補的である——Denoはデフォルトでファイルシステム/ネットワーク/環境変数へのアクセスを禁止しており、CEFのサンドボックス化されたrendererプロセスはフロントエンドコードからの脱出領域をさらに制限する。

CEFはオフスクリーンレンダリング（OSR）もサポートしている。通常モードではCEFはネイティブウィンドウを作成してその中でレンダリングを行う。OSRモードではレンダリング結果がメモリバッファに出力され、ホストアプリケーションがそれをどのように表示するかを決定する。この能力はDeno Desktopのwinitバックエンドにとって重要である——将来的にDenoが完全にカスタマイズ可能なUIフレームワーク（GPU駆動のUIなど）をサポートしたい場合、CEFのOSRモードはウェブコンテンツをテクスチャとしてレンダリングパイプラインに直接入力できる。

しかしCEFにも代償はある。CEF動的ライブラリ（libcef.so）のサイズは約150MBで、Chromiumのリソースファイル（.pak、icudtl.dat、locales）を加えると、総ディスク使用量は約200MBになる。 これはElectronとほぼ同じである。バイナリサイズだけを見れば、Deno Desktop + CEFはElectronよりも軽量ではない——その優位性はここにはない。優位性は2点にある：第一にCEFは共有可能だが、ElectronのNode.js+Chromium結合体は共有が困難であること。第二にDenoは究極のサイズ追求のためにwebviewバックエンドに落とすことが可能だが、Electronにはその選択肢がないこと。

3方式の比較

3つの方式を同一の表にまとめると、それぞれのトレードオフがより明確になる。

次元	Electron	Tauri	Deno Desktop (CEF)
レンダリングエンジン	Chromiumをバンドル	システムWebView	CEFをバンドル（システムWebViewに切替可）
バックエンド言語	Node.js (JS)	Rust	Deno (JS/TS)
バイナリサイズ	150-250 MB	3-15 MB	200 MB（CEFモード）/ 15 MB（webviewモード）
macOS互換性	最新Chromium、OS制限なし	システムWKWebViewのバージョンに制限される	最新CEF、OS制限なし
Linux互換性	一貫	webkit2gtkに依存、パフォーマンスと互換性の変動大	一貫（独自CEF）
プロセスモデル	Main + Renderer（Node.jsとChromiumが深く結合）	Rustメインプロセス + システムWebViewプロセス	Deno HTTPサーバープロセス + CEF browser/rendererプロセス
共有エンジンの可能性	低（バージョンの断片化が深刻）	天然で共有（システムエンジン使用）	中（ロードマップに共有ランタイム計画あり）
フロントエンドフレームワーク対応	任意のJSフレームワーク	任意のJSフレームワーク	任意のJSフレームワーク（Next.js等のフルスタックフレームワーク含む）
更新メカニズム	自作が必要	自作が必要	内蔵（Deno Deployスタイルのホットアップデート）

この表で最も誤読されやすいのは「バイナリサイズ」の行である。 Deno DesktopがCEFモードで200MBというサイズは一見Electronと同じように見えるが、重要な違いはこの200MBのうちどの部分が「可変コード」でどの部分が「共有可能なエンジン」かである。Electronの200MBのうち、Chromium + Node.jsが約180MBを占め、各アプリが独立してパッケージ化される。Deno Desktopの200MBのうち、CEFも約150MBだが、Denoの共有ランタイムロードマップはこの部分が将来的に1コピーで済む可能性を意味する。共有ランタイムが実現するまでは、Deno Desktopはサイズ面でElectronに勝っていない。共有ランタイムが実現した後は、各アプリの増分サイズを一桁MBまで圧縮する可能性がある——Tauriが今日実現しているように、しかしレンダリングエンジンの一貫性を犠牲にすることなく。

共有依存：デスクトップアプリに忘れられたLinuxの智慧

Linuxディストリビューションはパッケージマネージャを使って共有依存の問題を30年にわたって解決してきた。libssl.so、libgtk.so、libc.so——システム上には常に1コピーしかなく、すべてのアプリが同じものにリンクする。バージョンアップはパッケージマネージャが調整し、ABI互換性はディストリビューションレベルで保証される。この仕組みは非常にうまく機能しており、Linuxユーザーは「各アプリが独自のOpenSSLを持ち込む」ことに本能的に拒否感を持つ。

なぜデスクトップアプリはこの車輪を再発明しなければならないのか？ その根源は技術的な未熟さではなく、信頼モデルの違いにある。Linuxパッケージマネージャが機能する前提は、中央権威（ディストリビューション保守者）がすべてのパッケージのバージョン一貫性に責任を持つことである。デスクトップアプリのエコシステムにはこの中央権威がない——VS CodeはMicrosoft、DiscordはDiscord社、FigmaはFigma社がそれぞれリリースしており、それらの間に調整メカニズムは存在しない。各アプリ開発者は「ユーザーのマシンに何があるかわからない」と仮定せざるを得ず、最も保守的な戦略——必要なものをすべてパッケージに詰め込む——を選ぶ。

Deno Desktopの共有CEFランタイム計画は、これら2つの極端の間に中間点を見出そうとしている：システムレベルのグローバル共有（OSレベルの調整が必要）は行わず、Denoエコシステム内のホスト型共有のみを行う。 deno desktop を通じて構築・配布されるすべてのアプリのCEFバージョンは、Denoの統一バージョンマネージャによって制御される。これはFlatpakのランタイムメカニズム——複数のFlatpakアプリがKDE/GNOMEランタイムを共有する——に似ているが、より粒度が小さく、ブラウザエンジンのみを共有する。

この道が機能するかどうかは2つの変数に依存する：第一に、Deno Desktopエコシステムが共有を意味あるものにするだけの十分なアプリを生み出せるか（もしDeno Desktopアプリが3つしかなければ、共有ランタイムの利益は微々たるもの）、第二に、CEFのABI安定性が「複数のアプリが同一のCEFに依存しながら更新頻度が異なる」という状況に耐えられるかである。CEFのAPI安定性はChromium自体よりも良い——CEFのAPIラッパー層が多くの緩衝材を提供している——しかし、一枚岩ではない。CEFのメジャーバージョンアップ時に、共有ランタイムマネージャが「アプリAは新バージョンと互換性があるが、アプリBは旧バージョンにしか対応していない」状況をどのように処理するかについて、現在Denoチームは公開された技術的解決策を持っていない。

この賭けの勝敗を分けるもの

echelon がHNに寄せたコメントは、なぜDenoがCEFを選んだのが正しい方向性かを指摘している：TauriがmacOSとLinuxのシステムWebViewで経験した苦痛があまりにも大きかったからだ。Tauriの理念はクリーンである——システムネイティブのものを使い、重複したバイナリを配布しない——しかし現実は、macOSのWKWebViewの更新リズムはAppleが決定し、Linuxのwebkit2gtkの品質は小さなオープンソースコミュニティによって保証されている。理念の潔白さは実装の粗さを補償しない——ユーザーが覚えるのは「このアプリはLinuxでカクついて使い物にならない」ということであり、「このアプリはシステムWebViewを使っているから省スペースだ」ということではない。

DenoのCEF路線は理念の純粋性を捨て、実装の制御可能性と引き換えにした。それは気まずいが真実の工学的な事実を認めている：クロスプラットフォームデスクトップアプリの分野では、制御可能性はサイズよりも重要である。 レンダリングエンジンが自分たちのコントロールできないプラットフォームで一貫した動作をしないなら、節約したディスク容量は互換性問題に食われる開発時間によって何倍にも跳ね返ってくる。

しかしDenoはサイズ最適化を放棄したわけでもない——共有ランタイムロードマップがElectronとの根本的な差別化要因である。共有CEFランタイムが成功裏に実装されれば、Deno Desktopは「レンダリングエンジンの一貫性」（バンドルCEF由来）と「小さな増分サイズ」（共有アーキテクチャ由来）を同時に手に入れることになる。これはElectron（一貫性のみ、小さなサイズなし）とTauri（Windowsでのみ小さなサイズ、macOS/Linuxでの一貫性なし）がそれぞれ実現できなかったことである。

もちろん、ロードマップ上のものは納品済みのものとして評価することはできない。Deno Desktopは現在もcanaryバージョンであり、APIは安定しておらず、共有ランタイムは「将来の計画」にすぎない。この分野には美しいアーキテクチャ図は事欠かない——不足しているのは、共有エンジンのバージョン管理という一見単純だが実際には地獄級に困難な問題を真に工学的に実装できるチームである。 Denoチームにはその能力の蓄積がある（Deno自身のバージョン管理とリモートモジュールキャッシュシステムは、応用可能なインフラである）が、能力と納品の間の距離こそが、賭けそのものなのである。