[ef4]

> "Abstraction is dangerous"

The fact that Javascript people keep saying this with a straight face is getting really absurd.

You do realize Javascript is also just an abstraction, right? And that the browsers that run it also abstractions, and the operating systems, and the kernels, and even the hardware itself has multiple layers of abstraction?

"Abstraction is dangerous" is just fundamentally wrong. Abstraction is the only way we get anything done.

What you really mean to say is that bad abstractions are bad. But stated so clearly, it becomes obvious that it's a tautology. Well-designed abstractions that leak as little as possible are essential to everything we do.

This stuff matters, because instead of having stupid arguments over "how much" abstraction we want (which really boils down to 99 layers vs 100 layers) we should be debating exactly what abstractions we want.

[juliangregorian]

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

[ef4]

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.

[kristopolous]

Ok let me try. Bad abstractions are bad.

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.

[z3t4]

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.

[juliangregorian]

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.

[s_kilk]

Black boxes {are|should be} a good thing.

"Leaky Black Boxes" however (like angular), are awful.

I quite like having a black box with two sockets on it, that I can plug cables into and have it just do whatever it's supposed to.

However, if the sockets are a weird shape, or there 39 of them, or they leak a strange green ooze, then I get upset.

[wwweston]

Looks like someone things "dangerous" and "useful" are mutually exclusive. See also electricity, automobiles, consuming food, etc. No one is saying "don't use abstraction ever."

Maybe this metaphor will help:

"Using other people’s code is like surfing. You control and surrender. You’ve got to trust the wave to carry you, but stop paying attention, and the first abstraction leak will throw you under the water."

https://medium.com/@dan_abramov/youre-missing-the-point-of-r...

Sure, you could say "bad abstractions are bad." And it's true there's a spectrum. Some are much less leaky than others, of course, some have the boundaries of what they do and their interface outside more elegantly shaped than others. But saying "well, we just don't want bad abstractions" doesn't capture well the fact that all abstractions either leak to some degree or are awkward coverings for some problem domains.

Nor does it really get us where we want to go in terms of "exactly what abstractions we want." We want useful ones. We want minimally dangerous ones. And the way you get the latter is to understand how abstractions are dangerous.

[_pmf_]

>> "Abstraction is dangerous" >The fact that Javascript people keep saying this with a straight face is getting really absurd.

I stopped expecting anything of value in the article after reading this in the introduction, too.

[clay_to_n]

I only read the beginning few sections of the article, but it seems like it IS about "what abstractions are good", as opposed to "abstraction is bad". He's recommending abstractions that let you understand what's REALLY happening, so that you can reason about performance better.