> something like writing regular javascript is considered being close to the metal,

Good grief.-

> and high level means you install a library that does what you want out of the box, and you need to initialize it.

And, again. Grief.-

Someday, knowledge of the actual functioning of these systems might become so obscure so as to, basically, be lost - kind of like (in a way) the Apolo project know-how is fading away ...

> Someday, knowledge of the actual functioning of these systems might become so obscure so as to, basically, be lost - kind of like (in a way) the Apolo project know-how is fading away ...

We're already way past this point since the 70s. Do you read the official specifications for every hardware platform your software runs on? Do you even have access to and a deep understanding of the inner workings of your target OS? Do you know the intricacies and quirks of all the network-, display-, and input protocols used in your devices? Are you deeply familiar with every audio and video codec, encryption method, online data stream compression scheme?

Point is, none of that matters depending on your actual software. A sculptor doesn't need to be an expert in chemistry, mechanical engineering, and mining to create a beautiful stone statue after all. Intimate knowledge of the hardware is required if you build drivers, firmware, low-level embedded software, and critical systems (e.g. ABS, flight control systems, etc.) but not for building word processors, interactive websites, business apps, data entry systems, content creation tools and all the things users interact with on a daily basis on their PCs.

It'd be way too much for a single human being to know and understand in depth and unnecessary (as in not helping with getting the job done). Why is it that everyone understands and accepts and is comfortable with the fact that scientists and medical doctors for example, have their specialist fields and aren't familiar with the full spectrum of their respective jobs, while people expect software developers to be deeply familiar with 100+ years of cumulative knowledge and developments in hardware and software?

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.).

You could've saved yourself a lot of words and just skipped to the end. Better is the enemy of good or good enough. Sure. But it's not good enough, which can be confirmed by simply using it. Speed is not my only concern either. For instance, I was some time ago arriving to a foreign country and I wanted to check which stores are open on a Sunday. There was a big supermarket chain that had a store locator and so I opened that page, added my zip code and wanted to see the results. You could not scroll the page! If it was a one-off bug I would say shit happens, but I see this all the time. Things jumping up and down, things you try to use but don't react or react very slowly etc. I am quite sure that project had a ton of people working on it, it had a CI, it had very high engineering standards (at least according to what goes by engineering standards today), but it had a page that could not scroll.

You don't need to explain me the shtick of expensive labor and cheap machines, we've heard that one ad nauseam, it's hardly original thought.

Whether or not it's a program is irrelevant, if it's not a program and it does the job, why are you writing a program? And if you want to write a program to fulfill other business goals, why are you not doing a passable job?