Electron is a framework for building desktop applications with JavaScript, HTML, and CSS. It packages Chromium for rendering the interface and Node.js for operating-system access, allowing one codebase to run on Windows, macOS, and Linux.
The practical pitch is simple: a web team can build a real desktop app without first becoming a Windows, macOS, and Linux native-development team. The practical cost is also simple: every app ships a substantial browser and runtime with it.
How does Electron work?
Electron follows Chromium's multi-process model. The two processes you meet first are:
- Main process: runs in Node.js, manages the application lifecycle and creates windows.
- Renderer process: displays the HTML, CSS, and JavaScript interface inside a Chromium page.
A preload script can expose a small, deliberate API from the privileged side to the renderer. The renderer then uses inter-process communication, usually called IPC, to ask the main process to perform native work.
For example, a renderer button might call window.desktop.openFile(). A preload script exposes that one method, and the main process validates the request before opening a file dialog. The renderer should not receive Node.js as an all-access backstage pass.
Is Electron just a website in a window?
No. The interface uses web technology, but an Electron application can manage native windows, menus, notifications, clipboard access, files, processes, global shortcuts, and operating-system integrations.
Calling it "just a website" misses the privileged application layer. Treating it exactly like a website can also create serious security problems because a desktop app may access the user's machine in ways a normal browser page cannot.
It looks familiar. It has sharper teeth.
Why do Electron apps use more disk space and memory?
Electron bundles Chromium and Node.js so the application has a consistent rendering and runtime target. That duplication increases the installer and application size compared with frameworks that reuse the operating system webview.
Chromium also uses multiple processes to isolate windows and responsibilities. Those processes have overhead, although actual memory use depends heavily on the application: how many windows it creates, what the frontend renders, which dependencies it loads, and whether work continues in the background.
The tradeoff buys predictability. Developers know which Chromium features their app has instead of adapting to different system webviews. For some products, that consistency is worth considerably more than a smaller download.
Is Electron secure?
Electron can be used safely, but its native powers make ordinary web mistakes more dangerous. Cross-site scripting in a website might alter a page. Cross-site scripting in a poorly configured desktop app can become a path toward local code execution.
Electron's official guidance includes these defaults and practices:
- keep Electron current so Chromium and Node.js security fixes reach users
- leave context isolation enabled
- keep renderer process sandboxing enabled
- do not enable Node.js integration for remote content
- expose narrow methods through
contextBridge, not the entire IPC API - validate the sender and arguments of IPC messages
- restrict navigation, new windows, permissions, and external URLs
- define a restrictive Content Security Policy
Context isolation has been enabled by default since Electron 12, and renderer sandboxing has been enabled by default since Electron 20. Defaults help. They do not validate your IPC handlers while you sleep.
When should you choose Electron?
Electron is a strong candidate when:
- your team is productive in JavaScript or TypeScript
- you need consistent Chromium rendering across desktop platforms
- the product depends on Node.js libraries or mature Electron integrations
- desktop delivery matters more than minimizing installer size
- you want a large ecosystem and many production examples
- your application is complex enough that proven tooling reduces delivery risk
It may be the wrong fit for a tiny utility where download size, idle memory, or native platform feel is the main constraint. It can also be excessive when a Progressive Web App already provides every capability the product needs.
The browser is free. Shipping another browser should earn its rent.
Electron vs Tauri: what is the practical difference?
Electron bundles Chromium and Node.js. Tauri uses the operating system webview and a Rust core.
| Question | Electron | Tauri |
|---|---|---|
| Rendering engine | Bundled Chromium | System webview |
| Native/backend layer | Node.js in the main process | Rust |
| Typical application bundle | Usually larger | Usually smaller |
| Rendering consistency | Consistent Chromium target | Can vary by operating system |
| Team fit | JavaScript/TypeScript teams | Web developers willing to use Rust |
| Native access | Main process, preload scripts, IPC, and Node.js APIs | Commands, plugins, capabilities, and permissions |
Choose Electron when JavaScript continuity, Chromium consistency, and ecosystem maturity matter most. Choose Tauri when a smaller footprint and a narrow Rust-backed native layer are worth the extra toolchain and cross-webview testing.
Read what Tauri is and how it works for a closer look at that architecture.
How do you package an Electron app?
Electron provides the runtime, but a distributable product also needs packaging, installers, code signing, and usually an update strategy. Electron's documentation recommends Electron Forge as a starting point for packaging and publishing.
A sensible learning path is:
- Build one window with local HTML or your frontend framework.
- Add one preload method with
contextBridge. - Handle and validate one IPC request in the main process.
- Package the application with Electron Forge.
- Test the installed build on each supported operating system.
- Add code signing and updates before public distribution.
Do not design a cathedral of IPC abstractions for the first button. One narrow bridge that you can inspect is a better teacher.
What should you learn next?
Learn the process model before collecting plugins. If you understand which code runs in the main process, preload script, and renderer, security guidance becomes concrete instead of ceremonial.
Then study packaging and updates. Desktop users do not receive your fix because the server redeployed; the application vendor must deliver it to them. Electron officially supports its latest three stable releases, so keeping the embedded runtime current is ongoing product work, not spring cleaning.