Yes, there are so many examples of this .. a recent one for me, is iStatMenu .. it just got to the point that waiting for it to start, alone, was sufficiently boring enough that I sought an alternative .. and of course, I realized, there's no reason not to use the Linux tooling I'm accustomed to, and so I have btop where iStatMenu used to live, kinda. btop doesn't get in the way, doesn't phone home, doesn't check a registration key, isn't harvesting key clicks, and .. so on .. its just small, light, and fast.
Well, with the encumbrance of it living in a terminal window, but I also live in the terminal window even on MacOS, so its a feature not a bug.
Point is, I wouldn't have this to say about it if iStatMenu had just been a little more discrete about its loading times ..
When it comes to navigating (except public transit), hiking, and route building, Organic Maps[1] is very good. OSM data and offline-first is the way forward for detailed and _fast_ map experience.
For cycling route building I have to mention BRouter[2], which allows you to write a custom cost function that is used to tweak your route preferences.
I remember an engineer I talked to recently saying that OSM didn't have sufficiently up-to-date data for their routing use case -- new roads, closed roads, traffic data, etc. Is that the case?
The neglected part here is latency, speed itself can be masked
by progress bars/animations, but having visible lag ruins the idea
of speed and users treat it as slow vs animated loading bar.
Maybe it's me who's weird, but I find animations as much worse - it's basically pointless and wastes slightly more time (even when program is fast enough!).
The interface without animations feels snappier even if sometimes it takes a second to load. I disable any and all animations in software that I can - particularly in Android (via developer settings) and Linux (i3+vim vs something like KDE+VScode).
Some tiny amount of animation is needed to show that the system has responded.
I regularly use a website in which a submit button does not change state in any way. It is indistinguishable from the click having gone to /dev/null. And the completion of the action takes a copule of seconds.
It's literally, "no response ... few seconds ... oh, done!"
If the button simply responded in the usual way, like 3d poppin in and out effect, it would be better. The UI can change state also to show some "wait ..." text.
These are examples of animations, just not progressive/persistent.
I run headless Alpine Linux (a minimal distro) in my homelab and it’s fast AF. The lag in Windows Explorer is sad when something like cd folder/folder is instant in Linux.
I really don't understand how you can even create software that feels as bad to use as Windows Explorer. It's like it's barely attached to reality. There's this weird floaty delay in everything. You copy a file, or did you? You're not sure. It hasn't updated yet. Oh, now the copy dialog appears with this progress bar that isn't showing progress. The dialog just sits there. Is something happening? I don't know. Many seconds later the dialog closes. But it hasn't showed up in the window yet... oh, now it did!
How is that even possible, especially with modern hardware? Like you'd almost have to build the file explorer around like a sqlite-based message queue with a 1500ms poll interval to get performance characteristics like this. Absolutely insane feats of architecture astronautism are no doubt required for this to happen.
>I really don't understand how you can even create software that feels as bad to use as Windows Explorer.
I was wondering how bad a sign it was when the decline in performance between Windows 95 and Windows 98 was detectable in many ways, but nobody was complaining because it was not always noticeable on PCs that were 3 years newer. You had to figure Microsoft developers had way better PCs than that, and didn't have any clue at all.
Turns out my suspicions were correct, it was the insidiously ignored ramp-up to exponential amounts of sluggishness as time marches on.
To be fair, cd folder/folder is also instant in a command line in Windows, it's just the GUI aspects that are slow. Comparing Windows Explorer to a terminal is comparing apples to oranges.
I don't think so. Windows is a GUI first OS, and Linux is a CLI first (or even CLI native) OS. You can't open a command line window in Windows without loading more than half of the desktop stack.
In that sense, when a terminal (running on a desktop environment) in Linux is faster than Windows Explorer, it's a shame. When a big file explorer like Dolphin drives circles around native file explorer of Windows, that's a big ole embarrassment.
I don’t think I’ve ever noticed a difference in speed on the terminal between distros. Shells (or more accurately, plugins / frameworks - I recently gave up oh-my-zsh in favor of zimfw for that reason), yes, but not the terminal itself.
Shout-out to PowerSync for making it easier to develop fast offline-first mobile apps. It pushes data from Postgres/MySQL/SQL Server subscriptions to a SQLite into the user's mobile device, avoiding the need for many loading animations when the data is there ahead of time. My company is a customer and we recommend it.
I fully agree. I loathe slow software. I hate bloat. I love fast software. As a developer, I'm completely, even irrationally, obsessed with speed, performance optimization, and profiling. I wish more developers felt the same way.
The sad part is that most employers don't care particularly about performance optimization skills (the economics don't work out, they can often just fix the problem cheaper with more hardware—and even if they can't, they mostly don't bear the cost themselves).
The fun part is that when your employer _does_ care about software optimization, few people are actually good at it and your skills are more exclusive :-)
OP is probably referring to many engineering managers who think it is irrational to spend an hour in order to speed up a computing task that only shaves a few milliseconds off.
Even when that software is widely used so the few milliseconds add up to thousands of hours in collective time savings. 'We don't pay for user's time, only your's', is the attitude. Again 'irrational'.
I think it's the different feeling you get from using an end-to-end streaming service (compute, not videos) versus the one that does a lot of intermittent buffering. It's quite subtle actually. Using a vanilla language model can feel like that if it's also sufficiently small but they are going towards the opposite direction very rapidly now because cloud.
Fast and efficient software varies depending on the local context, but for me, I think I'd be fine with something slower as long as it's convenient enough. After all, once it passes a certain threshold, I can barely even notice the speed difference anyway.
I wonder what OP's thinks of IDEs like VSCode. Would they see it as heavy and not great because it's Electron-based? But I find IDEs convenient.
Yes, there are so many examples of this .. a recent one for me, is iStatMenu .. it just got to the point that waiting for it to start, alone, was sufficiently boring enough that I sought an alternative .. and of course, I realized, there's no reason not to use the Linux tooling I'm accustomed to, and so I have btop where iStatMenu used to live, kinda. btop doesn't get in the way, doesn't phone home, doesn't check a registration key, isn't harvesting key clicks, and .. so on .. its just small, light, and fast.
Well, with the encumbrance of it living in a terminal window, but I also live in the terminal window even on MacOS, so its a feature not a bug.
Point is, I wouldn't have this to say about it if iStatMenu had just been a little more discrete about its loading times ..
> Google Maps has gotten so slow
When it comes to navigating (except public transit), hiking, and route building, Organic Maps[1] is very good. OSM data and offline-first is the way forward for detailed and _fast_ map experience.
For cycling route building I have to mention BRouter[2], which allows you to write a custom cost function that is used to tweak your route preferences.
[1]: https://organicmaps.app/
[2]: https://brouter.de/brouter/index.html
I remember an engineer I talked to recently saying that OSM didn't have sufficiently up-to-date data for their routing use case -- new roads, closed roads, traffic data, etc. Is that the case?
No. It's their route function which sucks compared to Google maps. Their data is better and newer.
Cool! I'm guessing no traffic data in organic maps? I'd still install it to use as a backup.
https://www.cycle.travel is also excellent for cycling routes. Made by a solo developer as far as I remember.
The neglected part here is latency, speed itself can be masked by progress bars/animations, but having visible lag ruins the idea of speed and users treat it as slow vs animated loading bar.
Maybe it's me who's weird, but I find animations as much worse - it's basically pointless and wastes slightly more time (even when program is fast enough!).
The interface without animations feels snappier even if sometimes it takes a second to load. I disable any and all animations in software that I can - particularly in Android (via developer settings) and Linux (i3+vim vs something like KDE+VScode).
Some tiny amount of animation is needed to show that the system has responded.
I regularly use a website in which a submit button does not change state in any way. It is indistinguishable from the click having gone to /dev/null. And the completion of the action takes a copule of seconds.
It's literally, "no response ... few seconds ... oh, done!"
If the button simply responded in the usual way, like 3d poppin in and out effect, it would be better. The UI can change state also to show some "wait ..." text.
These are examples of animations, just not progressive/persistent.
As a kid I liked the interfaces that lagged badly, but still accepted input perfectly.
It felt like I was racing. Type the whole message before the screen updates? Check.
I miss AOL sometimes.
I run headless Alpine Linux (a minimal distro) in my homelab and it’s fast AF. The lag in Windows Explorer is sad when something like cd folder/folder is instant in Linux.
I really don't understand how you can even create software that feels as bad to use as Windows Explorer. It's like it's barely attached to reality. There's this weird floaty delay in everything. You copy a file, or did you? You're not sure. It hasn't updated yet. Oh, now the copy dialog appears with this progress bar that isn't showing progress. The dialog just sits there. Is something happening? I don't know. Many seconds later the dialog closes. But it hasn't showed up in the window yet... oh, now it did!
How is that even possible, especially with modern hardware? Like you'd almost have to build the file explorer around like a sqlite-based message queue with a 1500ms poll interval to get performance characteristics like this. Absolutely insane feats of architecture astronautism are no doubt required for this to happen.
It’s probably got phone home a few times to to make sure they’re measuring user engagement
>I really don't understand how you can even create software that feels as bad to use as Windows Explorer.
I was wondering how bad a sign it was when the decline in performance between Windows 95 and Windows 98 was detectable in many ways, but nobody was complaining because it was not always noticeable on PCs that were 3 years newer. You had to figure Microsoft developers had way better PCs than that, and didn't have any clue at all.
Turns out my suspicions were correct, it was the insidiously ignored ramp-up to exponential amounts of sluggishness as time marches on.
You know, like a snail without a shell :(
To be fair, cd folder/folder is also instant in a command line in Windows, it's just the GUI aspects that are slow. Comparing Windows Explorer to a terminal is comparing apples to oranges.
I don't think so. Windows is a GUI first OS, and Linux is a CLI first (or even CLI native) OS. You can't open a command line window in Windows without loading more than half of the desktop stack.
In that sense, when a terminal (running on a desktop environment) in Linux is faster than Windows Explorer, it's a shame. When a big file explorer like Dolphin drives circles around native file explorer of Windows, that's a big ole embarrassment.
I don’t think I’ve ever noticed a difference in speed on the terminal between distros. Shells (or more accurately, plugins / frameworks - I recently gave up oh-my-zsh in favor of zimfw for that reason), yes, but not the terminal itself.
Also called: "Death by PM"
Esp. known from Microsoft, Adobe, Google. Should be added to the Antipatterns repo
Shout-out to PowerSync for making it easier to develop fast offline-first mobile apps. It pushes data from Postgres/MySQL/SQL Server subscriptions to a SQLite into the user's mobile device, avoiding the need for many loading animations when the data is there ahead of time. My company is a customer and we recommend it.
If the software is fast as a byproduct of being simple, that tends to align with correctness.
If it is fast because it is optimized, then that does not align with correctness, because optimizing something that works only adds risk.
I fully agree. I loathe slow software. I hate bloat. I love fast software. As a developer, I'm completely, even irrationally, obsessed with speed, performance optimization, and profiling. I wish more developers felt the same way.
The sad part is that most employers don't care particularly about performance optimization skills (the economics don't work out, they can often just fix the problem cheaper with more hardware—and even if they can't, they mostly don't bear the cost themselves).
The fun part is that when your employer _does_ care about software optimization, few people are actually good at it and your skills are more exclusive :-)
Irrational how? What higher values does it undermine for you to make fast software?
OP is probably referring to many engineering managers who think it is irrational to spend an hour in order to speed up a computing task that only shaves a few milliseconds off.
Even when that software is widely used so the few milliseconds add up to thousands of hours in collective time savings. 'We don't pay for user's time, only your's', is the attitude. Again 'irrational'.
There are dozens of us! Dozens!
Shout-out: Voidtools Everything on windows. Lightning fast file search.
I think it's the different feeling you get from using an end-to-end streaming service (compute, not videos) versus the one that does a lot of intermittent buffering. It's quite subtle actually. Using a vanilla language model can feel like that if it's also sufficiently small but they are going towards the opposite direction very rapidly now because cloud.
I will read this entire article tomorrow while I wait for the Cursor UI and Visual Studio to finish loading.
No, no software is the best software.
BTW, the title should say "(2019)".
But that's an example of fast software: how many nanoseconds does it take to run zero instructions?
Best solution is no software, or as little code as possible. But that the best software is no software isn't very practical or actionable :)
No code is faster than no code
Faster at doing nothing?
No way I wanna chat with my oven
Got any burning questions today?
Maybe a few half-baked thoughts.
Fast and efficient software varies depending on the local context, but for me, I think I'd be fine with something slower as long as it's convenient enough. After all, once it passes a certain threshold, I can barely even notice the speed difference anyway.
I wonder what OP's thinks of IDEs like VSCode. Would they see it as heavy and not great because it's Electron-based? But I find IDEs convenient.
Remove the specter and friends mitigations from your linux kernel, and your system will be significantly faster.
Honestly, I'm in partially disagree camp. What matters is how much time it saves.
A good WYSIWYG editor will run circles around the fastest text editor. Even if WYSIWYG is a bit slower to open.
It would be preferable for software to be more focused and faster over time, but that doesn't attract people to it.
Slop or not, I enjoyed reading it. And could relate.
Previous discussion in 2019 https://news.ycombinator.com/item?id=20517144