> However, the point where I do agree with you is that we have a performance issue with JS. And I am not talking about slow JS engines. I am talking about developers who are not aware of how costly some operations are (e.g. loading a bunch of libraries). Yes, that is an issue that naturally arises with abstractions, but to conclude that abstractions themselves are the problem is wrong.

I could not agree more.

https://jackmott.github.io/programming/2016/07/22/making-obv...

Notice "Javascript map reduce (node.js) 10,000ms" vs "Javascript imperative (node.js) 37 milliseconds"

I've seen the map reduce way defended as being "more readable and maintanable", with plenty of agreement to it. When I contested it, mental gymnastics ensued and did not let up. Nobody dislikes performance, not really, but I think some don't like reflecting on how they arrived at their opinions. That's the bit they're really invested in.

And in general, "what does this abstraction stand for?" is a very dangerous question, if you ask it about computer stuff, you might also ask it about other things, and there more groups that don't like that than there are people in the world. Not to make this too political, but I think the pressure against thinking for yourself is way, way bigger bigger than the demand for performance. Just think of Ignaz Semmelweis.

Another issue is that many things are hard for us to visualize, as Grace Hopper explains: https://www.youtube.com/watch?v=JEpsKnWZrJ8