[skytreader]

A lot of answers already boil down to, basically, superior developer experience. But there's an aspect of this that I want to highlight: resource efficiency.

Around the latter half of the 00s, I had a Windows XP machine with 256MB of RAM and a Pentium 4 processor, with a matching spinning metal-disk hard drive. I could make decent Flash animations and games with it. I could view entire websites in Flash with Internet Explorer 8.

Today, my personal machine is a laptop I bought from 2016. Core i7 (4 cores), AMD graphics card, 16GB of RAM. It's not top-of-the-line even when I bought it but I put in ~200 hours of The Witcher 3 in it, finishing the main quest and the two paid DLCs. That said, modern web dev is a PITA in this mostly because I'm too cheap to upgrade to an SSD. Oh, also, the GitHub homepage that showed live commits on the globe makes the fans scream with Chrome unless I enable hardware acceleration. (In fairness that's enabled by default, but it so happened I had to turn it off and forgot to turn it back on.)

I still can't figure out why my personal machine can't provide a decent feedback loop on a React/Angular+Typescript stack (that's not even doing animations!) just because I don't have an SSD. In my very opinionated opinion, only a database server needs an SSD.

A Phaser+Typescript project (my preferred modern web gaming stack) is just a slightly better experience than React. But, again, I wonder why it needs hardware acceleration at all to function well and I've only implemented very "static" boardgames so far. Maybe I'm just a sloppy programmer but I'm definitely better than when I was making stuff in Flash. This shouldn't be eating that much resources, right?

[ChrisRR]

As an embedded developer it always surprises me that simple programs are still barely any faster, take 100s of MB of RAM, require a decent CPU despite the fact we're all using supercomputers compared to the Windows 95 days.

How is it that physicists and engineers are pushing the limits of physics to bring us ever faster processors and we still can't smoothly scroll a webpage, where as I can design an embedded product with a GUI on a 40MHz CPU

[AnIdiotOnTheNet]

Simple answer: because the software industry is a goddamned joke. It's full of complexity-fetishists who are arrogant enough to try and call themselves engineers while producing objectively terrible products and patting themselves on the back for it.

Remember a while back, when Casey Muratori told Microsoft their terminal emulator could be a lot faster if it used a glyph index, and professional Microsoft engineers told him that was complexity worthy of a doctoral thesis [0]?

There's a reason he got so mad at them, and its because this level of "competence" is pervasive in our industry and he has to see it every single f'ing day. See also: "When does the draw window change?", a demonstration of how Microsoft's flagship IDE's debugger fails to compete with a one-man project.

https://imgs.xkcd.com/comics/voting_software.png

[0] For anyone not in the know, this is essentially just emulating how a real dumb terminal from the 70s would work, is the blindingly obvious implementation, and would be familiar to just about any game developer on earth. Casey spent the next weekend coding a 3-orders-of-magnitude faster terminal display demo that was completely unoptimized as a demonstration of the lower bound of how fast a terminal should be. Microsoft's terminal is still not as fast, even though they did eventually implement his solution without, initially, giving him any credit.

[mike_hearn]

There's a few things that have led to this trend, none of which are obviously 'wrong' or dysfunctional:

1. Better GFX quality. Modern screens have vastly higher pixel resolutions than before and vastly higher than any embedded device. Also everything now has to be anti-aliased by default and we expect sophisticated Unicode support everywhere.

This means UI is lovely and sharp - our stuff just looks fantastic compared to the Windows 95 era. But this came at a really high and non-linear cost increase because you can't do CPU rendering and keep up the needed pixel rates anymore. This has caused a lot of awkwardness, complexity and difficulties lower down in the stack as people try to move more and more graphics work to the GPU but hit problems of internal code complexity, backwards compatibility etc.

2. Windows dominance ended, meaning apps have to be platform neutral at reasonable cost. In turn that means you can't use the OS native GUI widgets anymore unless you're writing mobile apps or some artisanal macOS app - you have to use some cross platform abstraction. This also led to the widespread use of GCd languages for UI, because ain't nobody got time for mucking around with refcounting and memory ownership in their UI code anymore.

3. For various reasons like distribution and sandboxing, browsers met people's needs better than other ways of writing apps but browser rendering engines are massively constrained in how much they can improve due to the backwards compatibility requirements of the web again. Flash demonstrated that viscerally back when it was around. So a lot of potential performance got lost there in the transition to web apps, and memory usage exploded due to the highly indirect and complicated DOM rendering model which in turn needs layers of (non-mmap-shareable) code to make it digestable for devs.

4. Browser devs lost confidence in language based sandboxes and so moved to process based sandboxes, but a process is an extremely heavyweight thing - lots of CPU cost from all the IPC and context switching and especially expensive in terms of memory overhead.

You ask why is embedded different. Others here are asking why games are different. This is simple enough:

1. Embedded apps don't care about OS independence, don't care about security or sandboxing and only sometimes have large hi-res displays. If you're on a 40MHz CPU your display is probably a dinky LCD. You can lose the abstractions and write much closer to the metal.

2. Game engines and GPUs co-evolved with the needs of games driving GPU features and capabilities. In contrast, nobody was buying a hot new NVIDIA card to make their browser scroll faster. Games also benefit from historically being disposable software in which the core tech isn't really evolved over a long period of time, so devs can start over from scratch quite frequently without backwards compatibility being a big deal. Normal application software can't justify this. Of course games are going the same way as app software with Unreal becoming a kind of OS for games, but ultimately, it's shipped with the app every time and porting titles between major engine versions is rare, so they can change things up every so often to get better performance.

Could things have been different? Maybe. If just a tiny handful of decisions had been different in the late 90s then Jobs would never have come back to Apple and the dominance of Windows would have never ended. The iPhone would have never happened and Android would have remained a BlackBerry competitor at best, with a UI to match. If the Windows team had executed better and paid more attention to security basics like sandboxing, ActiveX could have remained a common and viable way to way to ship apps inside the browser. Flash might still be around because it was ultimately Google and Apple who killed it off by fiat - Microsoft wanted to compete via Silverlight, but were by then sufficiently respectful of anti-trust concerns that they wouldn't have simply announced they were going to murder it in cold blood.

So it's easy to imagine a parallel universe where our tech stack looks very different. But, this is the one we live in.

[paganel]

> resource efficiency

Glad that you pointed that out.

Around 2002-2003 I was working an office night-shift, in front of a computer that was in no way the fastest even by those times' standards. But, even so, I was able to follow almost every at-bat in the MLB, live, through their Flash app (while I was doing my regular work in another browser tab). And it wasn't only showing stuff like Batter X hit a 1B, it showed you the exact location and the speed of the incoming pitch, where the ball landed (more or less), what was the out-field formation of the pitching side etc. Really cool stuff given the limited processing resources.

I'd say a HTML+JS solution (which, obviously, wasn't even possible back then for that kind of stuff) would require at least an order of magnitude more resources on the client side.

[teh_klev]

> only a database server needs an SSD

Where did you acquire that (somewhat flawed) opinion?

I've been using SSD's since ~2009 and those early devices were transformational even on already elderly equipment. You can pick up a modern 1TB SSD with a SATA interface for ~GBP77.00. A price well worth paying for the increase in productivity and quality of life not waiting for spinning rust disks to do their thing.

[nicoburns]

> mostly because I'm too cheap to upgrade to an SSD

Wow, that is cheap. We’re talking, what, $40? Basically everything these days assumes fast random disk IO, and will be slow if you don’t have it. If you’ve upgraded your computer at all in the last 10 years then you probably have been better off keeping the old one and getting an SSD.

[notacoward]

> Basically everything these days assumes fast random disk IO

I think the point is that they shouldn't. The majority of things that people do every day should fit in memory, requiring only short bursts of sequential access when loading and when saving files. Even databases and filesystems are pretty good at avoiding or overlapping random accesses. Exceptions exist, to be sure, but if "basically everything" gets slow when it doesn't have fast random access then "basically everything minus epsilon" is broken.

[nicoburns]

I mean yes and no. One might make the same claim about an FPU for example. It should be possible for most software to be fast without assuming fast floating point calculations. But if it can reasonably be assumed that the deployment platform does have that capability then does it make sense to focus effort into optimising that.

I think there's an argument to be that programs should focus more on when they're reading from disk because some programs can end up slow or laggy even on SSDs. But systems not running on SSDs (outside of embedded and object storage use cases) are exceedingly rare these days. And that's only likely to be more true over time.

[ridgered4]

I remember adopting SSDs quite early in their lifetime despite them having controller firmware teething issues at the time. It was hands down the most significant PC upgrade I've made in the last 20 years.

That said, Windows used to run acceptably on hard drive. I don't think I could even endure Windows 10 on one now with the amount of background disk hammering it does just staring at an empty desktop.

[Arrath]

I maintain that the jump from spinning rust to solid state may well be the biggest single QoL jump we'll see in consumer computing for another couple decades, barring, like, direct neural interface or something wild.

[notacoward]

> systems not running on SSDs ... are exceedingly rare these days

Just because it's there doesn't mean you have to rely on it. As you yourself say:

> programs should focus more on when they're reading from disk

Yes, they should. A program's interface to storage is often one of the main limiters on its overall performance or scalability, even with the fastest kinds of storage available. In general, it's best to assume that storage access - especially random access - will be crazy slow compared to anything else. Batch it, parallelize it, overlap it with other kinds of work. Any program that is unnecessarily I/O bound, relying on storage to be fast in order to be fast itself, will be unable to take advantage of other resources (CPU, memory). That's excusable for programs whose whole purpose is to access storage - e.g. the storage servers I worked on for ~30 years including in HPC - but otherwise it's just poor design. Unfortunately, that's the norm in our industry nowadays.

[warrenm]

Dan Luu has several articles on latency that address these questions:

- https://danluu.com/keyboard-latency/

- https://danluu.com/term-latency/

- https://danluu.com/input-lag/

[speedgoose]

Please get a SSD today. You stress me!

[HarleyBestfield]

Let me stress you more. I use a mid-2010 iMac as a daily driver. It still uses the original spinning disk hardware with more than 77000 Power_On_Hours. SMART says Old_age.

I like living dangerously.

[speedgoose]

What worries me is that you purchased a premium computer from Apple when everyone recommended not to buy it because its obsolete low-end hard drive crippled it.

And you didn’t consider making it a magnitude faster for a fraction of its price.

I’m sure you can find a fridge with better IO performance.