Please re-read the GP carefully: "The primary reason for this is because the people writing JavaScript do not know what they are doing".

If that isn't a personal attack on a particular group of developers, then I'm not sure what constitutes personal attacks.

Also, as a top-flight engineer working in a multi-billion company (and also having worked with Java and .net professionally for many years), the JS/TS ecosystem as a whole has never been better than it is today.

And TS remains my lang of choice today, for professional and personal projects :)

On the other hand, true criticisms of Javascript, the language, are boring. Yeah, there are problems. You learn to deal with those problems. They aren't really that horrible. I worked with a lot of less convenient languages than JS (especially ES6, which is actually not bad). The standard library is pretty bad, but the language itself is easy enough to use that it's pretty trivial to implement what you need yourself. There are also a few pretty well written third party libraries with no other dependencies which you can use. The build environment is horrible, but not really any more horrible than some other environments I've had to deal with.

No, the real problem is that a lot of Javascript developers choose to stick hot pokers in their eyes. They don't read the code of their dependencies. They don't care how many ridiculous dependencies of dependencies they use. They refuse (absolutely refuse, to the point of calling you an imbecile if you even suggest it) to write their own tools. They choose the build tools that are the most wonky and are built on the most insane internal code -- because they don't care to ever look at that code. They look at the "box features" and say, "Oh, everyone is using that and it has all the features we want. You are crazy if you want that stupid boring thing that barely does anything (and yet works)". They don't do any planning for configuration management. They don't think about how they want to upgrade their dependencies, and especially don't dare think about inspecting the code in the dependencies. "Latest is best! If it breaks, we'll deal with it then".

Javascript is not really that bad. It really is that the community does not have a particularly good grasp on how to minimise risk in large projects. On the other hand, it's a common refrain on other platforms. While Javascript is not really that bad, other platforms are considerably better and you can get away with really poor practices for a lot longer. Not that they won't absolutely kick your ass eventually -- it's just going to be a couple of years away when you have moved to another company at a higher pay scale.

JavaScript wasn't too complex back in the HTML/CSS days though. Lets be honest, we viewed it as a toy to sprinkle in some slick UI. Then some jQuery scripts started getting really out of control. Then I think ember and angular came out, or maybe it was backbone. Then things just kind of got more and more complex. Webpack is insane to learn. I finally took the time to learn it in isolation with es6, away from the heavy frameworks, and it wasn't so bad. But then when I look at using it with the heavy frameworks it makes me want to run for the hills.

I was playing around with puppeteer recently, which is a fantastic tool. It's perfect for what I needed. After I put together an ugly procedural proof of concept I wanted to figure out how to do things right and move it into classes. It's an adventure figuring out the right way to layout a project or even the right way to build a class. The fact that there isn't an authoritative answer tells me the eco-system is not mature or maybe I just didn't Google it right.

Meanwhile, PHP has https://www.php-fig.org/psr/. So anytime I can't remember how to name an Interface or an Abstract or anything really, I just google $blah + php psr. JavaScript is a shitshow that I have to live with, unfortunately. I know its funny coming from a guy that just used PHP as example for good language design, but at least the community has coalesced around standards...and composer > npm.

Its to the point now that I actively avoid making dynamic pages and SPAs AT ALL COSTS. It reduces the complexity of the code a ton that way. Thats not to say I haven't. I used VueJS for a big SPA because marketing wanted feature sets that required it. I fought it and lost. VueJS wasn't so bad, at least the learning curve was less than React, but SPAs are still terribad. Yuck.

> it's always the same

They're usually the same. This one forgot to flame about how the JS community is supposedly constantly reinventing things real programmers discovered decades ago. I think there's still time to edit that comment into conformance with the JS-bashing standard.

The rates for frontend are not high though.