7 ms·

Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update? Inevitably, when a new "hot" SSG comes on

Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update? Inevitably, when a new "hot" SSG comes on the scene, I try it, and then go back to compare it to the old "hot" SSG from 2 years ago. Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times. As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run. And like all SSGs, I see no mention of sane SEO defaults on the homepage. Let me guess--with Astro I'm going to have to set all of this up myself?

jutanium 4y ago
Astro is that tool. It can output a server that can react immediately every time you do an update.
bluehedgehog29 4y ago
Not sure if you've heard of Publii?[0] It's a static blog generator type thing, bit of a different concept to the framework posted. I've tried it a few times casually and it seems ok for non-devs to get something simple up and running. Bit of dev work can update templates etc The SEO defaults aren't perfect but they're easy enough to change in the software. [0] https://getpublii.com https://getpublii.com
MatthewPhillips 4y ago
Here's a good SEO component: https://www.npmjs.com/package/simple-astro-seo https://www.npmjs.com/package/simple-astro-seo
malfist 4y ago
Have you checked out Hugo? It's builds are pretty fast, and it has a watch function for rapid dev work. Not sure how you'd get away from a build on updates though, it is called a static site __generator_. If you want to skip the build entirely, just write .html files and call it a day.
game-of-throws 4y ago
Use any SSG not written in javascript and you'll be fine. Hugo, Zola, Jekyll, etc. Though if I was starting from scratch I might avoid Jekyll just because of the Ruby dependency.
- root_axis 4y ago
  > Use any SSG not written in javascript and you'll be fine. Commonly stated but not actually true. For example: https://github.com/getzola/zola/blob/master/Cargo.lock https://github.com/getzola/zola/blob/master/Cargo.lock https://github.com/gohugoio/hugo https://github.com/gohugoio/hugo (scroll to the bottom of the README)
  - weego 4y ago
    To be fair in every day use Hugo is a single very portable binary
    - procombo 4y ago
      This. Makes everything so smooth. Serverless cloud providers love it too. (Cloudflare Pages, etc.)
  - skrtskrt 4y ago
    Yeah Hugo has the advantage that dep management for Go is 10000x simpler than JS, Ruby, Python, etc., particularly when you are someone who doesn't work in that language regularly. Plus as sibling comment says you usually don't do anything but install hugo, `hugo [command]`
  - IceWreck 4y ago
    You don't need these deps to install it, just to compile it.
  - game-of-throws 4y ago
    If that scares you, you must be terrified of modern Linux distros.
- 4y ago
e_i_pi_2 4y ago
As a counterpoint - the big benefit I see from Astro isn't that it has minimal dependencies, it's mainly that it seems like a very flexible foundation to build from. So I'd agree a landing page doesn't need this, but "the best tool" for a landing page is probably too specialized for general use in larger applications.
rsolva 4y ago
> Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update? I am experimenting with Caddy's template functionality [0] in my pursuit of making dependency-free and buildless websites. Caddy's templates are inspired by the Server Side Include (SSI) functionality in Apache and Nginx, except it uses Golang's syntax. I have made several websites in Hugo and find it pleasantly similar, only more bear-bones. Although Caddy is serving static sites to the browser, it is technically more like using a dynamic scripting language like PHP on the server. I guess Caddy templates outperform PHP by a large margin because it is written in Golang and compiled, but I have never tested this hypothesis. Funfact: Caddy's entire website is written with Caddy's template system and the source code is available [1] for those who want to take a look! [0] https://caddyserver.com/docs/modules/http.handlers.templates https://caddyserver.com/docs/modules/http.handlers.templates [1] https://github.com/caddyserver/website https://github.com/caddyserver/website
- francislavoie 4y ago
  To add onto this, we recently added plugin support for templates, so you can write your own template functions if you'd like! https://github.com/caddyserver/caddy/pull/4757 https://github.com/caddyserver/caddy/pull/4757
  - infogulch 4y ago
    Have you considered adding WASM / WAGI support?
    - francislavoie 4y ago
      Not really; it's already really easy to write plugins for Caddy in Go, so we haven't really seen the need. See here: https://caddyserver.com/docs/extending-caddy https://caddyserver.com/docs/extending-caddy You could write your own plugin that calls out to your WASM layer if you want, but I'm not sure we need that built into Caddy. It would be extremely niche, I think.
cjlm 4y ago
Check out Eleventy[0] - written in JavaScript but largely no-nonsense with (relatively) few dependencies. [0] https://www.11ty.dev/ https://www.11ty.dev/
- notpushkin 4y ago
  We've used Eleventy on a project a year ago and it was super easy to get running. It is not tied to any frontend framework (but if you want an interactive part on the page, you will have to set it up yourself, in contrast to Astro's Islands [1]). My overall impression is: use 11ty for a first version, use Astro when you have more moving parts on the frontend. Little bonus for those coming from Python background (like me): 11ty uses Nunjucks, which is a JavaScript port of Jinja, so the templating system feels right at home. [1]: https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/
ASalazarMX 4y ago
Hugo (https://gohugo.io https://gohugo.io) maybe? I tried it for a small static site about internal documentation, and I'm very glad I did. The hardest part was reading the documentation, the installation, content generation and rebuilds were painless.
- skrtskrt 4y ago
  The hardest part of Hugo for me was creating my theme from scratch (docs are eh on this but I found some good 3rd party tutorials) but after that it's been an absolute breeze. After spending a little time understanding Go templating it is really beautiful
  - powersnail 4y ago
    Half way through customizing a Hugo theme, I suddenly realized that I don't need a theme at all. Hugo can be used themelessly, where you just write templates specifically for your site. Everything was so much easier from there.
    - procombo 4y ago
      That was my experience too. There is/was no formal standard for creating themes, just an empty dir (which they consider a feature). Even if they had one or two "official themes" that would have helped tremendously. Instead we spent a week researching how popular 3rd party themes did things, and made a hybrid. Then we moved away completely. I really wanted it to work for us and we were so close. Hugo is so fast and is brilliant on a couple of things.... but barely missed. I can't remember exactly but with what we were doing we were going to be heavily dependant on their Scratchpad, which felt like a hack. It's all just hacks, and they like it. Lack of solid conventions, and they LOVE it.
    - skrtskrt 4y ago
      wait do you have a repo example of this or some sort of link? My theme is so simple I think redoing it as themeless may be better
lucideer 4y ago
Repeating the Hugo recommendation. 1. I've not yet had issues building old sites 2. Just in case you anticipate such issues you can just check the binary into your repo
traverseda 4y ago
I like to use tup with jinja. https://gittup.org/tup/ https://gittup.org/tup/ https://github.com/kolypto/j2cli https://github.com/kolypto/j2cli
orthecreedence 4y ago
Maybe it's too obscure, but I really like Metalsmith. Once it "clicks" it becomes ridiculously easy to make plugins and to operate, and it generally doesn't go out of date. That said, it may require a bit of javascript knowledge to get a more customized build running. It does have YAML configuration and a set of useful plugins you can use without touching code, from what I know.
- schemescape 4y ago
  I liked Metalsmith because it was so simple that you could understand every single thing it did and why. Unfortunately, the dependency tree gets ridiculous quickly, especially since many of the plugins depend on different versions or implementations of libraries (e.g. path matching libraries). My site ended up with 200+ transitive dependencies.
onion2k 4y ago
Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times. Pin your dependency versions and never suffer this problem again! Shrink-wrap your node modules and don't even download them again! Use Yarn's offline cache to share package tarballs between applications to save on disk space! There are many options for this problem. And that's just in the JS ecosystem. Use something Ruby or Go based and it's even better. As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run. Except there really, really is. A static site generator is really an optimizing compiler for 4 or 5 different languages (html, css, js, markdown, a template language, etc), with a build tool chain, and often image optimization, and a server for dev, and usually some sort of semi-opinionated structure that scans a directory tree and magically turns that into something you can just throw up to a web server and have a working website. They're complex systems pretending to be "simple and easy" because the output is essentially HTML with a few whistles. You certainly can build a site generator with far less code, but when people want a lot of flexibility just by tweaking a JSON config file that necessitates complexity. And in JS, that means more packages. The beauty of tooling is that there are lots of alternatives if you feel you want to optimize for dependencies instead.
ARandomerDude 4y ago
I've been on the same Middleman template and pinned gemfile for 6 years now, with multiple production sites. If you don't want the trouble, don't chase the new hotness. Use what works until there's a compelling reason to switch.
unicornporn 4y ago
> Yet, I can never get the old test site I set up running again without massive annoyances. Use Zola or Hugo. They have zero dependencies.
p4bl0 4y ago
This is one of the reason I built Cigala [1], it's a single PHP script that let you build your website in the admin interface using a WYSIWYG editor (TinyMCE) that manipulates an SQLite database, and that produce static HTML pages for publishing. It only depends on PHP and SQLite which are available virtually everywhere for free (and in the worst case you can run it locally as the resulting static website can be copied to any static hosting). [1] https://code.up8.edu/pablo/cigala https://code.up8.edu/pablo/cigala
crabmusket 4y ago
I believe m4 comes preinstalled on some Linuxes.
omnimus 4y ago
Flat file CMSes usualy make far better SSGs than anything else. Like Kirby CMS or Grav.
deleted 4y ago
[deleted]

jutanium 4y ago

Astro is that tool. It can output a server that can react immediately every time you do an update.

bluehedgehog29 4y ago

Not sure if you've heard of Publii?[0] It's a static blog generator type thing, bit of a different concept to the framework posted. I've tried it a few times casually and it seems ok for non-devs to get something simple up and running. Bit of dev work can update templates etc The SEO defaults aren't perfect but they're easy enough to change in the software. [0] https://getpublii.com https://getpublii.com

MatthewPhillips 4y ago

Here's a good SEO component: https://www.npmjs.com/package/simple-astro-seo https://www.npmjs.com/package/simple-astro-seo

malfist 4y ago

Have you checked out Hugo? It's builds are pretty fast, and it has a watch function for rapid dev work. Not sure how you'd get away from a build on updates though, it is called a static site __generator_. If you want to skip the build entirely, just write .html files and call it a day.

game-of-throws 4y ago

Use any SSG not written in javascript and you'll be fine. Hugo, Zola, Jekyll, etc. Though if I was starting from scratch I might avoid Jekyll just because of the Ruby dependency.

root_axis 4y ago
> Use any SSG not written in javascript and you'll be fine. Commonly stated but not actually true. For example: https://github.com/getzola/zola/blob/master/Cargo.lock https://github.com/getzola/zola/blob/master/Cargo.lock https://github.com/gohugoio/hugo https://github.com/gohugoio/hugo (scroll to the bottom of the README)
- weego 4y ago
  To be fair in every day use Hugo is a single very portable binary
  - procombo 4y ago
    This. Makes everything so smooth. Serverless cloud providers love it too. (Cloudflare Pages, etc.)
- skrtskrt 4y ago
  Yeah Hugo has the advantage that dep management for Go is 10000x simpler than JS, Ruby, Python, etc., particularly when you are someone who doesn't work in that language regularly. Plus as sibling comment says you usually don't do anything but install hugo, `hugo [command]`
- IceWreck 4y ago
  You don't need these deps to install it, just to compile it.
- game-of-throws 4y ago
  If that scares you, you must be terrified of modern Linux distros.
4y ago

e_i_pi_2 4y ago

As a counterpoint - the big benefit I see from Astro isn't that it has minimal dependencies, it's mainly that it seems like a very flexible foundation to build from. So I'd agree a landing page doesn't need this, but "the best tool" for a landing page is probably too specialized for general use in larger applications.

rsolva 4y ago

> Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update? I am experimenting with Caddy's template functionality [0] in my pursuit of making dependency-free and buildless websites. Caddy's templates are inspired by the Server Side Include (SSI) functionality in Apache and Nginx, except it uses Golang's syntax. I have made several websites in Hugo and find it pleasantly similar, only more bear-bones. Although Caddy is serving static sites to the browser, it is technically more like using a dynamic scripting language like PHP on the server. I guess Caddy templates outperform PHP by a large margin because it is written in Golang and compiled, but I have never tested this hypothesis. Funfact: Caddy's entire website is written with Caddy's template system and the source code is available [1] for those who want to take a look! [0] https://caddyserver.com/docs/modules/http.handlers.templates https://caddyserver.com/docs/modules/http.handlers.templates [1] https://github.com/caddyserver/website https://github.com/caddyserver/website

francislavoie 4y ago
To add onto this, we recently added plugin support for templates, so you can write your own template functions if you'd like! https://github.com/caddyserver/caddy/pull/4757 https://github.com/caddyserver/caddy/pull/4757
- infogulch 4y ago
  Have you considered adding WASM / WAGI support?
  - francislavoie 4y ago
    Not really; it's already really easy to write plugins for Caddy in Go, so we haven't really seen the need. See here: https://caddyserver.com/docs/extending-caddy https://caddyserver.com/docs/extending-caddy You could write your own plugin that calls out to your WASM layer if you want, but I'm not sure we need that built into Caddy. It would be extremely niche, I think.

cjlm 4y ago

Check out Eleventy[0] - written in JavaScript but largely no-nonsense with (relatively) few dependencies. [0] https://www.11ty.dev/ https://www.11ty.dev/

notpushkin 4y ago
We've used Eleventy on a project a year ago and it was super easy to get running. It is not tied to any frontend framework (but if you want an interactive part on the page, you will have to set it up yourself, in contrast to Astro's Islands [1]). My overall impression is: use 11ty for a first version, use Astro when you have more moving parts on the frontend. Little bonus for those coming from Python background (like me): 11ty uses Nunjucks, which is a JavaScript port of Jinja, so the templating system feels right at home. [1]: https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/

ASalazarMX 4y ago

Hugo (https://gohugo.io https://gohugo.io) maybe? I tried it for a small static site about internal documentation, and I'm very glad I did. The hardest part was reading the documentation, the installation, content generation and rebuilds were painless.

skrtskrt 4y ago
The hardest part of Hugo for me was creating my theme from scratch (docs are eh on this but I found some good 3rd party tutorials) but after that it's been an absolute breeze. After spending a little time understanding Go templating it is really beautiful
- powersnail 4y ago
  Half way through customizing a Hugo theme, I suddenly realized that I don't need a theme at all. Hugo can be used themelessly, where you just write templates specifically for your site. Everything was so much easier from there.
  - procombo 4y ago
    That was my experience too. There is/was no formal standard for creating themes, just an empty dir (which they consider a feature). Even if they had one or two "official themes" that would have helped tremendously. Instead we spent a week researching how popular 3rd party themes did things, and made a hybrid. Then we moved away completely. I really wanted it to work for us and we were so close. Hugo is so fast and is brilliant on a couple of things.... but barely missed. I can't remember exactly but with what we were doing we were going to be heavily dependant on their Scratchpad, which felt like a hack. It's all just hacks, and they like it. Lack of solid conventions, and they LOVE it.
  - skrtskrt 4y ago
    wait do you have a repo example of this or some sort of link? My theme is so simple I think redoing it as themeless may be better

lucideer 4y ago

Repeating the Hugo recommendation. 1. I've not yet had issues building old sites 2. Just in case you anticipate such issues you can just check the binary into your repo

traverseda 4y ago

I like to use tup with jinja. https://gittup.org/tup/ https://gittup.org/tup/ https://github.com/kolypto/j2cli https://github.com/kolypto/j2cli

orthecreedence 4y ago

Maybe it's too obscure, but I really like Metalsmith. Once it "clicks" it becomes ridiculously easy to make plugins and to operate, and it generally doesn't go out of date. That said, it may require a bit of javascript knowledge to get a more customized build running. It does have YAML configuration and a set of useful plugins you can use without touching code, from what I know.

schemescape 4y ago
I liked Metalsmith because it was so simple that you could understand every single thing it did and why. Unfortunately, the dependency tree gets ridiculous quickly, especially since many of the plugins depend on different versions or implementations of libraries (e.g. path matching libraries). My site ended up with 200+ transitive dependencies.

onion2k 4y ago

Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times. Pin your dependency versions and never suffer this problem again! Shrink-wrap your node modules and don't even download them again! Use Yarn's offline cache to share package tarballs between applications to save on disk space! There are many options for this problem. And that's just in the JS ecosystem. Use something Ruby or Go based and it's even better. As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run. Except there really, really is. A static site generator is really an optimizing compiler for 4 or 5 different languages (html, css, js, markdown, a template language, etc), with a build tool chain, and often image optimization, and a server for dev, and usually some sort of semi-opinionated structure that scans a directory tree and magically turns that into something you can just throw up to a web server and have a working website. They're complex systems pretending to be "simple and easy" because the output is essentially HTML with a few whistles. You certainly can build a site generator with far less code, but when people want a lot of flexibility just by tweaking a JSON config file that necessitates complexity. And in JS, that means more packages. The beauty of tooling is that there are lots of alternatives if you feel you want to optimize for dependencies instead.

ARandomerDude 4y ago

I've been on the same Middleman template and pinned gemfile for 6 years now, with multiple production sites. If you don't want the trouble, don't chase the new hotness. Use what works until there's a compelling reason to switch.

unicornporn 4y ago

> Yet, I can never get the old test site I set up running again without massive annoyances. Use Zola or Hugo. They have zero dependencies.

p4bl0 4y ago

This is one of the reason I built Cigala [1], it's a single PHP script that let you build your website in the admin interface using a WYSIWYG editor (TinyMCE) that manipulates an SQLite database, and that produce static HTML pages for publishing. It only depends on PHP and SQLite which are available virtually everywhere for free (and in the worst case you can run it locally as the resulting static website can be copied to any static hosting). [1] https://code.up8.edu/pablo/cigala https://code.up8.edu/pablo/cigala

crabmusket 4y ago

I believe m4 comes preinstalled on some Linuxes.

omnimus 4y ago

Flat file CMSes usualy make far better SSGs than anything else. Like Kirby CMS or Grav.

deleted 4y ago

[deleted]