I understand some comments here are saying that they feel React is here to stay. I have no basis to judge that, but putting that side, a question: what is it about frontend web development that seems to lend itself to neverending development of new frameworks or ways of building apps? I'm genuinely curious. Is there something inherent in developing web apps that just isn't quite solved, some way in which each new framework doesn't quite solve the problems (whatever those are)? Or is it just that the web (unlike mobile) is so open and there's so much development interest that this leads to endless efforts to improve on what came before leading to new frameworks all the time? Appreciate any thoughts on this!
Coming from the backend, I feel the exact opposite. For any kind of frontend development you have a choice of ~3 clients, one programming language, a handful of frameworks, 2-3 of which have any real traction.
Compare that to literally hundreds of programming languages that can run server side code, dozens of database engines, servers, all kinds of operating systems, hosting platforms...the web of backend tech is pretty much endless, and growing every day.
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.
Regarding the last paragraph, I think an experienced developer can jump to new frameworks relatively quickly. They won’t be putting out PRs on day one, but can certainly do so in a week or two with a new framework. If your web fundamentals are strong, one can get through the docs for a new framework in a few days, then spend a couple of days looking at GitHub repos that use the framework in question to suss out best practice patterns of code organisation and you’d be in a good position.
It’s odd to me that frontend dev jobs ask for experience with specific frameworks, since most of the popular ones share core fundamentals a lot of the times. It’s no different than going to a new backend role to work on a large existing codebase. The codebase will have its own homegrown patterns and concepts to get familiar with anyway, how is this any different?
I was referring to greenfields projects, but the problem is even more acute for the maintenance problem you outline. You have a portfolio of front end projects: each one would involve learning whatever quirks the framework and implementation were used (by necessity). A company with a reasonably consistent back-end architecture, project structures and coding practices would have an easier time onboarding maintenance developers, as long as each project was done with some kind of eye to maintainability.
