3,600 Stars in 33 Days: MyGo Wants to Wrap Your Website in a Go Window — Cookies and All

Every SaaS founder knows this support ticket by heart: "Love the product. Can you make it a real app? The browser tab is… a lot."

And every engineer who has wrapped a website in a window knows the trap hiding behind that request. Your site doesn't just render HTML — it lives on session cookies and localStorage. Logins, tokens, feature flags, half-finished forms. A desktop wrapper that can't carry those across is a broken app with a nicer icon.

This week a new answer showed up, and it's moving so fast it's hard to photograph. MyGo — a pure-Go desktop framework by veteran OSS author Egoist — hit 3,600+ GitHub stars in just 33 days, shipped two releases in the last 30 hours (v0.7.2 landed yesterday evening UTC, v0.7.3 this morning), and the v0.7.2 release notes contain the exact sentence our hypothetical app needs:

"Sessions for pages. PageOptions.Session gives a page its own cookies, storage, caches and service workers, like Electron's partitions. NewSession(name) keeps a session on disk, NewEphemeralSession keeps it in memory, and Session.ClearData clears it."

Cookies, storage, caches — with Electron-grade partitioning — added to a project that didn't exist in August. Let's dig in.

The project card

	MyGo (github.com/egoist/mygo)
Author	Egoist (long-time OSS author behind poi, sao and a shelf of JS tooling)
First commit	September 26, 2026
Stars at publish	3,626 · 201 forks · 84 open issues
License	MIT
Version	v0.7.3 (published Oct 29, 2026 — this morning)
Language	100% Go, no cgo
Platforms	macOS 12+, Windows 10/11 (x64 + arm64), Linux x64/arm64
UI modes	OS webview or self-drawn native UI — mixable per window

Two things make MyGo structurally different from the field:

1. Pure Go, no cgo. No C toolchain, no platform-specific build days. The docs promise you can compile every target from any machine (only macOS signing/notarization needs a Mac — Apple's rule, not Go's).

2. Two kinds of windows, one binary. A window either shows a web page in the webview your OS already ships (WKWebView on macOS, WebKitGTK on Linux, WebView2 on Windows), or native UI written in Go that MyGo draws itself on the GPU via Metal, Direct3D or OpenGL — no HTML, no JavaScript, no webview process at all. One app can have both, side by side.

The project's own front page reports (label: project-reported, unverified by us): ~7 MB binary, ~44 MB memory for native UI, ~62 MB with the webview loaded, 0% idle CPU.

And yes — the velocity is AI-assisted, and the repo is refreshingly honest about it. Egoist's announcement post on X reads: "I created MyGo just three weeks ago, and it's already the best desktop GUI framework for Go, unbelievable things are happening thanks to Opus…" Community PRs carry a formal "AI disclosure" section; one from this week declares Claude Sonnet 5.5 wrote the code and tests, with a human owner reviewing. That's not a footnote — that's the 2026 dev loop running at maximum RPM.

The part you actually asked about: cookies + localStorage

For a "my website, but a window" app, this is the whole ballgame. Here's what MyGo gives you as of v0.7.2:

• PageOptions.Session — per-page isolated store: cookies, localStorage, IndexedDB, caches, service workers. mygo.NewSession("work") persists to disk across app restarts; NewEphemeralSession() stays in RAM (incognito mode, basically); Session.ClearData() wipes one session and leaves the others alone.
• PageOptions.Untrusted — shows someone else's page (a third-party site, plugin UI, user HTML) with no access to your Go methods, events, permissions or other origins. This is the flag you want when your window displays a site you didn't write, but your Go code signs the checks.
• Page.SetAuthHandler — answers HTTP sign-in prompts (Basic, Digest, NTLM, Negotiate) from Go. Page.SetCertificateErrorHandler — you decide what happens when a cert doesn't verify.
• Page options also cover user agent (and a suffix), preload scripts, trusted origins, permissions, navigation, downloads and printing — the classic website-wrapping toolkit.

So the wrapper-app sketch looks roughly like this (field names per current docs):

mygo.App.WhenReady(func() {
    mygo.NewWindow(mygo.WindowOptions{
        Title: "MyApp",
        URL:   "https://your-site.com",
        Page: mygo.PageOptions{
            Session:   mygo.NewSession("app"), // cookies + storage, persisted
            Untrusted: true,                   // site gets no bridge into your Go code
        },
    })
})
mygo.App.Run()

Login once, and your cookies ride in MyGo's session store across restarts — no browser tab, no bundled Chromium.

The honest caveats. First, the data lives in the OS webview's profile, not in a database you control — "clear cookies" semantics are the webview's, not SQL's. Second, finer-grained multi-store work is actively in flight: open PR #713 proposes StorageID for named stores (think: two accounts of the same site, side by side) and its platform matrix is a useful honesty check — macOS 14+ ✓, Windows (needs WebView2 Runtime ≥ 1.0.1210.39) ✓, Linux: not yet (ErrUnsupported, because WebKitGTK shares one data manager per process). And third, the meta-caveat: this API is four days old. It will move.

How it stacks up

The usual suspects, for a Go-flavored wrapper app:

	MyGo	Wails	Electron	Tauri
Core language	Go	Go	JS/Node	Rust
Renderer	OS webview or GPU-drawn native UI	OS webview	Bundled Chromium + Node	OS webview
cgo required	No	Yes (platform deps)	N/A	Yes (Rust toolchain)
Hello-world size	~7 MB (project-reported)	~10–20 MB (community-typical)	~150–250 MB installed (typical)	~5–15 MB (community-typical)
Cookie/session control	Sessions API (this week!)	Basic — mostly DIY via webview	Mature session partitions	Per-app store; fine-grained = DIY
Native UI without web	Yes, built in	No	No	No
Stars at publish	3.6k	36.8k	~121k	~106k
Age	33 days	~8 years	~13 years	~6 years
Auto-update / signing / installers	In the box (incl. delta updates + GitHub Actions)	Partial (v2/v3)	Via electron-builder + effort	In the box (Tauri v2)
License	MIT	MIT	MIT	MIT/Apache-2.0

All four are free and open source, so "cost" here isn't license fees — it's your weekend. Now the scorecard on the four axes that were actually asked for:

Fewer bugs. Electron wins by seniority — thirteen years of "weird Windows GPU driver" bug reports already filed, triaged and memed. Tauri is mature but drags in webview-per-OS inconsistency plus a Rust learning curve if your team is Go-shaped. Wails is the established Go option. MyGo? The code is three weeks old — but it's paced like a project five years in (dozens of releases, new contributors landing fixes within days of issue reports). The risk isn't sloppy code; it's churn: v0.7.2 alone shipped a breaking change (pinch-zoom/swipe defaults flipped off). If you pin versions and read release notes, survivable. If you @latest everything and walk away for a month, expect surprises.

Easiness. For a Go developer, MyGo and Wails feel like coming home — the entire app is one Go program, no Node orchestration, no Rust borrow-checker duel. MyGo's typed IPC is the sleeper feature: you bind Go structs, and it generates a TypeScript client from your Go code, types and doc comments included. That alone deletes a whole class of frontend/backend drift bugs. Tauri is excellent but assumes you'll write Rust for the shell. Electron assumes you'll accept JavaScript everywhere and a 200 MB folder in exchange for the smoothest docs on earth.

Performance. Tauri, Wails and MyGo all ride the OS webview, so page-render performance is basically the same tier — you're using Safari's engine on a Mac whether you like it or not. The differences are the tax around the edges: Electron pays a Chromium+Node tax on every launch and every MB of RAM; MyGo's webview path skips the tax, and its native-UI path skips the webview — windows open instantly, no engine boot. For a website wrapper you'll live in webview mode and the honest answer is: parity, with a much lighter process around it.

Cost. $0 for all of them, but MyGo bundles the boring-expensive parts — code signing, notarization, Windows installers, Debian packages, signed auto-updates with delta updates, and a GitHub Actions workflow that does the whole pipeline on tag push. With Electron you'll assemble that stack from electron-builder, electron-updater and a Friday you'll never get back.

The verdict for a website-wrapping app

MyGo today is the best idea in this lane and a bold bet for production. The cookies-and-storage story landed literally yesterday, the Untrusted flag is exactly the right security default for wrapping a site you don't control, and nothing else in Go-land gives you per-page sessions without DIY webview surgery.

Our practical take, split by risk appetite:

• Internal tool / beta / side project: Ship it with MyGo. Pin the version, watch releases (they come fast), keep mygo doctor handy. The webview path is stable OS tech; the framework around it is the moving part.
• Revenue-bearing product with paying users: Wails (or Electron, if your team is JS-native) is the today answer — battle scars matter when "the app won't start" is a support ticket. But keep your logic in a plain Go service layer, because…
• The six-month play: MyGo's velocity plus no-cgo cross-compilation plus typed IPC is the trajectory that could make it the default Go desktop answer. Your Go service layer ports to it in an afternoon; only the shell changes.

And one last thing worth appreciating: the repo treats AI-assisted contribution as a disclosed, reviewed first-class workflow — and the first external PR automating multi-account cookie stores arrived within a month. Whatever you think of vibe-coding, this is what the frontier looks like from the inside: a 3,600-star framework, five weeks old, that already speaks fluent cookie.

Sources: github.com/egoist/mygo (repo API + README + docs, pulled Oct 29, 2026), MyGo v0.7.2/v0.7.3 release notes, mygo.egoist.dev, PR #713 (with its platform matrix and AI disclosure), docs/windows.md, Wails repo API, Best of JS desktop snapshots, @localhost_5173 on X. All star counts and stats are point-in-time snapshots from publish day; performance figures marked "project-reported" or "typical" are community/unverified numbers.