I've been working with Electron for a while, and one thing that keeps bothering me is how IPC is designed. I mean, it's pretty good if you write a simple "Hello, world!" app, but when you write something more complex with hundreds of IPC calls, it becomes... a real pain.
The problems I bumped into:
1. No single source of truth for the API between renderer and main.
2. Channel names are just strings (easy to break, hard to refactor).
3. No real type safety across process boundaries.
4. I have to manually keep main, preload, and renderer in sync.
5. The errors I can see only at runtime.
I tried to think about a better approach. Something on top of a contract-based model with a single source of truth and code generation.
I wrote my thoughts about how the current design can be improved/fixed (with code examples) here:
The business logic of your app is running in the Main process using Bun runtime. The website you load or the app's frontend is running in a separate sandboxed Renderer process. When I run Electrobun app on macOS, I see that it launches the following processes with the following RAM usage:
- views://mainview (33.7MB) <- your frontend is running here
- react-tailwind-vite-dev Networking (5.4MB)
- react-tail wind-vite-dev Graphics and Media (16.7MB)
A Tauri app built on CEF (Chromium) is very similar to Electron (which also uses Chromium). The key difference is that Tauri uses Rust for the application’s business logic, whereas Electron uses JavaScript.
In this case I don't know why I should use Tauri instead of Electron.