|
|
|
|
|
by ef4
4152 days ago
|
|
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.