Hacker News Reader

Comment by martinsnow | Hacker News Reader

Much more accessible to frontend engineers so you can detach what would be backend problems to your frontend engineers. Often many microservices will be available but no cohesive endpoint or gateway will be available. Task your frontend with creating the gateway because they know the access patterns and they know what they need.

View on HN

Ok. I can understand that problem on a 30 person eng-team at med/large company.

It makes sense why nextjs kills my soul every time I touch it. For side-projects it's just me, for startups it's a few people where the entire premise of the company may change monthly, not to mention the API and product assumptions.

Perhaps it's just the millennial in me. Intentional frontend/backend bounded expertise is rather silly in a fledgling company.

We're talking multiple multiple business units spread out multiple disciplines. Funnily enough we can settle on a common backend language and frontend language and even frameworks in my org but apparently on HN everyone wants to be special? I would love to see how many features got shipped a week with that setup.

Frontend engineers don't have to be isolated in their own world. If they can learn JS and the craziness of JS frameworks they can learn Ruby or Python or whatever. Way too much complexity is added to web app development because of this idea that backend and frontend are two completely different worlds.

In that case why can't your python engineers learn typescript? There's no performance benefits and a much larger library of tools to choose from.

They usually already know JS? My point is about not isolating dev teams into front/back islands from a systems, product, and team management perspective.

Adding a separate JS frontend is a good way to double your costs and dev time. There's few situations that demand such heavy JS but people follow trends like sheep. And I say that as a frontend engineer who wrote JS/TS for a decade.

Reply on news.ycombinator.com