I don't hate JavaScript, hell I'm still working on my own library for it.
What I hate is Frameworks that use JavaScript to do CSS' job. I hate bloated frameworks that violate the basic concepts of separation of concerns. I hate "JavaScript for NOTHING". I hate when JS only site creation tells users -- particularly those who don't have it available, block it, or otherwise have it irrelevant for accessibility reasons -- to go plow themselves.
Apart from the lack of a decent / proper object model and bizzaroland mish-mash of type handling, there's not actually that much wrong with the core language... well, that and the aggravatingly and pointlessly cryptic C style syntax; but that's just me being a "Wirth" fan. I learned programming in machine language hand assembling long before I ever even had access to a high level language, and my first real useful high level language was Pascal... with a quick migration from there to Modula, Smalltalk, Eiffel, and Ada. I spent over a decade working in Ada... and still cannot fathom how the blazes C caught on.
In any case the problem arises when people use it for no good reason, use it to do what HTML or CSS should be handling, and use it in a manner that wholesale tells large swaths of users to sod off. THAT'S when I have a problem with it.
First lesson anyone should learn about JavaScript -- at least in terms of client-side development:
Good scripting should enhance an already working page, NOT be the only means of providing that functionality.
There are certainly exceptions to this, but when I see two or three megabytes of scripttardery impeding the usefulness, functionality, and speed of a site on pages that aren't even doing anything that should warrant the PRESENCE of JavaScript, that's when I take issue with it.
Since telling visitors with accessibility needs or in locked-down workplaces to go f* themselves isn't all that great a battle plan!
Which is why I don't like jQuery and 99%+ of the asshattery people do with it. I don't like what angular, react, and vue do client side for similar reasons -- or at least not in terms of what people do with it.
JUST like how HTML/CSS frameworks piss on accessibility, semantics, and separation of concerns -- in particular the separation of presentation from content. You'd almost think the people creating and using such garbage didn't actually understand the first blasted thing about HTML or CSS. JavaScript frameworks almost universally have the same shortcomings.
PARTICULARLY when they go full Pakled using innerHTML, something else we were told two decades ago had major problems but people still herpafreakingderp into damned near every script they write. THEN they wonder why they keep having slowdowns, user complaints, and worst of all possible XSS exploits. :/
All because using document.createElement, document.createTextNode, document.replaceChild and document.appendChild is "too hard" or triggers the lazy half-assed "wah wah wah, I dunz wanna tiepz!" response.
Hence my earlier question on here about "why are programmers afraid of the DOM". It's not like she has a whip...
My DOM-JON concept being an attempt to make a direct DOM manipulation that functions like what many of those frameworks derp out with innerHTML -- resulting in not having to worry about escaping/securing user generated text and dodging the performance headache of triggering the parser.
The laugh being so many of these frameworks TALK about being DOM manipulation tools when they are NOTHING of the sort, or nobody uses what few DOM features they actually have. Hence that whole "Virtual DOM" bullshit based on half-truths and outright ignorance caused entirely by the fact that what they are calling a DOM and manipulating/creating... ISN'T!!! They're futzing around with string based markup and then herpa-freaking-derping it into the page with innerHTML. That's NOT DOM manipulation.