Websites can serve content in two basic ways: statically and dynamically. Static content is generated ahead of time, stored, and retrieved as-is. Think images, stylesheets, and HTML pages that rarely change. Dynamic content is generated on-the-fly for the sake of a personalized response. Examples here include search queries, dashboards, and product recommendations tailored for the individual user.
With any website, there’s a mix of static and dynamic presentation, but lately there has been a surge of interest in minimal toolsets that generate sites that consist almost entirely of static content.
None of this is wholly new. Static site generation and its tools, like content management systems, have been around for decades. But the latest generation of these tools pare static content generation down to the essentials, making it possible to build and maintain static websites without having to depend on a bulky content management system. They also take advantage of modern software construction techniques by offering plugin architectures and other extensibilities.
Static website design
Most websites are a mix of static and dynamic content. A dynamically generated search request, for instance, may appear side by side with static sidebars, headers, and footers. For the sake of this discussion, though, we’re going to focus on websites that are “static first”—i.e., websites with no on-demand generation of content based on client requests. Such static websites tend to be built along the following lines:
- Content is served as static HTML, CSS, and image files.
- Static content is stored as-is on disk, typically with some level of in-memory caching, or placed in a CDN (content delivery network) and geocached.
- Pages are rebuilt from the back end whenever they are changed, and may be generated on different infrastructure from where they are hosted. The most crucial principle is that content is almost never generated on demand by visitor activity.
Not every website is conducive to static content generation, but for those that are, the benefits can be great. Because static content can be served on different infrastructure from where it was generated, it is easy to address the needs for scale, security, and separation of concerns. Static content is easy to serve at massive scale, because it is easily scaled out by way of caching or CDNs.
How a static site generator works
A static site generator does three basic things to create a website:
- Reads content, often in some simplified markup format, from files. Those files may be laid out in a directory structure that matches the output, or that structure may be created from a description file.
- Renders that content to HTML, according to templates.
- Saves the results in a new directory, laid out either to match the layout of the source files or according to some pre-defined pattern.
The most basic static site generators follow this pattern. More advanced generators may add other functions:
- Automatically push the resulting HTML to a website or CDN, if the content is hosted on different infrastructure than where it was rendered.
- Watch source files for any changes, and re-render the files whenever they are altered.
- Rebuild the entire source file tree intelligently, so that only the files that have to be rebuilt are rebuilt as a labor-saving measure.
Static site generator vs. CMS
Even the most advanced static site generators have deliberately constrained feature sets. This is part of the philosophy of the use case—they’re meant to serve as simpler alternatives to full-blown content management systems.
Most content management systems use a web front end, require a database to store content and manage user permissions, and need a fair amount of setup and maintenance to be useful. Static site generators take the opposite stance in most every respect. They run as command-line applications, rely on the operating system for file management and user permissions, work without a database (requiring only a configuration file at most), and don’t need a lot of admin work to get going.
Static site generators strive to make the creation and management of web content as overhead-free as possible. For instance, with a CMS, content is often edited and managed via the system’s own web interface. With static site tools, content is edited directly on disk using whichever text editor the user prefers.
In short, the biggest difference between a full CMS and a static site generator is the philosophy of the tool. A content management system is typically feature-rich by design. A static site generator zeroes in on rendering content as HTML, and typically leaves out everything else.
Top static site generators
If you want to get started with static website generation, you will find many good tools to choose from. Below I’ve listed eight of the better-known tools. Some static site generators are standalone tools (like Hugo here), but most require a language runtime. You will likely want to start experimenting with a tool written in a language you’re already familiar with or that you have good institutional support for.
Gatsby
Gatsby uses the JavaScript React framework to build static sites. It can build from more than just existing static files—it can also connect to databases, including existing content management systems like WordPress. This makes Gatsby a useful option if you’re migrating away from an existing blog engine. Gatsby also deploys directly to hosting platforms including CDNs.
Hugo
Hugo, written in Go, runs cross-platform as a native binary and so is a good choice for website developers who don’t want to deal with configuring a language runtime. Hugo provides many useful organization features out of the box, such as generating tables of contents or site menus, redirects and clean permalink URLs, and integrated support for common third-party website tools like Disqus comments and Google Analytics.
Jekyll
Jekyll, written in Ruby, provides a basic static-site generating workflow. In the words of its creators, it “gets out of your way and allows you to concentrate on what truly matters: your content.” Jekyll does provide many useful features within that minimal scope, though, like the ability to automatically generate links to next and previous pages on a blog. See also Octopress, a framework for preconfigured Jekyll site generation.
Lektor
Lektor, written in Python, is file-based like many other static generators, but it also provides a friendly admin interface, along with some tools that other static generators generally don’t include (e.g., image management).
Nikola
Nikola, also written in Python, offers advanced functions like intelligent rebuilding of changes, importers from many common blog engines, and a plugin architecture to extend the functionality as widely as needed.
Pelican
Pelican, written in Python, is one of the best-known and most widely used static website systems in that language. Pelican allows different kinds of page types (e.g., blog posts vs. standalone website pages), provides multilingual support, and caches common page elements for fast rebuilds.
React Static
Like Gatsby above, React Static uses React to render static pages. Unlike Gatsby, React Static keeps data queries and templates separate for more distinct separation of concerns, and doesn’t depend on GraphQL as an internal data query format.
VuePress
VuePress uses JavaScript’s Vue framework. VuePress emphasizes minimal functionality, expandable via a plugin system, and comes with a default template that is designed for technical documents. If you use JavaScript as your main language and you are more familiar with Vue than React, VuePress would be a good place to start.