Again, this is a symptom of the "one toe in the pool" syndrome. You have to throw yourself in.
Yarn is a perfect example. It came out very recently, relatively speaking. And yet it's clearly the future. Like, the only reason not to use yarn is if you have a legacy app that explodes for some reason if you try to type "yarn" instead of "npm install". But the common case is that you do "git clone foo && cd foo && yarn" and everything works perfectly.
It's so much faster, and almost never causes problems.
So why embrace that? It sounds like horseshit yeah? I hate to use heavy handed metaphors like that, but that's exactly the feeling that you get when you hear "Oh, now we're supposed to use yarn? what? npm install isn't good enough now? Those fucking JS idiots have no idea what they're doing."
In reality, you're seeing evolution in action. This is what natural selection looks like. The good ideas triumph. And yes, it's subjective what constitutes a "good idea." But when yarn comes along and makes all my npm installs 3x faster, you bet I notice and you bet I embrace it right away.
That's what I mean about throwing yourself in, though. If you don't actually force yourself to love this stuff, then of course you end up hating it. It's insanity incarnate. Yet if you just embrace that fact, and take it as a given, you can actually find it quite fun. It's an adventure to get to learn these new systems, not a chore. If you run across something that doesn't seem to make sense or doesn't work for you, just ignore it.
It just seems like we as developers run the risk of having our heads stuck so far up our own rears regarding our favorite language paradigms or the lack of greenthreads in JS or whatever it is you hate about the ecosystem, that it's very easy to lose sight of the bigger picture. Right now you can build a team of 50 engineers, and if you choose React, that codebase probably won't devolve into utter chaos. React makes it possible to do large-scale coordination. Like, I can send you my React component and it'll probably work in your codebase.
Ditto for Vue. If you hate the complexity of React, and you're a small team (usually just you alone), then you can just use Vue and not have to care at all about React+Redux's monstrous complexity.
You see? You can pivot however you like. If you hate X then just avoid X1 It's really hard to take these concerns seriously when there are so many options.
Ah, yes, that's the crux of it. We'd love it if the world would just stop changing so we can relax and stop learning. Well, too bad! Here's the uncomfortable truth: the moment you let yourself get too comfortable, your career dries up. That fear is a powerful motivator, so I suggest internalizing it. If you can't force yourself to love learning, then become afraid that if you don't learn it you'll find yourself unemployable after 5 years.
This almost happened to me, so I'm speaking from direct experience. I came from gamedev, and low level skills like that really do not translate into "I'm getting paid $INSANE/yr in a hot new startup." In fact, you can barely pass webdev interviews because you have to go "Uhh... Yeah, I worked on Rails back in 2007 or so. I guess I have some learning to do. But just trust me, I can learn it as I go. Oh wait, you don't believe me? But... I've spent my whole life learning as I go... It's fine if I don't already know Rails even though you're hiring for a senior rails dev position."
That situation is exactly what happens when you stop being on top of all this stuff. Go to sleep and wake up 5 years later and suddenly getting a job is hard. It's easy to smirk ad feel like it won't happen to you, but FWIW the way you feel about JS now is exactly how I felt about Rails in 2007.
And there you are a few comments above telling us we have to use Webpack because other older module systems are zombies that came and went.
The truth is that we'll never have enough time learn everything we should learn and every minute I spend re-learning a different way to do something I already know how to do is a minute I'm not spending learning something actually new and useful.
If, for example, I'm writing a web app related to storing and processing geology related measurements (which I am) I should be spending most of my 'learning time' studying things related to geology and the processing of said measurements, not re-learning how web development is done this week.
Something about this smells.
What is it.
Is it the way "we would love it if it stopped changing" but it's us who is changing it?
Is it that the changes are reinventing the wheel? Churn because frothy churn is easier and more profitable than meticulous, solid, long-lasting foundations?
Or is it that we still haven't managed to orient the programming industry around 'finished' software such that if we ever 'finish' software we immediately stop being employed, so we have a pathological need for software to continually need to be rewritten, at the level the average programmer can rewrite?
How is this client side rewrite every few months fundamentally different from the broken window fallacy? as in, unsustainable because it adds no value overall?
Node threw themselves into Semver, and it was supposed to be great. Nobody needs a lockfile because everyone obeys semver, so every time you do 'npm install' your app is guaranteed to work because everything is semver'd!
Oh wait, no, that didn't work out. Better freeze every dependency and sub dependency because who knows what will break when we update!
This is why throwing yourself at whatever shiny new thing without thinking or looking at how other languages do it is not always a great idea.
Last I checked its issue tracker was a pile of "hey, you, uh, didn't implement this npm feature at all, so things break" and "you're missing yet another obvious sanity check here, so things break". No wonder it's faster. The last thing I need in my JS stack is another thing that can fail under ordinary use, for marginal benefit.
You do you, though.
There's a Rails way, Python famously aims for one obvious way of doing things. That just isn't true of Javascript exactly because there is a history of developers writing several styles of JS, the "right way" to write JS being redefined by diligent people like Douglas Crockford & John Resig and things changing yet again and yet again.
And look at ES6, the JS ecosystem barely resembles what was considered good, idiomatic Javascript just a few years ago. There are a bunch of devs who have managed to stay on top of what's current and I'm sure are laying down examples of good practices & building tools in that style. But you are also talking about an ecosystem that includes people that started writing JS 4-10 years ago, have adopted some of the absolute newest flavor of the month practices but also have seen JS change so much over the years that they aren't throwing themselves into everything that is now considered a best practice because they know their code works and there could be another seismic change in 8 months.
Writing Javascript nearly every line of code is haunted with "is this still the way I should do this?" and no other language has that much hassle.