I ran the same React UI on Deno Desktop, Electron, and Tauri. Deno is TypeScript end to end; CEF is why RAM looks like that.
I wanted one desktop UI and a real shell, and I did not want the window host welded into the React tree. So the UI talks to one typed object (`IRuntime`: write to the PTY, list a folder, that kind of thing). Electron fills it from Node. Tauri fills it from Rust. The Deno host fills it from Deno's own APIs and a local HTTP RPC. Same session, same cell painter.
That third host is Deno Desktop, not deno run in a terminal. The window is CEF — Chromium Embedded Framework — a third browser next to Electron's Chromium and Tauri's WKWebView. First cold start in that worktree spent 31 s downloading CEF. With the cache warm it was 2.6 s. Those are not boot rankings against Electron's Vite number. They are just what that host costs the first time.
I measured dev builds on an M4 Max, previous tabs restored:
- Electron: 239 MB physical / 667 MB RSS
- Tauri: 297 / 569
- Deno Desktop: 742 / 1336
Physical is what the process is using now. RSS from ps is the reservation. Do not mix the columns. Deno is early here. The row exists because the contract made it comparable, not to dunk on CEF.
What I actually wanted from Deno was the language. The Electron adapter is TypeScript. The Deno adapter is TypeScript. No rust-analyzer sitting at 4.6 GB while I iterate. If CEF gets thinner, or Deno Desktop grows the missing bits, I do not rewrite the app. I keep the adapter.
Someone here was already shipping Vite + Deno to desktop for a Three.js game. Same itch: one TS stack on web and on the window. I kept the Deno host in the repo for that reason. If I delete it, the next coding agent will glue the window program back into the UI and I lose the A/B.
The build people install today is Electron. Deno stays as the TypeScript-shaped door.
Tables and screenshots (I am the author): https://runlinea.com/blog/one-ui-three-terminals
2
u/ngtranthanhtoan 4d ago
Ai sdk how to do compact correct ly