3 ms·
One eye-opening experience for me in this regard was when I installed an old version of Microsoft Excel--I think it was either the 2000 or the 2003 version--on
by torgoguys 2y ago
One eye-opening experience for me in this regard was when I installed an old version of Microsoft Excel--I think it was either the 2000 or the 2003 version--on modern hardware. The snappiness of every action was AMAZING. Every click, drag, keystroke felt instant.
It's hard to describe because modern Excel doing typical actions doesn't feel slow and prior to this experience I would have said it was immediately responding to my inputs, but the difference experienced was obvious and felt GREAT even though it was probably only a small number of milliseconds.
- MichaelZuo 2y agoThe 2010 version of Excel is significantly faster than later versions even for pure number crunching, e.g. doing some calculation over a big sheet with a million rows and a thousand columns.
- jeroenhd 2y agoMicrosoft Excel is probably also a good example for another reason. Microsoft Office 2003 Standard Edition cost $400 new, or $239 per upgrade ($664 or $397 in today's money). If you wanted Excel alone, you could buy that, for $229 (or $109 if you upgrade from an earlier version). That alone would be $380/$181 in today's money. Keep in mind that features were released every two years at the very earliest. Two years of Microsoft Teams costs $96 and gets you hosting. The question of web vs native isn't "do you want fast software or slow software" but "do you want cheap software that brings lots of features or do you want expensive software that makes you pay again to keep up with the competition after two years". Of course enterprise pricing was more generous and piracy was another factor that doesn't really come into play with Teams, but I'm not surprised all software has moved to quickly evolving web apps these days. In a time where paying more than $60 for a video game is considered controversial, $660 office suites simply aren't viable. Another smaller issue with even modern Excel over old versions of Excel is that a lot of sandboxing has been added since, and even that is proving not to be sufficient by itself. The old happy-go-lucky Excels were a one-click way into infecting a whole network because no time was wasted on boundary checks where it was not absolutely necessary to prevent the program from crashing. Web apps especially have layers upon layers of security mechanisms to prevent viruses from spreading as trivially as they did twenty years ago.
- preyneyv 2y agoHonestly, this was a big one for me too. I remember being a kid and using Office 2007 on a terrible Windows XP desktop, and things just worked. Now I'm on a "modern" machine with "modern" software, and right-click takes half a second to pop up the context menu. In the grand scheme of things, maybe not a big deal? But that's also how things get worse.
- cosmotic 2y agoSometimes all you need to do for something to feel super snappy is to disable all the animations and effects.
- rstuart4133 2y agoI've had two examples of this myself. In both cases, it was because I was unhappy with existing libraries and decided to write my own. The first was a simple Text UI for a business application. In other words forms using a text UI instead of a GUI. Underneath it was just laying out the screen with curses, and reading the keyboard, moving between fields on the form and doing basic jobs like text, number and date entry. I don't recall why we didn't use existing libraries, but it did mean we had something to compare it to. To this day remember the end result. It was blinding fast. So fast it ran far faster on a IBM PC running MMU-less Linux that any web form you'll find today. I still have no idea what the other libraries could possibly be doing to make them so slow. If you want to get a feel for the difference in todays terms, compare vim to vscode. The other thing was a web framework. None of the other members of my team had formal programming qualifications. All of them struggled with any sort of concurrency and I found myself forever fixing race conditions in their web apps. Whenever the "run the main loop until nothing changes" nature of modern web frameworks reared it's ugly head, they were lost. So I wrote one that didn't need that loop. Instead, when you changed a property, it and everything that depended on it changed when you did the assignment, synchronously. It turned you needed so much boilerplate it was ugly to use. But again, it was fast. The first remark most people made when using a SPA based on my app was how snappy it was. Everyone touts how simple and fast their virtual DOM is, but evidently that's only in comparison to other virtual DOM's. Compare to just manipulating the real DOM once and only once for each change, they are all dog slow. Then there is the difference between a Linux Desktop and the Windows 11 desktop. While I guess it happens less often than not, Windows 11 can take seconds to respond to a mouse click. Turns out that creates a cognitive load Windows uses seem to be unaware of. They have to constantly poll the interface to verify it's read for the next click or key press. You don't notice it until you move from a Linux windowing system to Windows. Then it's jarring, for a while.