It's like you have to constantly keep learning, but nothing you learn really matters in any deep way. It's just new names and APIs for the same stuff, month after month.

Imagine if you were a woodworker making furniture. You make the same furniture every day and love your craft. But every month, someone shows up, takes all your hand tools, and replaces them all with a set that are mostly the same but slightly different and all have completely different names.

1000x this. One of my pet peeves is the idea that all learning is equally worthwhile. It's possible to waste one's life "learning" the inane and shallow, and it's a suffocating experience when it happens.

'JavaScript is a never ending grind' - Wow no better way to summarize it than that. The funny thing is that I've always felt that Javascript the language is pretty straight forward and easy to comprehend. As someone who primarily writes Ruby and really appreciates the functional style of writing code, Javascript lends itself to that style very easily.

But the ecosystem around is just that never ending grind. At my last job, over the 3 or so years I was working fully stack, it was just a constant churn. Start with React / Redux / SRR / Jest / Mocha / (probably some other testing frameworks) / Flow. By the end none of the original testing frameworks were being used. React had introduced Hooks, which I actually like, but it was a whole new paradigm to learn again. Flow was out and we needed to migrate to Typescript as quick as possible. And this is just the React ecosystem!

React has its place and I'm definitely comfortable working with it (also writing 0 tests cause I have no idea where to even start for that) but I'm looking forward to the day maybe simple web apps get back to simple setups. Projects like LiveView[0] for Phoenix really give that hope.

[0] - https://github.com/phoenixframework/phoenix_live_view

>I've always felt that Javascript the language is pretty straight forward and easy to comprehend

While that's true, the completely opposite is true for Javascript the ecosystem.

I don't have much time for this cr*p, nor do I like it, so I tend to use olde fashioned JS + libraries like jQuery for old fashioned multi page web apps. I want to learn Blazor and Vue for SPAs to keep it more simple.

A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads.

As an analogy, consider fiction. Imagine reading as many new novels as possible as they're released. Well, most of these novels will be completely irrelevant 5 years from now. The good ones stand the test of time. So you might as well only read novels that are 5+ years old, yet are still relevant and receive acclaim.

If you worry that taking this approach with JavaScript will make you fall behind, my question is: Behind whom, exactly?

There's no way many in the industry can keep up with all the changes you listed as fast as they're coming out. Therefore, it follows that a great many of your JS developer peers are "behind." Therefore, it's okay for you to be, too.

What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows. Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest. The result is that I end up skipping a lot of the fads that die on the vine. For example, I largely missed CoffeeScript.

I think a lot of pain from JS comes from the expectation that one can and should keep up, when you probably can't, and definitely shouldn't.

> A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads.

The problem with this is that everyone jumps on new fads so quickly that, if you don't, you're likely to endup with a bug-ridden, half-baked, vulnerability-riddled, unmaintained/abandoned, slowly collapsing, termite-infested framework as the basis of your entire SAAS business, or whatever it is you're trying to run on something that even the creators abandoned for the next fad.

> What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows.

You have to be very, very lucky to accidentally end up with a "pretty recent stack" that will still be maintained in five years. On the other hand, the next part shows that you don't actually go with the 5+ year old "stood the test of time" tools:

> Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest.

Having to learn a whole new sub-ecosystem in as little as two years is exactly the kind of mind-destroying grind everyone's complaining about. I don't think anyone's just jumping on the newest thing that appears every six months; they're all just having to move to some new toolset every two to five years and burning out ten years into a career because otherwise they'll end up having to be the new maintainers of whatever tools they're using due to the fact nobody else is using them (and thus no one else is maintaining them) any longer.

Oh, yeah, and if I have to learn a whole new fucking sub-ecosystem and new version of the language itself with a bunch of breaking changes every two to five years, I don't have any time to spend learning fun things like a whole new language designed around a whole new paradigm.

ECMAScript and everything that touches it has become an actually focused bane for the joy of programming. It was fun just writing some clean plumbing for JavaScript applications in the past, but everything else about the process always ended up involving a bunch of scrambling to catch up with rapidly changing technology, planted on shifting sands even while I'm working with it, any time I start on a new project, where all I'm learning is a new set of persnickety conventions that will punish me if my approach is "wrong", force new work-arounds on me, and generally suck up all my time learning new rules to follow instead of interesting new ways of thinking about things that make me a better programmer and software designer.

Learning the interesting stuff, and figuring out new approaches to new problems based on the needs of those problems (and not the whims of the community), is a lot of what makes programming fun for many of us.

Linux exhausts me similarly.

* ALSA; esound; PulseAudio; etc. Just give me updated OSS or sndio on a BSD Unix system. That shit is stable, well-maintained, and not arbitrarily different every few years.

* SysV; upstart; systemd; etc. Just give me BSD RC. Maybe it's not ideal, but shit, it isn't swallowing 80% of userland with eventual ambitions of conquering the kernel and some of the worst defaults I've ever seen.

I'll just stop now, but I could go on for days in this vein. Maybe some of these tools are great, but I don't expect any of them to remain ascendant for more than five years in a form that is effectively recognizable by any significant measure but its name. The churn drives me insane. One of the reasons I aimed for software development in my professional life, abandoning the system and network administration (aka "ops") side of thing, was to escape all that crap. I want to write quality code, build new things and improve existing things, not participate in a rat-race to remain relevant just to have acquired nothing enduring from decades of effort other than stock options and a nice car.

> A lot of this is a direct result of feeling that one always needs to be on the bleeding edge, which is both unnecessary and also a recipe for wasting time on fads.

It's also because the JS ecosystem is absolutely massive -- too massive. Instead of consolidating around a good package, people create a new one. You end up with a small number of contributors (often one) per library, and being on the bleeding edge is the only way to make sure your dependencies are maintained.

Javascript's biggest problem is its lack of a standard library. Hence the ridiculous churn of trivial libraries such as leftpad.

Lack of standard library doesn't account for web framework churn, though. Momentarily seemed like we had coalesced around Vue and React, and here comes Svelte, among others. It's incessant.

React was released 7 years ago in may and is definitely the most dominant framework and going very strong, and will be a good career investment for years to come. I think framing that "momentarily" for yourself is making yourself very unhappy - life changes constantly, as we see with this pandemic, and we need to have a little bit or willingness to accept change every five years or so, or perhaps we need to choose a field that has less competition (which is also why we enjoy great benefits and great pay). It should also be noted that both Vue and Svelte are extremely similar paradigms to React, and not at all the big paradigm shift that we saw from Angular to React.

React is its own ecosystem at this point. I can't even keep up with React state management libraries...

That feeling of not having mastery of your tools is part of the problem.

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.

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.

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).

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".

Maybe I haven't been doing this for long enough (~8 years), but I think we're starting to see a plateau in JS-land.

I jumped into React early-on (5 years ago), and it's still going strong, and has been for way longer than Angular / Backbone / ExtJs ever did.

I wouldn't say Express is abandoned, I feel it's more that it's "matured". I mean what else can you add / improve?

State management is still an un-settled area; 2 years ago it seemed like Redux was the best choice, but GraphQL / Apollo is eating its lunch. However, when you think about it it still follows a similar conceptual model, but making it even more declarative: You have your "store" (the query result), and you dispatch "actions" to modify that store (the mutations). You just don't have to dispatch an action to fetch data from the server anymore; Apollo handles that for you.

It's true that JS churned very fast for a long time, but I'm seeing signs of it slowing down as problem areas become "settled" one-by-one.

Let me know when it's done settling in ECMAScript Land, then. In the meantime, I'm doing interesting stuff Somewhere Else.

Nailed it!

I've been programming professionally for 20 years and doing exclusively frontend with React since about 2014.

After the whole React Hooks thing, I can't freaking wait to do something else; and I'm absolutely livid with their decision to promote Hooks.

They should have forked React instead of introducing that into a somewhat mature ecosystem. Already went through this fractured bullshit with Coffeescript, and a million other frameworks of the moment. The JS community just doesn't learn, and when you see a big player like Facebook making the same mistakes, there really isn't much hope.

I've found that this grind is conquerable. There are only so many ways to go before you start to see the fundamental patterns, and friction in picking up anything new becomes seriously minimal. It's like how some other comments are, talking about how most of programming is really just data access and some clever gluing of frameworks. Or like how there are already software patterns, especially in OP.

My point is, you start to glimpse these overarching patterns as you interact with different takes, and you learn what works and what doesn't, ultimately empowering you to intelligently make tradeoffs or designs of your own. The chaos of web development is, IMO, because it was a new frontier, and a lot of inexperienced leadership occurred. This was compounded by bootcamps churning out people experienced only in Framework X, causing poor re-implementations of nearly _everything else_ inside Framework X.

It sounds like you feel like you _have_ to keep up with these things - perhaps someone else on the team is constantly insisting on migration, but they don't have to go through and tediously migrate and test everything. I'd suspect this lack of autonomy is at the core of your dissatisfaction. You can, and should, say no to a lot of trends, and if you do pick up something new, you should be able to clearly articulate why it's valuable, and these values should be more than superficial.

Another thing worth noting is that the release you work on today is the "legacy, painful" code of tomorrow. But that's a good problem to have - it got the job done. It just happened to get it done in one way, when there are really N ways, and so obviously the numbers game will work against you eventually, even in the imaginary case where the implementation is perfect.

I can't empathise with it being a grind - keeping up with the latest developments only makes sense if you need to for your job or the new thing brings something genuinely useful.

However, JavaScript as application code just feels entirely verbose. I guess coming from a very opinionated framework like Rails leaves you sheltered, but I'd rather use a technology designed for the task I'm trying to accomplish than to shoehorn JS into something else.

Personally I find no elegance in JS, and writing it feels like a chore. If I had to do that daily I'd want to quit too. Obviously YMMV, but I get no joy in trying to fit the tool to the job, I'd rather just use another tool.

One of the reasons it's so popular is because JS is like Latin. If you know some words from one Latinate language, you could blag your way around half of Europe, probably order a meal and find directions. If you know some JS syntax, you can scrape by using half the tools out there today, and accomplish a bunch of different things.

If you want to go and live somewhere though, it's better to learn the native tongue.

I was a game developer and I pretty much grew to dislike what I had to do at my former job. Doing same kind of mindless games, over, and over and over and pretty much repeating things.

I got into web development, but for me that means mostly back end. I pretty much dislike big opinionated JS frameworks like Angular, although I have to learn it and I will since I took over a project which uses Angular on front-end. Sometimes I generate HTML on the server side, when I can, using a bit of old fashioned JS and jQuery where is needed. Sometimes I write a REST API for backend and write the frontend using good old fashioned HTML, CSS, JS and jQuery. I like this two approaches the most.

Now I'm planning to learn Blazor and Vue for SPA development.

Well said, I was close to 8 years in web development and jumped ship a little over a year ago. Working in javascript development felt like a hamster wheel but maybe I just needed something different.

Might I ask where you work now and how you jumped ship?

I felt exactly the same thing the last few weeks but I have no idea what to do with it. Not sure how I would approach transitioning to another role really.