Hacker News Reader

Comment by m_w_ | Hacker News Reader

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.

View on HN

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.

Recently vibe coded this https://www.rominabox.app/ and also loved Tauri for the "builder" part of it! What a pleasure to work with.

Granted, it's very simple, but I felt it was a breeze.

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

No mobile support either

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.

LLMs can for sure write GTK4 (or Relm4), Swift UI, whatever windows uses, Kotlin for Android.

They can write brainfuck. I said less fluency.

What I meant: they can write it pretty well. Probably because share of good quality code of native apps is much higher bad quality, due to all js slop we had even before LLM slop.

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".

Egui maybe.

Why does nobody talk about GPUI? I had a great experience developing with it. My app starts up in ~200ms and uses ~75MB of RAM.

Reply on news.ycombinator.com