This is division of labor gone out of control.
Complexity doesn't get simplified by merely renaming things. Bloated javascript frameworks and associated "infrastructure" keeps requiring more and more people to manage them.
You can put a good backend guy on the 'back of the front end' no problem, it's sometimes similar work and it can feel like 'regular coding' - sometimes it helps to have the same team working both sides of the endpoint.
But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing.
It's not really a stretch.
Have you tried upgrading your React app that was 1.5 years old? How many times upgrading anything in npm gives you the worst nightmares?
It’s not just bloat, it’s the stress that front end dev brings. It’s a chaotic world, constantly changing for god knows why and the entire ecosystem does not value robustness and longevity. In fact, they've made it cool to break things all the time. Robust tools are considered "old fashioned". Apart from Angular, which is a still finicky, the rest of the dependency management is a complete nightmare.
I can easily revive a 4 year old backend code. Most likely without a single error. With absolute and 100% certainty, I can guarantee the opposite for any front end code, even Angular projects. Node js, the backbone of managing js projects itself doesn’t value backwards compatibility.
React is a special beast, I don't like it, yes, it's a little bloated and no, I don't so much think it's quite suited to the front/back of frontend division.
Your problem with bloat and fragmentation though, is not about this particular form of division of labour.
Front ends change a lot more for a variety of reasons.
One reason the front end evolves more is there's more going on, and more detail. The backend is logic, which can be more succinctly articulated by code. That's what code is for.
Most code was never designed for UI, and even HTML/CSS was never designed to do what it's doing. A simple web form can involve a lot of cross-cutting artifacts and complex statefulness.
Even with a great set of tools it can be quite hard to get right, and requires a different way of thinking than on the backend.
Front end problems are usually however, narrow in scope - a screen can usually only ever be so complicated, whereas on the backend, true scale can make a lot of things hard.
My main gripe is the people behind major frontend projects - Node, npm, React, etc. and their overall philosophy. The community is a shitshow and I hate how unorganized, unplanned, broken the entire ecosystem is. The worst part is that this is celebrated.
For straight up web or small companies, Wix, Shopify or Wordpress is fine. Look how great HN is with minimal tech.
For 'Web Apps' it's obviously more difficult, and the current of tech is unavoidable, but if you stay in the middle lane and don't use anything to risky, certainly with 'backed' tech like React you should be fine.
If your business is Widgets, then everything else should be 'off the shelf'.
If your business actually is web-tech in some way, you can start to push the boundaries.
I wrote a collaborative model editor in React and MobX, using some nigh unknown JS library to manage collaborative aspects and d3 for visualizations. All while interacting with multiple services. I upgraded seamlessly across webpack versions, despite continuing to use legacy decorators.
Plus, churn in the front end is completely overstated. Most libraries from a few years ago have the exact same APIs, but perhaps also added a new way of working. You do not need to adhere to this new way of working, or you can progressively adapt it. Small libraries died, but isn’t it professional diligence to evaluate the likelihood of that happening and the risk you take in the first place not doing it yourself? Especially when it is simple.
A thoughtlessly npm’d together FE is a pain, as is any thoughtlessly bolted together anything. Granted, some things lend themselves more to disaster than others.
I think it’s a people thing. Hire lots of hardcore .net peeps to wire up a complete setup, and of course nuget will be solid and npm a flaming mess.
I'd say ESPECIALLY on Angular projects (or React or Vue). Look at the package.json of any JS "web app" in any of the popular frameworks. Now imagine how many of those packages will have breaking changes in 1 year. By 2 year mark, many of them will be abandoned completely forcing the app maintainer to replace, or continue using an old version if that is even possible.
They require an understading of UI basics and reading the documentation. That knowledge is rarely specific, it's mostly the same pattern applied in a different manner. If a "good backend guy" can't read that (usually super simple) documentation of the frontend framework and understand how to apply it, I would not call him a "good backend". Just like a frontend dev should be able to read and understand what a node server does, a backend dev should be able to understand basics of UI frameworks, otherwise, it's not a developer we're talking about, it's a glorified typewriter.
It's not a technical ability issue in general, though there are a whole bunch of quirks such as browser compatibility that it can seem a little unfair to expect someone who mostly deals with optimising database queries and algorithms to also have to learn.
There is always a gap between what the designer produces and what needs to be created to make a fully functioning application. A good frontend-of-the-frontend developer has the passion, experience and user empathy to fill in this gap and make a site that is pleasant to use.
I say all this as a backend/platform developer.
1) It takes time to get to know the framework, it's know-how, and often the docs are not clear.
2) Good UI work is almost always more than just 'stuff on a screen'. But it doesn't have to be if you have good designers.
When you have 20+ engineers, it makes sense to specialize. When you have 3, it's a huge hit to your productivity. The scale of the app is mostly irrelevant to this.