Daniel D. Beck

Think habitat, not ecosystem, when you choose a static site generator

If you get a few technical writers in a room together, it’s only a matter of when, not if, the conversation turns into a static site generator competition. Hugo? Gatsby? Jekyll? What’s good? What’s bad? Why? Who can even say?

It’s genuinely hard to evaluate static site generators, especially with so many good and reasonable options. There are a lot of tools out there doing fundamentally the same thing and there are lots of considerations. Nobody wants to answer the question “What static site generator should I use?” with a coin toss.

One bit of received wisdom tries to cut the Gordian Knot with an appeal to each static site generators’ ecosystem. Consider the ecosystem, they say, and you’ll make a better choice. Wouldn’t it be nice if there was a big, nearly overriding consideration? The ecosystem wants to be the answer, but it’s flawed.

What’s in an ecosystem anyway?

There’s no universally agreed upon definition of a software ecosystem, but it usually encompases things like a tool’s development team, the community of users, the availability of complementary assets or tools, and the pool of potential employees or consultants who are already part of the ecosystem.

In the context of choosing a static site generator, considering the ecosystem usually means answering questions such as:

In the ecosystem metaphor, we want to know about the health of the ecosystem. Is this tool at the heart of a lush landscape full of life and activity? Or is it a relict that persists by the effort of a small set of enthusiasts?

Admittedly, the answers to these questions are interesting and some of the answers may be disqualifying for this or that tool. A generator that’s unsupported is probably not a good choice for a new project. But the ecosystem question often falls short as a deciding factor.

Healthy ecosystem ≠ healthy individuals

Even if you can judge the health of an ecosystem, knowing the health of a population doesn’t say anything in particular about the health of any given member of the population, namely you. Just because an ecosystem is thriving, it doesn’t mean that you can thrive in it.

For example, suppose you’re considering using Gatsby to build your next static site. Even a cursory look shows that Gatbsy has a thriving ecosystem:

Everything about Gatsby says that it’s at the center of a healthy ecosystem. But it could still be a terrible choice for you or your team.

When something goes wrong and you need help—and it will happen sooner or later—who are you going to turn to first? It’s probably going to be the people you already work with on a daily basis. For example, if the engineers you work with are all seasoned backend Ruby developers, they might not be well-equipped to debug your frontend JavaScript code. If you find yourself isolated in your immediate surroundings, the health of the ecosystem may not do you any good.

Habitats are specific

Instead of laboring over competing ecosystems, start by looking at your own habitat. When selecting a static site generator, it’s far better to focus on the teams and tools that you already work with. Once you know where you are, it’s easier to look outward.

Instead of asking questions about a tool’s ecosystem, ask some questions about your immediate surroundings. Take stock of the resources and expertise already available to you. You might ask yourself:

When you know about the strengths of your close environment, you can compare them with the needs of your candidate tool. Adopting a new tool always means learning its strengths, quirks, and weaknesses, but with a careful look at what you’re already capable of, you can protect yourself from having to learn everything from scratch. By starting with your place in the world, you begin the process of learning how you’ll fit into an ecosystem, not just that one exists.