4 ms·

People have gotten way too religious over SPAs, SSR, etc. Should you use X? Maybe it depends. I have been burned by using SSR when the complexity of the app in

People have gotten way too religious over SPAs, SSR, etc. Should you use X? Maybe it depends. I have been burned by using SSR when the complexity of the app increased and suddenly doing SSR was getting in the way and now I was uncomfortably mixing JS with server rendered pages and struggling to maintain state. I've also been on the other side, using React and creating more complexity than was needed. The point is: don't be dogmatic. Get requirements, extrapolate what could happen in the future, use first principles, weigh decisions against team capabilities, ask yourself if your decisions are for your own personal reasons or have significant positive user/business impact. Engineers who rush to use one technology over the other without doing their homework are just doing bad engineering. It has nothing to do with "fighting the good fight".

jacobsenscott 4y ago
People also need to work within the constraints of the chosen stack. You can make a very good experience in either a SSR and SPA app. But you can't make identical experiences. Product designers are notoriously bad at working within the constraints of a stack - so when you choose SSR with hotwire or whatever, you definitely need to push back when a product designer hands you a mock up of something that can't be done easily with SSR. Don't create some mess of SSR and JS. Tell the designer to go back and redesign the experience so it meets the constraints of the stack. So when I hear "the complexity of the app increased" I'm hearing "the designer invented something that doesn't work with our stack" and rather than saying no, the devs just tried to forge ahead with the wrong tools. (Obviously I'm projecting experiences I've had :))
- 0xblinq 4y ago
  Very well said
sodapopcan 4y ago
I agree 100%. Doing everything on the client has its place, but those aren't the type of apps I'm interested in working on. My problem is that for the bulk of web apps out there, a frontend JS framework (I'm sorry I don't have hard data on that but going by experience and the experiences of people I know). The "good fight" I'm referring to is not defaulting to React to build your information app that has very little interactivity. The recent "HTML over the wire" frameworks lean heavily on abstracted away JS to give you a middle ground between SPAs and pure SSR.
ivan_gammel 4y ago
Exactly. My rule of thumb is that SSR is good when you optimize conversion (hence focus on bounce rate, FCP, time to interactive), SPA is good when you optimize UX (hence focus on interactivity, response time, recoverability etc). On the customer journey SSR is usually everything before registration and login, SPA is for most of the things after (except some embeddable static content like help pages).

jacobsenscott 4y ago

People also need to work within the constraints of the chosen stack. You can make a very good experience in either a SSR and SPA app. But you can't make identical experiences. Product designers are notoriously bad at working within the constraints of a stack - so when you choose SSR with hotwire or whatever, you definitely need to push back when a product designer hands you a mock up of something that can't be done easily with SSR. Don't create some mess of SSR and JS. Tell the designer to go back and redesign the experience so it meets the constraints of the stack. So when I hear "the complexity of the app increased" I'm hearing "the designer invented something that doesn't work with our stack" and rather than saying no, the devs just tried to forge ahead with the wrong tools. (Obviously I'm projecting experiences I've had :))

0xblinq 4y ago
Very well said

sodapopcan 4y ago

I agree 100%. Doing everything on the client has its place, but those aren't the type of apps I'm interested in working on. My problem is that for the bulk of web apps out there, a frontend JS framework (I'm sorry I don't have hard data on that but going by experience and the experiences of people I know). The "good fight" I'm referring to is not defaulting to React to build your information app that has very little interactivity. The recent "HTML over the wire" frameworks lean heavily on abstracted away JS to give you a middle ground between SPAs and pure SSR.

ivan_gammel 4y ago

Exactly. My rule of thumb is that SSR is good when you optimize conversion (hence focus on bounce rate, FCP, time to interactive), SPA is good when you optimize UX (hence focus on interactivity, response time, recoverability etc). On the customer journey SSR is usually everything before registration and login, SPA is for most of the things after (except some embeddable static content like help pages).