The word 'static' often has negative connotations. It can be used to describe something as limited and rigid. A 'static website' is often used to describe a website that is small, simple, and does not do much. Lets take a second look at this, find out what 'static' really means when it comes to the web, and find if those limitations are true.
A static website is actually just a website where the views are pre-rendered. Let's define our terms. First, a view is simply a chunk of HTML. This could refer to an entire webpage, or a section of a page. To render a view means to take some data and plug it into some sort of template in order to generate the HTML. So, to pre-render a view means to combine the data and the template to generate the HTML before. But before what? In this case it means before the user requested the page.
Historically (you know, in the ancient times) this was the only way the web worked. The world wide web was a collection of linked documents. These documents came in the form of HTML, were identifiable by a URI, and contained links to other documents. All of these documents existed long before you the user ever typed in a URL to go to one. They were either created individually by hand or with some sort of static site generator.
Then came the evolution of the web with server side and client side rendering. These have been the default method of building websites for a long time. This is where you wait for a user to request a webpage and instead of a static document being returned, some sort of framework renders the view. This could be done on the server or in the browser. It might hit databases or user profiles in order to get the data to render the view.
Another evolution came with progressive web apps. Browsers gave websites the ability to have their views cached for offline use and to be installed as if they were native apps. Now users can interact with a website as an app, and never know or even care whether it is a native app or a web app. The only difference is where they installed it from. Native apps are installed from an app store and web apps are installed by visiting a website. However, in coming years even this might change, as app stores from Google and Microsoft might automatically make progressive web apps installable directly from the store.
All of this evolution occurred over the years with static site generation being left as a relic of the past, at least in the minds of many. However this need not be the case. There is nothing fundamentally at odds between static site generation and progressive, single page web applications. It might feel like single page applications require heavy and powerful frameworks, but it does not. It might feel like a progressive web app cannot be achieved with statically generated views, but it can.
So what are the benefits of static site generation over the dynamic options of client and server side rendering? Mostly performance, but also security, simplicity, and scalability. In a single page application you need lots of views. This might be things like navigation elements, product entries, profiles, articles, and more.
Instead of each web page being it's own view, the views are split into more fine grained pieces and then combined by the single page application to create full web pages. This is usually done with client side rendering; be it Angular, React, or something similar. However, there is no reason that this cannot be done with the views rendered ahead of time. For example, why wait until the user clicks 'add a product' to render the cart entry view? This can be rendered ahead of time and plugged into the single page application when needed.
This makes the system more performant as you are simple delivering html documents over the network without any server or client side application rendering the view. This also makes it more scalable, since all you have to do is deploy your views to a CDN with no need for some heavy duty web server. In fact, you need no web server at all. Just deploy your views 'to the edge' on a CDN. At the same time this reduces your applications surface area to attack, since there is no web server to hack, just views to retrieve. Of course you might have API integrations which require security, but the point is that you are minimizing the ways in which the system can be exploited to the bare minimum.
All of this means that a static website is quite dynamic, which does not indicate a contradiction in the design but an ambiguity in terms. Maybe 'static site generation' is not the best phrase to describe a dynamic, fully featured web application. How would we market this approach? What should it be called? JAMstack is one answer. However, to be a bit more explicit and verbose, we could call this a progressive, pre-rendered, single page application.
Thanks for staying with me through this tour of web history. I hope it has given you some context and motivation to check out the benefits of pre-rendering your views!
Check out my blog for more of my musings upon technology and various other topics.