Stupid Slow: The Perceived Speed of Computers | Hacker News Reader

Stupid Slow: The Perceived Speed of Computers

datagubbe.se

97 pointszdw94 comments

I’ve done a 4K UHD video editor which fits on a floppy disk (1.4Mb), with 30 OpenGL effects, 10 languages, audio pluggins, and is insanely responsive (https://raw.githubusercontent.com/smallstepforman/Medo/main/...), and programmed it in 2 years working 4-8 hours a week.

But it doesnt have a spell checker for 30 languages, it doesnt have a publish to social media button, it doesnt have a video tutorial, it doesnt have a collaberative network share mode, etc.

These features add bloat and latency. That is the root cause of software slowness today. Apps from 20 years ago are still usable today, and are blazingly fast.

It's also a native app running on a lean OS, not something written in JS running on what can be thought of as a VM (Electron.)

Another cause of software slowness is all the layers of abstractions. The author uses the Amiga as an example in the article. I also had a A600 and it was quite snappy because it did a lot less.

A video tutorial by itself doesn't add an bloat or latency. It can't. (Assuming the tutorial is hosted on eg Youtube or is just a video file that you deliver with the program.)

But you are right that you need to focus on latency, if you want to keep latency down. If you add all the other features, it's hard to keep that focus.

His app appears to be written for Haiku, which is a BeOS clone. It might not come with the right codecs or embedded WebView you'd need to run YouTube. And even if it did, booting a whole browser to display a video invariably will add latency.

Well, only when you actually watch the video.

I guess our commenter meant a video tutorial available from within the application?

how is your app architected that drawing a button to publish to social media would slow your app down?

Easy: it asks you the details of your accounts on first access, and stores them in its configuration. When launched the next time, it tries to log you in automatically. It also waits for the login to complete before drawing the button, so that it can gray it out if the login fails. Then it continuously checks the network and changes the button to reflect mutated conditions: connection lost, new messages/post...

can't speak to the OPs situation, but I remember a case in mobile apps where if you wanted to let people log in with facebook you needed to depend on the facebook sdk which necessarily blocked the cold start of the app while phoning home, for analytics purposes naturally

I think this became a discussion item because facebook servers briefly went down and a bunch of apps wouldn't open

If I'm remembering it wrong, consider this a hypothetical scenario :)

> That is the root cause of software slowness today.

No. The root cause is that there's certain speed above which average user doesn't perceive much improvement, so instead of optimizing the software to be as fast as possible, it's better to stick to that speed, put all the features we need, and minimize the expenditures.

Think about it this way: do you need your video games to be at 1000FPS, or is 120 enough and you'd rather see more graphics effects or lower price?

I'd rather have 1000FPS. 1000FPS is enough for motion quality that's good enough to be mistaken for real motion, and unlike realistic image quality, all it needs is one skilled programmer. Chasing realistic image quality is so expensive that you need to target the biggest market to stand any chance of making a profit. It inevitably leads to modern game design, where everything is homogenized and dumbed down for the masses, and full of anti-consumer practices like micro-transactions and games as a service.

You, sir, are not the target audience

do you have a 1000hz monitor?

No, but I could at least benefit from reduced latency by disabling vsync. The higher the frame rate the less obvious the tearing this causes. And monitor manufacturers are more likely to produce a 1000Hz monitor if there are already games that can render that fast.

"Apps from 20 years ago are still usuable today, and are blazingly fast."

To be clear, the hardware is faster today.

I am a daily user of "apps from 20 years ago".

I have no desire to let today's software developers negate the gains I should be receiving from the new hardware that I purchase. It is as if they think the hardware belongs to them and they can use the resources as they please. The resources belong to me, not to software developers.

It is like an expanding budget allocation that has no valid justification. In the year 199x/200x, the computer owner allocated program X that does job Y a certain amount of RAM, storage and CPU resources. Today, the computer owner has more RAM, storage and CPU available. Why should the computer owner allocate more resources to an "app" that wants to perform Y today than they did in 199x/200x. What if they do not want spell checker for 30 languages, publish to social media button, video tutorial and collaborative network share mode? The computer owner is not given a valid justification for the expansion nor the choice to say, "Upon careful consideration of your proposal for a 500% increase to the RAM, storage and CPU budget for app X to perform job Y, I have decided I will allocate the same amount of RAM, storage and CPU. The budget will not be increased. Thank you." As it happens that decision results in faster, more efficient completion of Y.

Well, it's also made in C, not some modern automated-memory-managed language compiled to bytecode interpreted by a VM.

I mean, C is not my goto language by far, but handling a truckload of memory operations efficiently seems like an ideal case for it.

A big difference is that we do very little on our computers now that is actually local to the machine. A significant percentage of the “stupid slow” actions involve waiting for a server that is usually optimized for throughput not latency if it is optimized at all. A surprising number of server workloads also have high latency disk access even though almost all laptops are running SSDs. I think we could vastly improve the performance of local software if we used the network primarily for syncing data, but operated on it locally.

Even if all network activity was cached, modern software has such layered complexity vs older software that I wonder how much things would truly speed up.

It's difficult for me to gauge overall effect between network reduction (say, 1% speedup across 50 concurrent and 50 inter-dependent network calls) versus complexity reduction (1% speedup across 5 concurrent + 5 inter-dependent calls).

> I think we could vastly improve the performance of local software if we used the network primarily for syncing data, but operated on it locally.

Aside from niche tools like AI, that’s exactly how software works already

I don't know what software you're using, but the vast majority of software I use is SPAs (whether they need to or not), and need an internet connection to even load.

But that's exactly the point of SPAs - they load once and run locally even when changing "pages", syncing just data. It's just like a normal desktop app embedded in the browser page. If they expose the PWA manifest they can also be installed so that they won't require the internet even for the initial load.

The old school MPAs were the ones that required the network for every single interaction.

Reddit-style SPAs combine the worst of these features: a large initial load plus every single feature requires network interaction, because all the data is on the server anyway.

This type of SPA has invented a new version of "FOUC" as well. Because the data for the front page doesn't come with the page, you get a set of placeholder items rendered.

Yeah read-heavy apps shouldn't be SPAs. There's just nothing useful to show or do in there without data. However if a native desktop version of reddit existed it would have exactly the same problem, so it isn't really a tech issue, they just picked the "wrong" approach (probably for DX + talent pool reasons).

Perhaps SPA developers should get this memo, because 95% of SPAs should be MPAs.

Can't argue with that, because most public-facing "apps" are mostly read-only. However after a bunch of years working for a software house I can tell you that there are a lot of "non-user" reasons for choosing SPAs. The ecosystem of all SPAs offers unparalleled developer experience that allows you to create many complex apps really fast and reuse a shitload of components, interactions, animations and whatnot. With basically 0 effort you can also create mobile and desktop apps from the same code. And the talent pool for something like React is a lot bigger and a lot more "UI/UX-friendly" than in whatever "backend-tech" of your choice. I work in .NET and when we recruit devs a lot if not most of them straight up hate frontend or don't care about UI/UX at all so we kind of can't do shit with them alone anyway. It's easier and cheaper to recruit a bunch of React devs.

TL;DR: money math works in SPA's favor, users be damned

Eh, most of the components you can reuse would work OK as pure HTML components anyway, and the "create many complex apps really fast" is definitely true, except a year down the line the app is a complicated piece of spaghetti you have to rewrite. Ask me how I know...

> except a year down the line the app is a complicated piece of spaghetti you have to rewrite

Small correction from a software house perspective:

except a year down the line the app is a complicated piece of spaghetti THE CLIENT has to rewrite OR PAY YOU TO REWRITE

And with this: > most of the components you can reuse would work OK as pure HTML components anyway

I unfortunately cannot agree. It is theoretically true from pure "it's possible" standpoint but it was not my experience in pre-jQuery times. The shit backend devs did with concatenating html + JS snippets as strings wrapped in various patterns like the builder to make it configurable was pure maintenance horror. I don't miss it at all.

Some software, maybe. There's an awful lot of server-side logic in something like Slack, even for presentation-layer concerns that could be purely local.

Blame JS haters. With the resurgence of old school SSR approach like the one enabled with HTMX we will see more of that in the future. Some devs will do a lot not to touch the frontend.

I think they mean things like asynchronous updates of backend data that occasionally sync out of band. Most apps I’ve seen will make requests and not act “optimistically” on them, rather wait for the round trip to complete before continuing.

I think the reason we don’t see this much is because you have to model your entire app on this (with multiple layers of data state and primitive types that represent sync-able states) and most apps aren’t written with that much forethought.

My first distinct experience of WTF slowness was when Windows needed to verify Start Menu shortcuts to URLs or local network addresses.

One machine having a bad day could wreck the start menu for everyone on the local business LAN.

Nowadays, I still largely blame network. Seems as though everything is either verifying something over the internet before showing you the UI and/or posting telemetry on your action after you click something.

I think a lot of it is simply that systems (with the exception of games) are designed in traditional ways, which are not focused on responsiveness and frame rate for the end user.

There’s little reason most applications used by most people couldn’t do the same 100fps that almost all video games can achieve. It’s just not a development priority, and being slow and laggy doesn’t negatively affect software revenues that much.

It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies the way they did with iOS system framerates and VR/AR passthrough latency. They have obviously already done this with the stack that supports the Apple Pencil, which benefits all iOS devices to some extent. It’s astounding that a $300 iPad can scroll around a map about an order of magnitude better than a brand new $50k Tesla’s console.

Most development teams just don’t really care about latency and perceived snappiness. Google does because they learned early on that even gains of a dozen milliseconds have direct and measurable effects on their ad revenue.

> It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies

To a great extent they already do. Native Mac/iOS apps very rarely exhibit these problems (and many companies producing native Mac apps even advertise this advantage).

I don't think there's much they can do about the electron apps - they held the line a long time on iOS before letting those run in the first place.

These days I explicitly go out of my way to find and run native programs. Sure they usually require a purchase but (1) devs need to eat too (2) the software is usually higher quality and (3) it’s ultimately cheaper than buying more cool hardware.

If that fails I take whatever remaining Electron options, which is just Discord these days, and create a desktop web app via Safari or Orion. WebKit is much lighter on the system.

Now when I fire up the company machine, which is even more spec’d out, it can feel stupid slow at times.

> Google does because they learned early on that even gains of a dozen milliseconds have direct and measurable effects on their ad revenue.

That's mostly only on their frontpage. Android isn't necessarily all that snappy, for example. Nor is GMail (app nor website).

> It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies the way they did with iOS system framerates...

Any more info on this? Android vs iPhone, and Android TV vs Apple TV suggests Apple is doing something very right on these small devices.

If someone told me 25 years ago that we will write complex desktop applications like Teams using Javascript I would have been worried about his sanity.

25 years ago was 1999. The pioneer of writing desktop-like apps in JavaScript was the Microsoft Outlook team who created the XMLHTTPRequest API so they could implement a fast version of the web version of Outlook. That was in 2000. The real pioneer of this approach though was Oddpost, which created the first truly desktop-like webmail app using XMLHTTPRequest in 2002. It only ran in IE5.

Two years after that Joel Spolsky - former PM on the Excel team - wrote his famous essay "How Microsoft Lost The API War" which predicted everything would eventually be rewritten as web apps. Gmail had launched two months earlier.

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

So, even back then the trend was clear. The Windows team systematically dropped the ball / refused to believe the ball existed, and was outcompeted by much smaller teams writing browsers.

> The Windows team systematically dropped the ball / refused to believe the ball existed

Oh, they had a very good go at killing the web or trying to tie it to their existing APIs: the IE6/ActiveX era.

I'm not really sure what they could have done, though. Other than modernize away from WinForms properly; they have repeatedly dropped the ball on UI frameworks and failed to modernize all their own stuff.

Conversely, Apple appear to have "won" despite (because?) completely ditching all backwards compatibility for their APIs on multiple occasions.

Well hindsight is 20:20 so I won't be too harsh on them, but a clairvoyant Windows team could have done some serious competitive analysis to try and discern why developers were wanting to build web apps despite the clear lead the MS ecosystem had in GUI toolkit quality, developer tools, languages and even (at that time) job market for devs.

I think if they'd done that they'd have concluded:

• Devs pick the web because it means deployment+start can be one click on a hyperlink, the browser will also update your software without any prompting of the user.

• Sandboxing really matters because it's what enables the former.

• Guaranteed and easy server connectivity really matters.

• High level scripting really matters.

So, they could have e.g. tried to make a sandboxed version of Visual Basic in which the P-code you downloaded was used just for UI, with all other serious logic on the server. Maybe even using a properly client/server variant of DCOM to provide client<->server calls. Basically a kind of web browser like thing but on top of the MS stack instead of HTML. Devs would probably have found that pretty compelling.

ActiveX was the closest attempt but it didn't fit the bill. It wasn't sandboxed in any way, and ActiveX controls took forever to download because they were all native code. They definitely weren't high level and you didn't get any kind of convenient server connectivity out of the box either. Then BillG decided to do .NET and I guess code sandboxing got sucked up into that project, the Windows guys were somehow allowed to reject the whole .NET concept, and deployment wasn't sorted out for many years. Kernel level native code sandboxing wasn't possible on the Win 9x codebase and is still pretty ropey even in Win 11, so that was also out.

Apple didn't really win against the web, and their API is largely backwards compatible to the start of OS X. Also, the initial versions of OS X did contain support for both running old MacOS Classic apps in emulation, and also porting them to the new APIs whilst minimizing the size of rewrite required (Carbon). So their backwards compatibility isn't too bad.

> the Windows guys were somehow allowed to reject the whole .NET concept

What I heard was that the higher-ups pushed .NET as a core part of the OS pretty hard during Longhorn, and it failed, leading to the Longhorn development reset around 2004 or 2005.

Disclosure: I was on the Windows team at Microsoft, but long after all of this happened (2017-2020), and I never learned about Longhorn history from the inside. I don't remember sources for what I said above, though I think Herb Sutter has talked about it.

That is basically correct. All the Longhorn .NET code I'd written in the past 2 years was junked. Never understood why the concerns that led to .NET being dropped for OS development weren't addressed before development started.

Yeah I've always assumed there must have been some really traumatic experiences in the past for Windows/.NET to become so completely divorced. I mean it'd have made sense to port or rewrite a pile of all the little utilities and subsystems that aren't performance sensitive at least. But I guess the backwards compatibility story w.r.t. .NET generics killed off their interest in allowing .NET to become a part of the Windows API.

One of the few Windows utilities that was allowed to be based on .NET, in Vista and Windows 7, was Narrator, the screen reader shipped with the OS. But Narrator was rewritten in C++ for Windows 8. That was still before I got there, but of course I asked about the history, since I was on the Narrator team. I think the deciding factor for doing the rewrite was the sluggish startup of the .NET version. I guess the need to run on Windows Phone 8.1 and Windows 10 Mobile was likely another factor, though now I don't recall if my teammates specifically said that it was.

Back then performance profile of .NET (Framework) was just not where it is today sadly (even with C++/CLI there were warts, but I only know what is publicly available unlike the sibling comment).

25 years ago, Microsoft was already writing complex desktop apps using Javascript. That was a major feature of Windows 98, you could have a "HTML UI". (ofc they made it easy to call into COM for the busy stuff.) I've never used Teams, but maybe it just sucks for reasons having nothing do with UI programming?

Just because it became reality doesn't make it any less insane, though.

And you would've been right. I'm still worried about their sanity to this day. Btw it's not just devs, most regular users I deal with on daily basis hate it (be it Teams or whatever), they just don't know why it's such a crap. And they don't have to.

A fair reaction.

Also, Teams isn't written in 1999 JavaScript.

> Also, Teams isn't written in 1999 JavaScript.

I dunno how relevant that is: 1999 JS performance is closer to 2024 JS performance than 2024 JS performance is to 1999 C++.

IOW, just because 2024 JS might be faster by a factor of 2, doesn't mean it's faster at all[1] than the equivalent program written in native code.

[1] Maybe it is - I haven't checked benchmarks because programming language benchmarks have almost no correlation to reality when you use the language in a program, because the program is not doing 25k calls to the same function in a while loop.

JS aside, there's virtually a 0% chance Teams would be in C++.

It'd be in a non-native language, like C#.

JavaScript is faster than you think. Miles ahead of Python, Ruby, Perl, PHP. Not too different than C#/Java (especially if you consider 2x to be effectively the same) [1].

[1] https://benchmarksgame-team.pages.debian.net/

> It'd be in a non-native language, like C#.

True; C# is the most obvious choice for Teams.

> JavaScript is faster than you think.

I'd be very surprised.

> Miles ahead of Python, Ruby, Perl, PHP.

Depends on "miles" - I think it is within the same order of magnitude as all of those. If it's far off from being in the same order of magnitude of those, I'd be very surprised.

> Not too different than C#/Java

I don't think so, not for idiomatic usages anyway. Java and C# are pretty damn fast! ISTR that Java/C#/Go are in a different order of magnitude from JS, Python, PHP, etc.

(The link doesn't work, btw)

JavaScript (V8) is well over an order of magnitude faster than Python (CPython).

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And Java/C# is nowhere even close to an order of magnitude faster than JS.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

There is no direct comparison vs JS but C# is much[0] more capable than Java at number crunching tasks because of its low-level features.

The better showcase would be complex application code where JS cannot keep up with .NET or JVM no matter how much you optimize V8 due to dynamic typing and even simplest operations like property access needing inline caching and guards.

[0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

déjà vu all over again

(Or would C# aot and GraalVM be more to the point?)

The other links do work.

https://news.ycombinator.com/item?id=40612347

404

To me, the problem isn't the language, but the use of the web layout renderer. Because it's the one everyone's familiar with, but also the most expensive computationally, and very vulnerable to having to re-layout all sorts of things.

It's also the most powerful and flexible one, increasing the chance that whatever crazy UI ideas your designers come up with can be implemented relatively easily.

It's not far off. We got some syntax niceties and 5 slightly different and conflicting ways to concatenate .js files from different directories a.k.a packages.

Apart from standardizing some things (doesn't hugely matter for electron since it's the only target) and getting async - what has really changed?

You could maybe use that argument in 2014 but writing js now is a fundamentally different experience to what it was 10 years ago, let alone 25.

Modules, iterators, async/await, localization, proxies, regex features, Promises, date functions, generators, classes, destructuring, WeakMap, strict mode, private members, BigInt, and a hundred other things.

Check out:

https://compat-table.github.io/compat-table/es5/

https://compat-table.github.io/compat-table/es6/

https://compat-table.github.io/compat-table/es2016plus/

https://compat-table.github.io/compat-table/esintl/

---

Not to mention that fact that Teams is actually written in TypeScript (tho compiled to JavaScript).

I see really only: strict mode, weakmap, bind, typed arrays, maybe spread. (+ async mentioned earlier) The rest as far as I can see can be either written as your own function or babel-style compilation. Sure, today's code would be nicer/shorter, but... the language itself really didn't change that much, just how we use it / what we expect from it.

> babel-style compilation

"It's not a different language, because you could have another language compile to it."

This has been the situation for years though. Only recently did we get reasonable native support for most new standards by default. Babel compilation down to IE level was really common just few years ago.

Most of the "modern JS" stuff was based on that idea. Teams was released before even the modules existed in the browsers.

Also https://node.green/ which lays out features in one big list

I'm still worried about the sanity of people writing web apps. /s

One of the basic causes for slowness is how the underlying language implementation does procedure calls.

Decades ago, I looked at how Microsoft handled procedure calls and returns of data. I found the same problem elsewhere.

The problem was related to copying of data. A single API call could involve (at the time) up to 100's of copy actions of the same value for each subsequent internal call. The actual processing of that data was minimal in the scheme of things.

This has been a problem amongst many others over the decades and will continue to be so for the foreseeable future.

Things that we did as a matter of course when resources were restricted have been dispensed with once those resource limits were exceeded. The lessons have subsequently been forgotten.

DBus is just as bad (its serialization scheme is bespoke and bloated), and people insist on putting its insanely inefficient overhead into everything so they can claim they "isolated" apps (as long as you ignore the gaping holes torn for and by dbus).

Nice observation.

Stupid slowness keeps creeping in. About four months ago, "bash" on Linux started having visibly slow character echo. Some update to Ubuntu 20.04 LTS added something. No idea what. Spell check? LLM-based command completion? Phoning home?

If it happens on a remote machine, maybe this:

https://man.openbsd.org/ssh_config#ObscureKeystrokeTiming

https://news.ycombinator.com/item?id=37307708

(I hope it is, there's something ironic in John Nagle complaining about network-induced latency in interactive sessions.)

Is there anything in UX that can't be ruined by security people?

Have you tried running it with strace attached? I wonder if that would reveal something weird happening with each keystroke.

+1 to strace

I'd wager some clunky autocomplete addon for bash is causing it.

I installed some sort of nodejs plugin for zsh once and then forgot about it. One day, the shell became unusable (it was already slow when going to certain directories for the same reason). Luckily, zsh lets you trace what commands are being executed: https://unix.stackexchange.com/questions/565905/oh-my-zshs-p...

That showed that the stupid nodejs plugin was making network calls all the freaking time. Instant deleted it. That may be what's affecting you if you're a web developer.

I'd expect autocomplete to affect bash startup time rather than on every key press.

I would be a bit more paranoid about that then you seem to be

Zomg, happened for me as well and I thought am going crazy.

Around February 2024?

No just a few weeks ago, but I update very infrequently on that workstation.

I once had a fancy bash prompt that displayed git status. Turns out that git status hits the network to check the state of the remote repo, and if you are having DNS issues, that's a 30 second timeout every time the prompt is displayed.

In other words, it may not be the OS at fault here. Make sure you've double-checked all your prompt customisations and autocompletes

I don’t think it is true that git status does any remote repo access. It doesn’t match the functionality of git and git status, as git status shows the difference between the working copy and the current commit - all of which is local information. From the man page:

  Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the working tree and the index file, and paths in the working tree that are not tracked by Git (and are not ignored by gitignore[5]).

Different story if the FS is a network FS of course.

Yes, my memory may be inexact as to the specifics. I'd hazard a guess the prompt ran a git fetch first so that status accurately reflected the state of the remote (rather than just the state of the local tracking branch)

Perhaps, rather than saying that older operating systems felt faster, and then getting into the weeds debating that (or quoting cold, hard numbers) we should change our terminology: I’d say that older operating systems felt ‘snappier’, which I think is quite different from ‘faster’.

(Side note: I would do unspeakable things for a macOS 9 GUI on a modern, lean OS, plus some cloud integration. That’s all I want, until I think of something else).

I feel insane reading that older systems felt faster/snappier. Especially before SSDs everything was super slow. You'd wait for a minute to boot the system, load up a game or anything other substantial. Then of course all of the app crashes, hang ups, blue screens, kernel panics or other mandatory restarts that basically are all gone now on every major OS that we're for some reason not counting. It's super stable and fast now.

Old machines felt faster because the delays better matched our intuitive mental model of what should be difficult. Displaying a single letter when you type should be instant because that's conceptually a very simple task. Switching between open applications should be instant because you can already see them both loaded. Opening a new application can be slow, because that's equivalent to getting up and fetching a new tool from your tool box. If you wanted instant access to it you would have left it on your workbench (left it running).

What I'd like is a future where software is "stupidly fast":

1. RIIR -- for native code execution performance, and correctness

2. async rust preferably -- green threads for efficient cpu usage

3. the constraint efficiency of game developers: 16 ms window to do all your processing

4. data structures sized to fit cache lines

5. vulkan/metal rendering pipeline

oh my

(edit: formatting)

> the constraint efficiency of game developers: 16 ms window to do all your processing

This is the only one that really matters. It also implies a complete redesign of how "responsiveness" is handled, because the usual failure mode of slow GUIs is to get blocked on a whole cascade of updates which have to be done in series. Immediate mode GUIs are a lot better for this because the programmer knows that they can't call out to get some data; you render what you're given, either it's arrived on this frame or it hasn't.

When you see how slow modern CLI tools can be, you don't need all this technology. Just think of respecting human time. The only true currency of life until we invent immortality.

Reminds me of my experience learning microcontrollers last year. You strip away many of the layers of abstraction and remember just how fast computers truly are and how much work they can do every second.

Seeing this reminds me of a wonderful talk by the late, great Joe Armstrong (co-inventor of Erlang): "The Mess We're In"

https://www.youtube.com/watch?v=lKXe3HUG2l4

Stupid slow startups times are the realm of MS programs like Excel, Word and SSMS (SQL Server Management Studio). Each upgrade of these programs produces longer loading times. I can only assume there's some serious synchronous phoning home going on with ssms at least.

The article starts talking about windows, but doesn't have any examples of windows apps. I would tend to agree about the bloat, but I assume that a machine running windows 95 and 4MB of RAM was pretty responsive except for the occasional disk paging and as long as you didn't have multiple large apps going at the same time.

Software products these days are being written quick and dirty to be released as fast as possible to capture the market. Nobody has time to create quality software because by the time you finish your product, your users will already be using your competitor's product which may be horribly slow and buggy and a memory hog, but it was released a year earlier than your product. So there you go. "Release fast, improve later" is the motto of the software companies today.

I wonder if the bigger cause of stupid slowness in our current bad software is Electron, or misuse of declarative UI frameworks like React.

Reply on news.ycombinator.com