Out of interest why would you run Steam in Wine?

I’m pretty sure the early steam client was based on Trident before chromium no?

Edit: actually it seems to have been Trident, then WebKit, then Chromium Embedded

I think these days it's easier to run Steam in Wine than it is to run Wine in the first place. If you're running a commercial packaging of Wine for gaming, both things are trivial.

(Successfully running Windows games is its own issue: I think "Steam Deck" compatibility badging is a pretty reliable tell for Linux gaming, but on a Mac, having the game be playable is a gamble on install and again with every patch.)

They used IE in the beginning.

[dead]

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.

You can just skip Tauri entirely and get true native apps. No web wrapping required

Like these https://goodapps.store/

Disclaimer: All mine, open-source, ai-assisted, less than 5MB each. I love rust+tauri combo.

Much better it can give us just webview in wry and winit without tauri bloat

Except EGS's slop garbage is 400MB on linux

Tauri doesn't solve the problems Electron solves. It just externalizes the solution so things can subtly stop working randomly.

[dead]

[flagged]

> forcing function to clean up tech debt

The real reason rewrites to fix tech debt used to fail was that it took too long to get to feature partity & the goal posts moved constantly while you were on the rewrite team.

The sunk cost of existing code is no longer considered in a rewrite.

Maybe it was hard to write in the first place, but it is not hard to rewrite anymore, as long you've got decent tests.

Also, you're going to get a different speed up depending on which page you have set as your starting page.

If you have steam configured so it shows the store page on startup, you have to add on the time it for that page to load.

The new version of Epic is based on Tauri. Also written in JS and probably React (haven't decompiled it yet) but the web runtime is part of Windows instead of shipped with the app so it takes less disk space and RAM. And you can write perf sensitive code in Rust for even more speedup.

Interesting, I didn't know they moved to a Chromium based desktop application. But honestly, I don't feel like there's any performance issues with the steam desktop client (I'm running it on Fedora, but I'm assuming performance is relatively similar on different platforms).

Ref: https://docs.steambrew.app/developers/environment

They already are. I asked opus 5.5 to plan out and begin building a swift version of my electron notes app, using a similar architecture / feature set. I hut enter and honestly forgot about it. 2 hours later im reading slack while making my next round of coffee, and my session is interrupted by a native app opening on my phone (the model installed it for me to test). It.... has 2/3 of the features already and looks awesome, holy crap. It skipped my suggestion to use the Lexical (web) editor and is.... using. platform native one.

time will tell if it can make it the way i like but.... it can definitely get far. Used 40% of my session limits on my $20/mo sub.

I wonder what best practices here look like at this point. In my world, we've moved past skills for something like this, having porting helper/validator/etc things be harness level is measurably better than what skills look like right now. The open plugin spec is certainly an improvement (namely in packaging and distribution)- but, really you'd be leaving perf on the table if you were not to tune your harness. I wonder if something like dsh, pi, or other extensible (coding) harnesses have something like a concept of "harness as an extension".

It’s just that the vibe coded stuff has so many assumptions baked in, that you will be constantly surprised about the behaviors your slopped codebase has. Doesn’t matter for small tools, where you’ll be delighted that clicking that one label copies it to your clipboard - nice one, Claude, that’s delightful!

It’s less nice when your web app launches that other service only when the other Tailscale node is up, because the agent interpreted your prompt as a hard access rule.

It's because no matter how 'good' the AI output is, "vibe coding" is strongly associated with "completely unreviewed and untested". LLMs have brought the skill floor straight through the ground and into the depths of hell, so people are doubly cautious with it because there's a very good chance with any vibe coded app that there's not a single person in the world that truly understands what it actually does just behind the scenes. It could be completely fine, or it could be breaking your system or uploading your sensitive data somewhere because the vibe coder provided flawed instructions or the LLM decided to make an unexpected 'optimization'. Wanna roll the dice and find out which one it is?

I'm reserving "vibe coding" in my head for "the programming style where you just prompt your way around without even looking at the code and only caring if your happy path works".

I have a couple of nice "vibe coded" apps I would never dream of releasing because I'm not interested in the QA, more than anything else. The problem is the other people who are not quite so considerate and think that what they tossed out in 15 minutes is of interest to the rest of the world. The value of a software package release now is more in the QA than the code.

Yeah I'm really impressed by what Opus 5.5 can manage.

I feel like human code is on a wide quality spectrum. The best human code is way better than what Opus 5.5 can do. But the average code, I'm not so sure.

I feel bad for your employer

> Human code is slop.

I'm not saying you have to be grateful to the millions of people whose work the AI you use was trained on, but why shit on them...

Opus 5.5 is impressive and I'm happy using it to write a ton of code.

But it also still writes awful code with poor maintainability if you don't keep a very close eye on it.

Trust me I know what it's like. I do a lot of it. Even with Opus you still have to guide it aggressively or your codebase turns to slop.

An experienced dev with Claude is better than either of them alone but you can't just point your agent at a repo and expect good results. And when people talk about vibe coding that's usually what they mean.

> People still talk about "Vibe coding" or implying "vibe coded" stuff is poor quality

Yes they do. Because it is. Anyone who cares about the quality of their product is, at minimum, carefully reviewing the output from an LLM to make sure it didn't sneak in anything crazy. More likely they are writing a lot of code by hand, because that is faster than reviewing and correcting the LLM code. Competent developers do not just hand it off and say "the AI is really good so I can trust what it put out".

Creating slop was already a solved problem before AI. AI just made it much more efficient.

human code is slop. tell us all what the LLMs were trained on? slop?