There’s a lot of truth to the joke lurking in this comment. Apart from the covert channel issues, the “market” has spoken: speed of development (and simplification of development) has been preferred to raw performance. I definitely consider that a good thing, even when I look upon a lot of code with horror).

40 years ago writing code was a lot harder; improving that has allowed a lot more interesting things to be built (both bc people can work faster and at higher levels of abstraction and because development is more democratic, leading to a wider pool of people writing things). The cost has been high though; few people think about the hardware and even the term “bare iron” is used unironically to refer to a machine running a multi-tasking OS!

But I think this will swing back the other way. Not by removing the abstraction but by “melting” some of the abstraction implementation layers. Hard work on improving interpreters and compilers has always been one of the ways, but assembly-optimized hotspots and tighter integration in some of the stack elements will be increasingly worth doing because fixing that speeds up all the developers working at higher levels.

The downside is that you won’t be able to, say, easily customize that version of React you’re deploying. But nowadays you really want to stay away from that anyway, in 99.99% of cases.