You example is flawed. Static (a in non-interactive) content is not a program. As soon as data collection, tracking, and user metrics enter the picture, the sim

You example is flawed. Static (a in non-interactive) content is not a program. As soon as data collection, tracking, and user metrics enter the picture, the simplicity of static content goes out the window (one more reason to dislike these things). The problem with opinion pieces like this awful article just goes to show once again that way too many developers these days lack the fundamentals, e.g. mathematics. A naive programmer will look at a problem and categorise is as "easy" and "simple" if it's already been solved and they now how to do it. Actual simplicity, however, isn't always obvious: No three positive integers satisfy a^n + b^n = c^n for n>2. Simple to show, right? So simple in fact, that many folks tried to use high-school maths to tackle it. Yet it took 358 years and over 110 pages ("bloat"!) of dense, advanced mathematical concepts ("layers of abstractions"!) and reasoning to prove it. There are many other seemingly innocent questions of the same nature, like the Goldbach Conjecture or the Collatz Problem that may take centuries and breakthroughs in various areas of maths to finally be solved. It's the similar with software; only that, unlike in mathematics, problems are often poorly defined, constantly changing, and developers aren't given decades to ponder them. To go back to your very first observation > If you actually use software intended for users it is slow. There are simply too many layers. you'll find it doesn't hold much water upon closer inspection. You basically missed the mark entirely. Why and where do these layers exist? Your CPU executes undisclosed µ-ops instead of opcodes specified by the architecture and emitted by compilers. Every memory access goes through an MMU instead of directly to RAM on all processors but the most basic microcontrollers. Hardware access is mediated by BIOS, drivers, and OS kernels. In short: "close to metal" is a vague and relative term in the 21st century and if your target platform is the browser, then yes, JavaScript is "close to the metal", because the "metal" in this case would be a W3C-compliant browser engine. Finally, there's economics. Better is the enemy of good and especially of good enough. Back in "the good ol' days" programmers were cheap and the iron was expensive. Today it's the other way around and the way modern software is built reflects that. Optimising for a myriad of diverse hardware and software platforms is tedious and expensive. The ones that win the competition aren't always the "best" solutions, but the ones that are first to market, deliver features quickly, or offer added value (support, documentation, user-friendly interfaces, etc.).