3 ms·

Much more accessible to frontend engineers so you can detach what would be backend problems to your frontend engineers. Often many microservices will be availab

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.

apsurd 2y ago
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.
- martinsnow 2y ago
  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.
dmix 2y ago
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.
- martinsnow 2y ago
  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.
  - dmix 2y ago
    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.

apsurd 2y ago

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.

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

dmix 2y ago

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.

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