Static site generators to watch in 2021 | Hacker News Reader

Static site generators to watch in 2021

netlify.com

84 pointsx14km2d82 comments

“Written in GO and readily installable as a binary, Hugo is tremendously portable…”

I am but a humble designer, who only knows enough to write some simple prototypes, and wants some organizational helps. Partials. Concatenating stylesheets. Little things that I used to use CodeKit for.

And I like Hugo because of that “it’s just a binary” bit. There’s no dependency hell. No leaning tower of JS or Ruby. You install it, it sits there, nothing can really break. That’s what I want.

Is that a niche criteria? Obviously. But I do appreciate it. (And if someone has a better suggestion for a very simple static site generator, bring it on.)

Hugo can be that simple if you don't have a complex frontend template. As soon as you want to make a SPA (or SPA-like experience), use a framework like React/Vue/Svelte/etc., or even try out stuff like TailwindCSS you're going to get sucked into the deep rabbit hole of bundling frontend assets, webpack/esbuild/etc.

So you kind of have to decide, are just static templates and static assets all you need? Stick with Hugo and enjoy the speed, simplicity, etc. There are some even simpler alternatives you might enjoy too, like mdbook or mkdocs. Both are more oriented towards technical docs but are similar to hugo at their core--send in some markdown (in the case of these tools you don't even need frontmatter or other schema) and get out some HTML.

If you're building something fancier or using more complex frontend setups then... there's no perfect answer right now. It's all about balancing complexity of the build system with what it gives you in the output. IMHO webpack and gnarly dependencies can be tamed pretty well with a simple docker container. Spend some time getting your perfect workflow setup, chuck it in a container that a CI system can run all day, every day without fail, and you'll be pretty well setup.

I use Hugo with a modern front end, and it’s extremely easy to get setup, especially now that it has built in ESBuild support.

Can you share more about this? I like Hugo for its speed and simplicity, but I find it hard to create elements within components the way I can in Vue. I haven't found any good resources for combining Hugo with frontend frameworks, so I'm curious what you do.

I've switched away from Vue to using Alpine.js, which makes it easier to combine backend templates with frontend ones, but here's the repo back when I was using Vue: https://github.com/spotlightpa/poor-richard/tree/eb816cac807...

src/entrypoints/donate.js defined a custom element, which was included on layouts/donate-page/single.html and layouts/partials/get-src.html conditionally included the Vue component either with Parcel's dev server in testing or precompiled files in production.

It's not very different from what you'd do in any not-JS web framework.

Cool, thank you!

So you kind of have to decide, are just static templates and static assets all you need?

In my particular instance: yup. I’m at the “loop through an array of things in a folder” level, not “deploy at scale” level.

I would think that if you wanted a SPA-like experience, you wouldn't be choosing a static site generator, no?

Everything is kind of converging. In the SPA world they realized the SEO sucks and they need static server rendered content, so there's a whole realm of SSR (server side rendering) built around it with Next.js, Vuepress, Sveltekit, etc. And on the static site side folks realized static sites can kinda suck and feel clunky, so loading some JS to add smoothness is nice. Check out Docusaurus for an example of a static site generator that actually uses React internally to build a SSR friendly SPA with fluid page loads. You don't have to choose one or the other anymore, you can get both a smooth SPA experience with full server rendered and SEO friendly content.

I have built a career around Hugo. It’s extremely capable once you learn its core concepts.

Can you expound a bit on what you are doing with Hugo vocationally?

https://github.com/spotlightpa/poor-richard/

Wow, excellent!

Leaning tower of JS just hit me in the soul after two full days of composer and npm dependency hell. I'll have to give Hugo a try for my next fitting use case.

>And I like Hugo because of that “it’s just a binary” bit. There’s no dependency hell.

I had that issue with Jekyll, I just couldn't get the set up to work on my system (to be fair, I gave up easily instead of asking for help).

When I came across Zola (https://github.com/getzola/zola), I was immediately drawn by the single binary aspect.

Think twice about building on top of Gridsome.

I love Gridsome, and it had tons of potential, but it's effectively a dead project. The maintainers haven't cut a new release since November 2020.[0] There's barely been any feature work since 2019.[1] Their Github repos have tons of PRs that have not been reviewed. There are serious site-killing bugs that have not been fixed for over a year.[2]

I really wanted this project to succeed. I asked to sponsor the project and volunteered working on their documentation for a few months, but it didn't seem to yield any new dev work.

The maintainers are extremely talented, and this is not a knock against them, but I just caution anyone against marrying themselves to a framework that's unlikely to have any ongoing maintenance.

[0] https://github.com/gridsome/gridsome/releases

[1] https://github.com/gridsome/gridsome/graphs/code-frequency

[2] https://github.com/gridsome/gridsome/issues/1032

Thanks for the warning -- some alternatives, in somewhat random but roughly dependability/activity/which I would choose order:

- https://github.com/netlify/netlify-cms

- https://github.com/strapi/strapi

- https://github.com/directus/directus

- https://github.com/tinacms/tinacms

- https://github.com/sanity-io/sanity

- https://github.com/wintercms/winter

- https://textpattern.com/

- https://github.com/Camberi/firecms (tied to firestore)

Maybe I'm missing something, but how are these alternatives to Gridsome? These all appear to be headless CMSes, where Gridsome would be the front end accessing the CMS.

No you're absolutely right -- these are all headless CMSes, I did not actually complete the JAMstack, only the wrong piece -- I don't know what I was thinking, don't know what made me zoom in on CMSes so much, guess I think of them as more important than the front-end in a JAMstack.

As recompense, some lesser known options for the frontend part of the JAMstack that weren't mentioned in the original post:

- https://github.com/getzola/zola

- https://hexo.io/

- https://www.getblades.org/getting_started.html

I had the same thought when reading the list. I was very excited about gridsome when I discovered it last year. It had so much potential but disappointing to see it untouched since.

I guess these things are not what ( a majority of the actively posting) HN crowd is thinking about when static site generators come up - but I want to mention that there is no need for all these hugo / jeckyl type setups for everyone when you can download a program write some text and publish - generating a static site with tools like:

NotePad++

sublimeText

PineGrow - https://pinegrow.com

CoffeeCup (site designer, html editor, form makers) -https://www.coffeecup.com/

BlueGriffon is a static site maker even has wysiwyg - https://en.wikipedia.org/wiki/BlueGriffon / http://www.bluegriffon.org/

I loved making pages and sites with NetObjects fusion the most - it seems that PineGrow is the closest thing to that but modern.

There are also a couple of 'Wordpress goes Static' plugins ( https://wordpress.org/plugins/simply-static/ is one of them ) that can pipe out static html pages from a WP install - and they are handy for positives of having a static site - with the bonus of all the WP themes - of course doing that destroys the dynamic things you may want - site search, contact forms, comments - but handy for the right use case.

In a pinch it is sometimes faster to pop open notepad and paste in an html5 boilerplate add some text and save it - done.

It's quite trivial to pull in bootstrap, bulma or similar with an include line or two and start making a page / generating a static site.

I wanted to write posts in Markdown with Latex support and the option of raw HTML but honestly every static site generator I looked at was super complicated and opinionated.

I ended up using Pandoc and a Makefile. It works really well.

A lot of these seem to be JS-based. Static site generators are supposed to be simple, static, and generate small pages that load fast. I don't see why I'd need React or Vue support for a *static* site.

Static just means your site is loading actual CDN- and cache-friendly files and not stuff dynamically generated on the fly by a server side process, or loaded through such a process.

Javascript can still be statically loaded in this situation and could be used to provide UI elements (such as collapsible sections) or even an interactive local search.

That is a very new domain specific overloading of what the term 'static website' means. Unlike the old usage which is from the point of view of the website user where static means they don't have to execute code, the new usages tend to be developer experience focused and of little general utility.

Yeah, the "new" usage of the term, where it describes the location of page generation, doesn't seem all that helpful. If you generate a file that's mostly html (with maybe a bit of JS mixed in), you have something that serves and renders fast even on lesser machines. That has always been the important distinction to me.

Edit: Just to be clear, I'm not saying web pages should be mostly statically generated html with a bit of JS. The point is that someone developing a web app shouldn't normally be concerned about whether or not it's static.

> I don't see why I'd need React or Vue support for a static site.

Sometimes the reason is the dev workflow rather than the output.

You can generate a fully static site (no JS) with React.

No one wants a bespoke template language for every different project. You want to be able to share and use the same template for rendering a dynamic contact list populated by an AJAX call on your site's dynamic pages, with the simple static marketing page that lists all the project creators for example. React/Vue/Svelte/etc. are just templating systems that started as dynamic frontend-only solutions but now see use in generating static pages too. The idea is that the same templates can be reused, shared, mixed and matched, etc. in all uses. You don't need to spend weeks building and maintaining two separate types of templates--those used for dynamic vs. static pages.

Every time I see a static site generator list, or a discussion thereof on HN, I always wonder: Why is Pelican consistently ignored?

It's been around for a long time. Has lots of plugins. Easy to extend. Fairly active development.

https://blog.getpelican.com/

For me it was the license that made me not pick it: https://github.com/getpelican/pelican/issues/1397.

A while ago I was picking a new SSG and I would have preferred something written in Python so I can hack on it more easily. I ended up moving on because of the license.

I am now very happily using Hugo.

Yes hugo is great. It breaks compatibility from time to time, but other than that it has worked perfectly for me for many years now.

Thanks for educating me - I did not know about this.

Not sure I see it as a problem, though. I'm producing static files, and uploading them to a web server. At no point is a user communicating with the program - which I think is the key clause that triggers the AGPL. The whole discussion about templates being treated as code is enlightening - but again: No user is communicating with the templates either.

Furthermore, even if I'm wrong on this, I don't see the leap that the content of the blog has to be AGPL. At worst, I'd merely have to release my templates and any other modifications I've made to the code (custom plugins, etc).

Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't. A lawyer would probably have to sort that out.

The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software. I don't want to learn one tool for personal projects and another for potential work projects, in case the opportunity comes up.

The easiest way to deal with that is to just switch to a tool that has a license that is more widely accepted.

> Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't.

No - it suggests that I'm not a lawyer. I would use those phrases for any license.

Let me put it concretely. Had I read the AGPL, I would have concluded that there is no problem in this use case - just as I would with the GPL or any permissive license. It's only because others disagree, for reasons that seem faulty to me, that I hesitate. Frankly, for me, this is a good example of (unintentional) FUD.

> The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software.

I thought the issue was GPL vs AGPL. If you're avoiding GPL, then it makes it more understandable. In any case, I use it for personal reasons. Were I considering it for our work, we would consult with our lawyers (have done so in the past) - regardless of the license. My work does not involve the web, so I don't have the concern of having to learn two different tools.

I use pelican, mainly because it was the top Python SSG at the time and thought maybe I’d hack on it. I never hacked on it, just used it. I’d probably pick something new if choosing today, like Hugo which has a larger ecosystem

I picked Pelican for similar reasons. All my prior experiences eventually led me to wanting to change some aspect of the blog software, but they were always in languages I didn't know. So I picked Pelican.

In the years since, I write code to get my desired output via Pelican probably once every few years, but it's totally been worth it to have that option. I really got sick of "Let's search to see if someone's written a plugin that does exactly what I need." And then to have the plugin broken with an upgrade.

The reason I gave up was coz I found a nice template and tried to use it and it just didn't work.

One aspect of static site development nobody seems to want to do is to keep themes up to date.

I'm surprised there isn't more love for pandoc in the SSG world. It is an unbelievably flexible and fast tool in my experience, with very little opinions or concepts to learn. Yet despite the simplicity it opens up a huge amount of customization with its AST filtering (either in lua or bring your own executable plugin). Pandoc + a shell script or even makefile could likely replicate many folks needs for a simple SSG.

I love pandoc, but it explodes the size of my Arch Linux updates because of the way Haskell is packaged. I'll have to check out whether there's some kind of single AppImage binary or something.

30 seconds after posting the comment, I found this:

https://aur.archlinux.org/packages/pandoc-bin/

I don't know why I never tried to look for it. But I can attest to that fact pandoc + miniserve is a very interesting static site stack for those who want ultra simple.

Yep they have single static binaries now that are way more convenient. Better yet too, there's a nice docker image that's easy to use as-is or build on with your own plugins/filters/etc: https://hub.docker.com/r/pandoc/core

You can install pandoc-bin.

https://aur.archlinux.org/packages/pandoc-bin/

Btw there is a static page generator utilizing pandoc directly: hakyll[1]. Since it's configuration is done via haskell source code file, you need to be willing to learn a bit of haskell though.

[1] https://jaspervdj.be/hakyll/

If you love building stuff in Rails, keep an eye on my project Sitepress at https://github.com/sitepress/sitepress (there's a project site too at https://sitepress.cc). I'm a few betas away from dropping a 2.x release. I'm still working through a few refactors that makes the whole thing more modular.

I built this because it was extremely difficult to embed Middleman or Jekyll into a Rails site. While I was building it, I discovered that Rails actually has a LOT of stuff in it already that make it work well for a static site compiler.

I run it in a few places, with the largest deployment at https://www.polleverywhere.com. At Poll Everywhere it's happily been serving up content pages for a few years. I've switched all of my personal static websites over to it as well.

Here's what's kind of crazy about Sitepress: you can use it to compile static websites -- OR -- you can embed it in rails and do things dynamically like display a "Login" vs "Logout" button state. The choice of "static" vs "dynamic" just isn't a big deal with Sitepress, you can have it both ways.

Last thing: I'm currently working on making Sitepress serve up Notion and Webflow content. This can be really helpful for teams that need to deal with multiple CMS formats from large teams.

If you love building stuff in Rails…

Check out Bridgetown, "a Webpack-aware, Ruby-powered static site generator for the modern Jamstack era". It's come a long way since it forked from Jekyll a year ago [1].

[1]: https://www.bridgetownrb.com

I have been working with Hugo about three years ago. I found Hugo quite nice and easy to learn compared to the other options. But later I discovered Publii (which isn't listed on this article). Publii finally made editing and publishing a real pleasure by offering a real backend to manage your articles, media, organize your site etc.

Yes, for smaller projects in which clients themselves will manage the CMS, it is really nice.

Earlier this year, I made a site using Zola. I was quite happy with it once I got past some of the quirks when dealing with URLs.

https://github.com/getzola/zola

Happy user of zola too

https://mrkaran.dev/posts/migrating-to-zola/

Thanks for sharing, interesting that you liked the sections/pages structure because it was something I was fumbling with initially (but did eventually settle into a groove).

I will say there is currently a lot of momentum behind other projects when it comes to the "out of box" themes that are available. I'd like to see more community maintained themes.

I made my templates and CSS (SASS) from scratch. I would have released them if they weren't so bespoke. I'd like to see some that make use of well-known CSS frameworks (eg. Bulma or Tailwind).

I have also recently shifted my blog from Wordpress to Zola. Happy so far!

https://vishalsodani.com/programming/moved-to-zola/

I'm surprised no comments here are in praise of Eleventy (11ty). As someone who works on more hardware-oriented stuff and not web dev, 11ty was the simplest to understand static site generator I've tried. I started out with Hugo, but there was too much going on for me to figure out how it works. Most tutorials or google searches ended up just pointing to "use this theme and change/add these files to add new stuff". 11ty is so dead simple in comparison. You just say, "hey, I have these files using these templates," and it just spits them out rendered. If you want to group certain data, you just label them using front matter and put them in a folder. And if you want to put content from one file into templates, you just specify what template file you want to use. I think it's the perfect balance between simplicity and customizability. Being able to write posts and markdown and throw together a simple HTML template for the base layout has been a lovely workflow to use.

yep, I'll give Eleventy some praise. As they mention 'unobtrusive and transparent' it's so lightweight and adaptable and great for workflow without being so insane over the top like any of those React 'site builders' which all seem more like building giant PWAs instead of a site of content etc.

Finding the time I will try out Python-based Nikola [0]. Its features are very intriguing to me and as it is based on Python, I could (potentially) write my own extensions.

What always drives me away from SSGs or what I don't understand: to create new content, you need to have your development environment.

What I would like to have would be Grav [1], but based on Python. With Grav you can log in, create or adjust your Markdown-files and you instantly have your new or changed content, from every browser in the world. You can also easily create your own backend/frontend forms within the application. I know that this is basically a CMS and not a SSG, but it allows me to adjust the content of a basically static site.

I also know that there is also Python-based Lektor [2], however I found Nikola more intriguing than this one.

[0] https://getnikola.com/

[1] https://getgrav.org/

[2] https://www.getlektor.com/

There's also this big list: https://staticsitegenerators.net/

And this smaller one: https://github.com/collections/static-site-generators

9 of these run on Node.js - quite interesting departure from what was the state a few years ago.

I wish we had a common specification around static-site generators though, something akin to CommonMark - so it was easier to switch between generators without having to spend time porting things around. The Jekyll directory structure for eg, is mostly respected various implementations - but it isn't a accepted everywhere for eg.

For any Swift devs needing to put together a webpage, check out Publish: https://github.com/JohnSundell/Publish

Haven't used it myself yet, just heard about it in John's Static Site Generation Corner on the Stacktrace podcast.

If you're considering using a static site generator for creating something like a personal blog, I suggest trying to create one yourself. The more hacky you do it, the better. It's a lot of fun.

Is there any kind of static site generator that lets me write documents in Markdown, store them in a directory, and automatically loads them into the static site and translates them to CSS?

I say this out of a genuine desire to be helpful, I promise: you wouldn't be translating your Markdown "into CSS", you'd be translating it into HTML, and then optionally applying CSS

To your original point, if you want something really simple this might work (haven't tried it, just found it on Google): https://github.com/gomarkdown/mdtohtml

And then for CSS, you could drop in something like this: https://github.com/andybrewer/mvp

>I say this out of a genuine desire to be helpful, I promise: you wouldn't be translating your Markdown "into CSS", you'd be translating it into HTML, and then optionally applying CSS

Thanks, that’s what I meant, just didn’t think I needed to spell it out for this crowd :)

Have a look at blogit (https://pedantic.software/git/blogit/). Not only does it do what you want, it also integrates Git into the mix.

Even better, thank you!

I've worked with Scully. It's nice in that it let us share stylesheets with another Angular repo, but apart from that there were a lot of things that felt unpolished and difficult to work with.

I'm cheering for it and I don't want to come off as discouraging for a product that I didn't pay for, but it has a long way to go. A lot of my work with it (but not all) was pre-1.0 though, so maybe it's improved.

SvelteKit uses Vite under the hood. Also, as it uses Vite, it's generally faster than React/Vue. Not sure that's really contested.

I prefer Pollen — https://pollenpub.com

Mine's duct taped on Svelte/Sapper and Airtable as a CMS... it's completely free, is static, and super fast... don't knock Airtable as a CMS until you've tried it...!

How are you doing the integration? Do you have an app that pulls in the pages live from airtable?

SvelteKit looks like a promising upgrade from Sapper.

I still like react-static. React + static.

https://github.com/react-static/react-static

Fun fact- if you're going 100% static then you don't need React, you can just use JS template literals. So instead of this:

  export const MyComponent = ({ first, last }) =>
    <h1>Hello, {first} {last}!</h1>

you'd just do this:

  export const myFragment = ({ first, last }) =>
    `<h1>Hello, ${first} ${last}!</h1>`

No dependencies (or build steps!) required

This stops being fun as soon as you have a user named ‘<script>’

Any user-entered string data should be sanitized before it enters the DB anyway

Don't modify input, sanitise output instead.

The user entered <script> you should save that verbatim, but there are many output formats, HTML, SQL, PS (Post Script), XLS etc etc where you need to escape user provided values

For a more complete list of (as of now) 326 generators, see:

https://jamstack.org/generators/

Why have a static site generator when you can just have a CDN?

Because for a lot of use cases, there's simply no need to have a full LAMP (or one of the many various alternatives) stack to serve what should be a simple website.

I'm not sure quite what you think static site generators do if you're comparing them to a CDN, but they take a set of scripts, markup, images, and whatever else you care to mix in, and then emit a static site - just a bunch of HTML/CSS/JS/etc. You can host it on anything that supports serving static files - Google Cloud Storage works (especially when fronted by Cloudflare, data bandwidth between those two companies is cheaper), a random old server, etc.

You typically render it locally, then simply upload the changes to whatever you're using to host.

Not all websites (and not even all websites dealing with somewhat dynamic content such as blogs) need a full server stack, and the security of the server is far better if it's just serving files.

I transitioned my blog from Blogger (when they updated it last summer and absolutely ruined the core functionality of their editor, which is editing text) to a Jekyll-rendered site. It works out well, and I simply integrate a Discourse instance I run for a variety of things into the templates to have a functional comment section for posts.

Please expound on this as if I were an 8 year old.

You’re late for school

I run a bunch of both.

Many sites don't need to be dynamically generated - they just need to provide some text and pics or whatever.

Some bonuses with non-dynamic - no worries if a php update fails - no worries if some other server side thing is broken - just serve files - no thinking.

Less worries about cpu overload - like having a dozen wordpres sites on a box - you can run into problems if one of those sites is getting hammered by login requests or similar - even if you 100% prevent them from logging in - you are still eating up php and what not which may affect your other dynamically generated sites on the server more than some static files that need to be pushed.

Of course you are right in that modern CDNs and cacheing make much of what used to be bigger problems more trivial in general..

A single site on a VPS less likely to be of concern compared to shared hosting or a dedicated box with several sites - in my experience - situations vary.

If you're using a CDN just to a cache a dynamic site you still need a server running, with the asociated costs, maintenance and security issues. With a SSG you really can have just a CDN: build and deploy direct to the CDN and you don't need to keep anything running. The costs and attack surface are much lower.

please use my static site generator: https://github.com/eguneys/jener

Reply on news.ycombinator.com