We've written before about our adventures into assembling our own Static Site Generator tech stack, named Besugo after the Portuguese red seabream. This time we thought we should step even further back, and discuss why we started working on it in the first place.

For nearly two decades, monolithic systems have reigned in the public domain. Powerful PHP platforms, fetching and updating a SQL database multiple times and building the results on the fly with every request, backing everything from simple institutional sites without much interaction, to all kinds of editorial software and online stores.

We ourselves started in the Drupal world, taking advantage of, and contributing to, one of the most versatile Content Management Systems (CMS) out there. And who hasn't heard of WordPress by now?

This was made possible because of the great strides we have seen in hardware development. More powerful machines mean more computational cycles per second. We let our imagination run free with these systems without fearing an immense drop in performance.

Waste!

But we hardly need a full-fledged CMS in every project we work on. Just because Drupal or WordPress can be used, doesn't mean it should.

And if something shouldn't be used, we definitely don't want to waste effort in maintaining it (and money hosting it!). So what else is there?

Back to the Future

For many projects, the obvious solution is static sites, those very same things that existed before all CMSs (GeoCities anyone?).

Great Scott!!Great Scott! It's the future!!

There's no processing done by the server, no complex database calls, no page rendering... A user's browser asks for a page, the server sends it back, that's it. If we want the fastest server response time, there's nothing faster than the server not doing anything. The performance bottleneck then falls on how long that response takes to reach the user.

Then it seems fate that static sites are the ones that can most benefit from an extensive Content Delivery Network (CDN). In simple terms, it means that your site isn't hosted in a single server, but spread over many physical locations across the world. It's not so easy to do this with a full-fledged CMS, but with static assets the user can simply receive them from whatever server is closest and the least busy (have we mentioned we love Netlify recently?).

And because there's no actual server processing, the attack surface on your site is greatly reduced. If security is a concern, as it should be, a static site is as secure as we'll ever get.

Where does the content come from?
We always look for the ability to change the content of a page without having to dive into the code, so we make use of Static Site Generators (SSG). In fact, they become practically mandatory when you scale up the content of your site to beyond two or three simple pages.

An SSG grabs the content of a site, typically in a series of parameters like title, body, lists, image arrays, etc., and renders the full website tree at build time, based on the given set of templates for the different page types. Actually, that's exactly how we build this very same blog you're reading now!

Because SSGs are plenty, we have the freedom to choose the technology that best suits the project. If we want to write HTML directly, and take advantage of some specific features of Go templating, we can use Hugo, a blazing fast SSG written in Go; if we'd rather start from a Javascript/React framework, there's GatsbyJS with a continuously increasing library of ready-to-use plugins to give it a boost; this blog you're reading takes advantage of Harp with Jade templating, yet another SSG tech stack with proven benefits.

All of these can fetch the content from different sources, such as from markdown files committed with the code, managed services like Contentful or Forestry, or even a custom solution from a CMS we can host ourselves.

But a static site is... well, static, right?

Of course not. Even if we're building with HTML directly, we can throw in our own Javascript layer and with that we can do whatever we want. That's what JAMstack is all about, we work with an API mentality from the start, and our static pages can show up-to-date information on statistics, or submit data to a service and show the results as soon as they're ready.

With a full CMS like Drupal or WordPress, we might be using modules for allowing users to comment on pages, for showing interactive maps, or for processing form submissions. We can have all of that and much more in a static site; we can simply use managed services for such things without worrying about their maintenance (many can be free although depending on the usage they can incur on some extra costs), or we can build our own functionality, whether fully custom or based on existing libraries, and integrate it as well. A site is only static if you keep it static.

Besugo slideSomething I put together for my presentation about Besugo at JAMstack OPO last year, demonstrating some of its build dynamics. Great Scott, I suck at diagrams...

We can do all this during the build process even, automating new builds on certain hooks from certain systems to turn a static site into a living organism. Just the benefits of a continuously integrated automated build process merit a blogpost of their own.

SSGs make us happy

A static site gives us speed, security, and freedom from infrastructure concerns. Just the hosting for most static sites may even incur no costs at all.

A Static Site Generator lets us build on the concept of simple static pages, taking full advantage of their benefits, and expand outwards to include functionalities we would never consider before, in particular, manage its content in an intuitive fashion completely separate from implementation.

SSGs can't do everything though (yet!), we still rely on a lot of other strategies for a lot of projects with different goals. But the benefits of SSGs are plenty, and they're becoming more powerful every day. For every new project we ask ourselves "can this be done with a static site?", we smile when the answer is yes!

This blogpost was originally posted at Marzee Labs blog.