ElectronかTauriかどっちにすべき？

概要

自分はElectronでzudo-textというノートアプリを作っている。ファイルツリー、CodeMirrorエディタ、ターミナル、AI機能を搭載したアプリで、「なぜElectronなのか: デスクトップアプリ開発の技術選定」みたいな記事シリーズを書いている最中に「そもそもTauriでいいのでは？」という疑問が出てきた。

TauriはRustバックエンドでファイルI/Oをネイティブに扱えるし、バンドルサイズも小さい。Electronから移行すべきなのか。Claude Codeに聞きながら、この問いを掘り下げていった。以下はそのやりとりをまとめたもの。

TauriだとファイルI/OにNode.jsが必要？

Takazudo

Tauriだとファイルの読み書きはどうするの？ Node.jsが必要ならNode.jsバイナリをバンドルする必要がある？そうするとTauriの軽量さのメリットがなくなるのでは？

Claude

ファイルの読み書きはTauriでは問題にならない。Tauriはこれをネイティブに提供している。

@tauri-apps/plugin-fs — Tauri公式のファイルシステムプラグインで、フロントエンドのJSからファイルの読み書きができる
#[tauri::command] — Rustでstd::fsを使う関数を書いて、フロントエンドのJSから呼び出せるカスタムコマンド

なので「Markdownファイルの読み書き」「JSON設定ファイルの管理」みたいなユースケースは、Node.jsなしでTauriが普通に対応できる。

Electronが本当に強いのはnpmエコシステムへのアクセス。具体的にはnode-ptyのような、Node.jsのネイティブモジュールに依存するパッケージが使える点。基本的なファイルI/Oではない。

TauriにはSidecar機能（外部バイナリのバンドル）があるので、技術的にはNode.jsバイナリを同梱することもできる。ただそれをやるとTauriの軽量さというメリットが消えるので、本末転倒になる。

npmエコシステムへの依存が、ElectronとTauriを分ける本当の判断基準ということになる。

CodeMirrorにはサーバーサイド機能がある？

Takazudo

CodeMirrorってサーバーサイドの機能あるの？ブラウザのエディタだけじゃなくて？

Claude

ない。CodeMirrorは純粋にブラウザサイドで動作するJavaScriptライブラリ。DOMの中でエディタをレンダリングする。サーバーサイドのコンポーネントは持っていない。

なのでTauriのWebViewでもElectronのChromiumでも同じように動く。CodeMirrorは「なぜTauriではなくElectronか」の理由にはならない。ElectronでないとダメなのはNode.jsが必要なもの、例えばnode-ptyのようなパッケージ。

TauriでもCodeMirrorは問題なく使える？

Takazudo

じゃあCodeMirrorをアプリのエディタに使う場合、Tauriでも問題ないよね？

Claude

その通り。CodeMirrorはどのブラウザ / WebViewでも動くので、Tauriでも全く問題ない。

TauriかElectronかの判断は結局こういう話になる。

node-pty（ターミナル埋め込み） — これがElectronを選ぶ決定的な理由
Rustの学習コスト — Tauriプラグインにない機能を自前で実装するならRustが必要

もしzudo-textが「ファイルツリー + CodeMirrorエディタ + JSON設定ファイル管理」だけで、ターミナルがなければ、Tauriで十分成立する。

zudo-textをTauriに移行できるか調べてみてもらってよい？

Takazudo

実際にzudo-textをTauriに移行できるか調べてみてもらってよい？

Claude

zudo-textのコードベースを見て、Node.jsをバックエンドで何に使っているか整理した。

Node.jsに依存している処理は以下。

node-pty — シェルプロセスを生成してターミナルを埋め込む（pty-manager.jsで約150行）
ファイルシステム操作 — fs / fs/promisesでMarkdown、pins、drafts、settingsの読み書き。ディレクトリの一覧取得、スキャフォールディング。fs.watch()でファイル変更のリアルタイム検知
OS統合 — os.homedir()で設定パスの取得、pathモジュール
Electronダイアログ — ディレクトリ選択ダイアログ

逆に、フロントエンドだけで完結していてTauriのWebViewでそのまま動くものは以下。

React 19 + React Router SPA
CodeMirror 6エディタ（Vimモード付き）
xterm.jsターミナルUI
Markdownレンダリング、Tailwind CSS、MiniSearch等

結論としては、node-ptyが移行のブロッカー。ターミナル機能がなければ、移行はかなり現実的。ファイルI/O、ファイル監視、ダイアログはすべてTauriプラグインで代替できる。Reactフロントエンドはほぼそのまま持っていける。

xterm.jsもTauriでは使えなくなる？

Takazudo

ターミナルにはxterm.jsを使ってるけど、Tauriだとxterm.jsも使えなくなるの？代替は？

Claude

xterm.js自体は使える。xterm.jsは純粋にブラウザサイドのターミナルUIレンダラーで、どのWebViewでも動く。

依存関係を分けて整理するとこうなる。

xterm.js（フロントエンド） — ターミナルのUIを描画する。Tauriでも動く
node-pty（バックエンド） — 実際のシェルプロセスを生成する。Node.jsが必要

この2つは別物。Tauriに移行する場合、xterm.jsはそのまま使って、node-ptyだけをRustのportable-ptyで置き換えることになる。

	Electron（現状）	Tauri（仮）
ターミナルUI	xterm.js	xterm.js（同じ）
シェル生成	node-pty（Node.js）	portable-pty（Rust）
通信方式	IPC via window.api.terminal.*	Tauri invoke() + events

移行作業はバックエンド側だけ。Rustのコマンドとしてportable-ptyを使ったPTY管理を書くことになる。

移行は技術的にはそこまで難しくない？

Takazudo

じゃあ移行は技術的にはそこまで難しくなさそう？

Claude

pty-manager.jsは約150行で、Rustで同等のものを書いてもスコープとしてはそこまで大きくない。

ただ、技術的に可能かどうかと、やるべきかどうかは別の話。

Tauriに移行して得られるもの。

バンドルサイズの削減（ChromiumをバンドルしないでOSのWebViewを使う）
メモリ使用量の削減

Tauriへの移行で失うもの / コスト。

IPCハンドラをすべてRustで書き直す（ファイルI/O、設定管理、ファイル監視、スキャフォールディング）
PTYマネージャをRustで書き直す
Rustの学習コスト（またはAIに頼る）
OS間のWebView差異への対応
今後使いたくなるnpmパッケージへのアクセスを失う

zudo-textは個人ツールなので、バンドルサイズやメモリ使用量はそこまで気にならない。移行コストに見合わないだろうという判断になる。

WebViewはOS間で違う？

Takazudo

WebViewって、macOSだとSafariベースで、WindowsだとEdgeベースってこと？

Claude

その通り。

macOS — WebKit（Safariのエンジン）
Windows — WebView2（Edge / Chromiumベース）
Linux — WebKitGTK

WindowsのWebView2は実質Chromiumベースなので、Electronと近い動作になる。問題はmacOSのWebKit。SafariはChromeと比べて一部のCSSやJS機能のサポートが遅れることがある。

React + CodeMirror + xterm.jsのアプリならおそらく動くだろうが、WebKit固有のレンダリング差異や、ChromiumにはあるのにWebKitにはないAPIにたまに遭遇することになる。ElectronならどのOSでも同じChromiumなので、そういうクロスエンジンのテストが不要。

結論

ElectronからTauriへの移行はしないことにした。

理由を整理するとこうなる。

node-ptyへの依存 — ターミナル機能がある限り、Node.jsが必要。Rustで書き直すことは可能だが、そのためだけにRustを導入するモチベーションが薄い
WebViewのクロスプラットフォーム差異 — Electronなら全OSで同じChromiumが動くのでCSS / JSの挙動が一致する。TauriだとmacOSはWebKit、WindowsはChromiumベースのWebView2、LinuxはWebKitGTKで、レンダリングエンジンがバラバラになる
移行コスト — IPCハンドラ、PTYマネージャ、ファイル監視など、バックエンド処理を全部Rustで書き直す必要がある
バンドルサイズ削減のメリットが薄い

個人的にはWebViewの差異は大きい。ElectronならどのOSでも同じChromiumなので、一度書けばどこでも同じ見た目・同じ挙動になる。取り立てて面倒と思われるのがMacのSafariで、比較的諸々の対応が遅い上に、頻繁にOSをアップデートしない人にとってはなんか知らんが壊れてる風にしか見えない。Electron無難という感想。

ターミナル埋め込みが不要で、Rustに慣れていて、バンドルサイズを気にするようなケースであればTauriは良い選択肢だろう。ただzudo-textの場合はElectronがプラグマティックな選択ということになる。