As somebody that's in JS all day but rarely touches backend, hearing about go, rust, kubernetes, docker, etc make it feel like backend is similarly fast-changing.
The difference seems to be in the narrative about the older tech. The "rails is still fine" crowd is loud, which is great. There is no equivalent for older JS tech. Though I would be willing to believe that's because things like jQuery are full of dated patterns that lead to bad times.
As a backend developer I am in the "jquery is fine" crowd =)
I'm always able to accomplish what I need without a lot of headache, though I'm not making gigantic SPA frontends.
There are very few people using go and rust for website backends. And kubernetes and docker are about deployment, not development.
If you are a backend developer, working in Ruby/Rails, or Php/Laravel, or Python/Django, or whatever, then I think you have a more than sufficient set of tools to do what you need to do, without worrying about much outside of that. It's a much more sane and stable experience than trying to be a frontend JS dev today.
> hearing about go, rust, kubernetes, docker, etc make it feel like backend is similarly fast-changing.
That's just hacker-news discourse. As for go and rust, backend programming languages aren't changing very much for most people. Python and Java are the most numerically significant languages and the experience of being a backend engineer in those languages doesn't change rapidly. (Python has just spent about 10 years releasing v3 and, while it is a great thing, honestly the difference that will have the most impact on peoples' brain-time is that you can interpolate variables into a string from the local scope using an 'f' prefix, and that `print` now requires function call syntax.)
Backend infrastructure is exciting and subject to radical change, however.
Yes, things are changing rapidly everywhere on the stack, but it seems that with front-end dev the same two things are left behind with each generation: performance and accessibility.
Each time we get close to making performant and accessible web sites easy for mortals to develop, some major disruption in the force occurs and well-crafted solutions no longer work in the new environment. So people reinvent them, poorly, and it takes another four or five years before things catch up.
I think many designers and developers prioritize their own needs or preferences and fail to advocate for what users really want. No user wants a web site or app to take 10 seconds to load on their phone, yet most do. Users don't care if your app is written in React, Angular, or served from a WordPress site. They just want to be able to use it.
The beauty of React and other frameworks is that it separates the concerns of state and UI.
I don't see it as a tool for making a fancy button or widget, I see it as a tool for guaranteeing that what the user sees is always what's actually going on in the logic.
Too many times I've written something like a "clear" button or a "reset" button in jQuery, added an extra field, forgotten to include it in that clear/reset method and now the UI doesn't match the logic, leading to unpredictable and hard to debug results.
React separates concerns but it doesn't separate state and UI. It separates concerns through components but encourages tightly coupling relevant state and UI into components because a UI typically reflects changes in state (this is what JSX is for).
I think jQuery and IIFE/AMD modules are fine. Tools for the job, React might be overkill for some smaller apps, and jQuery is a hassle with larger SPA/PWAs.
The difference seems to be in the narrative about the older tech. The "rails is still fine" crowd is loud, which is great. There is no equivalent for older JS tech. Though I would be willing to believe that's because things like jQuery are full of dated patterns that lead to bad times.