App instead of `localhost`?

[brillout]

I wonder whether we should use Electron (or preferably something like Tauri if it's a viable solution).

Downside: bloat.

Upside: looks professional.

I think it's worth it... especially if we can use a solution that doesn't bloat the user's memory. Is Tauri (or some other tool) a good option?

[suleimansh]

My vote: localhost-first, keep Tauri as an optional later wrapper, do not gate the rebuild on it.

Why it is not an either/or: the #405 rebuild produces a self-contained static Vike bundle. Tauri (or Electron) is just a native window pointing a webview at that same bundle. So we ship localhost now, and if we want the native feel later we wrap the exact same bundle in Tauri with near-zero frontend rework. Choosing localhost now costs us nothing later.

If we do go native, Tauri over Electron: system webview, few-MB binary, low memory. Electron ships Chromium (100MB+, heavier RAM).

One caveat on the footprint upside though: Tauri does NOT replace our Node daemon. The daemon does the file I/O, spawns the Claude Code runs, tails logs, and serves state. Tauri backend is Rust and will not run that. So a native app = Rust shell + webview + the same Node daemon underneath. We do not get to delete the daemon, we add a window around it. Memory = daemon + webview either way.

Also, the relay-shareable angle from #405: a static localhost bundle is trivially shareable, a native app is not. Good reason to keep the web target primary.

So: build the SPA now (localhost), revisit Tauri purely as a distribution shell once the SPA exists and we actually feel the "looks unprofessional" pain. Nothing in the rebuild forecloses it.

[nitedani]

I can recommend to take a look https://wails.io/

[suleimansh]

Thanks. Wails is the same shape as Tauri (system webview), just Go instead of Rust. Does not change the plan: any native shell still wraps the same SPA bundle and still needs the Node daemon underneath, so it stays an optional later wrapper. Localhost-first for now.

[brillout]

Maybe (eventually) all three:

• localhost (local)
• app (local) or "local domain" (local)
• web (hosted)

Personally, I prefer localhost over app. (Familiar flow, I can use my browser extensions.)

But, for non-technical users, having to open a terminal is quite unfamiliar (thus a no-go). But, I agree, we can focus only on technical folks for now => only localhost is fine for now.

"Local domain"

Idea:

• We serve the local dashbaord via the-framework.local instead of localhost:4200
  • This is possible via /etc/hosts
• We ship an app, but the only thing the app does is running the deamon and sets /etc/hosts, it doesn't ship any browser.

Download page

I think Cursor's download page is the end-goal for non-technical users:

Note

That said, maybe the vast majority of non-technical users will use the hosted version, in that case me might not need that.

Verdict

Let's keep localhost for now (we target developers for now).