DEV Community

Cover image for What is your favorite Static Site Generator and why?
Markus Hunsalz for IONOS

Posted on • Updated on

What is your favorite Static Site Generator and why?

Post in the comments what is your favorite Static Site Generator and why?

Over the last years it looked like the JAMStack is becoming more and more popular. Almost a rebirth of classic websites with modern toolings. I observed a lot of SSG projects were started. Some projects stand out of the crowd. Which one do you seriously consider in your daily work and what is your motivation to use Static Site Generators at all?

Discussion (15)

Collapse
johncclayton profile image
John Clayton

I recently had a look at a few and settled on Hugo. Gatsby was way too much like actually having to write code, and I want to seriously focus on the writing/content aspect more than the code. Jekyll was nice too - and of course it's attractive if you want to run via GitHub pages.

I didn't take a deeper look at many others - a one hour video tutorial on Hugo was enough to get started and now I have a site hosted on Netlify with push-to-publish interaction via GitHub - what more could I ask for :-)

I would say it also depends strongly on what you are trying to present / create.

Good luck!

Collapse
hunsalz profile image
Markus Hunsalz Author

Thx @johncclayton for your feedback.

For sure Gatsby, Jekyll and Hugo are parts of this outstanding crowd of projects. In addition hosting providers with a "push-to-publish" ease the interaction considerably.

Actually it’s an obvious truth that it depends on what web project you are working. But I’m still curious if JAMStack / SSGs is hype or trend or already mainstream?

Collapse
natescode profile image
Nathan Hedglin • Edited on

Hugo is amazing. At work we have a full production site we've built based on Hugo. Hugo rebuilds fast enough to have a live preview in the custom CMS we made.

Collapse
hunsalz profile image
Markus Hunsalz Author

Hey @natescode, your project sounds interesting. Is your project public? Would be interesting to get an idea how large one single build is? As far as I know, Hugo isn't capable to provide incremental builds. As a result you have to build everything even for a live preview you mentioned.

Thread Thread
natescode profile image
Nathan Hedglin

No, the code is private as my company built it for a client. The live site is bek.coop .

Hugo doesn't do incremental builds yet. They've done some caching for watch mode though. Which is what we use for the CMS preview.

I don't believe the site has a ton of pages or partials (I'd have to look).

Hope that helps.

Thread Thread
hunsalz profile image
Markus Hunsalz Author

Thx. At least your statement is a reference point to me.

I'm still curious to hear about other samples. Especially about samples of professional sites with a lot of content pages and dynamic issues.

Collapse
johnbokma profile image
John Bokma

Like a lot of people I use my own SSG called tumblelog. It's available as both a Perl and a Python version. Each version consists of a single program file that generates the static blog from a single input file consisting of articles in Markdown format. I use it to run my blog called Plurrrr.

Collapse
lukeshiru profile image
Luke Shiru

Astro is the best static site generator I know. It lets you use pretty much every popular framework and lib out there, without loading any JS unless you actually want to.

Collapse
hunsalz profile image
Markus Hunsalz Author

Astro looks very promising. I wasn't really aware of this SSG already.

@lukeshiru thx for this hint

Collapse
peerreynders profile image
peerreynders • Edited on

Astro's selling point is partial hydration (Why Efficient Hydration in JavaScript Frameworks is so Challenging).

Currently it's being developed as an SSG but the long term goal is SSR. Hence: "Today, Astro only supports Static Site Generation (SSG)."

(Fred K. Schott does occasionally mention this during his various appearances).

So imagine a version of Next.js that can work with React, Preact, Vue, Svelte or Solid components (the page itself being an Astro component) that ships only the JavaScript needed for the interactive islands on the page where the loading can be delayed until the event loop is idle, the component becomes visible or a media query is matched - at least that seems to be the long term goal.

Astro component's component script support TypeScript (VS Code extension for .astro files).

There is an example where islands share state via nanostores.

Thread Thread
hunsalz profile image
Markus Hunsalz Author

@peerreynders - Thx for your elaborate response. You make me even more curious to spend a little more time with Astro.

Collapse
webbureaucrat profile image
webbureaucrat

Eleventy. It's so rare to find a framework that is so flexible without requiring any configuration up front.

Collapse
hunsalz profile image
Markus Hunsalz Author

Thx @webbureaucrat for mentioning 11ty. I tried myself in the past. But I have to be honest 11ty didn't catch me. It's been too long ago that I could state the actual reasons. - Do you have 3 main reasons to win me back for 11ty?

Collapse
webbureaucrat profile image
webbureaucrat

Oooo fun challenge

Simplicity

A lot of static site generators come with way too much out of the box, which makes for a steeper learning curve without much benefit. I tried Hexo, for example, but the whole "themes" thing just didn't make sense to me ("Can't I just write some CSS?") Or elm-pages, which, as far as I understand, compiles to static pages with javascript rather than separating those concerns. I can't wrap my head around it. Or the many static site generators which are built around React, specifically.

Pluggability

I love that the configuration is itself a script file because it means you can just import an NPM package and start using it. It makes it easy to switch templating engines or markdown compiler or even write your own ad hoc extensions.

For example, I wanted the ability to sort my blog tags by number of articles under them so that I could highlight the topics I write about most frequently. It's basically one line in the .eleventy.js file:

    /* takes the collections object and returns a list of tags sorted by 
     * how many articles it has. */
    eleventyConfig.addFilter("byImportance", collections => {
        return collections.tagList
            .sort((tag1, tag2) =>
                  collections[tag2].length - collections[tag1].length
                 );
    });
Enter fullscreen mode Exit fullscreen mode

That's the kind of thing where, if it were any harder to do, I probably wouldn't have bothered.

Development Status

Eleventy is in a stage of project maturity that I think is the absolute sweet spot for adoption. It's young enough that it's iterating rapidly and isn't weighed down by any legacy burdens, but it also just went 1.0 and got sponsorship from Netlify and has a broad enough user base where you can ask questions and get answers.

This also means that if you looked at it before, it's not super surprising to me that it didn't impress you. It's matured a lot in just the past few months.

Feel free to have a look at my blog's source or fork it if you want, though I recommend deleting the scripts/ folder and full-build.sh, which are my front-end scripts and the script that compiles them, respectively. (I'm doing some really cursed things in a language called ReScript in there that I would definitely not do again.)

Thread Thread
hunsalz profile image
Markus Hunsalz Author

Wow, really an impressing answer!

Actually, I can understand why you favor 11ty over other SSGs now. - Simplicity can be a strength and combined with the easy expandability it's a sharp sword to solve problems. Next to that the maturity level speaks for itself.

Next time, I definitely will look at Eleventy with other eyes!