←back to thread

50 points senfiaj | 7 comments | | HN request time: 0.205s | source | bottom
1. karmakaze ◴[] No.45811352[source]
No software bloat isn't ok. Tech debt can be ok, and software bloat can be the consequence of tech debt taken on with eyes open. But to say that (some) software bloat without considerations is ok is how we have the fastest machines imaginable and still end up with UI that can't keep up visually with keystrokes.

Quoting Knuth without the entire context is also contributing to bloat.

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.

> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

replies(2): >>45812879 #>>45815365 #
2. locknitpicker ◴[] No.45812879[source]
> But to say that (some) software bloat without considerations is ok is how we have the fastest machines imaginable and still end up with UI that can't keep up visually with keystrokes.

Is this actually a problem, though? The blog features a section on tradeoffs, and dedicates an entire section to engineering tradeoffs. Perceived performance is one of these tradeoffs.

You complain about UI not keeping up with key strokes. As a counterexample I point out Visual Studio Code. It's UI is not as snappy as native GUI frameworks, but we have a top notch user experience that's consistent across operating systems and desktop environments. That's a win, isn't it? How many projects can make that claim?

The blog post also has a section on how a significant part of the bloat is bad.

replies(4): >>45813372 #>>45813501 #>>45815246 #>>45815656 #
3. _aavaa_ ◴[] No.45813372[source]
It is a problem. The engineering tradeoffs have to be done at each level of the stack. And as progressively more layers of the stack make the trade off away from speed the effects compound.

Nothing about a cross-platform UI requires that it not be snappy. Or that Electron is the best option possible.

Did VSCode do a good job with the options available? Maybe, maybe not. But the options is where I think we should focus.

Having to trade off between two bad options means you’ve already lost.

4. grayhatter ◴[] No.45813501[source]
> You complain about UI not keeping up with key strokes. As a counterexample I point out Visual Studio Code. It's UI is not as snappy as native GUI frameworks, but we have a top notch user experience that's consistent across operating systems and desktop environments. That's a win, isn't it? How many projects can make that claim?

Is it a win? Why? Consistency across platforms is a branding, business goal, not an engineering one. Consistency itself doesn't specify a direction, it just makes it more familiar, and easier to adopt without effort. It's easier to sit all day, and never exercise.

It's what everybody does, or it's what everybody uses, has never translated into it being good.

Notably; the engineers I respect the most, and the ones making things that I enjoy using, none of them use vscode. I'm sure most will read this as an attack against their editor of choice, SHUN THE NON BELIEVER! But hopefully enough will realize that it's not actually an attack on them nor their editor, but instead I'm advocating for what is the best possible option, and not the easiest to use. Could they use vscode? Obviously yes, they could. They don't because the more experience you have, the easier it is to see that bloat get in the way.

5. whilenot-dev ◴[] No.45815246[source]
> Perceived performance is one of these tradeoffs.

Perceived performance should never be a tradeoff, only the measured performance impact can be one.

My iPhone SE from 2020 has input delays of up to 2s after the update to iOS 26 and that's just really disappointing. I wouldn't mind if it'd be in the 0,3ms range, even though that would still be terrible from a measured performance POV.

6. jay_kyburz ◴[] No.45815365[source]
I work in Unity game engine all day and it's so painful and slow compared to building my web games or even games for the little Playdate.

I'm faced with a constant stream of 15-30 second pauses where I have to turn my brain off _or_ alt-tab over to the browser and get distracted. I find it challenging to stay focused with a constant stream of small pauses.

I've been thinking about somehow restructuring the project, or buying a faster computer or something, but I do know I don't want to live like this. :)

7. oofbaroomf ◴[] No.45815656[source]
Ok, but something like Zed is almost as snappy as native GUI frameworks AND has a consistent user experience. It doesn't seem like they are making any tradeoffs there.