I don't have a lot of arguments against tooling/framework issues in the JS world now. The proliferation and churn and quality limits are part of what make things very much not-fun for me. Good thing I can ditch to the server side and other places when I need a break. :) I think things like Vue, though, mark a point where developers are stepping back after the recent madness and asking themselves exactly what problem their tools and frameworks are really trying to solve and starting to do better.

But when it comes to the language itself... speak for yourself. Up until about 5 years ago, I thought JS development was a blast, and I was enjoying it enough that I was using Rhino as my alternate language for the JVM and having fun there too.

And I've built things in a dozen languages, so this isn't didn't-know-much-else-ism.

The fun didn't start, though, until I stopped expecting it to be something else.

"avoiding part of the language that is badly designed to escape traps" == understand the language well enough that what you expect to happen is what actually happens (and accept that just because you're familiar with one behavior in other languages doesn't obligate any other language to replicate it -- those expectations do not necessarily constitute the principle of least surprise).

"recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc." == understand the features that exist in JS well enough that you know how they can do the job you expected features from other languages to be required in order to do

And that's been true of any fun language I've found. There are some languages that never became fun for me because either I don't want to do things the way that the designers do (and in some cases because I expect the designers don't want anybody to have fun, they just want it to be a tool), but all the ones that did become fun required me to actually learn them first. And if somebody actually likes dynamic scripting languages at all, I'm baffled if JS-the-language isn't something they can't achieve contented productivity in. In fact, I'd go so far as to say I'm skeptical that a developer who can't achieve that in JS can genuinely achieve it in Python or Ruby.

"remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS."

For one thing: coffeescript has never been anything other than JS semantics, saying that using babel is an attempt to avoid using JS is like arguing that using Python 3 is an attempt to avoid using Python, and JSX is entirely orthogonal to this topic as it's essentially a templating tool that happens to be a language extension (like E4X) instead of a string processing library.

For another thing... I do remember that 10 years ago that among the contenders for JS libraries there were a number whose central conceit was that the problem with web development was that JS wasn't enough like development in some other language. Prototype's ethos, for example, seemed to be that it wasn't enough like Ruby.

jQuery was like "nope, the chief pain point is our browser APIs, what if we had some that were more amenable to concise practical use, took advantage of JS's functional strengths, and were normalized across browsers?"

I think it's pretty obvious in retrospect who had the key insight.

And I think that most of the progress from this point will come from people who have the same insight: understand JS's strengths, play to them, don't treat the browser or the language as if they need to be some other platform, think about what the general project pain points really are.