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.
My understanding is that the tauri CEF will use shared libraries where-as every Electron instance has its own copy of Chrome.
That's the whole point of my post: we get a relatively up to date Chrome and we get a shared library that all Tauri apps can share! Hence why I discussed why running n+1 apps should have lower overhead.
So it seems much much much better than Electron to me. Electron values the app developer, wants to give them assurances that the chromium is the exact specified chromium version, and bundles it. I get it, the world is complex and clamping down is a natural response, but this conservatism has given Electron its deservedly bad reputation, and Tauri's slightly shifted stance alleviates so much pain.
You could have just write the performance critical part of your Electron app using C++ and native node module and achieve the same performance improvements. You actually did it, but using Rust instead of C++.
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:
https://teamdev.com/mobrowser/blog/what-is-wrong-with-electr...
How do you deal with this in your project?
Do you just live with it or maybe you built something better on top of existing Electron IPC implementation?