Proposal: Add Wails for a desktop/web UI layer

[mabd-dev]

Background

TUI development velocity is just slow relative to the output. Not because Bubble Tea is bad, but because terminal UI has a tight constraints ceiling. You're fighting with character grids, escape codes, and terminal emulator inconsistencies to build something that still looks worse than a basic HTML table.

With Wails + Vue (or Svelte, React ...) you get:

• Sorting, filtering, search are trivial in a table component, painful in TUI
• Click into a repo, see file diffs, open in editor - natural in a GUI, requires complex state machines in TUI
• The UI can grow as the tool grows without the cost increasing disproportionately

What I'm proposing

Add Wails to the project alongside the existing CLI. Wails lets us build a native desktop app using Go on the backend and Vue + TypeScript on the frontend, no Electron, no separate runtime, just a single compiled binary.

The Go core (scanning logic, JSON output) stays completely untouched. Wails just adds a presentation layer on top.

What changes:

• A new app.go that exposes existing scanner functions to the frontend
• A frontend/ directory with a Vue + TS UI
• wails build produces a native .app / .exe / .deb that anyone can download and run

What doesn't change:

• The CLI still works as-is (reposcan, piping JSON)
• The TUI stays in place but won't be actively developed. It'll be frozen at its current state
• Core Go development workflow is unaffected

Why not keep investing in the TUI?

Bubble Tea is a great library, but a TUI has a ceiling. Mouse support is awkward, responsive layout is painful, and the development effort doesn't scale well. A web-based UI running inside a native window gives us a much better surface for things like filtering, sorting, diffing, and visualizing repo state.

Distribution

Builds would be automated via GitHub Actions on every release tag, producing platform-specific binaries attached to GitHub Releases. No setup required for end users.

---

Would love to hear thoughts:

• Does this direction make sense for the project?
• Any concerns about adding Wails as a dependency?
• Preferences on Vue vs React for the frontend?
• Should the TUI be deprecated eventually or just frozen?

[mabd-dev]

@nilp0inter @AnthonyGeorgeAZ @frittlechasm @vgauraha62
Would like your input on this

[mabd-dev]

I was able to build this macos app in few minutes. Using vue and typescript (no AI)

What I did

expose get report function in app.go (wails file)

func (a *App) GetReport() (ScanReport, error) {
    // ....
}

then wails, generates this

export function GetReport():Promise<main.ScanReport>;

which we can use in vue components.

Next are basic vue stuff. Get report, render it in table

And that is it.

With TUI (bubble tea) this would much more time to finish2

[frittlechasm]

As this is a major shift it would be better to understand what the goals are with this project.

If the goal becomes a full Git client with commit authoring, diff review, branch graphs, staging, stash, conflict workflows, and long-lived workspace state, a desktop app becomes the better choice.

If the goal is to remain a fast repository health overview and cleanup assistant then a CLI / TUI makes sense. I feel there's nothing faster than splitting an open terminal and running an alias to quickly get a view of all the repositories health. If the main concern is TUI development velocity, we could explore better TUI libraries or patterns instead of moving straight to desktop. LazyGit is a good example of how far a terminal-native Git UI can go when the TUI architecture is treated seriously.

A Third option is to support both over time: keep the CLI/TUI as the fast terminal-first workflow, while making the scan/report/Git-action layer UI-agnostic enough that a desktop app could be added later. That way users who want the desktop experience can use it, while users who prefer the terminal do not lose the current workflow.

[nilp0inter]

Hi @mabd-dev, thanks for sharing this proposal. To be direct, I actually have strong reservations about this direction and would advise against adding a GUI to the project.

While I understand the appeal of Wails and the frustrations of TUI development, I believe introducing a GUI will lead to significant scope creep, binary bloat, and a fragmentation of our development efforts.

Here is why:

1. Scope Creep and Bloat

A repository scanner is, at its core, a lightweight system utility. Adding a web subsystem (Wails, Node, Vue, TypeScript, Tailwind, etc.) turns a simple, highly efficient Go binary into a complex hybrid application. It introduces a massive web dependency tree for a tool that ultimately just needs to report uncommitted git files.

2. Fragmented Focus & "TUI Rot"

If we freeze the TUI to focus on the GUI, the TUI will inevitably rot. Whenever the backend Go logic changes, the TUI will break or fall out of sync. As a small team, splitting the project into "CLI/TUI" and "GUI" workflows means we will spend more time managing build pipelines and cross-platform GUI bugs than actually improving the core scanning logic.

3. My Workflow & The Tool's Purpose

Our workflows here seems to be fundamentally different. For me, this tool is a preventative utility, not an interactive dashboard:

• I run it automatically via a shell hook at the start of my terminal sessions.
• My target state is zero uncommitted repos. If there is work left over, I want a quick, text-based alert in my terminal so I can address it and move on.
• Having to launch a desktop GUI, use a mouse, and manage another OS window defeats the purpose of a fast, automated terminal check.

Conclusion

If the project shifts focus toward a GUI/desktop app with Wails, I think our visions for this tool have diverged. I am only interested in maintaining and using a lightweight, terminal-first utility.

If you decide to move forward with the Wails/GUI route, I will likely fork the current CLI/TUI state of the project so I can keep maintaining it as a pure, lightweight terminal tool without the web overhead.

I’d prefer to keep working together on this, but I want to be upfront about where I stand on the GUI transition.

[mabd-dev]

Thank you guys for your feedback. Really appreciate it

Rethinking what @frittlechasm said

As this is a major shift it would be better to understand what the goals are with this project.

The main core of this project is to report dirty repos. This is not supposed to be a git client. Seeing dirty repos and taking simple actions like push/pull/discard changes are simple and nice to have, but beyond that it's too much.

The reason I was thinking about desktop app is the ui building speed. Web tech like Vue/React are much faster to write good looking ui compared to TUI. Even with AI these days, writing vue/react code is far better than TUI. So I was only focusing on UI improvement and not liking the limitation TUI have
But I was deviating from the main core of the project.

That said, going with GUI direction was a bad move. The focus of this tool would continue to be in improving the reporting functionality and TUI usage

Thank you for your feedback, and all great contributions you are bringing to this tool