Comment by tancop
4 days ago
I used to think vibe coding would get us slow Electron apps but now we got speed wars between game launchers. I hope this comes for all types of software.
With that said, I tested it right now and Steam takes about 2 seconds to restore from tray and 10-15 for cold boot. The new Epic launcher is around 0.5 and 5 like the article mentioned. Maybe it's still in A/B testing or something.
It's nice but a low bar. Steam pioneered crappy Chrome-based desktop apps before Electron existed, which is also why it's so hard to run Steam in Wine. It has a longer startup and shutdown process (they even call it that) than my entire OS.
Epic, EA, etc then made their own similar launchers. Of course all of them also want to launch when Windows boots, update constantly, and not close when you press close.
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
Yes, but when they finally switched to Chromium, it was still before Electron
Out of interest why would you run Steam in Wine?
To play Windows-only games on Mac, or before Proton existed, Linux. You can't launch the games without Steam.
7 replies →
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.)
If you pay for Crossover, sure. Not if you want to use the free Wine. And it used to be hard even in Crossover.
They used IE in the beginning.
[dead]
Vibe coding can yield us Tauri apps that end up being like 3mb rather than 130mb for a "Hello World" app.
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.
4 replies →
Isn't egui really cpu inefficient though? It repaints at 60fps if e.g. you move the mouse over it
3 replies →
You're probably doing something the LLM has less fluency with.
4 replies →
Egui maybe.
1 reply →
You can just skip Tauri entirely and get true native apps. No web wrapping required
But there’s still no way to get consistent results cross-platform without a web view, right? I guess Tauri isn’t even consistent because it relies on the system’s browser and they do differ to some degree.
39 replies →
Like these https://goodapps.store/
Disclaimer: All mine, open-source, ai-assisted, less than 5MB each. I love rust+tauri combo.
Tauri doesn't solve the problems Electron solves. It just externalizes the solution so things can subtly stop working randomly.
Much better it can give us just webview in wry and winit without tauri bloat
Except EGS's slop garbage is 400MB on linux
[dead]
I actually think that vibe coding lends itself well to stuff with really strict type systems. When you use Claude Code, it basically works on a loop until it gets something "right". A type system allows for part of the "right" criteria to be baked into the compilation, giving a hard block if it doesn't at least pass that.
I've had reasonably good luck having Claude generate Rust code that performs well.
[flagged]
I see it as a forcing function to clean up tech debt
> 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.
I think in Steam's case it was more like a lack of competitive pressure, their publisher dashboard still packs HTML/CSS fixes for IE6/7/8 that's code they probably haven't touched in ~20 years and it's certainly not because they couldn't afford or lacked time to work on it!
2 replies →
> Maybe it's still in A/B testing or something
Are you on the beta branch? It doesn't look like its in stable yet (Settings --> Interface --> Client Beta Participation)
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.
i don't care how fast it is beyond a certain point. What is more shocking is all the bugs that vibe coding landed epic. I can't imagine shipping software at this scale in this state.
I really hope this comes true. I'd love Electron-free versions of Discord and Teams. I've been building a native Rust/GPUI desktop app, and the difference in startup and memory is huge.
yeah, Steam takes forever to start, one of the slowest apps I use. Photoshop is similarly lethargic starting up.
Counter-intuitively (or intuitively if you’re inside the industry), slow Electron apps became the norm because of how much developers cost. Now that AI can step in with parallel expertise at scale, I suspect we’ll have all sorts of optimization races.
On the other hand, OpenAI has recently successfully ported the abysmal performance of ChatGPT/Codex on macOS to the web (at least in Firefox) with no end in sight…
Prioritization still matters. Agents will happily optimize your app for performance, but at least current ones seem like you need to explicitly tell them.
Misc speed improvements, security updates on old applications… I’m doing a lot of that lately, quite quickly.
It’s similar for the productivity/launcher app Raycast. They’re trying to find new USPs compared to the many copycats.
Surprise it’s speed wars between Electron apps. Steam is based on Chromium/Electron.
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.
I also avoid installing Tauri apps too. Anything that loads Javascript that’s not my browser is a bad smell and potential resource hog IMO.
3 replies →
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
The switch from IE/Trident to Chromium happened in 2010 alongside launching support for Macs.
1 reply →
I'd imagine one can now focus on creating a client for a single OS and having the AI do the porting to others as it would essentially be a translation.
Perhaps it will bring back native apps because supporting other platforms is less laborious.
Hopefully LLM models and harnesses improve to where Chromium or Electron apps can be more trivially converted to native apps. You're paying for tokens for downstream compute efficiency across the user base.
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".
Not really a war. Steam updated their client the day before Epic decided to mouth off. Kinda hilarious actually.
[flagged]
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 have only very rarely in my career encountered code worse than what an LLM produces. It happens, but your typical programmer is still quite a bit better than an LLM.
1 reply →
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.
Hand crafted artisanal slop vs dark software factory slop.
human code is slop. tell us all what the LLMs were trained on? slop?