Electron Development

Why desktop applications refuse to die

Every few years the desktop application is declared obsolete, and every year more of them ship. The reasons are consistent: the software needs access to the local filesystem, USB or serial hardware, a scanner or a printer; it must keep working when the network does not; it has to launch at login and sit in the tray; or it runs on a machine where opening a browser tab is simply not how the work happens. Point-of-sale terminals, engineering tools, medical and laboratory software, trading tools and internal operations software all live here.

Electron’s proposition is that you can build that application with the web stack your team already knows, and ship it to Windows, macOS and Linux from one codebase. Visual Studio Code, Slack, Figma’s desktop client and Discord are all built this way, which settles the question of whether it can carry serious software.

What Electron is genuinely good at

• Reusing an existing web frontend — a substantial part of a React or Vue application can move to desktop rather than be rebuilt.
• Native capability through Node.js: filesystem access, child processes, native modules, serial and USB devices.
• Deep OS integration — tray icons, global shortcuts, native menus, notifications, file associations, launch on login.
• Offline-first behaviour, with a local database and synchronisation when connectivity returns.

The trade-offs, stated plainly

Electron ships a Chromium runtime with every application. That means an installer in the region of a hundred megabytes and a memory footprint measured in hundreds of megabytes rather than tens. For most business applications that is irrelevant; on constrained hardware, or for a small utility that should feel weightless, it is disqualifying.

When the footprint genuinely matters and the application surface is modest, Tauri is worth considering — it uses the operating system’s own webview, producing far smaller binaries at the cost of browser inconsistencies between platforms. If the application is mostly native UI with little web content, a native toolkit is the better answer. We would rather have that conversation up front than deliver something that fights its own runtime.

The part that actually consumes the schedule

Writing the application is rarely the hard part. Shipping it is. Code signing on Windows, notarisation on macOS, an auto-update channel that can roll back a bad release, crash reporting from machines you cannot access, and a hardened configuration — context isolation on, node integration off in renderers, a strict content security policy — are what separate a demo from something you can put in front of customers. We treat all of it as part of the build, not as an afterthought, because retrofitting an update mechanism after release is considerably worse than designing one.

The stack we work in

Electron with TypeScript, Vite for the renderer build, electron-builder or Forge for packaging, electron-updater for release channels, SQLite for local storage, Playwright for end-to-end tests against the packaged application, and signed builds produced in CI for all three platforms.

Related reading: cross-platform desktop app development for the wider comparison, and cross-platform app development for the mobile side of the same question.