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.

> The BE / FE split has been a really bad experiment.

What do you mean - "full stack" is very popular and frankly produces some of this weird unmaintainable code. Hiring backend-y type people and making them develop UI (with state especially) is where half these companies realize "crap we need a front end developer"..

I’m sure you can find horrible code bases in any arrangement. I will say that a good team will tend to be better for more projects than two good teams (fe/be). There certainly are cases where a split will make sense and be much better, but I have seen it become the default when one team should be.

This comment is steeped in bias. The front end is not complex for its own sake, it’s complex because APIs are needlessly rigid: https://bower.sh/front-end-complexity

Delete the API, render your html on the server, problem solved.

If you're not building something like Gmail, Docs, or Figma (AKA an app that should be on the desktop instead of the web). Rendered HTML should be the way to go, even if it's just a gateway to a more complex infrastructure.

I think you mean exacerbated

I get really exacerbated when people make this mistake.

It's not an experiment though. The divide is clear, you have a client application, and then server applications that the client talks to. This is even more true if you want a lot of interactivity. This line isn't going away anytime soon. There will always be an application that runs on the edge device or machine, and it needs to talk to some other application to store and retrieve data.

The secret is to make the thing that runs on the backend the application, and the thing that runs on the edge device the user interface.

It just depends on the use case. The "interface" could be complicated enough that it needs a full blown application with state. I would say that's the typical expectation today from users.