Almost every "Electron vs PWA" article ends up at the same tidy verdict: PWAs are lightweight, Electron is heavy, choose accordingly. It's true enough to be useless. If you've actually shipped either one, you know the decision is never about a bundle-size number. It's about which set of long-term trade-offs you're willing to own for the next few years — runtime control, security maintenance, hardware access, distribution, and the quiet platform politics that decide what your code can do on someone else's device.
So let's skip the table you've already seen and talk about the parts that actually bite. I'll assume you know HTML, CSS, and JavaScript, that you've heard of service workers and BrowserWindow, and that you want to make a real architectural call rather than win an internet argument.
The one mental model worth keeping
Both Electron and PWAs are the web platform wearing different clothes. The difference is who owns the runtime and how the app reaches the user.
- A PWA is your web app, enhanced with a service worker and a web app manifest, installed straight from the browser. It runs inside whatever engine the user already has — Chromium on most desktops and Android, WebKit on every iPhone. You ship a URL; the platform supplies the runtime.
- An Electron app is your web app plus its own private copy of Chromium and Node.js, packaged into a desktop binary you sign and distribute yourself. You ship the runtime too. Picture a spectrum of trust and capability. On the left, the "drive-by web" — maximum reach, minimum privilege. In the middle, installed PWAs — a bit more trust, a bit deeper OS integration. On the right, Electron — full Node.js, the local filesystem, native modules, the works, at the cost of reach and weight. Most of the real decision is just figuring out how far right on that spectrum your app genuinely needs to sit. Everything below is detail in service of that one question.
The dimensions that actually decide it
1. Who controls the runtime — and who pays for it
This is the single most underrated factor, and it cuts both ways.
Electron pins Chromium. Every user runs the exact engine version you bundled. That's a gift: no "works in Chrome, breaks in Safari," no feature-detection roulette, no waiting for a vendor to ship the API you need. You test against one engine and ship it to all three desktop OSes. For complex apps with heavy canvas, WebGL, audio, or custom rendering, that determinism is worth a lot.
The bill comes later. Pinning Chromium means you are now responsible for shipping its security patches. Electron releases a new major every 8 weeks tracking Chromium, and only the latest three majors get fixes — so a supported version ages out in roughly half a year. Fall four versions behind and you're shipping a browser engine with publicly documented CVEs baked into your installer. The practical consequence: budget a recurring Electron-upgrade sprint, not a "we'll get to it" ticket. Teams that treat the upgrade as optional discover the hard way that their desktop app has quietly become the least-patched browser on the user's machine.
A PWA flips this completely. You never ship an engine, so you never ship an engine CVE — the browser vendor patches it overnight and your users get it for free. The cost is the mirror image: you now inherit engine fragmentation, and you don't get to choose. Your offline logic has to survive Chrome's behavior and Safari's, and on iOS "Safari" means WebKit no matter what browser icon the user tapped (more on that below). You trade a maintenance treadmill for a compatibility matrix.
The honest framing: Electron lets you control the runtime and bill yourself for the privilege. A PWA hands runtime control to the browser vendor — which is liberating right up until the vendor's roadmap and yours disagree.
2. The maintenance cost most comparisons omit entirely
Two Electron-specific tax bills rarely make it into comparison articles, and both have ruined release days:
The Node ABI rebuild treadmill. Every Electron major bump can change the Node ABI, which means every native module you depend on — a SQLite binding, a keychain integration, a PTY for a terminal, an image processor — has to be recompiled against the new ABI. Miss one and you ship a binary that crashes on launch, on the user's machine, where you can't see it. The fix is process discipline (automate rebuilds in CI, gate releases on them), but it's ongoing work that a PWA simply never has.
Memory you have to actively manage. Each BrowserWindow is a full renderer process; forget to destroy one and you'll watch RAM creep upward over a long session. An empty Electron shell already sits around 150–200 MB resident; a real production app with a modern UI lands in the 300–500 MB range; a large workspace in something like a code editor can sail past a gigabyte. None of this is disqualifying — it's the price of carrying your own Chromium — but it means soak-testing a long-running session belongs on your release checklist. A PWA borrows the browser's already-running process and inherits its memory management for free.
A PWA's equivalent "maintenance" is mostly your service-worker caching strategy and remembering that a stale service worker is the most common reason "I deployed but users see the old version." Real, but an order of magnitude cheaper than an engine-upgrade program.
3. Hardware and deep APIs: how far can the web actually reach now?
The "PWAs can't talk to hardware" cliché is years out of date on the right platform. Through Project Fugu — the cross-vendor effort (Google, Microsoft, Intel, Samsung) to close the web's capability gaps — a PWA in a Chromium browser can today do things that used to be Electron's whole reason to exist:
- Web Serial, WebHID, WebUSB — talk to microcontrollers, configure keyboards, drive lab instruments and point-of-sale peripherals straight from a web app. (A real one: keyboard-configurator PWAs flash firmware over WebHID; firmware tools talk to dev boards over WebUSB.)
- File System Access API — open a real file with a real handle, edit it, and save back to the same file on disk, the way a desktop editor does.
-
File Handling — register your installed PWA as the OS handler for a file type, so double-clicking a
.fooopens your app. - Plus the Async Clipboard, Web Share / Share Target, Badging, Screen Wake Lock, and Background Sync APIs that make an installed PWA feel native. Here's the catch the showcase pages gloss over: almost all of this is Chromium-only, by design and by politics. The full File System Access API with genuine local handles is Chromium-only; Safari and Firefox expose only the sandboxed Origin Private File System (OPFS) — great for an app's own private database, useless for "let the user edit their Documents folder." And the powerful hardware APIs (Bluetooth, NFC, USB, Serial, MIDI, several sensors) are on a list Apple publicly declined to implement back in 2020, citing fingerprinting and privacy — a position that hasn't moved in 2026.
So the rule of thumb is sharper than "PWAs can't do hardware":
- Need deep hardware/filesystem access and your users are on Chromium desktop/Android? A PWA can very likely do it now.
- Need it with iPhone users in the room? The web can't reach there, and an Electron desktop app (or a native iOS app) is your honest answer.
- Need it guaranteed across every browser, forever? Electron, because you ship the only engine that matters — yours.
4. The iOS reality check (this is where dreams go to die)
If your audience includes iPhones, read this section twice, because it's the part that quietly invalidates half of the "just build a PWA" advice online.
Every browser on iOS is WebKit underneath — Chrome, Firefox, Edge, all of them. Apple's BrowserEngineKit technically allows alternative engines in the EU since iOS 17.4/18.2, but as of early 2026 no browser has actually shipped one, so in practice there's no competitive pressure and Apple alone sets the PWA roadmap. That roadmap has genuinely improved:
- iOS 16.4 (2023) brought Web Push — but only to PWAs the user has explicitly added to the Home Screen, never to a normal Safari tab.
- Safari 18.4 added Declarative Web Push and the Screen Wake Lock API.
iOS 26 made Home-Screen-added sites default to standalone web-app behavior, smoothing a long-standing rough edge.
And yet the gotchas that wreck offline-first assumptions are still here, and you will not find them in most comparisons:The disappearing push subscription. On iOS, push subscriptions for installed PWAs have a long history of going silently dead after a week or two of inactivity — the endpoint stops delivering and the user effectively has to re-subscribe. If push re-engagement is core to your product, treat iOS push as best-effort, not load-bearing.
The 7-day storage eviction. iOS will evict a site's storage (including cached assets behind your service worker) after about a week of non-use. "Offline-first" on iOS means "offline-first until the user ignores us for a week." Test the cold-start-after-inactivity path explicitly; a desktop Electron app never faces this.
No automatic install prompt. Android Chrome can surface an install banner; iOS makes the user find Share → Add to Home Screen by hand, and it silently fails inside in-app browsers (the Instagram/Facebook web view). Your activation funnel pays for this.
The DMA whiplash, for the record. In early 2024 Apple briefly stripped Home-Screen web apps for EU users under a DMA-compliance rationale, then reversed within weeks after developer and regulatory pushback. The lesson isn't the outcome — it's that on iOS, your PWA's core capabilities exist at one vendor's discretion and can shift with the regulatory weather. Plan with that fragility in mind.
None of this makes iOS PWAs a bad idea — for content, commerce, and dashboards they're often the right call. It makes "build one PWA, reach everyone equally" a myth. You'll build one codebase and accept that the iOS edition is a capability-reduced edition.
5. Distribution, updates, and footprint
This is where the day-to-day economics live.
Getting it onto the machine. A PWA installs from a URL in two taps, with zero store review, zero 15–30% platform commission, and instant global availability. That's a real business advantage — and the flip side is real too: no store listing means no store discoverability, no store trust signals, and no store ratings doing your credibility work for you. Electron ships installers you distribute yourself (or through the Microsoft Store, or — with effort and entitlements — the Mac App Store), which buys you presence and enterprise-friendly packaging at the cost of review, signing, and bytes.
Updates. A PWA updates the instant you deploy; the service worker fetches the new assets and your only real job is a sane cache-busting strategy so users don't get stranded on yesterday's build. Electron updates are infrastructure you build: an update server or feed, code-signed artifacts, a framework like Squirrel/electron-updater, and a tested rollback story. It works well once wired up, but "ship a fix in 30 seconds" is a PWA superpower that's easy to undervalue until you're hotfixing a production bug.
Code signing is its own project. This rarely appears in comparisons and routinely surprises first-time desktop shippers: macOS wants notarization (and the Gatekeeper dance), Windows SmartScreen punishes unsigned or low-reputation binaries until you've built trust (often via an EV certificate). Budget real calendar time for it. A PWA needs only HTTPS, which you already have.
Footprint. A typical Electron installer is ~150–200 MB before your own assets, because Chromium + Node + V8 + ffmpeg travel with every copy. A PWA adds essentially nothing beyond the page the user already loaded. If you're distributing to bandwidth- or storage-constrained users, this isn't a footnote.
6. The middle path most articles haven't caught up to: Isolated Web Apps
Here's the genuinely fresh part of the 2026 landscape, and the one that earns its place in a "what's changed" discussion.
Isolated Web Apps (IWAs) are Chromium's attempt to give web tech an Electron-grade trust model without the Electron runtime. Instead of being served live over HTTPS, an IWA is packaged into a Signed Web Bundle (.swbn), signed with a developer key kept offline, and served from a dedicated isolated-app:// scheme. Its identity is the public key, not a domain — so a hijacked DNS record or compromised CDN can't impersonate it, and it can be installed and verified entirely offline.
That stronger guarantee unlocks APIs the open web can't safely offer — most notably Direct Sockets (raw TCP/UDP), which lets a web app do things like speak to legacy hardware protocols or act as a local network client, territory that historically forced you into Electron or native.
Why it matters for this comparison, and the caveats that keep it honest:
- It's a real "third option" for the enterprise/kiosk/managed-device case: ship a signed, versioned, web-tech app that an admin force-installs via policy, with deeper capabilities than a normal PWA — and none of Electron's bundled-Chromium weight or CVE-maintenance burden.
- But it's Chromium desktop / ChromeOS only. There's no IWA support on Android, and Apple and Mozilla have publicly signalled disinterest, so it is not a cross-platform answer. It's a powerful tool for the "we control the fleet" scenario, not a way to reach the open internet.
- You also give up two things people love about PWAs: ephemerality and seamless server-side updates. You're back to building and signing versioned bundles — closer to a desktop release process than a
git push. Think of IWAs as the option to reach for when you'd otherwise choose Electron purely for capabilities and trust, your users are on managed Chromium/ChromeOS, and you'd rather not babysit a bundled browser.
Five real decision cases (not "it depends")
Comparison tables are abstract. Here's how the trade-offs resolve in concrete situations I'd actually stand behind.
Case A — A team dashboard / internal tool, users on modern browsers.
Ship a PWA. Installable, instant updates, zero distribution friction, and Fugu APIs cover almost anything you'll want. Reaching for Electron here is paying a Chromium-maintenance tax to solve problems you don't have.
Case B — A hardware-configuration utility (flash a device, read a sensor, drive a peripheral).
If your users are on Chromium desktop/Android, build it as a PWA on WebHID/WebSerial/WebUSB — it'll genuinely work and install from a link. The moment iPhone support becomes a requirement, that path dead-ends at WebKit, and your honest options become Electron (desktop) or native (mobile). Don't promise iOS hardware access you can't deliver.
Case C — A pro creative/coding app with heavy custom rendering and native libraries.
Electron. You want a pinned engine so your WebGL/canvas/audio behaves identically everywhere, and you likely depend on native modules and full filesystem access. Accept the footprint and the upgrade sprints as the cost of determinism.
Case D — A consumer app where iPhone re-engagement via push is the growth engine.
Be very careful with a PWA-only plan. iOS push only works for Home-Screen-installed PWAs, the install flow is manual and easy to lose users in, and subscriptions can decay after inactivity. A PWA can be a fine secondary surface, but if push-driven retention is the business model, a native iOS app (or a hybrid wrapper) is the safer bet, with the PWA serving Android and desktop.
Case E — Locked-down enterprise / kiosk fleet on managed Chromebooks needing raw socket or device access.
This is the new IWA sweet spot. A signed, admin-force-installed Isolated Web App gives you near-native capability (including Direct Sockets) on a controlled platform, without shipping or maintaining a private Chromium the way Electron would. Just don't mistake it for a path to the open web.
A decision framework you can actually use
Walk these in order and stop at the first decisive answer:
- Are iPhones a first-class target with push or hardware needs? If yes, the web alone won't cover it — plan for native or a wrapper, with a PWA as the broad-reach companion.
- Do you need raw sockets, native modules, or a guaranteed-identical engine across all desktops? If yes, Electron — or an IWA if your fleet is managed Chromium/ChromeOS and you'd rather skip the bundled-browser maintenance.
- Do your capability needs fit within Fugu APIs on Chromium/Android, and is broad, frictionless reach valuable? If yes, PWA. You get instant updates, tiny footprint, no store cut, and no engine-CVE program.
- Still torn? Default to a PWA and treat Electron as the thing you graduate into when a concrete capability or distribution requirement forces it. It's far cheaper to outgrow a PWA than to discover you've been carrying Electron's weight for capabilities you never used. And a pragmatic note that resolves a lot of "either/or" anxiety: these aren't mutually exclusive. A clean web codebase can ship as a PWA and be wrapped in Electron for the desktop edition that needs more, with most of your UI and logic shared. You're often choosing a primary delivery vehicle, not marrying one forever.
The takeaway
The real question was never "which is lighter." It's which trade-offs do you want to own. Electron buys you a controlled, capable runtime and hands you the bill for maintaining it — security upgrades, native rebuilds, signing, footprint. A PWA buys you reach, instant updates, and near-zero distribution friction, and hands you the platform's constraints in return — engine fragmentation and, on iOS, a capability ceiling you don't control. Isolated Web Apps are the emerging middle for managed Chromium fleets that want Electron-grade power without the Electron-grade upkeep.
Pick the trade-off you can live with for years, not the bundle size you can live with today. That's the decision — everything else is implementation.
Top comments (0)