- there are too many ways to do something: it's hard to understand patterns (they change with every framework, for example), many different standards that aren't compatible with each other.
- javascript delays failure and fails silently: it makes software prone to bugs as well and it also makes the language hard to debug.
NodeJS, npm, yarn, millions of frameworks and libs just add complexity to the language.
My primary complaint would be that working in Javascript is absurdly difficult for the beginner. It's ridiculously hard to understand the fundamentals when they have been a moving target since the early 2000's.
The problem is that "best practices" changes every day, and from one employer or team to another.
- Structural, optional typing is good. Use it. TypeScript seems to have de facto "won", but just use something; the very act of thinking about input and output types tends towards better code and you always have the flexibility, within your module boundaries, to go outside the type system if need be.
- Structured, functional-or-mostly-so view libraries make your system less fragile. Use them. React, Vue, whatever. They discourage your developers from making tag soup; this is a good enough reason. (Yes, there are some people on the "vanilla JS" train, but there are reasons it's a minority group--it's harder, you run the very real risk of making a worse thing, and there's less out there to bail you out if you get yourself into a corner.)
- Do the work up front: lint aggressively, format consistently, run coverage tests, and so on. It's an investment in correct code, and get in the habit early.
What you use matters less in putting into effect good practices. Why you use it and what they do matter much more.
These days I write pretty exclusively NestJS serverside and React/React Native on clients, using TypeScript through the whole stack and Swagger-generated clients for plumbing, and it definitely no longer sucks. But I had to 1) have a reason to get into it, and 2) spend a ton of effort to weld together a consistent environment that values developer time.
There probably is too much nonsense going on at any one point in the JavaScript ecosystem. I mostly work in infrastructure/devops roles, where it's just expected that you know ten thousand little things that are arbitrary and stupid but will eventually bite you; having to hold an entire stack in my head and understand how to pivot and manipulate it is kind of what I do everyday, but it's not a standard programmer skill. If you don't have somebody who can do that--and it's a mixture of human communication and empathy, technical skill, and a certain kind of technical taste, so it's not as common as one might like--I still, today, see why somebody might say that JavaScript sucks.