Hacker News new | ask | show | jobs
by overdrivetg 3350 days ago
Two big reasons are:

1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them

2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"

Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.
1 comments
scott_karana 3349 days ago
Point 2 is a good call. Hadn't thought of that.

In practice, Point 1 isn't too realistic though:

Front-end and back-end almost always use different build/debugging tooling, different unit/integration testing frameworks, and even different paradigms. Unless your developers are good at constantly switching modes, it's hard.

"no real upside" is wrong, as you point out, but I would stand by "no guaranteed upside" :-)

link