The abstractions aren't making this problem the developers without a willingness to work under the abstractions are.

I wrote this following tool in less than 90 minutes 5 years ago because I had some time left over before presentations at a company hack-a-thon. I updated it recently at about another 90 minutes of time.

https://github.com/prettydiff/semanticText

That tool was trivial to write and maintain. It has real utility value as an accessibility tool. I could write that tool because I am familiar with the DOM, the layer underneath. Many developers are not even aware of the problems (SEO and accessibility) this tool identifies much less how to write it. jQuery won't get you the necessary functionality.

Why are so many of your comments of a gate-keeping, self-congratulatory nature, or blanket criticisms of others?

I find it frustrating because I do think you have plenty of valuable stuff to say, but you're consistently presenting it in a rather unappealing package and I don't really understand what you get out of that.

Gate-keeping yes, self-congratulatory no. This subject is personally sensitive to me because it has immediate real world consequences that impact my livelihood and choice of employment.

I am away from home on a military deployment at this time and I am constantly thinking about what I should do when I return to the real world. I am actively investigating career alternatives by dumping software development, because I honestly believe my career is limited by the general unwillingness of my development peers to address actual engineering concerns out of convenience and insecurity.

> 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

In the jQuery era (Firefox release and IE6-10ish) they didn't change ever few months, in fact they never changed and didn't for about a decade, which was part of the problem.

Working with the dom in JS wasn't hard, it was just time consuming and required lots of boiler plate code.

JQuery made it quick and easy and cross-browser even if FF was still a small %.

JavaScript itself didn't change AT ALL for years before and after jQuery came out, so I have no idea what you are talking about. Plus HTML 5 was years after jQuery, with html 4 released in the 90s, you've got the wrong recollection of history.

The lack of change was part of what made jQuery so ubiquitous.

I wonder a bit why you write 'IE6-10ish' as IE7 was a big change already (not talking about IE8 or IE9, or what the other vendors did during that period). So when jquery was released, we had the split between standards and IE(6) compliant implementations already and the whole browser development started to get traction again.

So yes, the standards didn't really change during that period, but the real world implementations did. And jquery gave you a way to learn just one thing and don't care about what all those browser vendors were doing.

When IE7 was released absolutely no changes to JavaScript or HTML happened, IE just became slightly more standards compliant.

AFAIK the big thing in IE7 was that it had tabbed browsing, like FF. And slightly improved js performance, that V8 put to shame a couple of years later.

The actual split between IE6/7 and FF was mainly in the Ajax syntax, not the dom, etc.

My impression from what you're saying is that you didn't program js in the 2000s, did you? I did.

As a matter of fact, I did. But obviously, it seems that we didn't experience the events in the same way and I don't have the impression that you are even trying to understand what I am writing.

With libraries like react static that prebuild the dom of your page you don't have to worry about that