- cross-posted to:
- blogging@programming.dev
- cross-posted to:
- blogging@programming.dev
Hey, just wanted to drop this here. It’s a technical follow-up to The Unreasonable Effectiveness of Static Sites which was reasonably popular, and explains the components of a static site’s stack.
You must log in or register to comment.
Just last week I decided to try a different tech than I’m used to to run up a site. I did a little research then searched GitHub and found Hugo. I read the Hugo docs, followed their beginners guide and… Didn’t get fucking anywhere. Their docs are out of date, the examples are out of date. It looked so promising but my brain works best when referencing examples and when I couldn’t even get those to work, well, I don’t have time for that these days.
If anyone knows another static site generator with up to date documentation and an easy to run up example please let me know.
I use Pelican for the site and it’s working great. :)
Astro is also popular and will be familiar if you’ve developed with React before as they support JSX templates.
Hugo was born out of Google so it has all of the same benefits and drawbacks as every Google project (both internal and external):
- Lots of capabilities. You name it, it’s a feature.
- To support all of those capabilites, there’s abstractions for everything – enough to make you go a little insane if you have to go through the code.
- Lacking documentation. Nobody gets promoted for writing docs, so if you really need to know how that feature works, you have to go through the code.
- May be abandoned at any time (but pull requests/CLs are always welcome).
I use https://quarto.org
Pros: Markdown, easy to use. Docs are very good. Also, despite being a a static site, it comes with fulltext site searching, all done locally, enabled by default:
https://quarto.org/docs/websites/website-search.html
It uses pandoc under the hood, so anything that works with pandoc works there.
Cons: No support for any kind of template engine beyond simple variable replacement, as far as I know.
I used Astro. It is a start but you can incorporate any us framework you want to.
The Docs are great which is why I used it.
I tried a few. Zola was the only one I got far enough with to actually get my site deployed.
Some of that might be that I learned stuff from my previous failures, but I really feel like the combination of the way it works and the Zola-specific themes are what worked for me.
That’s interesting, Hugo is the only SSG I’ve had luck with so far. I’m kind of stuck on Docusaurus at work and it’s a disaster.
On the face of things they’re all so simple, but aren’t documented well for users new to SSGs, and the build often spits out something unexpected with no way to figure out why.
11ty is great, especially since it’s very BYO in terms of templating languages. (I started with nunjucks until I figured out the magic that is webc.)
I use zola for my sites. It’s got not as many templates as hugo but my sites don’t use templates and I found it very straightforward to use from scratch.
Hexo has been working great for me. I found the documentation great as well.
For this reason I’m building my own generator in Common Lisp, leveraging cl-who and parenscript. All components are descibed in one place and render as web components, which allows me to attach dynamic behaviors easily.
This works great for business-card style sites, deployed to netlify.
Another cool thing I realized - you avoid the chance of some framework updating under you and breaking everything. It’s a bit like pdf, it gets fixed and generally untouched.
I must sound like an old fossil but I just use windows notepad to build any basic sites that don’t need like a shopping cart or anything complex.
A generator can help if you have a bunch of data that you need to convert to some html structure. I know what you are saying though, as little complexity as we can get away with, innit :)
The advantage of static site generators is you have your template and it’s filled by the data for each page. It’s generally very simple and intuitive.
The problem with doing it your way is if you need to change a common element you have to edit every page. Instead of just changing the template.
Markdown to html just works so well as all your pages are structured the same.
I use PHP to generate anything repetitive. With that and CSS it’s pretty easy to make site wide changes.
What would be the advantages of these methods over something like Neocities?
For me, I write notes in Markdown anyways as part of a Zettelkasten, and by setting up my site this way I can stay in my development / note taking environment (nvim) and push stuff up to the site very quickly. It’s far easier as a developer to work off-the-cuff with this type of workflow, at least for me.
Also, would be very easy to self-host or move provider if Vercel or any other provider goes down.
I use Markdown with Jekyll because it integrates nicely with GitHub Pages and I can run it locally for authoring. There’s tons of support for it, as far as I can tell. Jekyll uses Liquid for templating, and it seems pretty good. For layout, I use Minimal Mistakes which has a really nice feel and it’s comparatively easy to customize. Once I was through all the layout configuration stuff, it’s really just a matter of writing articles and pushing them up to GitHub - rarely fiddle with anything technical these days.
I see, that makes sense
