MyGo vs Electron: What a Go WebView Desktop App Actually Weighs (2026)

A new Go framework called MyGo hit GitHub trending in October 2026 and crossed 4.8k stars within weeks. Its pitch is blunt: desktop apps without shipping Chromium. Each MyGo window either shows a web page in the WebView your OS already has, or draws its own GPU-rendered UI with no web engine at all. Either way, the README claims "an app is a single Go binary of a few megabytes, focused on low memory and CPU use" — against a typical Electron installer in the 100–300 MB range, per Electron maintainer Felix Rieseberg. That gap sounds like free money. Before you rewrite anything, it's worth being precise about what "smaller" actually buys you, and what Electron is still charging you for that a system WebView can't repay.

TL;DR

• MyGo builds desktop apps in pure Go with no cgo. A window shows a web page in the system WebView (WKWebView, WebView2, WebKitGTK) or a "native UI" written in Go that MyGo draws itself on the GPU (Metal, Direct3D 11, OpenGL).
• Distribution shape: one Go binary with the frontend embedded, packaged into a .app/dmg, an NSIS installer, or a .deb. The size is vendor-claimed at "a few megabytes" per app; Electron's typical unpacked size is reported at 100–300 MB by an Electron maintainer. That's roughly a 30–100x reducer on raw download weight.
• The system WebView means no bundled Chromium — but also no bundled Chromium. You inherit whatever engine each OS ships, and their features and quirks differ.
• MyGo's own performance page publishes measured steady-frame costs for its native UI toolkit (397 µs/frame for 1,000 static labels on an Apple M5) and explicitly says these are not cross-framework comparisons. Treat "lighter" as a design property, not a benchmark guarantee.
• Ecosystem maturity is the real trade: Electron is 12+ years old with thousands of contributors; MyGo is weeks old at ~0.7.x, effectively one maintainer, MIT, 1,125 commits.
• Keep Electron for apps that depend on Chromium-specific behavior, Node native modules, or a battle-tested updater story. Consider MyGo for small utilities, launchers, tray tools, and greenfield apps where a 5–10 MB download and a Go backend fit your stack.

What MyGo actually ships

MyGo is not a thin Electron clone. It has two UI modes, and one app can mix them:

1. Web frontend. You write HTML/CSS/JS with any tooling (the template uses Vite + Bun) and it runs in the OS's own WebView: WKWebView on macOS, WebView2 on Windows, WebKitGTK on Linux. Go methods that you register with mygo.Bind get a generated TypeScript client, so calls from JS are typed with Go's types and errors surface as rejections.
2. Native UI. You write the UI in Go with the ui package — flexbox/grid layout, widgets, text input with IME support, virtualized lists, shaders. MyGo renders it on the GPU with Metal on macOS, Direct3D 11 on Windows, and OpenGL on Linux. No webview starts at all, which is why the docs pitch it as "the window opens at once and takes little memory."

The web-mode hello world is small enough to judge at a glance:

type Greeter struct{}

// Greet returns a greeting.
func (Greeter) Greet(name string) string { return "Hello, " + name }

func main() {
	mygo.Bind(Greeter{})
	mygo.App.WhenReady(func() {
		mygo.NewWindow(mygo.WindowOptions{Title: "Hello", URL: "/"})
	})
	if err := mygo.App.Run(); err != nil {
		log.Fatal(err)
	}
}

The generated TypeScript side is a typed async call:

import { Greeter } from "./mygo"; // generated

document.body.textContent = await Greeter.greet("Ada");

Because it's pure Go with no cgo (CGO_ENABLED=0 is the build default), any machine cross-compiles for every platform:

bun run build -- -platform darwin/universal,windows/amd64,linux/amd64

The weight: what each installation actually puts on disk

This is the headline number, so check the sourcing on both sides:

• MyGo: the README and docs describe the result as "a single Go binary of a few megabytes" — a vendor claim, not a third-party benchmark. The build system embeds the Vite-built frontend into the executable, so the binary scales with your static assets the same way Electron's app.asar does. There are no distributed numbers per app in the docs I could verify; treat "few megabytes" as the transport cost of the framework itself plus your built frontend.
• Electron: Felix Rieseberg — an Electron maintainer — puts most Electron apps at "around 100 to 300 MB" unpacked. That cost is structural: every Electron install bundles Chromium and Node.js, because the framework vendors the engine to guarantee identical rendering everywhere. You can't shrink it below roughly the size of the Chrome runtime you're shipping.

So the honest framing is: a system-WebView Go app eliminates the single largest line item in an Electron installer — a complete browser runtime — and replaces it with a Go binary plus a dependency on whatever the OS provides. On Windows 10 that dependency is real: the WebView2 Runtime must be present (Windows 11 includes it). On Linux you need GTK 3 and WebKitGTK 4.1 installed by the user or your package manager; MyGo's .deb and install script declare those dependencies rather than bundle them.

The delta-update story softens the difference over time in both directions. MyGo supports signed Ed25519 updates with delta updates, so subsequent downloads are smaller than the first install. Electron's ecosystem (electron-updater, Squirrel) has had the same model for years. First-install weight is where the gap is absolute.

The weight: runtime memory

Binary size is a download metric. Memory is the metric users actually feel, and here the comparison is less flattering to vendor claims.

MyGo's native UI mode avoids a full web engine per window. The project's own performance page — the most transparent thing about it — reports measured costs for the UI toolkit, not for whole applications: a warmed view of 1,000 labels retains approximately 2.50 MB of Go heap, and steady frames cost 397 µs with zero allocations for that fixture. Note the docs' own caveat: results "describe steady frames and do not compare MyGo with another GUI framework," and the measurement excludes native window process memory and GPU resources.

In web-frontend mode, MyGo apps behave like any other WebView app: the OS webview process renders your page, and its memory profile is set by your page, not by MyGo. You skip Electron's JS heap and render processes but you don't control anything about WKWebView or WebView2 either — they're the OS's processes. That's the price of "no bundled engine": you rent the engine with the house.

Electron is heavier by design — a bundled Chromium plus a Node main process — and its team publishes an entire performance guide on trimming memory, CPU, and disk usage. Moving to MyGo's native UI mode removes Chromium from the equation entirely; that's the one mode where the "takes little memory" claim is structural rather than aspirational.

The rendering question nobody should skip

"Use the OS webview" means three different engines in production:

• macOS: WKWebView — Apple's WebKit, updated with macOS.
• Windows: WebView2 — Chromium-based, updated by Microsoft.
• Linux: WebKitGTK — WebKit wrapped in GTK, versioned per distro.

Electron exists largely because that row of the table was unacceptable in 2013: feature gaps and rendering differences across engines meant testing three browsers and shipping inconsistencies. Vendors a bundled Chromium instead, and 100 MB is roughly what that guarantee costs. MyGo's web-frontend mode re-exposes you to that variance (plus the WebKitGTK DMA-BUF renderer, which MyGo disables unless you opt in — a hint at the fragility involved). If your frontend is one React app that must pixel-match on every platform, a system WebView is a functional downgrade, not a savings.

MyGo's escape hatch is the native UI mode, and it is a genuinely different object: a Go-rendered, GPU-drawn toolkit — consistent by construction because MyGo paints it identically on all three backends, without any engine. The cost is a different authoring model: your view is a Go function of state, usability-tested headlessly via ui.Tester with go test. It is not HTML, and any investment in web components does not port.

What smaller actually saves money on

The "Tech × Money" ledger, honestly itemized:

1. Distribution bandwidth. If you self-host installers and updates, egress at typical cloud rates is a few cents per GB. 1,000 users pulling a 200 MB Electron installer is ~200 GB; pulling a few-MB Go binary is single-digit GB and becomes negligible. The absolute dollar amount is small either way — it only becomes real when combined with cost-side 3 below.
2. Delta updates. Both ecosystems support them, but the baseline matters: a MyGo delta patch operates on a few-MB base instead of a 300 MB base.
3. CDN and update infrastructure on a free tier. GitHub Releases storage and the cost of occasionally re-uploading failed artifacts are linear in artifact size. Small artifacts keep you inside free limits longer.
4. User goodwill on constrained machines — corporate laptops with slow disks, low-RAM Windows machines, VMs, CI sandboxes. This doesn't appear on your invoice, but it's where memory differences actually pay, and it's the strongest argument for MyGo's native UI mode.
5. Time is where it costs you. Learning a new framework, reporting bugs to a weeks-old project, and working around platform gaps are paid in engineer-days. At consulting rates, one lost week erases a lot of egress savings.

When Electron still wins

• Chromium-dependent frontends. If you rely on Chromium-specific behavior, integrated PDF handling, or benchmarked rendering behavior that matches your users' Chrome, the system WebView gamble is a regression.
• Node native modules and the npm ecosystem. Electron apps routinely depend on Node-level packages and native addons (node-pty, native crypto drives, speech stacks). MyGo's answer lives in its plugin set — fetch/proxy, SQLite, WebSocket, terminal — which covers real ground but not all of it, and not a decade of npm install fix-it-my-problem.
• Maturity of the whole ship pipeline. MyGo's packaging story is surprisingly complete — signing, notarization, NSIS installers, .deb, PKGBUILDs, signed delta updates, a GitHub Actions workflow — but the project is young, with fast-moving APIs and one main maintainer. Electron's long tail: any bug you hit already has an issue, a workaround, and a Stack Overflow answer.
• Web-first teams. If your team knows only TypeScript, "rewrite the shell in Go" adds a second language and a foreign IPC boundary — MyGo's generated typed client narrows that, but doesn't erase it.

The decision frame

• Greenfield + small + Go on the backend: try MyGo first. A week into it, you'll have a real typed-IPC app, a working native-UI prototype with headless tests, and installers for three platforms. The downside risk is rework if a platform gap bites — budget that, don't ignore it.
• Existing Electron app, no complaints: don't migrate for size alone. If size, memory, or startup pain is measurable and user-visible, prototype the offending surface as a MyGo native-UI window before betting the app — and only migrate features, not history.
• Web-complex, engine-dependent, or team-is-JS: stay on Electron and spend the effort Electron docs already tell you to spend: trimming memory, lazy-loading, and Windows-asar hygiene. That's cheaper than a rewrite and the cost is known.

Wrap-up

• MyGo's real pitch isn't just "smaller binary" — it's that with no cgo and no bundled engine, the entire cost structure of a desktop distribution (download, updates, CI, disk, RAM) collapses to roughly Go-binary scale, and the native UI mode removes web runtimes from the runtime budget entirely.
• The claims hold up as design properties, not as published benchmarks: MyGo's own performance page measures its UI toolkit (2.50 MB retained heap for a 1,000-label view) and explicitly disclaims cross-framework comparison; Electron's 100–300 MB norm comes from an Electron maintainer.
• Electron retains its money's worth in engine consistency, the Node/npm ecosystem, and maturity. For small utilities and launchers built by Go teams, MyGo is worth the early-adopter tax; for everything else, budget the cost of staying put first.

Sources: egoist/mygo on GitHub · MyGo docs · MyGo native UI performance page · MyGo getting started (repo docs) · MyGo distribution docs (repo) · Felix Rieseberg, "Things people get wrong about Electron" · azukiazusa, "Trying MyGo, a Framework for Building Desktop Apps in Go" · Electron performance docs