It's an old joke at this point that you can tell when a person first became a serious computer user based on how frequently they save their work. My muscle memory for ctrl+s is so ingrained that I type it every minute or two in things like Google Docs that literally ignore it.
This gave me shutters. Maybe it is some sort of manual transmission-type feeling of control, but that is terrifying to me. Something about that feeling of owning when the source file is changed.
I guess more analogous to your "save" mechanism would be my git commit.
So my muscle memory is a lot of ctrl-a, c.
[1] A mistake that Chrome adopted afterward and didn't reverse until 2016: https://tech.slashdot.org/story/16/05/19/2041232/google-chro...
[2] Wasn't the only cause, of course. The request could fail as well.
How did I not know about this?? And it supports Firefox + (neo)vim!
It may also make sense to cache some search data and ping some network resources, because those dialog boxes don't just show directories nowadays.
Surely I would prefer them to do those asynchronously, but the UI designers seem to all disagree.
Yes, you're right, Ctrl-S is so deeply embedded in my subconsciousness that I will be probably pressing those keys on my deathbed.
There's still lean software. Mellel (for macOS, https://www.mellel.com) is a very responsive editor, with a style edit model that's a bit different from Word. But it takes a lot of work to make something increasingly capable and keep performance.
Earlier and later versions were worse, and Outlook was horrible if you were stuck on a domain.
Excel always had issues if you were doing something stupid like using it as a database and all of the apps had issues if you were being stupid with OLE via copy/paste or were using Internet Explorer.
Or tried to use Microsoft Equation more than a couple of times inside a single document. The thing was ridiculously prone to crashing on top of producing butt-ugly typesetting.
Of course, that falls under “using OLE”, but IIRC so does using WordArt, which was rock solid (albeit much simpler and in particular incapable of in-place editing).
I remember a long, long time ago firing up Access. I quickly closed it and continued to use Excel as a database. As it was only for personal use this wasn't an issue.
I hated Access and eventually abandoned it. Meanwhile, I pretty quickly decided that Excel is the fastest and overall best Microsoft product by a mile. I now just use Google Sheets, but if you have Windows and need to do lots of spreadsheeting, Excel is just by far the way to go. Far, far better than Libre Office, Numbers, or Google Sheets.
To be fair, I was rarely dealing with more than a couple thousand rows. If it were millions, and complicated joins, maybe Access (or probably SQLite) would be better, but oh my god, how is Excel so much faster and more polished than everything else? (Rhetorical question: Joel on Software has some stories that help answer.)
Pre-web I used it for internal process automation - it required less effort than anything else (including modern capable frameworks like Rails) to provide a lot of functionality to applications with a low number of concurrent users (1-20 users).
I do really miss that - this kind of app is now often implemented with a low-code platform (with expensive consultants) or a web framework (5-10x the effort required for the same results).
Word would start in less than a second (not sure which version it was), and most features we use today were available. Adobe Photoshop 3.0 would start in less than 3 seconds, and same with Premiere 1.0.
Of course you lacked some memory protection features which could make the whole computer crash because of a single program failure, but daily experience was much better on old systems. They felt way faster because they have less input lag and because UI was less bloated.
I'm not saying 1990s computer and software were better, but they were way faster than what we use today.
Anyone can watch this video [1] to see how long it actually took to boot up or launch Word. But bootup seems to take 20 seconds, and launching Word took 7 seconds. Which roughly matches my memory.
So about an order of magnitude slower than you're describing. (The SE/30 had a clock speed twice that of the SE, but launching things is mostly bound by the hard drive speed.)
Other things like saving a 3-line Word document took 6 seconds. Quitting Word took 6 seconds. Basically, everything was pretty slow back then.
In contrast, I just tried launching Word on my M1 MacBook, and it took about three quarters of a second. While saving a file is simply instantaneous. And launching Photoshop takes 7 seconds.
Edit: here's another video [2] opening Photoshop 2 which takes a full 28 seconds.
which got slower and slower taking swap speed with it, which slowed down everything you were actually using. You'd defrag the drive regularly and that wouldn't do it so you'd have to wipe and reinstall from scratch. And that was some hours of work but like having a brand new machine again when you were done. You couldn't believe how bad it had degraded to. The good old days or selective memories?
Defragging is one of those clear cases for time shifting things from your high value time to your low value time.
I'll try to make a video on real hardware once I have time to show that I'm not exaggerating. And remember that the SE/30 is a computer from 89, so not even early 90s.
But this matches my memory as well -- Photoshop was by far the slowest program I had at the time to start up. I remember being bored waiting because it just took forever to load. While applications like Word definitely took several seconds to load, but that wasn't such a big deal.
Of course, all of this was a vast improvement over the several minutes it would take loading programs on my Commodore 64 a few years prior... from cassette tape! ;)
I used an SE/30 well into the late 90s as a kind of boutique writing appliance. I never used Word, I used BBEdit, which opened rather quickly. I always felt getting the machine up and going was faster than a standard Windows desktop.
The SE/30 was a hell of a machine. I set up an SE for a friend in the mid-90s for her to write papers on, and she really liked using it and never complained about the speed (and she did use Word). Which is saying something, because the SE was kind of a dog.
A fresh System 7 install on an SE/30 would boot from a hard drive in ~20 seconds. Adding system extensions could double this pretty easily.
In fact, I'm going to directly relate this to Wirth's Law. I think there was a brief span of years where software didn't get slower as quickly as hardware got faster. My experience of the early 90s was that my computer was slow as hell, and those of my more well-heeled friends were incredibly fast.
I mean, we all know the answer was 0. Hell, the systems you're talking about were likely not networked at all. I have a feeling that if we took all the 'slow' software we're talking about and cut out all the pieces reaching for the network in one place or another that we'd gain about an order of magnitude of speed back. Of course we'd lose about that much in functionality.
Really succinct fast code probably takes more time than verbose, slow code.
It takes me a lot longer to write small code, than big code (CTRL-C -> CTRL-V).
A big part of my refactoring, is looking for copy/pasta, and trying to do things like refine base classes or protocols, and whatnot.
Is that really the case? Are 2010 skype and 2022 discord comparable in terms of functionality? Are 2000 winamp and 2022 spotify app comparable?
Todo app 15 years ago was a simple CRUD app. Today todo app has to do CRUD, sync, offline mode, public API, integrations with popular services, collaborative projects and support 6 platforms.
People whine about bloated web tech in app, and how good it was with native while forgetting that availability and feature parity on all platforms is a feature too.
I still remember how bad it was before electron as a windows user. Half the apps that seemed cool(omnifocus, bear notes) had mac only desktop version, other(1password, evernote) had a native windows version that felt ugly and unpolished.
The present day "apps" you describe are bloated because they bundle an entire web browser and more, maybe the equivalent of a container, to run the little sliver of JS/html that presents the UI to the user.
The reason they are bundled like this is to enable web developers to work on them.
Sync was done in many ways, thanks to the app using actual files to store information. It wasn't a concern of the app itself - nor it should be. Off-line mode was the default. Public API wasn't needed. Collaborative projects is something nobody asks for in a Todo app, and of course, portability gets much easier when you have much less code to port.
Still, I could imagine apps back then having all those online and multiplayer features[0]. But even then, this doesn't add up to modern bloat. APIs, collaborative editing, sync, integrations - these aren't compute-heavy or real-time features, they shouldn't cause a big performance impact. That is, unless you're doing something stupid, like blocking on network requests, keeping state on a server, or just constantly parsing and serializing JSON (or XML).
> Are 2000 winamp and 2022 spotify app comparable?
Yes. WinAMP reigns supreme. Spotify app is hot, bloated garbage and has only a small fraction of features WinAMP offered. The entire value of Spotify is in their service part - but music streaming existed in 2000. You probably could make WinAMP stream from Spotify if you tried hard enough. I hope someone does and uses this to demonstrate what should be obvious: there's no technial justification for Spotify being so heavy, so feature-less and so bad UI/UX-wise.
--
[0] - They didn't have them, because most of those features only became useful once smartphones and mobile connectivity took off in the earnest.
The UX of those phones was pretty poor though.
[0] - SyncML.
> The UX of those phones was pretty poor though.
That... really depends. Having physical buttons was nice. I could write on those numeric keypads about as fast as I do on full touchscreen keyboard today, except I'd make less errors and could do it without looking at my fingers.
Which brings me to one piece of feature phone UX I strongly miss to this day: fixed latency. The firmware/OS was pretty much (or maybe even de facto) a real-time OS. With few rare exceptions, every interaction had consistent, fixed latency. Because of that (and physical buttons), I quickly learned to operate my phone without looking at it, or even pulling it out of my pocket. Unlock, menu, down, down, OK, [wait 1 second], down, OK, start typing... - these kind of sequences quickly became muscle memory.
All that was lost with switch to smartphones, as both Android and iOS have randomly changing and unpredictable UI latency, and the UI itself isn't fixed in space either.
I mean, kinda but not really.
Back in the day a large number of us likely had huge (exceptionally legally questionable) MP3 libraries that we managed. And while, yea having 100GB of music with just about everything was nice, it is also a major pain in the ass. So much so that Winamp pretty much died after streaming (long with legal issues in MP3s) took over the market.
Now, if the music market wasn't legally locked down, would there be better streaming apps? I believe so. So it appears we may be asking the wrong questions. Not why apps are getting slower, but why it seems the market has fewer competing apps at all levels.
This is exactly the phenomenon I recently started describing on HN with the phrase "software is resisting commoditization". It's rare these days to see an app you could use for a while and then replace with an equivalent alternative.
I think SaaS is a big driver of this - by keeping important functionality (and user data) server-side, the user ends up being locked into your software. No need to rely on IP protections - there's just no way for them to pirate the bits running on your infrastructure. And even if someone reverse-engineered your APIs and built a better frontend, the users of that alternative would still be tied to your backend, and thus your service.
This means there's no business in making alternative frontends. Instead, it's better to start your own SaaS and go after a different market slice. Even seemingly equivalent products quickly drift apart, each optimizing strongly for slightly different audience. It's easier than to fight another company over their users directly.
A tailored set of features is a good "unique value proposition" for a while, but it may be too easy for someone to eventually replicate. Taking user data hostage is better, but users don't like it very much. The best UVPs seem to have nothing to do with software.
Spotify is a stellar example here: the real value they own isn't software or infrastructure, it's all the relationships and contracts they've established in the music industry. This moat is impervious to nearly all competition - unless you're insider on the music label side, or plugged into Softbank's infinite money hose, you're not going to replicate it. Spotify, in turn, doesn't have to give a shit about its music player anymore.
How to fix this? I'm not sure if it can be. We'd need to destroy the ability for businesses to prop their software with some unique propositions that can't be easily copied by competitors. I can't see it happening without a total overhaul of intellectual property and computer crime laws. Things like Data Portability section of GDPR help a little, but ultimately there's just too many ways to create those tiny moats that make applications non-substitutable.
Why else do I have to upload my fitness/health data to see it on my smartphone in addition to Garmin watch?
The increase in resources available since 200s is measured in orders of magnitude. Are there similar increases in software features that warrant the increased bloat?
> I still remember how bad it was before electron as a windows user. Half the apps that seemed cool(omnifocus, bear notes) had mac only desktop version, other(1password, evernote) had a native windows version that felt ugly and unpolished.
Now all apps are ugly and unpolished
In my opinion - yes. Most of what Spotify provides implemented in the cloud (on server side). Client is a UI to select and stream music. Winamp supported music streaming to but didn't have an advanced UI to select what to stream. I see no fundamental reasons why a desktop app for Spotify should use much more resources. Given open API it should be possible to make a Spotify plugin for Winamp.
I haven't used Spotify desktop app but can guess it is written using electron or something like that and this is the main reason it uses much more RAM/CPU than Winamp, not because it does more work.
My experience was very different, may be because I don't care much about how an app looks but care is it allows me to do what I need to do fast. Before electron most apps followed Microsoft UI guidelines, had consistent look and feel, hot keys for most functions with basic hot keys (like save/open/help e. t. c.) consistent in different apps, low UI latency (unless the system is swapping but electron made this problem worse by using more RAM).
It's true lots of software were unreliable back in the day. But: - Crashes sometimes != Slow, bloated, and unreliable. I'd rather have something simple and responsive that crashes every now and then, than something that is aggravating to use all the time. - With the massive increase in hardware performance, there's just no excuse at all for slow unresponsive software now, especially from the big vendors. The reasons are not even usually technical; the bloat is from ads and tracking and more
> I'd rather have a search take a second or two longer if it is able to handle synonyms and different word forms.
I'm not sure people are complaining abut search being slow. Most complaints about search is that is lower quality than it used to be.
> VS Code is so much better than Visual Studio from around 2000.
VSCode and Visual Studio are two completely different products, one is a code editor, and the other is a full blown IDE. There were very good editors back in the day. And VSCode has started showing signs of a decrease in quality.
What does Visual Studio from around 2000 have that VSCode doesn't? I get that VSCode offloads a lot of work to the language server and extensions, but it offers IDE-like features including auto-completion, code navigation, and the UI is more than just code editing - it integrates version control, a test runner, debugging, etc. What is it missing that makes it not a full blown IDE?
A visual GUI designer, for example. Also a visual database model designer. Code generation too, and more
These are resource demanding features
An example that stands out in my mind is Photoshop 7, CS1, and maybe (memory is a little blurry) CS2. It felt considerably more responsive running on a thermally-non-ideal iMac with a single core PowerPC G5 and spinning rust hard disk than PS CC does today on a well cooled M-series MBP or custom built Ryzen 5950X tower with a 7000MB/s PCI-E 4.0 SSD.
That's just ridiculous. Yes, Photoshop has taken on some functionality since then but there is no excuse for anything to feel laggardly on such powerful hardware when it ran great on comparatively pedestrian machines 15 years ago.
All you need to do to prove to yourself how bad things have gotten is to find an old PC (or VM) and load up a copy of Windows XP.
The amount of bullshit between mouse click & updated photons arriving back at your eyeballs is insane in 2023. Software used to be much faster than me. Now, it is significantly slower. The only things that are reliably better are our networks and hardware.
I saw a recent talk on Blazor wherein Steve Sanderson ran through an example in an old version of visual studio. Watching how fast the project loaded actually made me depressed in a real and deep way: https://www.youtube.com/watch?v=2nRDdeIMGVo (@ 45:15)
The idea that software is slower now is nonsense, if anything it's faster in general. It's using orders of magnitude more hardware, of course, but how is that a problem?
Compare what the latest greatest word processor does vs the equivalent from the 90s to what a computer game today does vs the equivelent from the 90s. The latter is what orders of magnitude of improvement looks like.
Now, in an ideal world you could get an 'idiot' version that would meet all your needs and run nothing extra and be nice and fast. Of course now you have countless different versions of software to release and test and hope nothing fun happens. Or, you do like everyone does and releases a big old binary of fun that does everything and give QA a few less things to do.
I won't say about word process, but spreadsheets?, well not many years ago many of them would stop working at 65k rows and say tough luck, and these days we have absolutely huge datasets running in them.
If I'm not using it, why is it slowing the application down? I don't buy this reasoning. Binaries are not big in modern terms and they don't go slower for including code that never runs.
This is ignoring the plethora of bad decisions in the past we're paying for now. Your word processor is likely running in a virtualized environment in your operating system because 30 years ago running full blowin programming applications with no security in your document was a good idea. Then you'll have another layer or two of anti-virus on top of it.
> Your word processor is likely running in a virtualized environment in your operating system
Is also not a good reason.
This is what we're saying! None of the "good" reasons given for why software is slow today stand up under scrutiny!
Spending hours upon hours every day getting an app snappier and snappier and watching the VS hog making everything so slow and sad.
I don't know how much the market really has a say in this. I don't use Slack because I want to. I use it because I must. When we had open protocols, you really could choose the best client. Nowadays everything is a walled garden.
It's amazing just how poorly we've managed to make a chat application run. Across the board companies are using JS-based apps not because it necessarily leads to a better user experience but because it reduces their costs. Running a couple might be fine. Running more than that really slows things down. And developers tend to forget that most of the world isn't running a machine with the specs that they run with and many don't bother testing their stuff on machines with more limited resources.
I routinely have to kill applications when trying to build software or pair program because our video conferencing tools aren't light on resources either. I can't just add more RAM to my laptop because everything is soldered on now. That's another big difference from the past couple of decades. People could cheaply upgrade their hardware every couple of years. Now, you have to buy a brand new device, so people naturally hold on to their hardware longer. Mobile phone users are hanging on to their devices longer. Just yesterday we saw news that GitHub employees can only refresh laptops every four years. We should be working to make more efficient use of resources instead of targeting everything at the latest hardware specs.
Obviously there was old, bloated software. I think most of what people remember as being slow had a lot to do with spinning disks. I upgraded a family member's computer to something more modern not too long ago. He's pretty set in his ways and still uses old versions of MS Money and the like. It was amazing how much faster they ran. I can't know for certain, but I don't see that sort of future for JS apps. They're slow on considerably more advanced hardware. While more memory would help, more CPU cores likely won't.
I wish performance would be taken more seriously in the UX world. But, it costs less to cut corners and when you have a captive market, who cares? Once one company starts doing it, others do too, making it a race to the bottom. I'm thankful there are still indie developers building high quality, platform-native applications.
That's quite literally the market having a say.
The explosion of JS apps is a cost saving measure for vendors that given real choice, I don't think many consumers would opt for. The point is once you have lock-in and network effects, your customers don't really have much of a choice in the matter. At the very least, you can't say that's the market speaking in favor of the substandard apps any more than you can say it's the market speaking for any other choice the vendor makes.
As a related example, I'm sure people that were using 3rd party Twitter clients aren't feeling like the market has spoken and the best app has won just because Twitter killed off their API access. Their choice to stay on the platform has nothing to do with the their new-found love of the official apps.
The Linux point is interesting. I have a Linux workstation I use regularly (in addition to a macOS laptop) and sometimes the desktop integration is nice to have. I just also struggle to believe a company worth 10s of billions building tools for software developers couldn't solve the problem in any other way. It feels a bit like we let companies off the hook. Whatever misgivings people have about the UI consistency, we have plenty of Linux desktop software that runs well and developed on far smaller budgets. I could live with resource-hogging vendor software if there were open protocols or APIs in place to supplant with something of my own.
I still find it amaizing that it worked. A 486 is something like half the speed of a single core ESP32 today...
If it had 16MB of RAM, or 32, it could run better. A 486DX133 would be fine.
It's not entirely a myth. MS Word is not a representative example, though. It's been pretty awful from the start.
Today's software, on average, is very much larger and less performant than software from the olden days, and generally is not more featureful.
What is is, is cheaper to produce and modern software tends to have a much prettier (and graphical!) user interface.
With at least 20x processor speed, double the bits, and 1000x memory (let alone SSD's) I would have expected something better than what we have.
We also have better UX, more functionality, and better quality.
If people want to run the software of the mid-90s on modern hardware, I'm sure they can figure out a way. The upside is that when it crashes or you have to switch back and forth with modern software with greater functionality, the underlying system will let you do that very quickly.
Really? Do you think modern user interfaces are great? Everybody implements their widgets from scratch using html, css and Javascript. The boring old ui toolkits standardized a lot of features that are today non existent or different everywhere. For example a plain old list widget where you could select multiple items had standard ways to select ranges, to add ranges to a selection, to toggle the selection of single items, to select all of them. Most modern software doesn't have those actions. And even if it has some of them you have to find out how. Whereas such things used to be commonplace. Regularity of boring features is actually intuitive. Nice looking is not intuitive.
Install Windows 2000 and Office 97 in a VM. Word will be blazingly fast compared to the latest version. What features do you ever use in the latest version of Word that weren't present back then?
Things like word used to be much better in speed of the interface - it used to take fewer clicks to do stuff
Go open that Excel 97 with a spreadsheet containing 65,537 rows.... Oh, you can't.
People aren't building modern software that does the same set of things so attempting to measure it is much more difficult than opening up a zillon year old VM.
Most people don't care if their spreadsheet takes 1 second or 10 seconds to open. What they do care about is "Bob sent me a spreadsheet and I can't open it" or "The app crashed and lost all my data" (and technically I've seen spreadsheets crash plenty, but they tend to have a recent copy of the data saved which is eating up resources to monitor and do this). And things like "I want to hit undo 50 bajillion times".
And that is just feature bloat. There is a ton more 'just import a library' for that bloat because adding libraries is generally much easier when it comes to fixes then finding the place in your source code and fixing it.
And how quickly would the latest version of Microsoft Word start up on 90s-era PC?
Okay, so it wouldn't start up at all because the computer would not have enough memory, among other things. Let's say we built the absolute closest computer that could still technically run modern MS Office. We'd choose the absolute slowest CPU that can still boot Windows 10, the smallest amount of memory, and so on. It would still be many times faster than a 90s-era PC.
How quickly would modern Office open on that hardware? What about Office 95?
I was writing VB applications and could get the UI done in minutes, script it up and attach it to DCOM objects running on servers in hours. Whole applications done and dusted in a few days. It was easily the most productive environment I've ever worked in.
Now I'm writing Go in VSCode, and the language server + plugins + tools take forever (well, multiple tens of seconds). I have to run the UI in a browser, the server in a container, and the database in another container (with all the pain that entails). It's a mess and it's just not nearly as productive.
Usually, the truly bloated software (like a lot of edutech) is just because of regulatory capture. Most of edutech isn't judged by the market, but by committees of corrupt idiots, who always exist and for which the open market is the solution for.