"Black boxes are dangerous" is maybe a more precise way of expressing the concept. I don't think the author literally believes you must be writing machine code.
If black boxes are dangerous then you really should be writing machine code. Which is absurd of course, and demonstrates that black boxes are a very good thing.
Javascript itself is a black box. It would totally suck if you had to know how it's implemented inside to use it.
Additional complexity without additional functionality, increased dependencies without increasing stability, poor documentation and buggy implementations; strongly coupled things which have no business being coupled and overt assumptions on what kind of application you are writing and how you ought to structure it.
They have fundamentals which don't interact with anything else - events that won't be caught, arrays that use their own iterator, etc.
They decide to suppress language features like console logging and replace it using different names. You never learn this by reading the outdated documentation but by startling discoveries 45 minutes into what ought to have been a 15 second bug.
And let's not get started on how utterly useless the call stack or object inspector becomes.
They presume there are fewer coherent approaches to programming in a language then there actually are so they shoehorn you into writing things in one specific poorly documented, buggy, highly complex, inappropriate, monolithic, and fragile way.
One of the main arguments for the abstraction approach is that they assist average programmers like a golfing handicap. But the reality is that the quality of the programmers work remains the same - but now with the abuse and misuse of the language AND a convoluted abstraction. You are far worse off.
The historical problem is that these things despite all of these clear flaws become immensely popular - each one for about 6 months.
And then your business critical application gets locked in. Locked in to the hottest framework from 5 years ago.
Awesome
btw, I tweet about my hatred of this specific topic here: https://twitter.com/frameworkhater ... I think a proper manifesto may be in order.
I can see all sides of the arguments here. I do love API's, but I hate "frameworks", especially when they consist of useless functions like
function _MY_framework.enterprise.displayMessageInConsole(msg) {
console.log(msg);
}
That does something that would actually be easier in vanilla JS.
All years of writing JS may have made me blind, but that's how I see most JS frameworks. Mostly useless.
That said, manipulating the DOM in JS is a PITA. I can totally understand why you would want to do it another way.
I guess the DOM is not meant to be manipulated with ... And breaks if JS is turned off.
I think in the near future in maybe 5-6 years we'll see apps that are a mix of Browser and Native. That has the protected environment like a browser, that ask for permission to use hardware features, that can be accessed through high level API's, have native performance and run by typing an domain address much like WWW.
Sometimes you really kinda do. Garbage collection and DOM repaint/reflow come to mind. No abstraction is completely airtight, doesn't mean it's not useful, doesn't mean it isn't a "black box" to a neophyte.
Javascript itself is a black box. It would totally suck if you had to know how it's implemented inside to use it.