Quick look on Static Website Generators
The aim of this article is to help people of all skill levels understand exactly what static site generators are, acknowledge their advantages, and understand if their limitations are a deal-breaker or if, on the contrary, they can be overcome. With that, you’ll hopefully be able to make an informed decision on whether or not a static site can be the solution for your next project.
- It needed to be using a technology I am very familiar with so that I can extend and customize as needed. I knew that this meant that it would probably not be one of the popular generators as many of them are Ruby-based (and Ruby isn’t my area of expertise).
- It needed to be open source so that I could contribute to the core project.
- It needed to provide a workflow that could be easily automated and potentially tie in well with tools for this like Grunt JS.
- It needed to be command line driven. I wasn’t interested in using an all-in-one GUI approach as I felt that could limit customization.
How dynamic sites work
Try to imagine for a second that the only way for people to know what’s happening in the world is to go to the nearby news kiosk and ask to read the latest news. Yes, I know it’s silly but it will all make sense in a bit, please bear with me.
The attendant has no way to know what the latest news are, so he passes the request on to a back room full of telephone operators — picture a big telephone switchboard room in the 1950s. When an operator becomes available, they will take the request and phone a long list of news agencies, ask for the latest news and then write the results as bullet points on a piece of paper.
The operator will then pass his rough notes on to a scribbler who will write the final copy to a nice sheet of paper, arrange them in a certain layout and add a few bits and pieces such as the kiosk branding and contact information. Finally, the attendant takes the finished paper and serves it to the happy customer. The entire process will then be repeated for every person that arrives at the kiosk.
That is essentially how a dynamic website works. When a visitor gets to a website (the kiosk) expecting the latest content (the news), a server-side script (the operators) will query one or multiple databases (news agencies) to get the content, pass the results to a templating engine (the scribble) who will format and arrange everything properly and generate an HTML file (the finished newspaper) for the user to consume.
How static sites work
The proposition of a static site is to shift the heavy load from the moment visitors request the content to the moment content actually changes. Going back to our news kiosk metaphor, think of a scenario where it’s the news agencies who call the kiosk whenever something newsworthy happens.
The kiosk operators and scribbles will then compile, format and style the stories and produce a finished newspaper right away, even though nobody ordered one yet. They will print out a huge number of copies (infinite, actually) and pile them up by the store front.
When customers arrive, there’s no need to wait for an operator to become available, place the phone call, pass the results to the scribble and wait for the final product. The newspaper is already there, waiting in a pile, so the customer can be served instantly.
And that is how static site generators work. They take the content, typically stored in flat files rather than databases, apply it against layouts or templates and generate a structure of purely static HTML files that are ready to be delivered to the users.
Advantages of static
Perhaps the most immediately noticeable characteristic of a static site is how fast it is. As mentioned above, there are no database queries to run, no templating and no processing whatsoever on every request.
Web servers are really good at delivering static pages quickly, and the entire site consists of static HTML files that are sitting on the server, waiting to be served, so a request is served back to the user pretty much instantly.
2) Version control for content
You can’t even imagine working on a project without version control anymore, can you? Having a repository where people can collaboratively work on files, control exactly who does what and rollback changes when something goes wrong is essential in any software project, no matter how small.
But what about the content? That’s the keystone of any site and yet it usually sits in a database somewhere else, completely separated from the codebase and its version control system. In a static site, the content is typically stored in flat files and treated as any other component of the codebase. In a blog, for example, that means being able to have the actual posts stored in a GitHub repository and allowing your readers to file an issue when something is wrong or to add a correction with a pull request — how cool is that?
Platforms like WordPress are used by millions of people around the world, meaning they’re common targets for hackers and malicious attacks — no way around it. Wherever there’s user input/authentication or multiple processes running code on every request, there’s a potential security hole to exploit. To be on top of the situation, site administrators need to keep patching their systems with security updates, constantly playing cat and mouse with attackers, a routine that may be overlooked by less experienced users.
Static sites keep it simple, since there’s not much to mess up when there’s only a web server serving plain HTML pages.
4) Less hassle with the server
Installing and maintaining the infrastructure required to run a dynamic site can be quite challenging, especially when multiple servers are involved or when something needs to be migrated. There’s packages, libraries, modules and frameworks with different versions and dependencies, there’s different web servers and database engines in different operating systems.
Sure, a static site generator is a software package with its dependencies as well, but that’s only relevant at build time, when the site is generated. Ultimately, the end result is a collection of HTML files that can be served anywhere, scaled and migrated as needed regardless of the server-side technologies. As for the site generation process, that can be done from an environment that you control locally and not necessarily on the web server that will run the site — heck, you can build an entire site on your laptop and push the result to the web when it’s done.
5) Traffic surges
Unexpected traffic peaks on a website can be a problem, especially when it relies intensively on database calls or heavy processing. Introducing caching layers such as Varnish or Memcached surely helps, but that ends up introducing more possible points of failure in the system.
A static site is generally better prepared for those situations, as serving static HTML pages consumes a very small amount of server resources.
Disadvantages of static (and potential solutions)
1) No real-time content
With a static site you lose the ability to have real-time data, such as indication about which stories have been trending for the past hour, or content that dynamically changes for each visitor, like a “recommended articles for you” kind of thing. Static is static and will be the same for everyone.
There’s not really a solution for this, I’m afraid. It’s the ultimate price to pay for using a static site, so it’s important that you ask yourself the question “how real-time does my site need to be?” — if its concept is based around delivering real-time information then perhaps a static site isn’t the right choice.
2) No user input
Adding user generated content to a static site is a bit of a challenge. Take a commenting system for a blog, for example — how do you process user comments and append them to a post using just plain HTML pages? You don’t.