[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-en-why-electron-is-heavy-tauri-react-native-alternatives":3},{"id":4,"title":5,"author":6,"body":7,"cover":406,"description":407,"draft":408,"extension":409,"locale":410,"meta":411,"navigation":412,"path":413,"publishedAt":414,"seo":415,"seoTitle":416,"slug":417,"stem":418,"tags":419,"__hash__":423},"blog\u002Fen\u002Fblog\u002Fwhy-electron-is-heavy-tauri-react-native-alternatives.md","Why Electron is heavy: Tauri, React Native and the alternatives","Manuel Tardivo",{"type":8,"value":9,"toc":373},"minimark",[10,14,19,22,25,28,41,45,48,51,55,58,63,90,94,115,119,141,152,156,159,163,166,180,184,187,190,193,197,200,204,213,217,220,224,227,231,234,238,241,245,248,252,255,259,262,266,298,302,326,330,333,340,344,347,351,354,357,360,363,367,370],[11,12,13],"p",{},"It all starts with an everyday annoyance: Chrome, Arc and the other Chromium-based browsers eat my RAM and CPU, to the point where they slow down the stuff I actually work with. Safari is much lighter, but for development it is not enough, because it lacks DevTools features that are essential today.",[15,16,18],"h2",{"id":17},"where-the-idea-comes-from","Where the idea comes from",[11,20,21],{},"The first idea was a native browser for macOS, as light as Safari but 100% compatible with Chromium.",[11,23,24],{},"Then I dug in, and it turned out the weight is not in the interface, it is in the engine, Blink and V8. Google optimises it a lot, but for speed and security, not for RAM.",[11,26,27],{},"That is where the question got bigger. The desktop apps we all use every day, Slack, Notion, even the Claude app, are built on Electron, and each one carries a whole Chromium with it. So, three questions:",[29,30,31,35,38],"ul",{},[32,33,34],"li",{},"why Electron is so heavy;",[32,36,37],{},"why Tauri and React Native do better;",[32,39,40],{},"what could be built to change things.",[15,42,44],{"id":43},"electron-is-a-runtime-not-a-compiler","Electron is a runtime, not a compiler",[11,46,47],{},"You cannot \"compile Electron better\". Every app ships a whole Chromium plus Node.js, and the app's code stays JavaScript, HTML and CSS: it needs a web engine to run.",[11,49,50],{},"No compiler can remove Chromium if the code expects Chromium. The weight is not in how the app is built, it is in the engine you bundle with it.",[15,52,54],{"id":53},"tauri-and-react-native-they-look-the-same-but-they-are-not","Tauri and React Native: they look the same, but they are not",[11,56,57],{},"They are two different roads: Tauri uses the web engine already in the system, React Native does not use a web engine at all.",[59,60,62],"h3",{"id":61},"electron","Electron",[29,64,65,72,78,84],{},[32,66,67,71],{},[68,69,70],"strong",{},"Engine:"," Chromium + Node.js inside the app.",[32,73,74,77],{},[68,75,76],{},"Code:"," web.",[32,79,80,83],{},[68,81,82],{},"Size:"," heavy, about 200 MB per app.",[32,85,86,89],{},[68,87,88],{},"The price you pay:"," every app loads its own Chromium.",[59,91,93],{"id":92},"tauri","Tauri",[29,95,96,101,105,110],{},[32,97,98,100],{},[68,99,70],{}," system WebView (WKWebView on Mac), Rust backend.",[32,102,103,77],{},[68,104,76],{},[32,106,107,109],{},[68,108,82],{}," light, 5-10 MB per app.",[32,111,112,114],{},[68,113,88],{}," rendering changes from one OS to the next, and on Mac you inherit Safari's quirks.",[59,116,118],{"id":117},"react-native","React Native",[29,120,121,126,131,136],{},[32,122,123,125],{},[68,124,70],{}," no browser, native AppKit\u002FUIKit components and JavaScript on Hermes.",[32,127,128,130],{},[68,129,76],{}," rewritten with React Native components.",[32,132,133,135],{},[68,134,82],{}," light.",[32,137,138,140],{},[68,139,88],{}," no DOM and no real CSS, the web interface cannot be reused.",[11,142,143,144,151],{},"On a Mac WebKit is already in the system and already in memory, which is why Tauri starts so light. And it is not a hobby thing: Microsoft uses React Native on Mac for parts of Office, with ",[145,146,150],"a",{"href":147,"rel":148},"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Freact-native-macos",[149],"nofollow","react-native-macos",".",[15,153,155],{"id":154},"what-could-actually-be-done","What could actually be done",[11,157,158],{},"The magic compiler does not exist, but two concrete ideas do, and the first one is the most promising.",[59,160,162],{"id":161},"_1-a-translator-from-electron-to-the-system-webview","1. A translator from Electron to the system webview",[11,164,165],{},"It takes an Electron app and swaps Chromium for WKWebView.",[29,167,168,171,174,177],{},[32,169,170],{},"It maps the Electron APIs (windows, IPC, menus, tray) onto the native ones, and Node onto a lightweight backend.",[32,172,173],{},"The frontend often already works in Safari: many Electron apps have a web version that runs fine there.",[32,175,176],{},"The hard parts are the Node APIs and the native modules.",[32,178,179],{},"I could not find a shipped automatic conversion tool: there is only an attempt announced in a VS Code issue (you will find it below).",[59,181,183],{"id":182},"_2-a-shared-chromium","2. A shared Chromium",[11,185,186],{},"Today five Electron apps load five different Chromiums. With a common runtime, like the JRE for Java, the weight would be shared.",[11,188,189],{},"It has been discussed many times, but it never happened, because every app wants its exact Chromium version.",[11,191,192],{},"Between the two, the translator wins: a clear problem, an audience that feels it (developers who hate Electron, which is a lot of people) and less work than a browser.",[15,194,196],{"id":195},"who-has-already-tried","Who has already tried",[11,198,199],{},"There are plenty of lightweight frameworks already, but they are all for new apps. A shipped automatic translator from Electron, as of today, does not exist.",[59,201,203],{"id":202},"electrobun","Electrobun",[11,205,206,207,212],{},"System WebView, main process in TypeScript on Bun, native bridge in Zig. Version 1.0 in February 2026, over 11,000 GitHub stars. A framework for new apps: a simple React app weighs about 64 MB against about 271 MB with Electron (",[145,208,211],{"href":209,"rel":210},"https:\u002F\u002Fbetterstack.com\u002Fcommunity\u002Fguides\u002Fscaling-nodejs\u002Felectrobun-desktop-apps-typescript\u002F",[149],"source",").",[59,214,216],{"id":215},"zero-native","Zero-Native",[11,218,219],{},"Minimal Zig shell on top of WKWebView, optional CEF. Early stage. A framework for new apps, binaries of a few MB.",[59,221,223],{"id":222},"deno-desktop","deno desktop",[11,225,226],{},"Deno runtime with bundled CEF or system WebView. Available, and it plans a CEF runtime shared between apps.",[59,228,230],{"id":229},"electron-tauri-translator","Electron → Tauri translator",[11,232,233],{},"Build-time conversion, zero config. Only announced in a VS Code issue, no release found. It is our idea 1: the space is still empty.",[59,235,237],{"id":236},"webview2-windows","WebView2 (Windows)",[11,239,240],{},"System Chromium, with an optional shared runtime. Available on Windows: the shared runtime already exists, just not on Mac.",[59,242,244],{"id":243},"shared-electron-runtime","Shared Electron runtime",[11,246,247],{},"One Electron for every app. Turned down by Electron's creator: whoever picks Electron cuts development costs, not the costs of the people using the app, and Chrome Apps and Adobe AIR went badly.",[15,249,251],{"id":250},"how-i-would-build-it","How I would build it",[11,253,254],{},"Fine, but what if I had to actually do it tomorrow morning? This is a desk study, not a project in motion: it is here to find the walls before running into them.",[59,256,258],{"id":257},"the-principle","The principle",[11,260,261],{},"Rewrite nothing that already exists. The engine is there (WKWebView), the lightweight shell is there (Electrobun or Tauri), a light JavaScript runtime that speaks almost all of Node is there (Bun). The translator is the glue between the Electron app and these pieces.",[59,263,265],{"id":264},"the-four-pieces","The four pieces",[267,268,269,275,286,292],"ol",{},[32,270,271,274],{},[68,272,273],{},"The X-ray."," It opens the app package (the asar archive), lists every Electron API in use, every Node module and every compiled native module, and tells you before you start what translates on its own, what needs a hand and what cannot be translated.",[32,276,277,280,281,285],{},[68,278,279],{},"The fake Electron."," A library that answers ",[282,283,284],"code",{},"require('electron')"," with the usual shape (BrowserWindow, ipcMain, Menu, Tray, dialog, shell, app), but underneath calls the Mac's native APIs through the lightweight shell. The app thinks it is talking to Electron, and it is talking to the system instead.",[32,287,288,291],{},[68,289,290],{},"The main process on Bun."," The app's Node code runs on Bun, which covers most of Node's APIs. The native modules Bun cannot digest go to a small separate Node process, switched on only when needed.",[32,293,294,297],{},[68,295,296],{},"The bridge in the page."," Preload and contextBridge become scripts injected into WKWebView (WKUserScript), IPC goes through WKScriptMessageHandler and custom protocols through WKURLSchemeHandler. Nothing changes for the frontend.",[59,299,301],{"id":300},"where-you-hit-the-wall","Where you hit the wall",[29,303,304,314,320],{},[32,305,306,309,310,313],{},[68,307,308],{},"Web APIs that only exist in Chromium:"," WebUSB, WebHID, WebSerial, desktopCapturer screen capture, the ",[282,311,312],{},"\u003Cwebview>"," tag. This needs an honest way out: the window that needs them opens with a Chromium (CEF) of its own, and the rest of the app stays light.",[32,315,316,319],{},[68,317,318],{},"A moving target:"," Electron ships a new major version every eight weeks, so the fake Electron has to keep running after it. You start from the APIs the most popular apps really use, not from all of them.",[32,321,322,325],{},[68,323,324],{},"Safari's quirks:"," to catch them you need an automatic screenshot comparison, the same app in Chromium and in WebKit, before calling a translation done.",[59,327,329],{"id":328},"how-i-would-test-it","How I would test it",[11,331,332],{},"One platform, the Mac, and one real open source app to translate. Measure before and after: RAM at launch, RAM after an hour of use, package size. If the numbers do not drop hard, throw it all away with no regrets.",[11,334,335,336,339],{},"If they do, the next step is a single command that takes the app and gives back the translated ",[282,337,338],{},".app",", and only then you open it to other apps and other systems.",[59,341,343],{"id":342},"the-real-problem-is-not-technical","The real problem is not technical",[11,345,346],{},"Whoever picks Electron cuts development costs, not the costs of the people using the app, as the table above shows. So who pays for the translator? The developer, who has to want it, or the person using the app who would like it light? Until you answer that, you have a cool experiment, not a product.",[15,348,350],{"id":349},"we-keep-doing-more-and-optimising-less","We keep doing more and optimising less",[11,352,353],{},"In 1995 Niklaus Wirth, the Pascal guy, wrote that software gets slower faster than hardware gets faster. Thirty years later I have a Mac that does unthinkable things, and it struggles to keep five chats and two browsers open.",[11,355,356],{},"I think the reason is simple: a new feature shows, 150 MB less RAM does not. Nobody goes on stage to say their app is lighter now. Actually, someone did: in 2008 Apple introduced Snow Leopard with a slide that said zero new features, just faster and lighter, and people still remember it.",[11,358,359],{},"With AI writing code non-stop it gets even worse, because adding costs almost nothing, while optimising means understanding what is already there, and understanding takes time.",[11,361,362],{},"The way I see it: it is much faster for me to come up with something new starting from something that already exists and works. The translator is exactly that, not yet another framework on the list, but a way to make light what we all already use every day.",[15,364,366],{"id":365},"so","So?",[11,368,369],{},"The translator is still the most promising idea, but to make sense it has to give more than a manual migration to Electrobun, which already speaks TypeScript. Otherwise anyone who hates Electron is better off rewriting the shell themselves.",[11,371,372],{},"And meanwhile Arc is still open, eating RAM like nothing happened.",{"title":374,"searchDepth":375,"depth":375,"links":376},"",2,[377,378,379,385,389,397,404,405],{"id":17,"depth":375,"text":18},{"id":43,"depth":375,"text":44},{"id":53,"depth":375,"text":54,"children":380},[381,383,384],{"id":61,"depth":382,"text":62},3,{"id":92,"depth":382,"text":93},{"id":117,"depth":382,"text":118},{"id":154,"depth":375,"text":155,"children":386},[387,388],{"id":161,"depth":382,"text":162},{"id":182,"depth":382,"text":183},{"id":195,"depth":375,"text":196,"children":390},[391,392,393,394,395,396],{"id":202,"depth":382,"text":203},{"id":215,"depth":382,"text":216},{"id":222,"depth":382,"text":223},{"id":229,"depth":382,"text":230},{"id":236,"depth":382,"text":237},{"id":243,"depth":382,"text":244},{"id":250,"depth":375,"text":251,"children":398},[399,400,401,402,403],{"id":257,"depth":382,"text":258},{"id":264,"depth":382,"text":265},{"id":300,"depth":382,"text":301},{"id":328,"depth":382,"text":329},{"id":342,"depth":382,"text":343},{"id":349,"depth":375,"text":350},{"id":365,"depth":375,"text":366},"\u002Fblog\u002Fperche-electron-pesa-tauri-react-native-alternative-cover.webp","Chrome eats my RAM, so do Slack and Notion. Why Electron weighs so much, what Tauri and React Native do better, and the idea nobody has shipped yet.",false,"md","en",{},true,"\u002Fen\u002Fblog\u002Fwhy-electron-is-heavy-tauri-react-native-alternatives","2026-10-17",{"title":5,"description":407},"Why Electron is heavy: Tauri, React Native, alternatives","why-electron-is-heavy-tauri-react-native-alternatives","en\u002Fblog\u002Fwhy-electron-is-heavy-tauri-react-native-alternatives",[61,92,420,421,422],"react native","desktop apps","performance","WOHoWzqeWs1-uDgogss6ijXvJgiEBzjl6KGexNN3eKU"]