Dan Romero on Warpcast

Dan Romero pfp

Curious if React folks here have strong thoughts on SSR vs. SPA?

16 replies

0 recast

0 reaction

borodutch @ lunchbreak.com pfp

borodutch @ lunchbreak.com

@farcasteradmin.eth

ssr is plain stupid users have supercomputers in their hands do not outsource computing to centralized machines also makes cdn's less effective (as opposed to serving lightweight spa) crawlers run js now, for the ones who don't you can use prerender libs

2 replies

0 recast

0 reaction

pugson pfp

if you can't pinpoint the exact benefits SSR will bring to your project then you don't need SSR. next.js becoming the #1 react framework and doing SSR w/ data for everything has caused a lot of react apps to become slower than their SPA counterparts with decoupled backends.

0 reply

0 recast

2 reactions

Jseam pfp

SSR was generally better for SEO, with SPA you needed a separate service that served the metadata for the page SPA still remains useful for static sites

0 reply

0 recast

1 reaction

Tony D’Addeo pfp

SPA (with intentional use of the History API and appropriate state in the URL) unless you have a compelling need for SSR, which SEO is the only compelling one I’ve heard

0 reply

0 recast

0 reaction

Breck Yunits pfp

SPA all the way and then for content sites dump a static HTML. build. OurWorldInData.org is built as a static site, and then we had some SPA for the charts and backend.

0 reply

0 recast

0 reaction

Varun Srinivasan pfp

Varun Srinivasan

it aint much, but its honest work https://i.imgur.com/YUqgo0X.png

0 reply

0 recast

0 reaction

Nicholas Charriere pfp

Nicholas Charriere

SSR as much as you can. It ships less code, is more secure, and significantly more productive for engineers to build in. SPA when you need really advanced interactivity or client side state. These days a hybrid model called "islands" is popping up a lot (see deno fresh / astro)

1 reply

0 recast

0 reaction

Nar pfp

Imo a combination, SSR for things that matter for link previews and SEO. CSR for the rest to reduce FCP eg in the case of server cold starts

0 reply

0 recast

0 reaction

David Furlong pfp

Right up my alley 1/ Initial page load html should probably always be from SSR/ISR/SSG because it's considerably faster than sending 150kb+ JS client bundles that need to be downloaded and run. For SEO one of SSR/ISR/SSG is crucial as well as most crawlers in practice don't wait on CSR

2 replies

0 recast

0 reaction

Britt Kim pfp

Yeah. Combine them. SSR always has a place. You might want to pull data from private APIs. You might want to hide proprietary logic. You might need to do things that aren’t js. They aren’t antithetical.

0 reply

0 recast

0 reaction

typeof.eth 🔵 pfp

typeof.eth 🔵

+1 for depends on the use case. CSR-only SPAs are less common these days and more web apps are doing a mix of CSR, SSR, and SSG. Web3 throws a wrench in things since you may need the user’s account to render content so SSR/SSG is a no-go for some things. I’m usually using a mix of three with Next.js.

0 reply

0 recast

0 reaction

Venkatesh Rao ☀️ pfp

Venkatesh Rao ☀️

1 reply

0 recast

0 reaction

Brandon pfp

All depends on the project really. I’ve worked with nextJS, remix, and CRA. Remix is pretty bad ass, allowing the strength of React to really shine while leaning heavily on native browser APIs. SSR allows you to hide environment variables, which are not truly hidden in an a SPA, causing the security on SSR to be bett

0 reply

0 recast

0 reaction

4535 pfp

You actually can combine both. But anyway depends on ur needs

0 reply

0 recast

0 reaction

Carlos Matallín pfp

Carlos Matallín

The right tool for the right thing. Throw in SSG (Static Site Generation) and ISR (Incremental Static Regeneration) for more uses cases. I’m very excited for developments in partial hydration.

1 reply

0 recast

0 reaction

Alex Loukissas 🍉 pfp

Alex Loukissas 🍉

Not exactly a comparison right? Do you mean client side rendering vs ssr or MPA (eg remix) vs SPA (eg next)?

0 reply

0 recast

0 reaction