TypeScript 開発者のための Electron 代替
Electron はデスクトップアプリを Web 開発者にとって身近なもの にしましたが、そのサイズとメモリのコストは「Electron 代替」を 定番の検索キーワードにしました。TypeScript を言語として使う なら、2026年時点で現実的な道は4つあります：Electron に留まる、 Tauri へ移行する、Bun でランタイム埋め込みのバイナリを作る、 あるいは Perry でネイティブへコンパイルする。それぞれがまった く異なるトレードオフを取ります。
4つのアプローチ
Electron——基準点
すべてのアプリに Chromium と Node.js を同梱します。長所は 10年に及ぶ本番実績と、チームがすでに知っている UI スタック （HTML/CSS/JS）です——VS Code、Slack、Discord もこの上で 動いています。短所はその基準コストです：hello world の インストーラでおよそ80–150 MB、複数の Chromium プロセス、 アイドル時に数百 MB の RAM。デスクトップ専用です。Perry vs Electron の詳細な比較。
Tauri——システム webview 内の Web UI、Rust バックエンド
Tauri は Web フロントエンドを維持しつつ、同梱の Chromium を捨てます：UI は OS の webview（WKWebView、WebView2、 WebKitGTK）内で描画されるため、インストーラは一桁台の MB に収まります。安定しており、ドキュメントも充実して おり、Tauri 2 では iOS/Android が追加されました。トレード オフは、バックエンドが TypeScript ではなく Rust であり、 UI を超えたアプリロジックには Rust を書いて IPC ブリッジ を越える必要があること、そして各 OS が異なる webview を 提供するためレンダリングがプラットフォームごとにわずかに 異なることです。Perry vs Tauri の詳細な比較。
Bun——シングルファイルバイナリ、GUI レイヤーなし
「bun electron」を検索する人の多くは、Electron の重さなし に Electron の手軽さを求めています。bun build --compile は、Bun ランタイムをバンドルされた TypeScript と一緒に 埋め込むことで単一の実行ファイルを生成します——CLI や サーバーには最適で、それ自体がランタイムであるため npm との完全な互換性があります。しかしバイナリはおよそ60 MB （macOS arm64）から100 MB超（Linux/Windows）になり、 コードは依然として JIT 実行され、Bun には UI フレーム ワークがありません——デスクトップアプリには結局 Electron、Tauri、あるいは webview ライブラリが別途必要 です。Perry vs Bun の詳細な比較。
Perry——ネイティブウィジェットへコンパイルされる TypeScript
Perry は TypeScript を事前にマシンコードへコンパイルし、 本物のプラットフォームウィジェット——AppKit、UIKit、 GTK4、Win32、JNI 経由の Android——を通じて UI を描画 します。webview も IPC ブリッジも一切ありません。UI と ロジックの両方に1つの言語だけを使い、hello world は ~330 KB、一般的なバイナリは2–5 MB、起動は~1 ms、そして モバイル・ウォッチ・TV を含む10のターゲットに対応します。 正直な注意点：Perry は1.0未満であり、UI API は独自のもの （宣言的で SwiftUI に近く、HTML/CSS ではありません）、 エコシステムは Electron に比べればまだ若いということです。
横並びで比較
| Perry | Electron | Tauri | Bun (--compile) | |
|---|---|---|---|---|
| 言語 | 全体を通して TypeScript | JS/TS + HTML/CSS | JS/TS フロントエンド、Rust バックエンド | TypeScript |
| UI のアプローチ | ネイティブなプラットフォームウィジェット | 同梱の Chromium | システムの webview | なし（CLI / サーバー） |
| hello world のサイズ | ~330 KB | ~80–150 MB | ~3–10 MB | プラットフォームにより~60–116 MB |
| 実行 | AOT マシンコード | JIT（V8） | JIT（webview の JS エンジン）+ ネイティブ Rust | JIT（JavaScriptCore） |
| アイドル時のメモリ | 数十 MB（単一のネイティブプロセス） | 数百 MB（マルチプロセスの Chromium） | Electron より少ない（OS の webview） | ランタイム相応 |
| モバイル / ウォッチ / TV | iOS、iPadOS、Android、watchOS、tvOS | なし | iOS、Android（Tauri 2） | なし |
| 成熟度 | 1.0 未満 | 本番実績10年以上 | 安定版（1.x/2.x） | 安定版 |
React Native や Flutter はどうなのか？
Electron に関するあらゆるスレッドでこの2つは話題に上がります が、答えている問いが違います。React Native はモバイルファースト です：あなたの JavaScript は Hermes エンジン上で動作し、 ブリッジ越しにネイティブビューを操作します。デスクトップ対応 は別のコミュニティ／Microsoft のフォークを通じてのみ存在して おり、Electron のそのまま置き換えにはなりません（Perry vs React Native）。Flutter はデスクトップとモバイルの両方をカバーします が、TypeScript を離れて Dart を使うことになり、プラット フォームのウィジェットを使う代わりに自前で描画します。 TypeScript に留まることが制約であるなら、現実的なデスクトップ の候補は上記の4つのままです。
どれを選ぶべきか？
Web スタックに留まる
UI がすでに React/Vue/Svelte で構築されていて、今すぐ実績 十分なデスクトップ配布が必要なら、Electron は依然として 最もリスクの低い選択です——サイズとメモリで対価を払う ことになります。そのコストが気になり、バックエンドを Rust で書くことに抵抗がないなら、Tauri は Web スタックの 体験の大部分を、はるかに小さいフットプリントで提供して くれます。
webview を手放す
本当に求めているのが、TypeScript を入れればネイティブ アプリが出てくること——1つの言語、本物のプラットフォーム ウィジェット、小さなバイナリ、そして同じコードベースから のモバイル／ウォッチ／TV——であるなら、それはまさに Perry が埋めるために存在するギャップです。対価として 1.0未満という成熟度を払うことになります。そして CLI やサーバーを、互換性リスクゼロの単一ファイルとして だけ必要としているなら、Bun の--compile が現実的な選択です。