Static Site Generation (SSG) refers to the technique used to generate html or content of sites based on data from options like CMS (Content Mangement System) or a database. Frameworks like NuxtJS and Gatsby support SSG.
Server Side Rendering (SSR) refers to the technique used by tools to perform actions like data retrieval from CMS or database but on the server which is then prepared and sent to the user as html. Frameworks like NuxtJS and Remix.run supports SSR.
Frameworks like Remix.run propose more of an SSR approach to loading data on webpages. I do agree with this philosophy in that websites these days are hardly static and require some form of data to be dynamic. With Remix.run, you can load this data server side and at a much faster rate than Next.JS SSR even as discussed in a recent post by Ryan Florence on the tradeoffs of Remix.run as compared to Next.JS.
So if SSR really is the way to go about building web pages in recent times because of the dynamism of websites, why do we still have a lot of teams and developers choosing to go with SSG for projects such as blogs or websites that do load some or even more dynamic data.
The question is not whether you load a bit of data or you load more. Once you load data, why not offload this data loading to the server instead of relying on the client?
I have just one thing to counter this tradeoff we have with dynamic web pages when using Remix.run, cost and management of data. And by cost, yh I mean mostly money.
Consider having a company blog or a personal blog, even ones such as devdojo here, loading data from your database, CMS or whatever storage form you are using can be very expensive depending on the platforms you use.
CMS platforms mostly charge based on API requests and you can imagine if you are using a CMS and your pages are SSR generated. Upon each request to a page that loads data, an api request will have to be sent which counts towards your quota. Now even if you set up a caching mechanism, you also need to worry about the cache configuration and cost.
With frameworks like Next.JS for instance and the support for Incremental Static Regeneration (ISR), you can load some data during the build time of your app and incrementally load more only when needed for instance with the unstable_revalidate feature. This of course helps you cut down the number of requests you need to send to the api, as during the next build you could build enough pages with data from the api that is required and then only send request to retrieve more when needed and not to send api request to get data each time a user visits your page.
I think that the web now is more dynamic but the cost of data is also something to be considered by companies and individuals alike, data that can be generated should not be forced to be server rendered but generated at build time and made available to the user. I am sure your boss will be very pleased if they can reduce cost invested in tools such caching platforms or SQL database read replicas for data retrieval and also the cost of reads to whatever storage platform they are using.
With SSG support in frameworks, I can easily export my html, put it on s3 and have it running my web pages. I can't do this with SSR only frameworks.
I think frameworks like Remix.run still need to rethink supporting only SSR as not all companies or individuals have the capacity to afford data loading at the request time of their web pages. It's fine if you have a free service or are backed by a good financial means and can scale with little concern about data cost. You can afford data loading at request time but if we can also give flexibility to offload some of these data loading tasks to build times, it can go a long way to help reduce some unnecessary data costs.