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

▲

locknitpicker 3 days ago | parent | next [-]

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

▲

grayhatter 2 days ago | parent | next [-]

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

▲

robenkleene 2 days ago | parent [-]

> Notably; the engineers I respect the most, and the ones making things that I enjoy using, none of them use vscode.

Curious what they use?

▲

d0lphin 2 days ago | parent [-]

Not OP, but a surprising number of senior(+) engineers at my company use default vim or neovim (no plugins or customizations)

▲

locknitpicker 2 days ago | parent | next [-]

> Not OP, but a surprising number of senior(+) engineers at my company use default vim or neovim (no plugins or customizations)

That's fine. They could very well be using the tool they always used. Support for vi bindings is not the best everywhere, and vim works also through terminal connections, which is great if you need to ssh somewhere to edit a few files.

If you have to work with anything related to TypeScript or even JavaScript, you need to think long and hard to figure out what you're doing if your first option isn't vscode.

▲

lkirkwood a day ago | parent [-]

... why? What does it offer that literally any other IDE does not? Genuinely asking.

	▲	grayhatter a day ago \| parent [-]
		Nothing, but that's the point. There's the engineering maxim, which I completely, and unequivocally support; that perfection isn't achieved when there's nothing left to add, but only when there's nothing left to take away. But that's not enough to explain why it's the preferred editor for elite tier eng. The thing it offers, in contrast to everything else, is simplicity. Everyone loves to pretend that vi is so difficult o that it is impossible to quit. But if you can forgive it's steep learning curve, it does provide an accelerated experience. And then, critically, it's already out of your way. All experts advocate the idea behind the quote, "if you give me 6 hours to cut down a tree, I'd spend the first 4 sharpening my axe" Learning the keys of vim is that same sharpening. I used to use sublime text, my primary reason was because it was fast. That means it got out of my way. Today, I use neovim. And I've never bothered to set up tab complete, nor anything else like it. It does take me, about 2 extra seconds, per meaningful code block, to type the extra characters needed. But in trade for those tens or milliseconds. I'm granted the intuition for the name of the exact stdlib function I want to call. It lives in not just my head, but I also have developed the habit of understanding the context behind the call. The feature neovim gives to it's users, it the intuition and the confidence to reason about the code they've written. There's a lot of anxiety going around about the future of software development, related to AI. The people who have invested the mental energy of learning vim aren't worried, because it's exceptionally obvious that LLMs are pathetic when compared to the quality they've learned to emit naturally. Or, more simply; if you're the type of person who's willing to invest the mental effort to become good at something. Vim is engineered to make you even better. Contrasted with vscode which has been engineered to make it easier to type... but then... all that time spent has only made you good at the things AI can already do. tldr; vscode improves the typing experience, vim improves the thinking experience. AI isn't coming for the jobs of the thinkers...

▲

fragmede 2 days ago | parent | prev [-]

Heads up that if you're on macOS, the included version of vim, like bash, is frickin ancient. If you run into problems with vim being slow, you may want a newer version.

Homebrew's got you covered though!

▲

oofbaroomf 2 days ago | parent | prev | next [-]

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.

▲

_aavaa_ 3 days ago | parent | prev | next [-]

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.

▲

whilenot-dev 2 days ago | parent | prev | next [-]

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

▲

JuniperMesos 2 days ago | parent | prev [-]

The Visual Studio code user experience is bad - in part because it is an electron app that is not as snappy as native GUI frameworks, but also for a variety of other reasons. I do not use it voluntarily and resent that many coding tools I would like to use deliberately architect themselves as VSCode plugins rather than more general tools applicable to any editor.

I have definitely run into issues with the UI not visually keeping up with keystrokes in VSCode (occasionally), and also other Electron apps (more often - perhaps they haven't had as much attention to optimization as VSCode has). For this reason alone, I dislike the Electron ecosystem and I am extremely interested in projects to develop alternative cross platform renderers.

Ultimately I would like to see Electron become a dead project so I never have to run into some interesting or useful or mandatory piece of software I need to use that was written using Electron because it was the most obvious choice for the developer.

▲

2 days ago | parent | prev [-]

[deleted]