Almost everything on computers is perceptually slower than it was in 1983 (2017)

> These posts fondly remember just the speed, but always seem to forget the frustrations, or re-imagine them to be something we treasured.

More to the point, I grew up with early Windows XP computers and early 90s Internet, and I don't remember the speed. Maybe I'm just too young and things were magically faster in the 80s? Maybe I was born just slightly before everything took a giant nosedive and became crap?

There are lots of things that annoy me about modern computers, but none of them take upwards of 2-3 minutes to boot any more. I remember loading screens in front of pretty much every app on my computer. A lot of my modern apps I use don't even have loading screens at all. I remember clicking buttons on apps and just kind of waiting, while the entire computer froze, for an operation to complete. Sometimes I'd start to do something complicated and just walk away and grab a snack because I literally couldn't use my computer while it ran.

There were entire joke websites like Zombocom set up to riff on how bad the loading screens were on the web back then. I would wait literally 10-15 minutes for Java apps like Runescape to load on a dial-up connection, despite the fact that the actual game itself played fine over that connection, and the delay was just due to dropping a giant binary that took no intelligent advantage of caching or asset splitting.

I can't imagine waiting 10-15 minutes for anything today.

I got a low-key allowance out of going to other people's houses and defragging their computers. Do you remember when Windows would just get slower over time because there was an arcane instruction you had to run every year or so to tell it to maintain itself?

> On the library computer in 1998 I could retry searches over and over and over until I found what I was looking for because it was quick Now I have to wait for a huge page to load, wait while the page elements shift all over, GOD FORBID i click on anything while its loading

What library were you going to in 1998? I also did library searches, and they were insanely slow, and prone to the exact same "don't click while it loads" behavior that the author is decrying here. And that's if I was lucky, sometimes the entire search engine would just be a random Java app that completely froze while it was loading results. And forget about giving me the ability to run multiple searches in parallel across multiple tabs. Whatever #!$@X cookie setup or native app they were wired into could never handle that.

The modern database search interfaces I have today are amazing in comparison. I have annoyances, but you couldn't pay me to go back in time. A lot of those interfaces were actively garbage.

Again, maybe I'm just too young and everything took a nosedive before I was born. But even if that's the case, it seems to me that interfaces are rapidly improving from that nosedive, not continuing to slide downwards. The computing world I grew up in was slow.

To me, this the major paradigm shift is away from native clients to a model that, at the very least, allows for the entire client to be re-downloaded every time the application is loaded, which is the case in the current web app landscape.

Even if the entire application is stored locally, the goal is frequently on code reuse with systems like React, so it is still baked into the design.

We talk about function keys being missed--but the fact is, one of the main issues is that your web browser already makes use of many of these keys. This is not a problem with the web app you are using, but with the fact that you are using a web app, which is a client running within your browser, itself a native client.

Simply returning to native desktop clients for productivity software would be a huge step in the right direction. There are economic incentives not to accommodate this user need, however. Developers need to offer cloud-based, app-based access to their services in order to remain competitive. For many companies, it is built into their SaaS business model! If you develop a productivity application professionally, you would need to believe that the existence of the native client (and all of the resources and man hours it consumes) will give you a meaningful competitive edge. The benefits to users are obvious to developers who have time to reflect on it, and to the users running a POS system, but not to the people several levels above the POS operator who are making decisions. For them, a cloud system that centralizes access, control, and supervision works better for them.

I had a job recently where I had to do data entry for a lot of invoices into a intranet cloud system. The system was slow; fields had bugs that literally caused the text to be entered backwards for some reason (seriously)... and it sucked for me. But for our business partner who was a majority owner of our main asset, it affords them control, centralization, and remote administration.

I actually agree with the OP aesthetically, but it dwells on the POS operator and forgets the hidden user-- POS operator's managers and business ownership.

I will also say that to those of you who feel anti-javascript--an SPA is much better at managing stateful applications than dynamically pages generated by the server, and I'd much prefer to minimize chat between client and server where possible, which SPA frameworks do afford.

I think the whole thing could be improved by better support for native-style applications in the browser, possibly running in some "native mode".

The last thing all say is that windows are nice for multitasking, but they do represent a significant cognitive load to manage, and you can't usually do it from muscle memory. I remember teaching my grandparents to use AOL in around ~2000, and I literally had to make exercises for them to try to establish "object permanence" with windows that were hidden. The interface appeared flat to them, and they didn't intuitively grasp that another window jutting out behind another was a part of a separate interface altogether. They got it eventually, but it is the type of thing that is easy to forget when we live our lives enmeshed in window based operating systems. But look at phones--they don't have window-like functionality even after all this time, with bigger and better screens, multi-core processors, etc. Why? Because we still consider a phone to be a "device". It's capable of multitasking, but we subdue that aspect of the interface in favor of focus and usability. Terminal applications are similar in that respect, and I think that's why people find them attractive in some contexts.

To anyone who feels strongly about this, I'd say: Develop a beautiful productivity app for native desktop usage. Market it. Make people fall in love with it. A deluge of such apps may promote a reversal of this trend.

Yes but the flip side of it is that it takes more time now to restart an Adobe application than it took to reboot the machine in the 1980s

As the OP who wrote this while drunk two years ago and thinks that about 30-50% of it is objectively wrong, it's extremely funny to me that every five months someone reposts it here and everyone gets in a fight about it again. Many of the details are entirely inaccurate - the thesis is still completely valid, and it's Computer Person Thinking that wants to attack the details while refusing to stand back and look at the overall picture, which is that using computers is now an incredibly messy experience where nothing quite does what you want, nothing can be predicted, nothing can be learned.

I hypothesize that this is because programmers and other various Computer People consider "being on the computer" to be a satisfying goal in itself that sometimes has positive side effects in the real world, while everyone else simply has stockholm syndrome and has long since given up on even imagining a better experience.

> Your sentence starts out like you're stating a fact, but then peters out with "probably."

Fair enough. I'd argue that I put the word probably in the first half of the sentence, so I don't see it as "petering out", but fair enough.

I will agree with the critique that I'm making an assumption about mapping use cases, and don't have hard data. I'm happy to be corrected by any real data on the topic.