Questions to ask before choosing a static site generator

Static site generators (SSGs) are like your favorite sitcom. They accept and process data0, sort of like writing the script. Next, the SSG outputs all the assets into an easy-to-view folder, like releasing the show to the network. Airing the show is then like publishing the site — we invite people to view it and hope they give us a few laughs, and then tell someone else about it.

Traditional web applications, on the other hand, are more like Hamilton (your favorite musical, obviously). Web apps wait until a page is requested before generating an on-demand view, while SSGs have already built and distributed their pages. And at home, you can watch and rewatch the sitcom as much as you’d like, and the actors don’t have to do any work, whereas (before July 3, 2020) if you wanted to see Hamilton again, you had to go back to the theater and the actors had to do it all over again for you. In other words, since there isn’t any work for the server to do, SSGs initial responses tend to be extremely fast. They even allow the static files to be distributed via a content delivery network (CDN) all over the world.

Some SSGs have a hybrid approach (like Hamilton on Disney Plus). That means certain pages are generated at build time, but others can be dynamically generated. You can go to the theater for a live performance, or you can watch a taping whenever you’d like. And really, this is the best of both worlds. That’s because it minimizes work required for pages that very rarely change. It also can generate dynamic pages, such as displaying content specific to a certain user.

Most SSGs are not tied to a specific content source; you may need to convert CMS data to structured content such as Markdown, JSON, YAML, etc. Some of the options also help with this via tools like GraphQL which integrates data from multiple sources into one easy-to-use API.

But choosing a SSG can be a daunting task since there are so many to choose from. Below is a list of questions that can be helpful for you to answer when choosing a SSG. These questions should help narrow down the field to a more manageable set so you can more easily see if they fit your needs.

1. What language or framework is it based on?

There are so many different SSGs out there, so chances are there’s one that will integrate with your current language or framework. Working in a framework you’re already familiar with is a great starting place for your SSG.

Conversely, this may also be a good time to try something new out. Why? Well, since SSGs are simpler, they have a lower barrier to entry. Decisions — such as where the data lives, for example — can be made outside of the SSG you’re using. Since you can use the data along with parts of the HTML, CSS and JavasScript, you lower the risk of choosing an SSG built on a language or framework that doesn’t work.

2. What are your requirements?

You’ll want to make sure that the SSG you choose can handle as much as possible. You also want to make sure that the SSG works well with services. Here are a few possible requirements:

• Will you want users to be able to update parts of the site (such as create a list of their favorite posts) or will it be purely content driven from a CMS.
• Do users need to allow users to log in? Is there an existing authentication service you are migrating from can it be used?
• Is the site's dynamic content based on a logged-in user, a location or something else user specific?
• Does it integrate easily with tools you’re using (such as a CMS you already have set up)?

3. How easy is it to extend?

An SSG should make it easy for you to add your design and content. Many SSGs have template languages to help make the process of building your site easier, along with built-in integrations with tools like Sass, PostCSS, Babel and other commonly used projects. You’ll also want to check if the SSG allows you to build custom extensions, plugins or themes, that way you can more easily share code from multiple projects.

4. If you need information or have an issue, where do you get help?

Does the SSG have good easy to use documentation? For open-source projects, is there a good place for community support? Are there online forums where you can learn from other developers such as Discord? The answer isn’t always readily available, so having a place to ask questions is helpful.

5. Are there quality plugins or extensions available for it?

You shouldn’t reinvent the wheel unless you have a specific need. Does the SSG team provide a repository where you can get access to plugins or extensions? This can drastically improve the speed at which you can complete simple tasks. Just be sure not to lean too heavily on plugins, since they can actually be the source of issues.

6. How is your data currently stored?

Are you already using a CMS you like? If so, does it have an API from which you can retrieve data when the site builds? Is your data currently spread out around multiple systems? You may want to check out an SSG that can consume data via GraphQL so you can easily merge it.

7. Is there a cost associated with it?

Most SSGs are open-source and can be hosted on services such as Netlify or Vercel. You could introduce costs based on the services you add if the SSG or hosting provider does not have a solution for it. For instance, if you want to accept form submissions, you may need to use an external form service. In most cases, these costs are fairly low, but depending on the volume of services you choose to add, they can increase over time.

How do you choose the right static site generator for you?

With so many good SSGs to choose from and so many questions, where do you start? Like most answers in development, it depends...

1. Make sure the SSG you choose is easy to use for your team (the whole team — not just developers). At the end of the day, all SSGs have much the same basic output. Sure, some have more optimizations and features, but they’ll all output static files that can easily be served on a CDN via services such as Netlify or Vercel.
   
2. Ensure the SSG solves as many requirements as possible with a good path forward to build custom features for the ones it does not. When paired with ease of use, you have the ability to quickly roll out features for your users as the site grows.

Here at Ample, we’ve primarily used Gatsby.js which has worked well for our team. For you, Gatsby.js may be a good choice and may not. Only you can decide… but if you want some advice, contact us and our team of experts will help you out.