You are correct, there have been changes on the back-end as well: containers and Kubernetes vs serverless. The endless tension between microservices and monoliths. Multiple IaC options. Onprem vs cloud (which cloud?), and associated cycles of disillusionment.
The difference may be that once a particular back-end approach/architecture/design is adopted by a dev shop it remains stable over multiple projects. I’ve seen this in both consulting and in LOB roles. Because of this, I can hire a competent .NET developer and be confident that I can get them to be productive relatively quickly, since the foundation on which we write our code is stable, and I can invest in enhancing the developer experience to support them. In fact, an explicit criterion for every project in my teams is that we make it easy enough for any competent C#
developer to ideally be able to open a small, but meaningful PR by the end of their first day on a project (if needed, I don’t treat it as a retention gate or anything!). They do have to adapt to our infrastructure and our ways of working, they don’t need to relearn the fundamentals of how to produce code.
Whereas every time a new front-end project starts, there’s a near-compulsion to use the latest and greatest techniques. Everyone has to catch up, because of their previous experience being somewhat redundant. No one can invest in improving things for other developers, because they don’t have the time, and because any investment would be wasted, since it would be redundant beyond the current project (or two, if we’re lucky).
I can’t really hire an Angular developer for a React project that starts tomorrow, and expect them to be reasonably productive immediately, despite them being competent in Typescript, CSS, Node etc. Heck, I wouldn’t even be able to hire a React developer who last did it 5 years ago, and expect them to be immediately productive.