Electron is worst development platform...

#javascript #typescript #electron #tauri

...for desktop apps

You know that feeling when you open Slack on a fresh laptop and your fans spin up before you even read the first message? Or when Discord eats 800 MB of RAM to display a list of usernames? Or when your perfectly capable 2019 MacBook suddenly feels like a toaster from the early 2000s the moment Spotify launches?

Yeah. That's Electron.

For me it was a moment when I was running an RPG session as GM, and for the love of me I couldn't boot up Spotify to play background music.

I'll save you the suspense: I don't think Electron should exist in its current form. It's a hack that escaped the lab and conquered the desktop, and most of us are paying for it in RAM, battery life, and the slow death of laptops that should still have years left in them. Let me explain why.

How Electron actually works

If you've never peeked under the hood, the architecture is almost insulting in its simplicity. Every Electron app is, literally, a copy of Chromium plus a copy of Node.js bundled together and shipped as a single executable. Your "desktop app" is a browser tab. That's it. That's the whole trick.

The main process runs Node.js and owns the window lifecycle, file system access, and native OS integration. The renderer process runs Chromium and displays whatever HTML/CSS/JS you wrote. They talk to each other through IPC. If you've ever built a web app, you already know 90% of Electron.

// main.js — this is basically the whole "desktop" part
const { app, BrowserWindow } = require('electron');

app.whenReady().then(() => {
  const win = new BrowserWindow({ width: 800, height: 600 });
  win.loadFile('index.html');
});

And that's the appeal. You ship your existing React/Vue/Angular app, slap Electron on top, and you have a "native" desktop application on Windows, macOS, and Linux. No native code, no platform-specific knowledge, no learning curve. Your frontend dev can now do desktop.

This is exactly the problem.

Why Node.js is a performance disaster for this job

Let's be honest about Node.js for a second. Node is great for what it was built for: I/O-heavy servers where you spend most of your time waiting on network or disk. The single-threaded event loop is a strength when the work is "shuffle bytes between sockets."

It is not great as the runtime for a long-running desktop application that holds state, responds to UI events, and is expected to feel snappy on a five-year-old laptop with 8 GB of RAM.

Node carries V8 with it, which means every Electron app ships its own JavaScript engine with JIT compilation, garbage collection, and all the memory overhead that comes with running a language designed for short-lived web pages as the backbone of a long-lived desktop process. GC pauses that nobody notices in a request-response server become visible stutter when they happen mid-scroll. And because the main process is single-threaded, anything CPU-heavy you do blocks the entire app unless you carefully shuffle work to worker threads — which most apps don't bother with.

Now multiply that by Chromium. Electron isn't just shipping Node. It's shipping a full browser engine — V8 (again, separately for the renderer), Blink, Skia, the whole networking stack, the whole accessibility tree, the whole rendering pipeline that was built to handle arbitrary untrusted web pages. You don't need most of it. You're shipping it anyway. Every. Single. App.

I can already hear voices: "but modern computers have 32 GB of RAM, who cares about 300 MB for an app?" Sure. Until you have Slack, Discord, VS Code, Spotify, Notion, and your password manager all open at once. Suddenly you've burned 2 GB on six apps that, combined, do less than a single instance of Firefox. And god help you if you're on a 2018 laptop with 8 GB.

Case in point: Spotify, Discord, and your old ThinkPad

Pick literally any popular Electron app and benchmark it. The numbers are embarrassing.

Electron apps idle at 200 to 300 MB, while Tauri sits closer to 30 to 40 MB. That's an order of magnitude. Electron packages include a full browser, which pushes installers above 100 MB. Tauri apps are usually under 10 MB. On a typical MacBook or Windows laptop, Tauri apps launched in under half a second, while Electron builds usually took between one and two seconds to load.

These aren't synthetic micro-benchmarks. These are the actual numbers people get when they ship the same app twice. And the gap gets worse, not better, the longer the app runs — because Electron apps tend to leak. Slack famously had to publish blog posts explaining why their app uses so much memory. Discord regularly trends on r/programming for the same reason. Spotify's desktop client is, no exaggeration, slower and heavier than just opening Spotify in a browser tab.

The point is not that any single app is uniquely bad. The point is that the entire category is bad, and we've all just accepted it. We've collectively decided that "the app takes 800 MB and 8 seconds to launch" is a reasonable cost for "the frontend dev didn't have to learn anything new." That trade-off only looks fair if you don't count the cost imposed on every single user.

"But Python apps are slow too" — and that's exactly my point

The most common defense I hear when I bring this up is some flavor of: "JavaScript isn't really the problem, interpreted languages are just slow, look at Python apps." This is supposed to be a gotcha. It is the opposite of a gotcha.

Python is famously not built for speed. The GIL is a real limitation. And yet — a typical PyQt or Tkinter application starts faster, uses less memory, and is more responsive than a comparable Electron app. Calibre, the e-book manager written in Python with Qt, runs comfortably on hardware that struggles to launch Slack. Anki, also Python + Qt, is responsive on a Raspberry Pi. These are not toy apps.

Why? Because they're not shipping a browser. They're not running two JavaScript engines side by side. They're not maintaining a DOM, a CSSOM, a render tree, a layout tree, and a paint pipeline just to draw a button. They call into native widget toolkits that the operating system has been optimizing for thirty years.

If your "modern JavaScript framework with V8 JIT" loses on performance to interpreted Python with a C++ widget library, the problem is not "interpreted languages are slow." The problem is that you bundled an entire browser to render a sidebar.

The better alternative: Tauri

Tauri solves the actual problem instead of pretending the problem doesn't exist. The pitch is simple: keep the web frontend (use whatever you want — React, Vue, Svelte, vanilla HTML), but throw away the bundled Chromium and Node, and replace them with the system's native webview plus a Rust backend.

The system webview matters more than people realize. On Windows that's WebView2 (Chromium-based, kept up to date by Microsoft). On macOS that's WKWebView (Safari/WebKit). On Linux it's WebKitGTK. The user already has these installed. You don't ship them. Your app gets smaller by an order of magnitude immediately.

The Rust backend matters too — but maybe not for the reason you'd expect. Yes, Rust is fast. Yes, it's memory-safe. But the bigger win is that Rust forces you to think about what your app actually needs to do on the system side. Every file read, every network call, every clipboard access has to be explicitly exposed as a command from Rust to the frontend. Compare that to Electron, where the renderer process can require('fs') and read your entire disk if you forgot to disable nodeIntegration (which, historically, a lot of apps did forget).

// Rust side — explicit, typed, opt-in
#[tauri::command]
fn read_config() -> Result<String, String> {
    std::fs::read_to_string("config.json")
        .map_err(|e| e.to_string())
}

// Frontend side — just call it
import { invoke } from '@tauri-apps/api/core';

const config = await invoke<string>('read_config');

That's it. No IPC boilerplate. No bridge files. No contextBridge.exposeInMainWorld ceremony.

The numbers back it up: Tauri 2.0 produces 12 MB average bundles vs 180 MB for Electron 30.0 in identical apps. App size: Tauri installers stayed in the single-digit MB range. Memory use: Tauri consumed an order of magnitude less memory at idle. And since the 2.0 release, you also get mobile targets (iOS and Android) for free from the same codebase, which Electron simply cannot offer.

Is Tauri perfect? No. Rust compile times will test your patience. The ecosystem is smaller than Electron's. Cross-platform webview inconsistencies are real — what works in WebView2 might render slightly differently in WKWebView, and you'll occasionally curse Safari for being Safari. But none of these problems are remotely as bad as shipping 200 MB of duplicated browser engines to every user.

And if Tauri isn't your thing — other alternatives worth knowing

Tauri is my recommendation, but it's not the only way out. Here's the honest landscape in 2026:

Flutter Desktop — Google's Dart-based toolkit, now stable on Windows, macOS, and Linux. Flutter Desktop keeps performance close to raw C++ levels while reusing up to 95 percent of mobile code. Best pick if you're already invested in Flutter for mobile and want one codebase across all platforms. Downside: it draws everything itself, so your app won't feel 100% native — but it'll be smooth.
Wails — basically Tauri but with Go instead of Rust on the backend. Same architecture (system webview + compiled backend, no Chromium), gentler learning curve if Rust scares you, smaller community.
.NET MAUI — Microsoft's evolution of Xamarin. C# and XAML, native widgets on each platform, first-class on Windows obviously, decent on macOS, Linux is community-supported. The right pick if you're in a Microsoft shop or your team already knows C#.
Qt (with QML or Widgets) — the grandfather. C++ or Python (PyQt/PySide) bindings, used by KDE, Telegram desktop, Wireshark, OBS Studio. Steeper licensing situation (LGPL vs commercial), but the most battle-tested option on this list by a wide margin.
Slint — a newer Rust-first GUI toolkit with its own declarative markup language, targeting both desktop and embedded. Worth watching if you want native-feeling UI without a webview at all.
Neutralinojs — if you really, really must use JavaScript and don't want to learn anything new: Neutralino is like Electron, but uses the system's browser instead of bundling Chromium. Smaller, lighter, still JS all the way down. The "harm reduction" option.
Native + SwiftUI / WinUI 3 / GTK — if you're targeting one platform seriously and the others as afterthoughts, native is still unbeatable. Cross-platform isn't free; sometimes the right call is "build the macOS app properly and let Windows users use the web version."

Conclusion

Electron isn't going away tomorrow. Slack, VS Code, Discord, and a hundred other apps are too entrenched to rewrite, and for them the calculation already happened — they bet on Electron, the bet shipped, and now they live with the cost. Fair enough.

But if you're starting a new desktop app in 2026 and reaching for Electron because "the team knows React"? You're making the same mistake the entire industry made ten years ago, when the cost of that decision wasn't fully visible yet. It is now. We've had a decade of users complaining about RAM usage, fan noise, battery drain, and slow startup. The receipts are in.

Here's what I'd actually do:

Tauri if you have a web frontend already and don't mind Rust on the edges. This is the default.
Wails if Rust is a hard no and Go is fine.
Flutter Desktop if you're going mobile and desktop from one codebase.
.NET MAUI if your team lives in the Microsoft ecosystem.
Qt if you need rock-solid maturity and complex UI.
Native if you really only need one platform.
Electron if you're maintaining an existing Electron app and a rewrite isn't on the table. That's it. That's the only good reason left.

*"Hey, but why not React Native?" *
Because "F*CK REACT" - that's why.

Your users' laptops will thank you. Their batteries will thank you. And in five years, when their hardware is still capable of running your app smoothly, they won't even know to thank you — which is exactly how good engineering should feel.