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.
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
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.
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.
But like sibling said, if you're happy with your setup, keep it.
Commonly stated but not actually true. For example:
https://github.com/getzola/zola/blob/master/Cargo.lock
https://github.com/gohugoio/hugo (scroll to the bottom of the README)
Plus as sibling comment says you usually don't do anything but install hugo, `hugo [command]`
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.
After spending a little time understanding Go templating it is really beautiful
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.
My theme is so simple I think redoing it as themeless may be better
It's that theming structure that was a pain to figure out the first time for me
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.
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
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.
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.
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.
If you don't want the trouble, don't chase the new hotness. Use what works until there's a compelling reason to switch.
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.
Use Zola or Hugo. They have zero dependencies.
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?