The perceived speed of computers
datagubbe.se
datagubbe.se
The instant you introduce network calls that touch remote boxes, you have added a consciously-noticeable amount of lag to the operation. Yes, there are also programs which feel slow even when doing things entirely locally, but that's in a different ballgame.
Why is everything a web app these days? Many reasons. One that doesn't get enough airplay is that it's simply much harder to pirate a web app. This is not the dominant explanation, though, the real one-bit answer is non-technical end users don't have to install anything with a web app to do what they want and that massively improves one's sales funnel.
A decade plus of being able to get paid for web apps much more reliably than for local desktop applications has led to the supply of web developers increasing, and the supply of desktop GUI developers decreasing. So eventually we have even seen web app tech get retrofitted back into the traditional application market, because that's what the economics suggest is the cost-effective approach. The whole churn is fascinating to watch play out.
What drives me crazy ;) is that many software developers have no sense of what is a "reasonable" amount of time/resources to accomplish certain workloads. If they can't even tell or have never seen anything that's high performance then they just think this is normal. No sense of, how many operations per second a CPU can perform, memory and disk performance etc. The slow performance is just normalized in a team.
Right now, it takes almost a full second for our TTFB.
Compounding this is the current microservices fad combined with dockerisation of everything on top of virtualisation on top of layers of cloud virtualisation. Then someone thought: Not enough layers, let's add side-cars!
Here's a simple lesson: The typical web app is single-threaded for one user, even if it is asynchronous and has multiple servers and layers. That means that at every instant in time, at most one core is "lit up" and doing useful work for that user. While data is "on the wire" between servers, zero cores are doing useful work.
Effectively, modern web apps provide some fraction of one core of computer power for each user. The more network hops, the more load balancers, firewalls, proxies, etc... there are in the path, the smaller this fraction is, eventually approaching zero.
No amount of "scale" will make the experience of ONE user better.
This just hasn't sunk in. People look to FAANGs for best-practices guidance, but FAANGS care about billion-user scalability, which is a very unique and special problem. Their solutions are all about scaling out, and almost never about making one user's experience "scale up".
Application performance is less a technical problem than an organizational and cultural problem (at least if performance has become so bad that it starts to be annoying - e.g. I'm sure at some point in the past both Xcode and VS started much faster than now, and on much slower computers).
If the team cares about performance they will find ways to improve it no matter the technology they use, they "just" need to make time for performance investigation and optimizations. There's usually a lot of low hanging fruits to pick before switching to a more efficient tech stack will enable further improvements (and at that point you're probably deep in diminishing returns territory).
Notepad is not. The new version in Win 10 needs 3 to 5 seconds to start.
Calc.exe is also not a web app. It also needs 3- 7 seconds to start.
Today is it normal to see black region on a local program because drawing on the screen is a hard, unsolved problems.
All what matters is profit.
And that’s only going to get worse as Generative AI comes along to “help” people do development.
#1 thing we figured out is that 'raw performance' and 'perceived performance' are two very different things - we were selling raw performance, customers were buying perceived performance - perceived performance is sort of an S-shaped curve, on the left there's a flat area where it's too slow, increase it a bit, it's still to slow, in the middle there's an area where performance changes are very noticeable, and on the right there's another flat area where it's fast enough.
Getting to that middle bit first was where we made our money, once we hit the rightmost bit we were mostly waiting for the competition to catch up.
Anyway the real point I'm trying to make here is that what you're aiming for is that 'fast enough' spot, not 'fastest' - for everything, it's worth spending time benchmarking to figure out what is slow (spending the time watching someone else use it is time well spent)
My advice: work with an old Apple computer and put this against a brand new super giga overclocked Windows hardware monster. Apple focuses exactly on perceived performance first and foremost. On all my devices - MacBook Pro 13 from 2013, MacBook Air 2018, iPhone 6 - one thing is always smooth no matter what: UI interaction and transitions.
I read a lot about Apple and Google engineering and I remember that they put a priority on perceived performance first. I think there is a 300ms seconds threshold under which optimization brings in no additional benefit, however massive discomfort above this limit in that humans perceive animations as jerky, which leads to feelings of discomfort.
Jobs demanded that Apple Safari had a one or two second rule AFAIK, so that any new feature must not slow down opening up time.
Displays and chip design is also aimed at this perceived performance metric.
Windows always appears jerky and laggy to me, no matter the age or raw performance the machine got, while any Apple device is guaranteed to feature smooth UI interaction no matter CPU load.
I love it and as a product manager it became a mantra for my enterprise software SaaS platform a mantra as well. Customers love it, they feel taken care of. And that’s great.
I found myself interacting with a Windows Server 2008 VM the other day (don't ask!) and was astonished how snappy the UI was, relative to today's machines (Windows or Mac).
I think people perhaps have gotten to good at accepting the gruel they get, rather than the feast they could have. My partner tries to get me to be less frustrated all the time. She is right, of course, that this is not a helpful emotion. But I cannot concede and just accept gruel like this. Ordering plane tickets is something I dread every time.
Anyone have good ways of keeping the energy to improve and not let this affect you, despite it doing?
This applies to local apps and web apps alike. No excuses!
MS really hates their users, I think to myself sometimes, in the sense, that they do not get how much time you lose opening up an app every day and waiting for a simple spreadsheet to pop up, while on the other hand people would rave if only this was a damn fast process.
I mean, we have a guy who is really into scrum in our team, and is always chasing us to update, create or move our tickets to the correct queue/status/whatever. As engineers we are so tired of waiting for Jira to respond that we usually just give up midway after clicking somewhere and work on our tasks then forget about that tab and never complete what we meant to update on Jira.
I was on the team that managed one of the JIRA installations at Whole Foods, before the company got bought by Amazon. I remember what a good JIRA installation looks like.
Apples to apples, C++/QT will always beat the shit out of JS/Electron.
The real problem here is computers HAVE gotten too fast, so lazy shit like electron is acceptable as 'good-enough'
Perhaps the poster's perceived internet speed is also slow! :D