Hacker News Reader

Comment by krisrm | Hacker News Reader

I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.

View on HN

That's definitely true at the organizational level, and it's an argument with some merits.

In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!

My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".

that sounds like a mismatch between the architecture and how work is getting planned no? if the backend is in the critical path to delivering the user value of a feature then the backend and frontend engineers need to be developing (and testing) the feature together

They ALWAYS need to be building and developing the feature together or this happens. Decent API design without deep understanding of Client implementation or performance needs is nearly impossible.

They generally should all be in the same team, but that often doesn’t scale.

Not having them in the same team pretty much never works well though either.

Also allowing your mobile app to use the same API as the website.

That's not really unique to SPAs, right?

I don't know much about front-end development but I imagine you can create a front-end that is both not an SPA, and not server-rendered.

It's not about being unique, or what you can/can't do. You certainly can mock a front end with a ssr app, but it gets messy when you are building a rich client app and need to start sharing state back and forth.

You can still do that with SSR solution, the mocking just moves one step down, instead of mocking a JSON request you mock a class or an interface.

Why not eliminate that organizational bottleneck by using a full-stack framework that lets one person do it all? DHH recently described Rails as a one-person framework [1]. I think Phoenix fits that category as well.

[1]: https://world.hey.com/dhh/the-one-person-framework-711e6318

Reply on news.ycombinator.com