5 ms·

IMHO it's a huuuge mistake to try and squash these two very distinctly different things into one word (SSR), and it has added a ton of confusion to many with Ne

by Tehnix 4y ago

IMHO it's a huuuge mistake to try and squash these two very distinctly different things into one word (SSR), and it has added a ton of confusion to many with Next.js's move away from it. - SSR: Dynamic rendering of paths, happening at runtime. - SSG: Static rendering of paths, happening at compile time. A separation makes it much clearer that the core difference here is that SSG can only take you as far as "something generic for everyone" and SSR will be able to render "a page unique for a specific user". Infrastructure-wise there is a world of difference between the two approaches and they are not even close to being related. - SSR: You'll need servers, scaling, load balancing, etc. - SSG: CDN + S3 and you're done EDIT: To add a bit, imagine the following "I'm using SSR.", "Ah, cool, like full SSR or only half SSR?", "Only half, serving static files" - at this point, it's clear that we've now overloaded SSR to be a less useful term to describe what it is, which I personally find quite unfortunate.

vlovich123 4y ago
I don’t know. I think a good SSR library + some clever front end frameworks + an edge compute platform where you don’t have to worry about anny scaling and you’re done. I’ve seen some really impressive demos of stuff that is extremely dynamic (ie per request), rendered server side on first use for the immediate portion you need with transparent hydration in the background to download interactivity as needed. Sure it seems more complicated ha CDN + S3, but I think in actuality it’ll be simpler in application. It all works super slick and conceptually there’s actually very little complexity for those applying it (the frameworks take care of the difficult bits). Since this is happening at the edge (in Cloudflare’s case, where I work, within something like 50ms of transit time to 95% of the population), and you’re only doing the initial view, you can get websites that load large pieces of content much more quickly than rendering it client side which is dominated by less powerful devices (ie SSR+transfer time is competitive) with less bandwidth/higher latency if you’re collating responses from different backends. You could even see that extending where they prefetch the raw data you’ll need to render the rest of the page in the background and either prepare a rendering, just bring it closer into the cache as a prefetch, or even push it to your browser proactively. Now of course it’s possible this stuff won’t generalize but I don’t see any obvious obstacles. It feels like within 10 years this could be the dominant way client web apps will be written. I get that we originally used to do that but it’s about taking the best of both worlds (SSR let’s you get super high performance initial loads while dynamic client side handling let’s you handle interactivity better and doing it transparently makes your development process a heck of a lot simpler as you don’t really need to differentiate the code as much (whereas I think you would with SSG+SSR). For SSG you probably don’t need to find general pieces of content and set up a different layer vs changing some caching parameters / doing content based hashing transparently. I think that’s maybe the direction OP was heading with in his remark of the distinction not being helpful.
- Tehnix 4y ago
  Don't get me wrong, I definitely think the current movement and focus on a great UX is amazing! But as someone that cares a lot about scalability and operational complexity + cost, it hurts a little to see certain approaches that'll work great in small scale, but be troublesome at large scale be recommended so strongly :/ > edge compute platform I would consider that quite a big difference in infrastructure. It can easily be done already right now, but the cost and performance equation between serverless compute (at edge or not) v.s. static file serving becomes noticeable at scale. Let's make some pricing examples: - We'll have 2 million "first page loads" per day (~60 million per month) - Let's give our bundle a low estimate of 200KB ------------ Vercel's pricing (just to take a popular example)[0]: - Pro tier: $20/month includes 1m execution units (EU, 50ms of CPU time) and 1TB bandwidth - Then $2 per 1m EU and $40 per 100 GB bandwidth - Let's ignore GB-hours for now (memory x runtime)[1] - Let's assume you're always able to render your SSR page in 50ms or less (quite optimistic if you're doing any form of DB operations in your SSR) AWS CloudFront pricing[2]: - Always free tier: 1TB bandwidth, 10m requests - Then $0.085 per GB bandwidth and $0.0100 per 10k requests - (at scale you can get +50% discount on bandwidth by committing) ------------ We can then run the numbers: - Estimate (200 KB) on Vercel: - (60m requests - 1m free) * $2 per 1m = $118/month - 200 KB * 60 million = 12,000,000,000 kb = 12TB - (12TB - 1TB free) / 0.1 * $40 per 100GB = $4400/month (you'd probably want an Enterprise plan at this point unless I did the math wrong here. Their FAQ suggests to reach out to their sales team which you should definitely be doing at this scale!) - = $118 + $4400 = $4,518/month - Estimate (200 KB) on CloudFront: - (60m requests - 10m free) / 0.01 * $0.01 per 10k request = $50/month - 200 KB * 60 million = 12,000,000,000 kb = 12TB - (12TB - 1TB free) / 0.001 * $0.085 per GB = $935/month (which could be $440/month with reserved capacity) - = $50 + $935 = $985/month ------------ Totally open for having made a calculation error above, but this is the kind of thing that one needs to concern themselves about at scale. The above example is quite realistic, in fact it's a lot less than our usage at my current work. Admittedly here we are seeing most of the cost come from bandwidth. If you substituted Vercel with AWS Lambda you would be able to benefit from the CloudFront pricing on this. [0]: https://vercel.com/pricing https://vercel.com/pricing [1]: https://vercel.com/guides/what-are-gb-hrs-for-serverless-function-execution https://vercel.com/guides/what-are-gb-hrs-for-serverless-fun... [2]: https://aws.amazon.com/cloudfront/pricing/?nc=sn&loc=3 https://aws.amazon.com/cloudfront/pricing/?nc=sn&loc=3
keyle 4y ago
SSG is a static website?
- Tehnix 4y ago
  Yup (static site generation)! But more complex than a traditional SPA setup. Traditionally an SPA has been just one single bundle file that is downloaded. With SSG you pre-generate a file per path which gives the user many of the benefits of SSR on that first page load, before the SPA part takes over again.
  - ZephyrBlu 4y ago
    You are slightly conflating SSG with SPAs. SSG doesn't necessarily mean you have an SPA-like site, it could just be a MPA (I.e. classic website).
    - eric-burel 4y ago
      Many answers are in this thread, I should have made my point clearer: from Perseus doc, it has a limited vision of static rendering, that stems from a slightly incorrect mental model. Statically rendering and not needing a server are different subject, and statically rendering is not limited to generic content. This can be easily proven if you think statically rendering a page as precomputing the render at build-time. I've written multiple time about this subject and Next 13 App Router design choices are consistent with this theory. This makes Next much more powerful that many competitors, as it covers all use cases of static rendering.
  - re-thc 4y ago
    You also get disadvantages. SPA due to its history is widely supported. SSG not so much e.g. from a routing perspective. It's good if your platform can support it.
    - satvikpendem 4y ago
      But...SSG is how pages traditionally worked. You have some files in a folder and use <a> to link between them, no dedicated router required. Routers are needed in SSR though, depending on your use case.
eric-burel 4y ago
See, that's the problem: you said SSG can only take you as far as "something generic for everyone". This is not true, otherwise you could not implement static i18n. Also I don't want to squash them either but dynamic vs static is for instance much more appropriate, it's a shortcut for request-time vs build-time server rendering.
- throwaway290 4y ago
  What is generally meant by SSG is that at runtime you send fully usable static pages and don't need to run any app logic. This radically expands your options for hosting (S3 + CDN, done). You can't have personalization unless you run app servers, you can provide some alternatives at build time (localization, AB tests) but nothing actually personalized. Whereas with SSR you run an app aware server, which means you can store client state and do everything with it sending to the browser final HTML, but it is more costly. So to me and many others whether a framework can do SSR or SSG is a very important distinction, critical for infrastructure planning. I often see it being downplayed together with a promotion of various proprietary platforms offering edge computing but this stuff is just not necessary for many cases. Edit: No idea what terminology is used at NextJS, above is what I think is generally understood by SSG (static site) and SSR (server-rendered site).
  - eric-burel 4y ago
    That's not Next wording, what you are describing seems to be an exported app (reintroduced in Next 13.3 via export output, and available in Next 12 via next export) SSG in Next is just pre-rendering some pages server-side at build-time, it's not so involved
- Tehnix 4y ago
  Static i18n is pretty easy to implement though? I’m Next.js I’ve previous solved it by making the chosen language part of the route. Sure, it generates more files, but that doesn’t really matter at all (cheap to host still, cheap to serve still). I could get behind static vs dynamic, but “server-side” has no meaning then to me, since there is no server/backend men at to be involved for the static part then (at least in my mental model of it).

by Tehnix 4y ago

vlovich123 4y ago

I don’t know. I think a good SSR library + some clever front end frameworks + an edge compute platform where you don’t have to worry about anny scaling and you’re done. I’ve seen some really impressive demos of stuff that is extremely dynamic (ie per request), rendered server side on first use for the immediate portion you need with transparent hydration in the background to download interactivity as needed. Sure it seems more complicated ha CDN + S3, but I think in actuality it’ll be simpler in application. It all works super slick and conceptually there’s actually very little complexity for those applying it (the frameworks take care of the difficult bits). Since this is happening at the edge (in Cloudflare’s case, where I work, within something like 50ms of transit time to 95% of the population), and you’re only doing the initial view, you can get websites that load large pieces of content much more quickly than rendering it client side which is dominated by less powerful devices (ie SSR+transfer time is competitive) with less bandwidth/higher latency if you’re collating responses from different backends. You could even see that extending where they prefetch the raw data you’ll need to render the rest of the page in the background and either prepare a rendering, just bring it closer into the cache as a prefetch, or even push it to your browser proactively. Now of course it’s possible this stuff won’t generalize but I don’t see any obvious obstacles. It feels like within 10 years this could be the dominant way client web apps will be written. I get that we originally used to do that but it’s about taking the best of both worlds (SSR let’s you get super high performance initial loads while dynamic client side handling let’s you handle interactivity better and doing it transparently makes your development process a heck of a lot simpler as you don’t really need to differentiate the code as much (whereas I think you would with SSG+SSR). For SSG you probably don’t need to find general pieces of content and set up a different layer vs changing some caching parameters / doing content based hashing transparently. I think that’s maybe the direction OP was heading with in his remark of the distinction not being helpful.

Tehnix 4y ago
Don't get me wrong, I definitely think the current movement and focus on a great UX is amazing! But as someone that cares a lot about scalability and operational complexity + cost, it hurts a little to see certain approaches that'll work great in small scale, but be troublesome at large scale be recommended so strongly :/ > edge compute platform I would consider that quite a big difference in infrastructure. It can easily be done already right now, but the cost and performance equation between serverless compute (at edge or not) v.s. static file serving becomes noticeable at scale. Let's make some pricing examples: - We'll have 2 million "first page loads" per day (~60 million per month) - Let's give our bundle a low estimate of 200KB ------------ Vercel's pricing (just to take a popular example)[0]: - Pro tier: $20/month includes 1m execution units (EU, 50ms of CPU time) and 1TB bandwidth - Then $2 per 1m EU and $40 per 100 GB bandwidth - Let's ignore GB-hours for now (memory x runtime)[1] - Let's assume you're always able to render your SSR page in 50ms or less (quite optimistic if you're doing any form of DB operations in your SSR) AWS CloudFront pricing[2]: - Always free tier: 1TB bandwidth, 10m requests - Then $0.085 per GB bandwidth and $0.0100 per 10k requests - (at scale you can get +50% discount on bandwidth by committing) ------------ We can then run the numbers: - Estimate (200 KB) on Vercel: - (60m requests - 1m free) * $2 per 1m = $118/month - 200 KB * 60 million = 12,000,000,000 kb = 12TB - (12TB - 1TB free) / 0.1 * $40 per 100GB = $4400/month (you'd probably want an Enterprise plan at this point unless I did the math wrong here. Their FAQ suggests to reach out to their sales team which you should definitely be doing at this scale!) - = $118 + $4400 = $4,518/month - Estimate (200 KB) on CloudFront: - (60m requests - 10m free) / 0.01 * $0.01 per 10k request = $50/month - 200 KB * 60 million = 12,000,000,000 kb = 12TB - (12TB - 1TB free) / 0.001 * $0.085 per GB = $935/month (which could be $440/month with reserved capacity) - = $50 + $935 = $985/month ------------ Totally open for having made a calculation error above, but this is the kind of thing that one needs to concern themselves about at scale. The above example is quite realistic, in fact it's a lot less than our usage at my current work. Admittedly here we are seeing most of the cost come from bandwidth. If you substituted Vercel with AWS Lambda you would be able to benefit from the CloudFront pricing on this. [0]: https://vercel.com/pricing https://vercel.com/pricing [1]: https://vercel.com/guides/what-are-gb-hrs-for-serverless-function-execution https://vercel.com/guides/what-are-gb-hrs-for-serverless-fun... [2]: https://aws.amazon.com/cloudfront/pricing/?nc=sn&loc=3 https://aws.amazon.com/cloudfront/pricing/?nc=sn&loc=3

keyle 4y ago

SSG is a static website?

Tehnix 4y ago
Yup (static site generation)! But more complex than a traditional SPA setup. Traditionally an SPA has been just one single bundle file that is downloaded. With SSG you pre-generate a file per path which gives the user many of the benefits of SSR on that first page load, before the SPA part takes over again.
- ZephyrBlu 4y ago
  You are slightly conflating SSG with SPAs. SSG doesn't necessarily mean you have an SPA-like site, it could just be a MPA (I.e. classic website).
  - eric-burel 4y ago
    Many answers are in this thread, I should have made my point clearer: from Perseus doc, it has a limited vision of static rendering, that stems from a slightly incorrect mental model. Statically rendering and not needing a server are different subject, and statically rendering is not limited to generic content. This can be easily proven if you think statically rendering a page as precomputing the render at build-time. I've written multiple time about this subject and Next 13 App Router design choices are consistent with this theory. This makes Next much more powerful that many competitors, as it covers all use cases of static rendering.
- re-thc 4y ago
  You also get disadvantages. SPA due to its history is widely supported. SSG not so much e.g. from a routing perspective. It's good if your platform can support it.
  - satvikpendem 4y ago
    But...SSG is how pages traditionally worked. You have some files in a folder and use <a> to link between them, no dedicated router required. Routers are needed in SSR though, depending on your use case.

eric-burel 4y ago

See, that's the problem: you said SSG can only take you as far as "something generic for everyone". This is not true, otherwise you could not implement static i18n. Also I don't want to squash them either but dynamic vs static is for instance much more appropriate, it's a shortcut for request-time vs build-time server rendering.

throwaway290 4y ago
What is generally meant by SSG is that at runtime you send fully usable static pages and don't need to run any app logic. This radically expands your options for hosting (S3 + CDN, done). You can't have personalization unless you run app servers, you can provide some alternatives at build time (localization, AB tests) but nothing actually personalized. Whereas with SSR you run an app aware server, which means you can store client state and do everything with it sending to the browser final HTML, but it is more costly. So to me and many others whether a framework can do SSR or SSG is a very important distinction, critical for infrastructure planning. I often see it being downplayed together with a promotion of various proprietary platforms offering edge computing but this stuff is just not necessary for many cases. Edit: No idea what terminology is used at NextJS, above is what I think is generally understood by SSG (static site) and SSR (server-rendered site).
- eric-burel 4y ago
  That's not Next wording, what you are describing seems to be an exported app (reintroduced in Next 13.3 via export output, and available in Next 12 via next export) SSG in Next is just pre-rendering some pages server-side at build-time, it's not so involved
Tehnix 4y ago
Static i18n is pretty easy to implement though? I’m Next.js I’ve previous solved it by making the chosen language part of the route. Sure, it generates more files, but that doesn’t really matter at all (cheap to host still, cheap to serve still). I could get behind static vs dynamic, but “server-side” has no meaning then to me, since there is no server/backend men at to be involved for the static part then (at least in my mental model of it).