[tomxor]

I'm one of those "weirdos" who loves writing JS, and yet I agree with everything you just said being horrible. But I enjoy writing plain JS, that doesn't mean react, angular... i've run out of examples because I honestly don't care about those things.

However, I'm in a position where I have enough autonomy to avoid all that crap and just use the bits I like. When you get minimal and ignore all of the noise about the latest hotness JS libraries, the plain language (not including the lanky browser APIs) is not unpleasant especially over the last few years where some modern syntactic features were added - You can go even further and be selective of the language itself and it can get even more pleasantly minimal, my recent delight has been excluding classes and prototypes as much as possible.

When you take this approach the whole "churn" issue disappears (JS is backwards compatible, you will never have the issues you have with Rust or Elm forcing you to re-write).

I suppose this is the argument many make for C++ which is that, yes it can be a complex nightmare, or (if you are able) you can restrict yourself to a desirable subset and have a happy time. In JS's case, most of the complexity is from "keeping up" with the community and libraries, not the core language itself.

[apotheon]

I enjoyed the hell out of writing application plumbing, but the moment it started turning into an actual application that interacted with the outside world I was dealing with the hell of the Node ecosystem of "compiling" and packing for the browser, framework crap, buggy testing libraries, and all the rest of that nonsense, with an acutely clear understanding that all of it would change in five years and I would have almost zero useful knowledge from the tooling and ecosystem experience of the preceding half-decade.

In the mainstream professional JavaScript world, my advice is to escape as quickly as you can, and pursue things where the learning focus is on more interesting things than the arbitrary whims of the authors of half-baked (because they never have time to mature before they die) frameworks. If you can just live on the fringes and write JavaScript your way and not worry about constantly impending obsolescence of your entire technology stack (from Linux all the way up to your JavaScripty CSS framework), though, I'm sure you can have a great time doing it.

I'm writing a lot of C and Ruby these days, and I love it. I get to learn more about myself as a programmer, instead of more about other programmers as fly-by-night framework developers.

[tomxor]

I'm not really sure what you mean by "constantly impending obsolescence", but as one anecdote in the face of that: I have plenty of core JS code in production that was written 3-4 years ago. I've gradually improved or changed parts of this codebase but that had absolutely nothing to do with external libraries of which I use very few... this feels very unchanging to me, my code is not about to implode due to any external reasons.

I write my own UI/MVC type code from scratch just because that's the way I roll and my requirements there are a combination of minimal, extremely performance sensitive and in many cases esoteric where I have to write the UI anway so it's not much work compared to forcing existing libraries to do what i want... but if had to I could replace it with some hip and upcoming UI + MVC library and still keep 95% of my core code completely independent and intact.

I think JS world feels like massive churn if 90% of what you are doing is UI UX etc, because that's the interface that can never sit still in the name of progress... either that or you (not you necessarily) are doing it wrong and not separating UI code from your application code (I've seen this happen quite a bit in ye olden angular days where everything becomes attached to angular for no apparent reason, and angular itself is the worst of OOP + MVC where everything is convoluted and difficult to follow).

[apotheon]

If you're basically building everything from scratch, of course you aren't going to see the churn as much.

If you build on others' frameworks, and those frameworks drop out of maintenance because the maintainers moved on to shiny new things, any security vulnerabilities or emerging incompatibilities with browsers can quickly prove ruinous for people who used those frameworks.

I wrote a SPA while working at a consultancy. It was actually pretty churn-proof the way I wrote it, but during one vacation day and the following weekend a couple people (including the boss) just rewrote the whole thing to use more faddish framework stuff. I don't work there any longer, but since then (about 2016) they've probably had to effectively rewrite it twice if they kept up with that approach.

That's what I mean by "constantly impending obsolescence".