> 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/

> 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.