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?
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.
> 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!
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.
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.
Honest q: what’s the problem with Ruby? Compile time? Gem management? I’m using Jekyll and sometimes wonder if I’m missing anything from the newer systems. My compile time is negligible, and once I figured out how to integrate Tailwind, I’ve had no issues.
I don’t see a reason to switch a site from one to the other if you and any collaborators are comfortable maintaining the runtime. The same goes for JS based tooling (I imagine), I just don’t node so good.
Personally, I use Hugo for new projects because it lowers the burden for content collaboration.
Templating is weird in Go, though if you’re working on themes. I like it now, but it’s procedural vertically and LISPish horizontally, if that makes any sense.
Usually it’s just me or me and another guy messing with that, and others often unfamiliar with anything except Java contributing vanilla markdown documentation. “Clone the repo, run this binary” is helpful there.
Personal preference mostly. rvm/gem/bundle is just a lot to set up and keep in your head compared to running a statically-linked binary. It feels like a relic of a previous era. Plus compiled languages are faster, and massively easier to set up if you have contributors running Windows.
But like sibling said, if you're happy with your setup, keep it.
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]`
Hugo (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.
Much of the interesting and useful tooling today is in the JavaScript ecosystem, that you will still have a package.json, Node dependency, etc. Except they are not Hugo’s problem, they arrived via a theme you are using, and they are your problem.
Hugo itself is a pretty lean template system. That means it doesn't know much about building websites. All kinds of things you hope it will know about (SEO, how to plugin analytics systems, much much more), are sitting over in themes in the ecosystem… tangled up with the axis of what visual appearance you want.
So the notion of swapping themes to swap appearance doesn't work, because the theme you picked provides a bunch of functionality in addition to appearance, and a different one will not have the same functionality.
This isn't a complaint, it is a good piece of work with many well-thought-out ideas. But it is pretty far from what the poster was looking for.
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
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.
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.
OK I see, but even though it's themeless you still have to follow the Hugo theming structure (_default, partials, index.html, etc). Mine is the same as that, it's just nested into the themes directory.
It's that theming structure that was a pain to figure out the first time for me
Yeah, that template look-up hierarchy is unavoidable. The benefit of being themeless is mostly organizational: one config file, one asset directory, etc.
Totally agree on this. Took me a bit to wrap my head around it vs other templating I’ve used.
Also figuring out the variable structure took me a bit, but now the docs make sense to me.
My theme is super simple. A few templates, 1 CSS file, and a tiny amount of vanilla JS. I just let Hugo + CSS do most of the lifting.
I think some folks have had bad experiences with themes that layer a JS framework on Hugo, though. That may be a better case for a completely JS ecosystem.
There’s a lot of good options. That’s a good problem to have. Just use what you like, I guess.
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.
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.
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.
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.
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.
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).
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.
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?