3 ms·

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.

gryn 2y ago
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.
- happimess 2y ago
  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.
- mejutoco 2y ago
  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.
gedy 2y ago
> 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"..
- mangodrunk 2y ago
  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.
qudat 2y ago
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 https://bower.sh/front-end-complexity
- bullfightonmars 2y ago
  Delete the API, render your html on the server, problem solved.
  - skydhash 2y ago
    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.
namaria 2y ago
I think you mean exacerbated
- daotoad 2y ago
  I get really exacerbated when people make this mistake.
proc0 2y ago
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.
- jmulho 2y ago
  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.
  - proc0 2y ago
    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.

gryn 2y ago

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.

happimess 2y ago
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.
mejutoco 2y ago
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.

gedy 2y ago

> 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"..

mangodrunk 2y ago
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.

qudat 2y ago

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 https://bower.sh/front-end-complexity

bullfightonmars 2y ago
Delete the API, render your html on the server, problem solved.
- skydhash 2y ago
  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.

namaria 2y ago

I think you mean exacerbated

daotoad 2y ago
I get really exacerbated when people make this mistake.

proc0 2y ago

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.

jmulho 2y ago
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.
- proc0 2y ago
  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.