Windows, macOS and Linux from one codebase, for internal tools and utilities where reach and development speed matter more than a few megabytes.
It has a real cost in size and memory. It's worth it when the alternative is three separate applications.
The same application on Windows, macOS and Linux, which is hard to match any other way.
Your existing front-end developers can build and maintain it without learning three native toolkits.
File system, local processes, hardware and system tray, which a browser tab can't reach.
Signed automatic updates, so users aren't left on a version from two years ago.
Software that has to reach the file system, a local device or a serial port, which a browser isn't allowed to do.
The same interface with the things only a desktop app can offer: local files, offline use, notifications, launching at login.
Flashing firmware, provisioning devices, reading logs over USB. Unglamorous software that has to exist and rarely justifies three native builds.
Windows, macOS and Linux from one codebase, which for an internal tool is usually the entire argument.
Written for someone deciding, not for someone who already knows. Skip it if you do.
A way to ship a web application as a desktop program. It bundles a browser engine and a Node runtime, so your interface is HTML and CSS while your code can touch the file system, devices and the network like any native application. VS Code, Slack and Discord are built this way.
One codebase for three operating systems, built by people who already know the web. For a tool used by a hundred people inside a company, the alternative is three native applications and there's rarely a budget for that.
Electron apps are large and use more memory than native ones, because each ships its own browser. That's real. It matters for a small utility running all day and matters much less for a tool someone opens to do a job. What isn't fair is the claim that they must feel slow: most that do are badly built rather than badly hosted.
Security. An Electron app that gives its web layer full access to the operating system is a serious hole, and plenty do. Context isolation on, node integration off, and a narrow bridge between the two isn't optional, and it's the first thing we check in an inherited one.
It means any script that reaches your interface can reach the file system. The fix is well understood and worth doing immediately.
It embeds a browser, so an old Electron is an old browser with its known vulnerabilities, shipped to every desktop.
Sometimes justified. Often it's a decision nobody revisited.
It uses more memory and disk than a native app, which is a genuine trade. For internal tools and utilities that cost is usually far smaller than building and maintaining three native applications.
Yes. Electron applications run locally and can store data on the machine, syncing when a connection returns.
Yes, for Windows and macOS including notarisation. Unsigned desktop applications are increasingly blocked outright, so this isn't optional.
Not if it's built properly. What people notice is a slow start and a heavy install, both of which have a lot of room for improvement in most existing apps.
Possibly. It's much smaller because it uses the operating system's own browser engine, at the cost of that engine differing between platforms. For a simple tool it's a good trade; for something complex the consistency of Electron is usually worth the size.
A few lines are enough to start. You get a reply within two working days.
