← Back to context

Comment by m_w_

4 days ago

I would go one step farther - if you're vibe coding, skip Tauri altogether. I've been on-and-off vibecoding a GitKraken replacement using egui instead, and the memory footprint is very low. Otherwise can't tell the difference, as I'm not reading the code either way.

Using Tauri on Linux gave me appreciation for why Electron just ships an entire browser. WebKitGTK is kinda rough around the edges.

  • I vibe-coded a paste manager using wails (https://github.com/egeozcan/mahpastes), and I'm currently on linux (bazzite) and I have 0 problems with the rendering.

    • One of the things I hit is that there is no way to trigger an "open folder" dialog. It gets mapped to "open file" instead. The correct hooks exist in both WebKit and in GTK, but not wired up in WebKitGTK. I think the fix would be quite minor but I looked into what is involved in raising a patch and decided to leave it. There are a lot of minor paper cuts like this.

      I did hit a couple of CSS or rendering quirks, but the rendering perf also seemed noticeably poor, and that's harder to live with.

    • Try it on an older LTS distro release that is still under distro support or even better, one that's under extended paid only support. Anything pre 2022 is probably completely broken and anything pre 2024 might have strange bugs. There was a great one where building a Tauri or Wails app on Ubuntu 22.04 for better compatibility but running it on a newer distro had a font rendering bug because of the older Webkit2Gtk. Trying to display emojis crashed the apps.

Isn't egui really cpu inefficient though? It repaints at 60fps if e.g. you move the mouse over it

  • If it is, it hasn't been a problem so far. I have been focused heavily on memoization, to what extent that's possible when fully vibe coding.

    Fwiw, what it's trying to replace (GitKraken) is slow, clunky, and resource hungry, so it's not hard to beat.

  • Egui mostly repaints on the GPU, so the inefficiencies doesn't really show up until you try to render 10k tree nodes in a list or something, and even then you can do virtualization.

You're probably doing something the LLM has less fluency with.

  • Definitely would concede this, but I haven't had any issues so far. It's been able to make things look exactly as I've dictated them, even with relatively complex visualization of git branching. I get the sense that, with how capable Opus 5.5 is, "less capable" no longer means "not capable enough".