7 ms·

To be clear, there is a difference between SSR and SSG. SSG is something like PHP, which generates the full page HTML in the backend. I think HN is SSG? Many ne

To be clear, there is a difference between SSR and SSG. SSG is something like PHP, which generates the full page HTML in the backend. I think HN is SSG? Many news websites or wordpress blogs also fall in this category...

Phrodo_00 3y ago
If you're talking about static sites, wordpress definitely isn't it, it renders server side every request. (Google's Blogger.com used to be static, not sure about now). HN is likely not static either.
traverseda 3y ago
I've never heard the term SSG before. Apparently stands for "static site generating" and is a `next.js` thing. No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cache instead of generating a page for you. A cache is not a static site, although maybe next.js is redefining the term, I don't know. Get off my lawn.
- michaelmior 3y ago
  SSG long predates Next.js. It was by no means the first, but I wrote something that I think could be called a SSG (not the term I used at the time) back in 2010 while the first release of Next.js wasn't until 2016. [0] https://michael.mior.ca/blog/designing-an-offline-cms/ https://michael.mior.ca/blog/designing-an-offline-cms/
  - traverseda 3y ago
    Sure, static html sites have existed forever, but I don't know when the term "SSG" was popularized. I assume it was pretty recently all things considered.
- la_fayette 3y ago
  Ok, it seems I mixed up the acronyms, I thought SSG stands for server-side generated. What I actually mean is, that there is a difference between SSR with react, which requires some kind of rehydration on the client, in contrast to a website generated by, e.g., PHP on the server, which doesn't require this. The PHP website doesn't require the client to rehydrate and produces less load on the client. With the disadvantage, that a subsequent page view requires again a full load, while the SSR loaded react page, doesn't require that. I didn't check the HN code yet, but it feels like a server- side generated website and not a SSR delivered react (or similar js framework) website...
  - traverseda 3y ago
    Server side rendering has meant basically just generating HTML and serving it for a long time.
michaelmior 3y ago
I assume by SSG you mean static site generation? If so, that's something different entirely. At least in the ways I have commonly seen it used, SSG refers to generation of HTML offline so that all the content hosted is static. For example, in a blog you would generate one HTML page for each blog post. If you were running a blog using some PHP service (such as WordPress), then even those static HTML is what's sent to the browser, the pages themselves are generated on the fly.
deleted 3y ago
[deleted]
KronisLV 3y ago
> To be clear, there is a difference between SSR and SSG. Here's a simple way to think about it. SSG: there will be a process that generates/bundles HTML/CSS/JS ahead of time with all of the content that the site will have, like the many static site generators out there. You should then be able to take the output of the SSG process and host it on a dumb web server, like Apache/Nginx. For example, that's what I do with my HN Personal Blogs site, a set of Python scripts generate HTML output a few times per day, which is then served on an Apache container: https://hn-blogs.kronis.dev/ https://hn-blogs.kronis.dev/ SSR: there will be a runtime of some sort that will execute any number of scripts on the server, to dynamically generate a response for the user's request. This is what many PHP and Ruby sites are, if they don't opt to just use those languages for an API. You click on a button in the site, your request is submitted, the language runs some logic on the server and sends you a response, typically there's a DB as well, that most users interact with. However, you can also mix those approaches. For example, you could make it so that the front page of your site is pre-rendered or at least cached, so that your servers need to do less processing and your DB would be under less load. That's also what some flat file CMSes like Grav do - so that the articles will load pretty quickly, though those approaches introduce some complexity and the risk of stale data in some cases. There's also stuff like hydration and many more recent concepts, but that'd get more lengthy.

Phrodo_00 3y ago

If you're talking about static sites, wordpress definitely isn't it, it renders server side every request. (Google's Blogger.com used to be static, not sure about now). HN is likely not static either.

traverseda 3y ago

I've never heard the term SSG before. Apparently stands for "static site generating" and is a `next.js` thing. No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cache instead of generating a page for you. A cache is not a static site, although maybe next.js is redefining the term, I don't know. Get off my lawn.

michaelmior 3y ago
SSG long predates Next.js. It was by no means the first, but I wrote something that I think could be called a SSG (not the term I used at the time) back in 2010 while the first release of Next.js wasn't until 2016. [0] https://michael.mior.ca/blog/designing-an-offline-cms/ https://michael.mior.ca/blog/designing-an-offline-cms/
- traverseda 3y ago
  Sure, static html sites have existed forever, but I don't know when the term "SSG" was popularized. I assume it was pretty recently all things considered.
la_fayette 3y ago
Ok, it seems I mixed up the acronyms, I thought SSG stands for server-side generated. What I actually mean is, that there is a difference between SSR with react, which requires some kind of rehydration on the client, in contrast to a website generated by, e.g., PHP on the server, which doesn't require this. The PHP website doesn't require the client to rehydrate and produces less load on the client. With the disadvantage, that a subsequent page view requires again a full load, while the SSR loaded react page, doesn't require that. I didn't check the HN code yet, but it feels like a server- side generated website and not a SSR delivered react (or similar js framework) website...
- traverseda 3y ago
  Server side rendering has meant basically just generating HTML and serving it for a long time.

michaelmior 3y ago

I assume by SSG you mean static site generation? If so, that's something different entirely. At least in the ways I have commonly seen it used, SSG refers to generation of HTML offline so that all the content hosted is static. For example, in a blog you would generate one HTML page for each blog post. If you were running a blog using some PHP service (such as WordPress), then even those static HTML is what's sent to the browser, the pages themselves are generated on the fly.

deleted 3y ago

[deleted]

KronisLV 3y ago

> To be clear, there is a difference between SSR and SSG. Here's a simple way to think about it. SSG: there will be a process that generates/bundles HTML/CSS/JS ahead of time with all of the content that the site will have, like the many static site generators out there. You should then be able to take the output of the SSG process and host it on a dumb web server, like Apache/Nginx. For example, that's what I do with my HN Personal Blogs site, a set of Python scripts generate HTML output a few times per day, which is then served on an Apache container: https://hn-blogs.kronis.dev/ https://hn-blogs.kronis.dev/ SSR: there will be a runtime of some sort that will execute any number of scripts on the server, to dynamically generate a response for the user's request. This is what many PHP and Ruby sites are, if they don't opt to just use those languages for an API. You click on a button in the site, your request is submitted, the language runs some logic on the server and sends you a response, typically there's a DB as well, that most users interact with. However, you can also mix those approaches. For example, you could make it so that the front page of your site is pre-rendered or at least cached, so that your servers need to do less processing and your DB would be under less load. That's also what some flat file CMSes like Grav do - so that the articles will load pretty quickly, though those approaches introduce some complexity and the risk of stale data in some cases. There's also stuff like hydration and many more recent concepts, but that'd get more lengthy.