Static site generators are tools that can be used to build websites by generating static HTML pages from dynamic content such as templates and markdown files. They have become popular in recent years because of their many advantages over traditional dynamic website technologies.

Over the course of two decades, the developers at Mono have been working with a myriad of CMS solutions. We have also been using a lot of different stacks, but regardless of their complexity or flexibility, there was always something lacking. They were either slow, or complex, or too open for attacks, or too expensive to scale and maintain.

Jamstack

Then came Jamstack. “Jam” stands for JavaScript, API and markup. This simple concept has revolutionized the way we think about building web applications by providing better developer experiience, better performance, lower cost and total scalability.

In Jamstack, web sites are served as plain old static HTML files. They are usually generated from source files (usually Markdown), using a Static Site Generator. Dynamic functionality is abstracted into reusable server-side APIs and accessed with JavaScript. To make maintenance even simpler, we usually use serverless functions (AWS Lambda or Azure Functions) instead of traditional server infrastructure. There are no restrictions on which client framework to use.

Static Site Generators

Here are some of the main advantages of working with a static site generator tool:

• Performance: Because static sites are just a collection of HTML, CSS, and JavaScript files, they can be served very quickly. This makes static sites much faster than dynamic sites, which often have to query a database and run server-side code in order to generate each page. Static sites are usually deployed to and served from a Content Delivery Network, instead of a single server or a small server network, making the performance gain even greater.

• Scalability: Static sites can be easily scaled to handle large amounts of traffic. Because there is no server-side code to run, it’s easy to add more servers to handle a spike in traffic without having to worry about scaling the underlying infrastructure.

• Security: Static sites are much more secure than dynamic sites. There is no server-side code to hack, and there is no database to exploit. This makes static sites a good choice for sites that handle sensitive information.

• Low cost: Because static sites can be served from simple hosting platforms like S3, they can be hosted very cheaply. This makes static sites a good choice for small businesses and startups that don’t have a lot of money to spend on hosting.

• Easier workflow: With a static site generator, developers can work on a local environment using version control and testing with the same data and structure that will be used in production. This makes the development, testing and deploying process faster, smoother and more efficient.

All of this doesn’t mean that user experience for site admins has to be degraded when static site generators are used. Content editors are not limited to working with code editors. Static site generators are routinely coupled with various “visual” content management tools and editors.

Choosing a Static Site Generator

A list of static site generators for Jamstack sites is very, very long and it can be difficult to pick the right tool. Some of the most popular choices are Next.js, Hugo and Gatsby, but you might find a different favorite based on your preferences.

For us at Mono, the choice was simple: Hugo, a static site builder known for its speed, flexibility, and ease of use. A typical website of moderate size can be rendered by Hugo in a fraction of a second. They say it takes around 1 millisecond for each piece of content, and we can confirm that. The site you are currently using holds more than a hundred of blog posts, and dozens of “general-purpose” pages with a ton of accompanying resources. It takes below 5 seconds to build it on an average machine, and most of the time is being spent by webpack, not Hugo.

Setting up Hugo

To start using Hugo, the first step is to download and install it on your machine. You can download the latest version of Hugo from the official website and follow the installation instructions for your operating system. Once installed, you can check that it is working by running the command hugo version in your terminal.

Once you have Hugo installed, you can create a new project by running the command hugo new site project-name. This will create a new directory with the name you provided and set up the basic directory structure for your project. Please spend some time familiarizing yourself with this structure - while simple, it allows you to easily create even the most complex navigation structures in your project.

After this first step, you should probably learn about Hugo templates that go into the “layouts” directory and start putting together basic visual elements of your pages. It is important to understand how the template lookup order works. Don’t be intimidated by its apparent complexity – as they say, that’s the flexibility talking :) Most Hugo sites contain just a handful of templates.

While you’re at it, be sure to check the syntax for partial and shortcode templates to make smaller, context-aware components that make your templates and content DRY.

To create a new blog post, you can use the command hugo new post/post-name.md. This will create a new markdown file in the “content/post” directory with the name you provided. You can then edit this file to add your content. You will need to understand Hugo’s content organization and front matter, but that is basically all you need in order to start. Once you have added some of your content, you can start the Hugo server by typing hugo server - by default, it listens at http://localhost:1313/. When you are ready to publish your site, just type hugo and it will be rendered in seconds and stored in the “public” folder.

Where to go next

This was just a short introduction to the Jamstack philosophy and Hugo, one of the most popular static site builders on the market. We just barely scratched the surface; in the following posts we will continue describing how to:

• configure Hugo (languages, taxonomies, URL rewriting, deployment options…),
• integrate webpack and various build options,
• explain how paging works,
• describe the basics of Go templating,
• use page bundles,
• add Netlify CMS to support visual content editing and explain how to use it without Netlify CDN,
• enable dynamic functionality including contact forms and search/indexing functionality based on third party services and Lambda functions,
• build a complete CI/CD pipeline to deploy sites to AWS S3 and CloudFront CDN.

We hope you will enjoy Hugo as much as we do.