As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea.
When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger.
I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc.
Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front.
Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.
I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases.
Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.
I wonder what you think of components. Back in the day it was heresy to mix css html and js. Everything was separated. Nowadays a component mixes them all.
In a way, it is exactly the example opposite of what you mention.
When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger.
I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc.
Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front.
Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.