Why modern software is slow

I'm a game developer and game performance is better than ever. 144 Hz monitor? 4k? We got you covered. Even ray tracing and VR is on the way.

Most games render frames of a 3D world in less than 17ms, but most websites take 3-7 seconds to load because of all the ads and bloat, and things shift around on you for another 20 seconds after that, so when you go to tap a link you accidentally tap an ad that finally loaded under your finger. If you optimize those websites, they run super fast though, but it's quite a pain to do with the dependency bloat in modern tech stacks...

(note: games lag as well when you drag in a million dependencies you don't need)

The thing is, most sites and web apps try to solve a user problem, and if you are the only company in town that solves that problem, then performance barely matters - what matters is solving the problem. The users will put up with some pain because the problem is even more painful.

With games, it's all about the experience of interacting with the software - so performance is (hopefully, depending on your team and budget) amazing.

That, and... performance tuning is hard work, and I think most people don't know much about it. It's a fractal rabbit hole. Cache misses, garbage collection, streaming, object pooling, dealing with stale pointers, etc. Even I have a ton to learn, and no matter how much I learn, I probably still will have a lot more to learn. It's easier for many teams to hand wave it I guess as long as they aren't losing too many customers because of it.

> For most software, functionality, signing up for a subscription, platform availability etc are usually prioritized higher than response times and keyboard shortcuts.

This is why I love working in fintech. The engineering is paramount. Customers will not accept slow or buggy software.

I get to solve hard problems, and really build systems from the ground up. My managers understand that it is better to push back a deadline than to ship something that isn't up to standard.

The way that game developers get their performance is more or less orthogonal to the way many other applications are expected to function.

It is impressive that they can draw so much stuff so fast, but there are actually very few objects on the screen that the user can directly interact with.

A specific example: in a DAW, you might have tens or even hundreds of thousands of MIDI notes on the screen. These look like (typically) little rectangles which are precisely the short of thing that games can draw at unbelievable speed. But in a DAW (and most design / creation applications), every single one of them is potentially the site of user interaction with some backend model object.

All those complex surfaces you see in contemporary games? Very nice. But the user cannot point at an arbitrary part of a rock wall and say "move this over a bit and make it bigger".

Consequently, the entire way that you design and implement the GUI is different, and the lessons learned in one domain do not map very easily to the other.

> Alternative hypothesis: (brace yourselves) people don't care enough. Any vendor will prioritize requirements, if performance is not in there, that CPU and memory is going to be used if in any way it helps the developers. Conversely, by looking at a system you can infer its requirements.

I think most of all, it isn't sufficiently visible. Most development is done on high powered hardware that makes slow code very difficult to distinguish from fast code, even though you can often get 10x performance improvements without sacrificing readability or development effort.

Individually it's just a millisecond wasted here and there, but all these small inefficiencies add up across the execution path.

Here's a fun benchmark to illustrate how incomplete beliefs like "compilers are smart enough to magically make this not matter" can be:

https://memex.marginalia.nu//junk/DedupTest.gmi

It's a 50x difference between the common idiomatic approach and the somewhat optimized greybeard solution, with a wide spectrum of both readability and performance in-between.

If you put zero thought toward this, your modern code will make your modern computer run as though it was a computer from the late '90s.

> This proves (anecdotally) that performance isn't unacheivable at all, but rather deprioritized. Nobody wants slow apps but it's just that developer velocity, metrics, ads etc etc are higher priorities, and that comes with a cpu and memory cost that the vendor doesn't care about.

I saw a project that had a very clear N+1 problem in its database queries and yet nobody seemed to care, because they liked doing nested service calls, instead of writing more complicated SQL queries for fetching the data (or even using views, to abstract the complexity away from the app) and the performance was "good enough".

Then end result was that an application page that should have taken less than 1 second to load now took around 7-8 because of hundreds if not thousands of DB calls to populate a few tables. Because it was a mostly internal application, that was deemed good enough. Only when those times hit around 20-30 seconds, I was called in to help.

At that point rewriting dozens of related service calls was no longer viable (in the time frame that a fix was expected in), so I could "fix" the problem with in memory caching because about 70% of the DB calls requested the very same data, just in different nested loop iterations. Of course, this fix was subjectively bad, given the cache invalidation problems that it brought (or at least would bring in the future if the data would ever change during cache lifetime).

What's even more "fun" was the fact that the DB wasn't usable through a remote connection (say, using a VPN during COVID) because of all the calls - imagine waiting for a 1000 DB calls to complete sequentially, with the full network round trip between those. And of course, launching a local database wasn't in the plans, so me undertaking that initiative also needed days of work (versus something more convenient like MySQL/MariaDB/PostgreSQL being used, which would have made it a job for a few hours, no more; as opposed to the "enterprise" database).

In my eyes, it's all about caring about software development: either you do, or you don't. Sometimes you're paid to care, other times everyone assumes that things are "good enough" without paying attention to performance, testing, readability, documentation, discoverability etc. I'm pretty sure that as long as you're allowed to ship mediocre software, exactly that will be done.

I think people care but there are no alternatives. My 3 month old Windows 11 machine with a Ryzen 5700 and an RTX 3080 regularly starts chugging on stupid things like moving a window, chrome will randomly just peg a cpu with some sort of "report" process, and visual studio locks up when the laptop awakes from sleeping. Id drop it in a second but for what? Mac sucks for game development, has the same issues with too many weird background processes, and linux distros never seem to work on laptops well, even ones designed for it (system 76 for instance). The aren't real alternatives.

One of the reasons users don't care is that they have no expectations of quality. It's painful to watch non-tech people use software written by incompetent developers, like Teams. You'd literally see someone type, then Teams UI would hand. They would pause typing and patiently stare, hands on keyboard. UI would unfreeze 3 seconds later, they'd keep typing. To me this is insane, but people are used to it / have been trained to expect it and consider it normal, apparently. Just like (a somewhat more reasonable) expectation that things need to be restarted in an escalating sequence if something is not working.

If I could go back in time and make one change to the history of computing, I'd add code to every consumer-facing GUI OS that would kill-dash-nine any application blocking UI thread for more than say 200ms. And somehow make it illegal to override for any consumer software, or if I were God make it so any developer trying to override it to let their software be slow gets a brain aneurysm rendering them (even more) incapable of writing software and has to find work digging ditches.

Bad alternative hypothesis. The implemented approach with recursive search is more complicated than just enumerating the files in the Sound recordings directory. A singular focus on requirements would have resulted in the easy solution that's also more efficient.

This is sheer stupidity: a more complicated, less efficient solution to a simple problem.

> 30 years ago, nobody in their right mind would have thought "du'h, I'll just recursively scan whatever directory THIS environment variable points at and then apply whatever this library does to each file in it to get some list and then extract the files I need from that list"..

I think plenty of people would have made the error of filtering after applying an expensive operation than before. This seems like a classic rookie mistake, not an indication of some paradigm shift in thinking. What was impressive was that no one at Rockstar thought of improving the loading performance for so long that a use decided to reverse-engineer it.

Alternative opinion here, 30 years ago games/software were much simpler. I assume we did not have conglomerates like Rockstar and EA who pushed their employees beyond their limits. Game industry is notoriously known for exploiting programmers.

Imagine being a SWE working 12+ hours a day 6 days a week getting no rest. I might have accidentally coded something like this so that I could go home a couple of hours earlier.

Yeah, I don't buy it. I've been programming for more than 20 years, and I'm pretty sure people were making the same complaints 20 years ago that this article and you are making now.

For some software, performance is important. For others, it isn't. Some developers are good, at least at making performant software, some are worse. That's always been true and will probably always be true.

Funny enough, if you read the guidelines for Metro apps (or Modern apps, or UWP apps, or whatever the hell they are called now), Microsoft specifically says that you should offload all expensive operations to an async thread and keep the UI thread free so the interface can be quick and responsive. When I was making my first apps in university, they would routinely reject them from their app store saying the UI is not responsive enough. You'd think they actually care about efficiency and responsiveness.

But then they hardcode a whole Documents directory scan right in the UI thread in their own damn voice recorder app. Unbelievable.

> It used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result.

We didn't used to have product teams as large as engineering teams. You can still engineer software the way you want, you're just beholden to some product persons idea about deadlines now. If you can turn your little unit of work around quickly no one will bat an eye (of course, we all know that's not realistic most of the time). If you dare trying to take longer than their perception of how long it ought to take then you better be prepared to discuss the "value add" of your performance minded solution as nauseum.

We went from ”premature optimization is evil” to ”optimization is evil”

30 years ago, much (UNIX) system software was built out of calls to system(), ie it would have shell commands do most of the steps. Partly this is because it is hard to do everything in C and partly it is just laziness. This is partly the reason for terrible security (the IFS environment variable could be changed to change the meaning of the system() calls and trivially make a suid program do bad things).

I think you’re giving programmers of the past too much credit.

I disagree, software has always sucked. We can remember lots of the good software, and back how things used to be but the reality is this is nostalgia speaking.

A perfect example is windows 95 - wiggling the mouse causes a huge speedup in long running applications [0].

> used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result.

That "tricking" came with lots of issues. Massive security holes, significant app stability issues, and hugely increased developer time to implement things. I can get a hardware accelerated Sha1 hash of a buffer in one line of c++ today, and I know it will be correct.

People who do that work still exist. Computers are fast enough that it's worth not spending hours optimising for every allocation when you're displaying half a dozen strings on screen, but people like Casey Muratori, Bruce Dawson, still exist and still write code.

[0] https://retrocomputing.stackexchange.com/questions/11533/why...

I was writing an NMEA parser today. (NMEA 0183 is a common serial GPS data protocol) My serial port reads returned an IOvec-like type which exposed limited operations. I spent probably an hour making helper functions and doing various verification and parsing operations on the IOvec type because it saved having to copy the data into a contiguous buffer. Midway through I stopped and realized that I would only need to copy when the ~50B message straddled the end of the ~64kB buffer. It takes a few nanoseconds to copy 50B. I spent an hour on an optimization that would never do anything but complicate the code. If I had just written the simple and obvious code, and spent that hour profiling the application to optimize what would actually make a difference, I'd be much better off.

That is what the quote is talking about. I don't think you can blame the quote if people are just ignoring the first word, and I'm not convinced that's actually a common thing.

Virtually every single performance thread on stack exchange has that one guy that says regurgitates something about premature optimizations and maintainability eg

Q "I'm working on high throughput data science thing, is branchless math better than conditional instructions here, because this thing needs to take less than a lifetime to finish"

A "You should focus on code readability, it's way more important ..yadeyadaya ... i work on python and websites"

I blame slipping standards in CS programs and the entire concept of "information science"

Also the "developer's time is expensive" belief pushes developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with the goal of application, but hey, it's cheaper to just slap something on the existing packages and ship it. The "expensive parts" are pushed to the end users.

Yup. There surely is such thing as over-optimized, early-optimized, over-clever, over-terse, over-engineered, over-abstracted, etc. But in terms of actual impact in the software ecosystem, the simple problem of not-good-at-programming still blows them all out of the water, combined.

It's important to be able to recognize which of the two echelons of problem-space one's codebase inhabits.

It's a great maxim but it's misapplied.

What's ironic is premature optimization is not just code, using K8s or expensive cloud solutions when a bare metal dedi will suffice. etc.

Instead it's just parroted by people who want to churn out MVP quality code in prod.

Well, modern programmers more often think "optimization is the root of all evil". I read an article that literally recommends not to optimize until the end.

Nobody wants to do post-mature optimizations, as in never touch a running system.

No one will say thank you for fixing something, but everybody will blame you if you fail trying.

""premature optimization is the root of all evil" is the root of all evil."

I like your take that human tolerance is the limiting factor. I'd agree that is a major constraint. The rest of it is just economics.

When I started programming, people I learned from would optimise code in assembler, use clever algorithms and write highly unreadable code that was impossible to debug. One bit of code I remember interleaved various operations so that it's access would line up with disk reads. I rewrote it to just hold the data on memory. It wasn't much faster than his disk based code in practice.

But the only reason to go to that kind of effort was the severe constraints hardware placed on software. When those are largely removed, the imperative is to write code fast that other people can still understand.

I think part of it is the terrible software people are forced to use at work, which is bought by people who only look at feature lists and price. This stuff eats away at their expectations until they are OK with bloated stuff like discord for private use too.

I have almost 15 year old CPU with 2 GB RAM and Intel Core 2 Duo processor. It has Windows 7 installed. I recently opened it again and was amazed to see that it actually works and it is also very snappy by current standards.

This is why some people want to still use DOS and Win 3.1 because it is faster.

I run Win95 and Win2000Pro in a virtal machine with old software and it runs faster than the most recent versions.

I put Ubuntu on a Lenovo PC and it runs faster than Windows 10 did.

I had a experiences both with a very very old win95 box and an old linux 2.4 kali usb key.

The linux one was strange because my arch/systemd/ssd/i3 setup is lean, you get parallel boot, no heavy DE no bloat.. but everything felt lighter and faster on kali and I had a physical reaction saying "I don't miss anything from my current laptop, that old thing was closer to my needs".

Maybe a part of our brain that doesn't care about typography or visual effects much and prefer good old crude solid lag free tools.

I recently had the pleasure of installing OS9 on a classic 2001 iMac – the "lampshade" one, though I don't think that nickname does it justice!

I was, and am, blown away by how responsive it is. Plus, the UI sound effects add to the experience in a great way. You can HEAR when you've done something "in the computer." Just a bunch of clicks and boops. It's fantastic. Makes you think about what we've just... gotten used to.

Speaking of Windows: Microsoft PMs stupidity can never be matched by declining SW development efforts, even with better HW.

Here you cannot really blame the poor developer, when the PM demands to scan all Documents, not just some relevant sound recordings. It's so obviously insane, that only PM's get away with this. Of course the dev matched our PM here, with his insane directory iters, but alone the idea must be appreciated first.

I think the issue is actually the sandboxing and other stuff. WinRT StorageProvider API is known to be extremely slow and NTFS / Windows IO subsystem is itself already quite slow compared to UNIX. The issue IIRC is that StorageProvider is designed for sandboxing and the way they implemented that involves doing RPCs to other processes. So there's probably some heavy context switching involved, but it's architectural, and so the voice recorder was never fixed.

https://github.com/microsoft/WindowsAppSDK/issues/8

"The challenge here is simply that listing the StorageItems in a StorageFolder is incredibly slow and resource intensive compared to using the standard .Net/Win32 API to list the file paths. A quick test showed that in .Net it takes about 0.003ms per file, whereas with UWP StorageItems it takes about 2ms per file, which is around 700 times slower. Also, looking at the Runtime Broker, UWP uses about 70kB memory per file, which is a huge cost when loading 10,000+ files, whereas .Net uses around 0.1kB per file (that’s a very rough estimate)."

Somewhere else, someone proposes a theory that due to API mismatches/design issues in Win32 the RuntimeBroker is trying to use a design that isn't a great fit in order to try and provide certain security guarantees, and this requires pre-fetching a lot of data up front in case the app requests it. But NTFS is slow, so, all this additional traffic makes opening files via the Storage API really really slow.

The problem here isn't really "modern software", it's that Microsoft wrote a lot of new APIs over time with the intention of replacing Win32 (UWP/WinRT) but they aren't dogfooding them all that effectively, and they're using C++ for everything, so there are problems that don't get fixed for years.

This was exactly the problem with CORBA in the 90s. It made remote calls as easy to use as local calls. Once they looked the same people would make RPCs in loops like that.

Imagine the cost of a non obvious RPC call in a nested for loop? Just not funny.

Another reason could also be the fact that devs usually only ever run development builds of the software.

So you end up dismissing slowness due to this ("I am sure this is faster when compiled in Release!").

I've made that mistake before until it was so slow that I decided to compile a Release build which was just as slow and found out that a regression was introduced.

Automatic performance monitoring for 'tasks'/services/computations is relatively straightforward but not quite as easy for UI interactions so these often get ignored.

> there are only going to be a handful of test files

Bingo. This used to be a well-known benchmarking cheat, because performance on a full (or even once-full) filesystem can be very different than on a freshly made one. Almost as common as short-stroking, if you remember that. Anybody who wanted realistic results would run tests on a pre-aged filesystem. Cache warming is another example of a similar effect, and there are probably others across every area of computing. It's always really tempting to run tests in a maximally clean environment to get maximally consistent results, but that just doesn't reflect real-world usage.

> it's possible the GPU might not have ever really emerged as a major consumer product

I’m really skeptical about this take, the gains from the GPU architecture are too large to pass up on

Nanite is a software rasterizer running as a compute shader on the GPU though, it still requires the power of a GPU but takes advantage of the increased flexibility of modern GPUs.

but I don't know enough to make it fast

I'd say that in the vast majority of cases, you don't actually need to; what you need to instead focus on is how to make it not slow, and to do so is really not that difficult. In a word, it's (total) simplicity. The less code there is in total that the CPU has to execute, the faster it'll be. Thus, don't add unnecessary abstractions/indirections unless necessary, pull in huge libraries and use a tiny fraction of their functionality, etc.

I'm of the opinion that you don't need to know about cycle counting and such to write decently efficient software. You don't need to specifically optimise if you start off with a sane and simple design.

The #1 rule of optimization is that it's only 10% or 1% of the code which matters. You only need to optimize the code which runs 1000 times a second, the code which runs 1 time every 10 seconds in a background thread can be inefficient and nobody will notice or care. You don't need to rewrite your entire app to make it run substantially faster, you only need to rewrite the hot-paths.

Another key rule is to limit the "main loop" to as little as possible: don't run big computations which don't affect what the user is focusing on. For example, web browsers will pause and unload tabs when you have several of them: this means you can have over 100 open tabs and your web browser will still run fast, because the unopened tabs are not doing anything, they are just caching the URL and (in some cases) whatever is rendered on the site. Similarly, most games try not to render or update things outside of the player's vision. You don't have to go to extremes like this, but if something doesn't affect the user's flow (e.g. an extra feature only a few people use), its performance impact should be negligible. Specifically: don't put code in your hot-path that doesn't need to be there.

Another key rule is to use well-written libraries for your algorithms. I assure you a vector-math library with 1000 stars implements vector-math operations much faster than you can, and those operations are neatly wrapped in easy-to-use functions.

When you have code in your hot-path which needs to be there, is too slow and you can't replace it with a library, then you bring out the big-O and zero-allocation techniques. And also, caching. A lot of optimization is ultimately caching, as computation is generally much more expensive than memory. Those super pretty render engines all use a ton of caching.

You can have a piece of software with tons of bloat, extra features, inefficient/redundant computations, and an Electron back-end, which is still fast (example: VSCode). Even the Linux kernel has a lot of bloat in the form of various drivers, but it does not affect the main runtime as these drivers are not loaded. Even graphically-intensive games and simulations have redundant computations and excess allocations, they are just not in the hot-path.

And last tip: don't write exponential-time algorithms. The above doesn't apply when you have an exponential-time algorithm, because even when n = 30 it will slow your computer, and when n = 75 it will run past the sun burns out.

First, learn how to run an execution profile[1], like the author did in this article.

Second, try to find out how fast software is written in the domain. These are often architectural decisions. Is this software better written by loading the entire data into memory? Or should I process it sequentially and keep memory usage bounded? What data needs to be kept "hot"?

Third, try to figure out what parts of the OS or libraries you use have potentially unbounded waiting. You don't want that to be in any thread that has to be responsive. Either make it async or run it in another thread. This is the cause of a lot of slowness in software, where it gets tested mainly on a single machine but it is actually a distributed system, or where there is never contention for a file in testing, nor is a database row ever locked by another application.

1. https://learn.microsoft.com/en-us/visualstudio/profiling/pro...

Study basic algorithms and data structures. The purpose of this is not to pass a leetcode test, those are obnoxious and those companies that conduct them should be embarrassed. The purpose is to learn how to analyze systems and their performance on two primary metrics: time and space. This isn't all there is to understanding larger systems (simplistic counting the steps of a loop is not sufficient if you're swamped by IO access times, for instance, but it's a start). But you need to be able to examine a system and understand tradeoffs. When deciding between different data structures you're often faced with a situation like: X is faster at A, but slower at B; Y is the opposite. Which do you choose? I can't tell you, you have to know your intended use-cases. Will A dominate in your application, or B? This is the kind of thinking that scales, too. A database that's better at random access reads and writes is better for some applications than one that's optimized for sequential reads but lousy at random writes, so choose the suitable option based on a reasonable expectation of your system's needs.

Study parallel programming (that is, actually having two or more threads/processes/whatevers running simultaneously). This will help you understand the limits of parallelism in speeding up programs, but also the potential for some programs. You'll learn about how to divide work across N processors, the limits of performance gains, and where you will get performance losses (critical ones: synchronization and communication).

Study concurrency so you can see how to make use of asynchronous patterns. I don't mean strictly async/await style, just how to use whatever language/OS facilities to avoid unnecessary blocking. Like, if you're making a network query it can take seconds or longer to resolve (depending on location, size of the data, remote server load, etc.). Your program shouldn't wait if it still has other things it can do (if it doesn't, then let it wait).

Use a profiler, study your real systems and see where they spend their time. What functions get called the most, what functions or syscalls consume the most time. Is there a file/resource that's constantly being used? I once sped up a program by around 60x just by realizing that the previous coder was repeatedly reading from the same file. It wasn't needed, he could have read from it once (optimal), or at least cached it in memory (though memory wasn't so plentiful then, it would've been a tight fit on a mid-00s desktop, but fine today). Apply the ideas above to analyzing it and improving it.

Use an old computer. Slow operations are enlarged which makes it more obvious where the problem lies. I have an old HP EliteBook 6930p with a Core 2 Duo P8700 CPU from 2008. I did put an SSD in it because Windows 10 is unusable without it.

> if I'm a bad programmers and I care about slow software but I don't know enough to make it fast, how do I go about learning?

Learn how to use a sampling profiler.

Under Big O and any time you have an algorithm, see what the complexity is and if you can reduce it.

Just wait until it starts nagging you to rate it in the Microsoft Store like the calculator does.

I also don't dig the look of these apps compared to the clean GUI of Windows 2000 for example. I understand everything needs to be big and vectorized because of 4k displays, touchscreens and whatever else, but it always feels like these apps are running on Flash.

And to tell us this you're using imgur that loads JS garbage from 10 domains in order to display a small picture.

I started in the industry in the 90s. Back then most devs were actually interested in computing and motivated to learn. And management was pretty loose. In my first job they basically told "Here is the problem. Come back in a few months.". No standups, no backlog. But I sat in a nice office with two other guys where we could talk about the problems.

Nowadays I feel there are a lot of people who got into computing as a career but don't really care. And management is trying to convert software development into a micromanaged sweatshop with easily replaceable people.

> What on earth is going on in the computing industry? Did all the smart nerds get siphoned off to hedge funds and machine learning, so Microsoft and Google can only hire the dregs to write boring desktop software?

They’re grinding leetcode and getting a new job every ~1.5 years.

What happens when owning a home and starting a family near your employer is hard and gaming the interview process is easy.

The answer to this question is not politically correct, and therefore will not be answered. We will all end up with quantum computers and software that runs slower than any software from the late 90/2000s

It comes down to difficulties of getting a team together that can implement cross-platform software. Shipping native implementations is more than quadruple the work and cost as compared to shipping with Electron, which is reliably cross-platform and doesn't need you to gather programmers who can pull off native work, not to mention the complications in communication and management that arise after headcount of a group gets larger. There are now alternatives to Electron (Tauri/Rust and Wails/Go) and some Electron projects are starting to transfer over (like 1Password -- you can really feel difference) but it'll take time for the ecosystem to mature and become more attractive than Electron for the average project.

But right now, Electron remains a solid choice if you want to ship cross-platform desktop software without overextending on budget and time. Moreover, it's possible to make Electron apps that aren't terrible if they're optimized enough (Discord, VSCode, etc.).

PDF software is a different ball game as PDF is a behemoth of a specification. Did you know you could envelope 3d models within PDF files? Obviously a stripped down implementation (which you should use, if you don't require the fancier parts of PDF) will be snappier.

End users don't pay for desktop software any more. I wonder if this is part of the answer.

Have you tried using Okular? It's a pretty serviceable PDF reader on Linux, and now has a Windows port as well.

Okular also comes with a per-page cropping mode, though it tends to cause issues when scrolling between pages. I prefer to use pdf-crop-margins (and on encrypted PDFs, qpdf --decrypt so pdf-crop-margins can read them) to generate a pre-cropped PDF that works on any reader, but keep the original PDF around for when I like it better.

Another trick is that on large 32+ inch screens, you can use Firefox's pdf.js in horizontal scrolling view to hold 2-3 pages on-screen simultaneously and cross-reference them easily, then switch to the hand tool for easy continuous scrolling.

Isn't it the natural progression of most technical devices ?

For instance looking at coffee machines, the general direction was:

- no machine, or decent but not so advanced machines - super basic machines, or advanced but finicky machines - crappy capsule machines, or super advanced finicky machines

Depending on how you look at it, there is a path from "advanced but finicky machines" to "crappy capsule machines". Personally I think things still improved, even as the low end is still crappier than the middle/high end from decades ago.