Colin
@colin
@nickcherry what stack is the Warpcast web app using? Would love to hear about design decisions etc
2 replies
0 recast
0 reaction
Nick Cherry
@nickcherry
Knowing that we would want OpenGraph support and eventually SEO, we seriously considered SSR solutions like Next and Remix. Ultimately, though, we felt that they introduced a fair amount of complexity with relatively little upside – the biggest benefit being "free" server-side rendering for OG and SEO.
1 reply
0 recast
0 reaction
Nick Cherry
@nickcherry
A CSR solution was simpler and I would argue potentially more performant, but we still needed to solve the OG problem. We considered outsourcing the server-side rendering to someone like prerender.io, but we didn't love the idea of relying on a third-party, particularly when our product reqs weren't that demanding.
3 replies
0 recast
0 reaction
billzh
@billzh
Great thread. Why do you think CSR is more performant in this use case?
1 reply
0 recast
0 reaction
Nick Cherry
@nickcherry
I think SSR tends to be more performant for FMP at the beginning of the session (notably with a delay before JS becomes interactive), but assuming you are hydrating the app, I think you end up sending more data over the wire and may get into waterfall situations for subsequent page loads.
1 reply
0 recast
0 reaction
Nick Cherry
@nickcherry
If done very well, I think SSR would be marginally more performant than CSR, but it's nowhere near as clear a winner as it's made out to be, and the added complexity is often not worth it IMO.
1 reply
0 recast
0 reaction
Nick Cherry
@nickcherry
The biggest perf difference that you'd notice, I think, is for FMP, but a CSR app can narrow that gap with code splitting, caching, etc.
1 reply
0 recast
0 reaction
billzh
@billzh
Thanks for the detailed explanation. Been thinking about similar tradeoffs as we build Alphacaster. Though we did eventually go with SSR
0 reply
0 recast
0 reaction
