4 ms·

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

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 1y ago
> 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.
- _aavaa_ 1y ago
  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.
- grayhatter 1y ago
  > 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 1y ago
    > 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 1y ago
      Not OP, but a surprising number of senior(+) engineers at my company use default vim or neovim (no plugins or customizations)
      - fragmede 1y ago
        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!
      - locknitpicker 1y ago
- whilenot-dev 1y ago
  > 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.
- oofbaroomf 1y ago
  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.
- JuniperMesos 1y ago
  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.
deleted 1y ago
[deleted]

locknitpicker 1y ago

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

_aavaa_ 1y ago
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.
grayhatter 1y ago
> 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 1y ago
  > 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 1y ago
    Not OP, but a surprising number of senior(+) engineers at my company use default vim or neovim (no plugins or customizations)
    - fragmede 1y ago
      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!
    - locknitpicker 1y ago
whilenot-dev 1y ago
> 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.
oofbaroomf 1y ago
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.
JuniperMesos 1y ago
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.

deleted 1y ago

[deleted]