True - often "full stack developer" is synonymous with dilettante
To me, it reads like this: let's take away one of the only advantages of the web, the strict separation between frontend and backend, by mercilessly introducing heavy coupling and making one end depend completely on the other end for the sake of short-term one-off projects. After all, rockstar developers have long moved on to their next glorious project when maintenance time comes. After all, you don't want to slow down a rockstar full stack engineer with mundane un-agile concepts like layers or such archaic waterfall nonsense.
On the contrary, I would describe it as normal, in the sense that all of these web technologies are just tools and protocols. Any software developer with broad experience ought to be looking at general software architecture principles and programming techniques and testing strategies and all the rest and then choosing whatever tools help them get the result they need.
"Front-end developer" and "back-end developer" always seem like "C programmer" or "Python programmer" to me: they're job titles you use when you don't have enough experience with different tools and techniques yet to drop the qualifiers and just call yourself a web developer or programmer. And those in turn are just titles you use until you realise it's all about building something useful and the job title doesn't actually matter at all except perhaps as a convenient shorthand for initially finding people you can talk with intelligently about getting stuff done.
| a convenient shorthand for initially finding people
| you can talk with intelligently about getting stuff
| done.
Interesting position. To me, that strict separation is more often a curse than a blessing in web development.
I'm all for maintainable, modular software architecture, and you obviously have a distributed system if you're running some parts on a server and some parts in a browser. However, I don't see why it's helpful to elevate the physical barrier where the remote comms fits to a kind of "strict separation" more than any other case of separating concerns.
IME the browser/server divide tends to introduce heavy overheads (on the scale of using completely different programming languages, and marshalling all useful data from one form to another) that don't in themselves offer much benefit in return. It also tends to push less experienced developers into treating the entire system as composed of just two modules (front-end and back-end) or maybe three (throw in a separate database/ORM component) rather than thinking about what they're modelling, how their business logic needs to work, how their user interface logic should be structured, and so on.