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.

A walk through history

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.

Dynamic rendering

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.

This system is powerful because it is dynamic. Views are only rendered after the user has requested it. Ruby on Rails, Spring, React, Angular, and most of the other web frameworks use this approach. In the history of the web this dynamic system evolved with the concept of single page applications. This meant that as users navigate through the different views of your application, instead of going to new pages for each view, the view was updated 'right from under their feet'. This means that JavaScript DOM APIs are used to update the HTML without navigating to a new URL. This lead to dynamic and interactive experiences. Instead of waiting on page reloads after every click, the website now felt like using a native app.

Progressive web apps

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.

A simple reintroduction

If we are to continue our walk through the history of the web, I would add JAMstack as the next destination in our journey. It is really no evolution at all, but rather the attempt to brush the dust off the so called 'relic' which is static site generation, and let the old timer meet the fresh faces of single page applications and progressive web apps. The idea is a simple one; simply render your markup ahead of time and enhance this with JavaScript that connects to APIs. This is nothing crazy or new. It is just reintroducing some long standing methods of building web sites with some other newer concepts.

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.

Selling the concept

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.

Finally, I would like to leave you with a small treat. Check out samplejam.alexlockhart.me to see a small example of this in action. The pre-rendered views are built with OrisonJS and deployed to a CDN with Netlify. A small amount of JavaScript provides the single page application and progressive web app features. Additionally, a sample API integration is shown by adding products to your cart. All of this is done without any HTML being rendered at runtime.

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.