I though this was about the wedding registry site at first.
Anyway, I liked this line from the Github:
> Hugo gets ehh for the template engine because while it is probably the most powerful template engine in the list (after Jinja2) it personally drives me insane, to the point of writing my own template engine and static site generator. Yes, this is a bit biased.
This seems to be the life cycle of static site generators (SSG). It works at first, but you end up wanting to design your own custom SSG once you run up against something that goes against your mental model of how things should work.
I did this exact thing when I got frustrated with Hugo. I made my own custom SSG in order to create my blog.
The other thing that tends to happen with SSGs is that it can be a lot more fun to play around with the tech than actually writing blog posts!
If you're interested you can read here to see how I made an SSG for my blog:
I did this exact thing when I got frustrated with Jekyll (and friends) and created Hugo. Of course, at the time all SSGs were in dynamic languages and very VERY slow.
I know the feeling. In my very meta case I get frustrated with my own SSGs, so every time I start learning a new language an SSG is one of my two standard projects to give a frame of comparison.
I now have my own SSGs written in C#, Go, Node, Python, Ruby, and PHP.
It's totally ridiculous, I know. Yak shaving and shiny to the nth degree.
That makes a lot of sense to me. It used to be that writing a blog engine was the "Hello World" of a new language or framework. So, it makes sense that a SSG would be a good non-trivial project to use to learn or understand the pros/cons of a language.
Sorry to pile on here, but THANKS for Hugo! It’s legitimately great and has helped me quickly and easily updated (with the help of netlify) set up a really useful set of online notes for myself. I truly appreciate your work.
Hey - thanks for making Hugo. We run our blog on it and I love it. Spitting out an AMP version and maintaing it side-by-side with our non-AMP version was a piece of cake.
Edit: noticed you make Cobra too! Damn - I owe you like 1000 man hours of saved work.
When Jekyll was created, all Apple laptops shipped with Ruby, and Apple has (had?) a large share of the “developer/power user” market. That’s my theory, at least.
> I did this exact thing when I got frustrated with Hugo. I made my own custom SSG in order to create my blog.
> The other thing that tends to happen with SSGs is that it can be a lot more fun to play around with the tech than actually writing blog posts!
Exactly that. A great way to learn a language too.
Pollen seems so incredibly cool and powerful, but every time I have tried to play around with it, I get distracted by small quirks and areas that I wish were documented more clearly, or in a more organized format.
My daydream is to make a _good_ technical documentation system with it that is usable by the everyman, but it's still just a bit too much of a stretch. Markdown + pandoc + LaTeX templates get close, but LaTeX templating is a nightmare, and markdown is far too limiting and lacks expressivity (without ad-hoc DSL's slapped on top).
If anyone has a good pollen tutorial or example repo, I'd _love_ to know of it.
Metalsmith is pretty slick. I like how _everything_ is a just a plugin/middleware in essentially a pipeline. I've used it to template/scaffold [1] out projects before and it worked reasonably well.
As long as they all use the same content format (like markdown + preamble) it’s relatively easy to move from one to another. Transferring themes is a pain though.
I think we are doing pretty well with increasing the number of SSGs even without a meta SSGG. But I guess there are still more blogs around than SSGs, so there's still potential for incrementing that counter.
The thing about an SSG is that it's so trivial to write your own (at least for the basic cases). And then you may well get more benefit after that point from retaining the ability to customize it than you would from having a generalized one that you need to wrestle toward your use-case
It's something that feels highly generic, and so programmers jump on the chance to genericize it, but may not actually be that useful to have as a thing you can grab off the shelf
The problem I see with using a SSG is that (a) it probably doesn't do what you want, combined with (b) it's designed to automate specific workflows rather than to make customization easy. There are obviously some cases for which someone else's automated workflow is useful. I'm not sure how often the tradeoff is worth it if you are proficient with a programming language that you can use to automate the workflow yourself.
Personally, all I want is a full proper programming language in my templating. Every templating language ends up being irritatingly limited, for me at least.
I think that's the big divide in templating languages— whether or not you trust the template author. Zero trust is a template like Liquid which has some trivial scripting stuff, but nothing non-halting (written originally for Shopify, where storefront owners could completely customize their look & feel).
And total trust is PHP.
In the middle is the whole realm of somewhat-trusted, where the templates can embed varying degrees of executable script, but you are at pains to let users know that too much embedding is a bad practice, and that especially if they're "just a designer", they should work with someone from software team to implement a properly-encapsulated solution for whatever it is they want to do.
I use PHP for exactly this reason. I wrote my own single .exe binary (written in C++) that generates JSON files from markdown files + others. The JSON files are then turned into static files via PHP using whatever template I care to create.
I think people their life harder when they go out of their way to avoid using PHP when really it is suited towards these types of problems.
Please explain how it's "not the right comparison".
The parent listed static site generators including Gatsby, Hugo, and Jekyll. I suggested NextJS is a superior option to those 3, because (among many other things) it supports "export" of a fully static, pre-rendered site, which puts it -- unambiguously! -- in the "JAMstack SSG tools" category. So I'm baffled by the downvotes, and your dismissal.
What am I missing? Thanks in advance!
PS Edit to add: NextJS is even listed, as the 1st result, in the parent's jamstack link!
Thanks, @aendruk -- ok, that issue is a legit reason for some people, in some cases, to prefer a dedicated SSG-only tool over NextJS. But it's not a reason to leave NextJS off the list altogether.
I think I’m just going to write a HTTP server for my website in Go, download the entire website with wget and host that statically. At least that way I can have any feature I want.
When I decided it wasn't worth keeping my personal site dynamic, I took my webapp and pulled out the core of it, and built a small little script that enumerated the possible urls and "requested them" from the old webapp and wrote them to files, turning the webapp into a static site generator.
I've been contemplating converting some legacy WP to static, but have not had the time to review available options.
With root access to the server / just good old wget, are there benefits to using the plugins/services? Which would you suggest? Would be grateful if you shared your experience.
Simply because a lot easier to host static files than it is to host a web server binary that has to be executed. I can just upload to GitHub Pages or AWS S3 and let them worry about the HTTP caching, TLS certs, upgrade to HTTP/3, etc.
Writing a blog post about how you enabled the writing of that blog post is the most fun part! I just happened to write my own today in a very similar vein [0]. I guess using webhooks to automatically deploy might be pretty obvious, but I didn't know how to do it until today.
Hello, i'm curious about your patches. Do you believe they could be useful for other people? Would you be willing to help upstream them?
I'm happy you coded your own SSG, and if you're happy with it it's cool, but maybe your painpoints with zola are valid for other people as well and we could try to fix them for everyone :)
> It works at first, but you end up wanting to design your own custom SSG once you run up against something that goes against your mental model of how things should work.
There is a middle ground. I hit this point in Jekyll when I wanted Insanely Great image thumbnailing that no extant Jekyll plugin could provide, ended up writing my own tool to do that, but didn't want to duplicate the rest of Jekyll's functionality too. It's kiiinda hacky and I probably should propose the interface changes upstream if I keep doing this, but a very light monkey-patch lets my tool pretend to be a Jekyll::StaticFile that just happens to write out many separate files: https://github.com/okeeblow/DistorteD/blob/master/DistorteD-...
Yeah, I wrote two. And I think my next SSG will be a Makefile, because generating HTML is the easy part. The tough part is tracking dependencies and xrefs, which I also think are the tough part of any build system (SSGs themselves are a subset of build systems).
That, and coming up with a good design for the page.
I'm doing the same thing but I wonder if I should even write something about it, hehe
Seeing all those HN posts about new static website generators and then your post makes me think that the important thing here is the concept of it, rather than specific implementations. I kind of like the multitude of options because it tells me that there's demand for that stuff, and we're all trying to find the most elegant solutions.
As a webdev, I'm happy to admit I'm not a programmer. I just dump some data in HTML templates, sprinkle some CSS and JS, while trying to give devs, editors, and users the tools to manage/navigate a website without much pain and suffering.
> The other thing that tends to happen with SSGs is that it can be a lot more fun to play around with the tech than actually writing blog posts!
I wish I could remember the link, but there's a fantastic XKCD-style cartoon making fun of over-engineered static site generator blogging setups.
When you build a static site, basically there's a 99% chance your only blog post is going to be "How I rebuilt this blog in [insert] static site generator."
Indeed I guess there are so many SSG because it's so easy to create one. In fact it might take as much time or even less to build one than it does to learn all the quirks and bugs of an existing one.
If you really want to focus on writing, why don't you just use WordPress? My feeling is that SSG is a toy to play with.
I had a SSG blog before. After stop using it for half year and came back, I found I had to relearn the whole thing to be able to make it work again. Add any function is a PITA. Totally wasting of time.
Making a Wordpress theme is more complex, and is full of footguns for security concerns. The fact that using a specific theme can open security issues server-side is worrying to me.
I want my server to serve files without having to worry about security vulnerabilities. That's why i use a SSG (zola).
You have to relearn it if you want to create a new theme for it. If you want to focus on writing, you just put new markdown files inside the post folder.
Not to mention that wordpress isn't static, which makes hosting more complicated & expensive.
My two cents are blogging through static hosting is more complicated than wordpress on basic php hosting. I need the email hosting comes with the $3/month web hosting anyway.
I run a few (well, one published, one in the works, a couple one-offs for student showcases) websites built with Zola. It's a great, little, simple piece of software.
What I like:
* Already supports the tooling I enjoy → SCSS out of the box, django/jade-like template engine (Terra, its sister project), markdown w/ TOML frontmatter
* Fast → build times are almost instant, dev server builds to memory and does live-reload
* Gets out of your way → it doesn't do more than it can, yet provides enough to work
* Builds a search index for client-side searching if needed
* Single Binary → I can pass the executable around with the repo and installation and environments are not an issue (ruby and python are painful for part-time developers it seems, at least with my non-developer academic peers).
I like that it provides a simple base to build on. I have one site that uses webpack to generate bundles for a couple JS files to allow for modern JS (babel) → all I have to use webpack for is JS, Zola handles the rest.
I migrated our Django theme for our previous site in an afternoon. I've found that those I work with often don't really understand how formatting in a CMS will apply in the published result, and often have to go back in and edit their pages for conformance → If I have to touch it anyway, I'd rather do it in markdown myself, something I enjoy using.
I have students/interns who have picked up markdown faster than any other markup or CMS. I've tried mezzanine [^meh] and wagtail [^excellent, but heavy for our brochure-ware] in python, wordpress is a pain [^either too flexible, or not flexible enough, research interns don't easily see how complex theme interactions occur] and some others like cockpit [^neat but flexible to a fault, yet too rigid for how free-form folks want to interact with it]. Markdown is translatable, and usable in other tools: it's a great common denominator with a very low bar for entry. Students continue to use it after first interacting with it on these projects after they've left.
What I'm missing:
* a way to build from an API endpoint instead of markdown, i.e.: point to an endpoint to get the section list, build children as pages. Then I could use content from a postgrest instance, or build it from a list of remote markdown files... (no, I haven't really thought this through very well)
> I have students/interns who have picked up markdown faster than any other markup or CMS.
That's also my experience with non-technical users.
> a way to build from an API endpoint instead of markdown
Well zola is not extensible in this regard. But it should be trivial to build a shell/python/rust script that exports your content to the format zola expects. Don't hesitate to post in the community forums if you need help with that.
Yeah, that’s the start. And I think what I’m after is eventually on the way. I’m not sure this would quite work the way I’d like; I guess variables could be passed into the template based on path and it could request different remote content based on that— I’d prefer to be able to use remote resources just like markdown instead of a different workflow.
Again, maybe I haven’t thought about this enough yet.
Hello, i'm not the creator/maintainer but i contribute to zola, and i'm happy to answer questions and receive feedback/criticism.
In particular for the next release, we're currently talking about making paths/links more consistent across zola [1], reworking the translations/internationalization system [2], and improving the README. [3]
In the past I wrote a couple sites using jekyll and really liked it. For my personal site I decided to give zola a go on a whim. I was pleasantly surprised by how complete and easy to use it was.
It had features for image manipulation built in that I had to get from a meh plugin for jekyll. I ended up reworking one of the sites I wrote in Jekyll in Zola on the next update. It was an art portfolio site so I leaned on these features heavily. It ended up being a pretty quick weekend rework and made the code base much easier to work in.
No mention of Eleventy [1] here. Definitely worth a look, my personal view is it nails the balance of simplicity, power and flexibility. I have used it for all sorts of projects, from marketing websites to quick client docs and presentations. For non-trivial usage in a project see google web.dev [2].
I tried both Eleventy and Zola along with a few other SSGs for my blog [1], and ended up going with Eleventy. I love that it's flexible with my directory structure, that I can write shortcodes with JavaScript (without adding JS to the client), and preview my site from my phone without any extra setup. (It gives you a URL when you start up the development server! Magic!)
It was almost trivial for me to add a social sharing image generator for my posts. [2] That's something I never thought my SSG would be able to do.
Definitely check it out if you're looking at static generators. Zola too, which is amazing in its own right.
As a keen NixOS user, I love the idea of configuring my site with nix and embedding nix exprs in markdown. However, I'm unsure whether the project is still active, or if the whole thing was more of an experiment. The repo[2] seems a little quiet, but the documentation is extensive and great considering! I wonder if the author just considers it complete? Curious to here experiences from anyone who has had a play.
I wish there were a way to use static site generators written in languages other than JS but still use JS features like JSX. I really dislike most templating languages because they are just hacks over a real programmatic way of composing content (via functions that return content). In templating languages, it's more like straight substitution of content.
It's similar to macros vs actual functions in something like C++. Sure, you could write everything in macros but why not use actual composition?
My input as a former technologist turned marketing guy over the years - where is a decent SSG (perhaps like Zola) with page building drag and drop tools like a Wix or a Squarespace?
I'd love to move our site off of Wix - and have full control when needed and work offline before publishing pages - but inevitably you dive back into code or the guts of database queries once you leave these WYSIWYG tools.
Between Wix and Zola is an opportunity, in my opinion.
Some time ago i found about Publii which is a desktop-based static site CMS with a mostly WYSIWYG editor (i write "mostly" because you do not edit the text directly in the site like you'd do in, e.g. iWeb, but you still use a rich text editor). It works as a desktop application (it is actually written in Electron), you do all editing locally and then you upload the files to a server (you can do that either manually or using its automatic uploading functionality which -from what i can see in my installation- supports FTP/FTPS, SFTP, Amazon S3, GitHub Pages, GitLab, netlify and Google Cloud). The sites are stored in folders with an SQLite database for most stuff and media files in their own folders.
Though in terms of customization is rather lite. There is theme support with custom themes so i guess it is possible, it just looks like a baklava of webdev layers to me that i didn't want to bother with. Most themes do seem to provide a tiny bit of customization though.
I made a blog with it and so far the main limitation is that i don't feel there is much i have to write, not the software :-P.
I haven't formally studied computer science nor programming, so it's very hard for me, but I wanted to build a set of tools that would eventually allow for what I call "block-stitching": a UI that mixes the data, its editor (form fields), and its destination template.
The idea is to be able to quickly build a web page using nestable components, and being able to export/import the structured data, in as many formats as possible.
But since I hardly ever interact with other devs, I might have missed similar projects which are mature enough already? (I just like to build my own crap, it's fun)
Zola seem the most popular static site generator that allows you to generate a website without any JS bundle without using some strange hack.
This is the way I firstly stumbled upon it as I was looking for a fast way to generate a fully static site with the advantages of a generator and none of the overheads...
It may be limited for certain use cases but I think it would be my first choice for editing a static site without JS
See my other comment [0], it seems only JS based ones use stuff like composition of content while most others are template-based, which is not as powerful.
No not really. There is a large anti-javascript crowd who avoid anything and everything js based, and frameworks like Gatsby and NextJS require you to interact with js and its tooling.
With those two as the examples, I'd definitely agree with that. I'd regard both as frontend frameworks and I've never heard Next described as a SSG, though, but Gatsby seems to be used as such by fans of reckless overengineering (because I definitely need GraphQL for my blog).
Eleventy would be quite a bit closer to Hugo/Zola, but even then you'd have to use npm/npx to install and run it.
Pelican can easily generate no-JS websites. If a theme doesn't include JS, there won't be any, and (wild guess) half the themes don't. It's also extremely easy to tweak most themes not to use JS.
I tried Zola and liked the speed and simplicity. However support for its templating language is scarce and I'm not super keen on writing extensions in Rust.
I have also looked at Hugo, which is determined to uphold evil and suffering by using Go's horrible templating minilanguage; Nanoc, which is cool but at times inscrutable and perhaps a little too obscure; now I'm playing with Jekyll. In short I am doing everything except actually writing.
I went from Jekyll to Hugo, because, although Jekyll was great at first, as the numbers of pages grew it for slower and slower until it was taking about a minute to compile. Switched to Hugo and compilation takes about 2s for the same site. On the other hand, yeah, there's lots of other frustrations - besides the weird templating stuff, they have one of the least friendly and helpful dev teams I've come across when I've occasionally asked a question on their forum.
Any specifics that stand out to you? I haven’t done a lot with templating, but when I was investigating Hugo a while back it seemed straightforward enough. But that was at a high level.
> For me the most difficult thing about it is that it is another language grafted on top of Go, and it does not always do what you expect it to do. ...
Ah, I see. At my first glance I thought it was just normal Go syntax. I’ll have to look into this more, thanks!
Hello, i would say there's a few missing template features in Zola (especially hashmap literals/functions) but i don't find it scarce. Could you elaborate with your painpoints so they can be addressed for others as well?
Zola is constantly evolving for the better, and the community forums are also a good place to exchange feedback/criticism
The Tera template language is not in wide use, so multi-language integrations with HTML were non-existent when I checked. That's tremendously inconvenient.
Well there is only a single Rust implementation for the moment, but tera templates are really similar to jinja (only difference i know is usage of named arguments in filters/functions).
Just an ordinary static website. Some standalone pages, some blogging posts. I can take another look at Zola and see if I've changed my mind -- the speed really is excellent.
While I'm not a fan of Go's template syntax, I do appreciate that there are a bunch of themes available for Hugo, and now a pretty easy system for working with them (modules). I like not having to spend a lot of time on the formatting to get something decent.
We're looking at Gatsby now. We don't care about the language used to generate a site as long as it doesn't send silent errors into the finished result (always a concern with JS...)
I'd personally try NextJS, it's a lot easier than Gatsby. This is the main article that turned my mind after trying both: https://jaredpalmer.com/gatsby-vs-nextjs
Using react-static here. Has some issues and not always free of regressions, but also not as bloated as say Gatsby.
If you write React components in a way that leaves them functioning when statically rendered, I think it is relatively straightforward to roll your own generator that calls React’s built-in renderToString() on top-level app component during HTML generation, and bundles basic JS that does hydrate() in case user agent happens to have JS enabled (those two methods do a lot of the heavy-lifting). Devil’s in the details, of course, but have been low-key looking into that lately.
I tried Jekyll, Hugo and Pelican. Neither sat as well with me personally as Gatsby.
I like only having to worry about a single language stack, and I can use typescript with Gatsby which negates some of my misgivings with js. Plus I can use react paradigms everywhere which is nice.
I keep trying to return to Zola but it seems I have to do much of the work there myself. It's kind of the other end of the spectrum for me: too much freedom! I wouldn't mind some convention-over-configuration there. Also the templating language isn't at all intuitive to me but it might be just me being stupid.
But I also want multi-lingual articles and article revisions so maybe Zola is not for me.
I absolutely love it how lightning fast it is, though, and I am sad that I still couldn't bring myself to learn it. These days my bandwidth (and desire) to invest fully in a new tool is at minimal values. :(
I think Zola would get much more traction if it had several typical cases covered in the tutorials: not only blogs but simple company pages, semi-informal technical docs, and the like.
Can somebody recommend something as fast as Zola but with more features -- or just it being much easier to learn? And don't say Hugo; it is really easy to start with but the moment you get off the beaten path you are looking at days of effort to modify your site.
> I wouldn't mind some convention-over-configuration there.
I strongly agree. I started some of that with my theme https://tildegit.org/southerntofu/zola-water and i'd be pleased to cooperate on "standard" conventions across themes so we can swap themes easily without having to reconfigure/reorganize everything.
> But I also want multi-lingual articles and article revisions so maybe Zola is not for me.
zola supports translations, though the details of that are being reworked. Revisions are not supported so far, but is technically possible by building your site in a specific output folder for every commit (or something along those lines).
Linking across revisions, as it is not supported by zola would require either an external component (eg. in an iframe) or a build script that rewrites output pages to be aware of their revisions. Though implementing a simple git interface to zola to expose commit names involving a specific page would not be hard (managing the different revisions as single pages, like is done for translations, would be more complex).
> I think Zola would get much more traction if it had several typical cases covered in the tutorials
Agreed. There is definitely a lot to improve on the website/documentation. If you have a more detailed proposal and/or would like to get involved, feel free to talk about it in the community forums https://zola.discourse.group/
I do have suggestions and ideas but I feel like the author(s) are too busy and would appreciate code PRs much more. I mean, everyone can just talk and talk, right?
> Linking across revisions, as it is not supported by zola would require either an external component (eg. in an iframe) or a build script that rewrites output pages to be aware of their revisions.
Ah, I mean something much simpler than that. Imagine having a combo box at the top of the article, named "Versions" (or "Revisions") that has the value of "latest (2020-02-28)" at the top and currently selected and then has all others just as dates below. When you choose one, the page loads another HTML file. Extremely simple vanilla JS, likely 5-10 lines.
Or you can just have a limited list (say the last 5 revisions) with direct links -- again before the content starts. Clicking those would not even need any JS at all. It would be a plain old <a href="/blog/whatever-article/rev/2020-01-31.html">2020-01-31</a> markup.
And if an article has no revisions (only has been written once) then the needs for such a combo-box or list of links disappears and they should just not be rendered at the article's page at all.
> I do have suggestions and ideas but I feel like the author(s) are too busy and would appreciate code PRs much more.
That is correct, and it would be sad and damaging to believe exhausted volunteer maintainers should satisfy each and every desire of yours. However, stating expectations and desires respectfully is really helpful, especially when it is done in a precise manner so someone with time and energy can try to implement it.
> When you choose one, the page loads another HTML file.
Well if you're keeping different versions of the Markdown file within your content folder, then it's not a problem. A page can link to its siblings just like you described.
But zola, like all SSGs i know, uses a simple folder for content so there is no notion of history of a single file. We usually use a version control system (like git) for that.
> That is correct, and it would be sad and damaging to believe exhausted volunteer maintainers should satisfy each and every desire of yours.
That's precisely why I am keeping silent. I worked on OSS myself and I don't want to come off as entitled. When I don't find the features that I would like I am mostly just shrugging and thinking to myself "either I'll research Zola's code base and make a good PR about it or I'll just keep my thoughts for myself because everyone can demand their own favorite features and it's not a productive use of the maintainers' time to read people's wishlists".
> However, stating expectations and desires respectfully is really helpful, especially when it is done in a precise manner so someone with time and energy can try to implement it.
True to an extent but I've been bitten by this in the past. My definition of respectful expectations is somebody's idea of entitlement even if I use language like "please consider this feature if you find yourself with some extra bandwidth in the future" and "I think this would help adoption because I know I am not the only one wanting it" and "this could help with SEO for this or that class of websites".
I learned that many OSS maintainers are tired and jaded -- and thus very jumpy as a result. So I just stopped giving suggestions after I have been slapped with "only PRs are welcome, otherwise we are not interested in theoretical discussions" several times in the past.
I realize Zola's maintainers might not be like this but there's something else to consider as well: it's mentally very tiring to have to use extremely watered-down diplomatic language (almost to the point of begging) just so you don't get on somebody's bad side if they had a crappy day.
I've had people rage at me for saying something as simple as: "feature X would be very helpful for workflow Y, would you consider adding it during the next 6 months?" (I guess the trigger was the implication of a deadline imposed on somebody's hobby work but the reaction was violent enough that I lost my desire to apologize.) And so it goes.
> We usually use a version control system (like git) for that.
I don't know the specifics but wouldn't that require Zola's Rust code to be aware of the GIT history of the website itself? Sounds like 5 tons of complexity loaded on top of 10kg worth of software, so to speak -- but I might be wrong.
^ The above describes only 3 articles, one of each has no revisions (why-i-left-ruby.html), one of them has two revisions (resume) and another has three (reasons-to-choose-rust-in-2021).
However, I am just talking out of my a$$ and can't comment if this is easy to integrate or what complexity and repercussions would it have to the otherwise free-form directory/file structure that Zola encourages.
I don't mind feature requests at all! The only thing I mind is people getting angry if I close a feature request as too niche or out of scope for Zola.
For the revisions, I don't think it would work right now the way you want. I have thought about something similar before but couldn't figure out a satisfying way to do it (or even whether it was common enough for the work to be worth it).
> For the revisions, I don't think it would work right now the way you want. I have thought about something similar before but couldn't figure out a satisfying way to do it (or even whether it was common enough for the work to be worth it).
Well, if you like the feature, go for it! It's your project. :)
Seriously said though -- I think this has a lot of future in terms of f.ex. tech docs or Wiki-like articles where you would want to revise your opinion / take on a hot topic a year later. Such a feature is a glaring omission from the SSG engines IMO.
I'd love to help but sadly I am wrestling with severely deteriorated health and just being productive at work and functional enough for my family life is draining 90% of my daily energy budget. So I'd lie if I said that I could help right now. So I prefer not to lie.
(I'll definitely check out the thread for i18n, thanks for linking it!)
> The only thing I mind is people getting angry if I close a feature request as too niche or out of scope for Zola.
That won't ever happen with me. I don't get angry. I realize what it is to be an OSS maintainer and I am not entitled. I'll shoot my idea and if it doesn't get accepted I'll just shrug it off.
Thank you for the encouraging words! They mean a lot. Keep up the good work. Zola is so far my favorite SSG engine, it's just that I can't muster the energy to learn it well and maybe help extend it. Here's hoping for the future.
I really like Zola and have been using it for my personal site for a few months now. I tried to use Hugo, which admittedly seems more capable, but found it to be too complicated for my use case. I was up and running with Zola, including my own CSS, site layout, and posts ported from a custom SSG within 2ish hours. I’ll continue to use it, it’s a very pleasant experience so far.
I tried Org Mode the other day and gave up when Emacs didn't allow me to edit an in-place SQL fragment with some cryptic error that you can't edit it in-line, so had to use a keybind to open a new buffer in order to be able to edit something that in Markdown is as as simple as triple backticks, the word "sql", the SQL code, and then another block of triple backticks.
Am I missing something? Org Mode is always so glorified yet it failed a pretty basic use case for me.
I suspect I encountered the same bug (in vanilla Emacs). It seems in Emacs 27 they introduced support for sql-indent-mode[1][2] which is not shipped by default but is in elpa. However there is a hook that checks if that package is installed, if so then loads it by default. It seems when not installed, somehow said hook messes things up in org-mode.
Thanks to some investigative work from Doom Emacs people[3][4], I have found that my issue was fixed by simply installing the sql-indent package. Of course you would need to make sure these settings are set to true to enable tab acting according to native mode in source code blocks:
And yes, I wasn't amused by this. I had another problem with shell mode indentation in org source blocks as well. That said, while the lack of cohesion due to decentralised nature of Emacs development occasionally surfaces like this, I think it would be unfair to not mention that org-mode when not buggy - which is more often than not - makes a lot of great features accessible. For instance, it automatically connects to Postgres, runs my query fragment, and populates an org-mode table (which are awesome) with the resulting output - I find this feature invaluable.
Oh and if you are a Spacemacs user, perhaps give Doom Emacs a try.
I do use Spacemacs. Do you have an advice about how to install sql-indent there? I'll find it one way or another, just wondering if you have experience. I think I can do the rest quite fine (already mastered setting those vars in Spacemacs, thankfully).
As for Doom Emacs, I am mentally way too fatigued by learning new tools almost every day. :(
I hear that it can be kind of like Spacemacs but it requires quite a bit more manual management which I am not a fan of. Do you have any experience confirming or refuting this impression of mine.
Very thankful for the links, I'm currently going through them.
I did try Doom Emacs though. I felt it was usable right out of the box with nice defaults. But then again I haven't used it for a serious time length (I prefer Emacs keybinding, rare I know).
I also empathise with tool fatigue. I haven't significantly touched my Emacs config in a while, been in strictly bug fixing mode. That does mean I shouldn't update major version of Emacs, or the packages, but I sometimes do that anyway :/
Last time I blindly updated Spacemacs itself I lost an hour getting it back to a workable state, sigh. Learned my lesson since then. I do both: (a) completely back up my ~/.emacs.d to another directory and (b) write down the last-known GIT commit hash of Spacemacs. Paid off huge dividends half the time I did updates ever since.
I love Emacs but it seems certain things won't ever get resolved (like macOS slow rendering although that's like 70% attributed to huge fonts with a lot of emojis in them so I got that part sorted at least).
Again, thanks for the support -- much appreciated! I'll go through the links plus will try to resolve my Org Mode problem in particular -- eventually.
I am using it with Spacemacs so there's likely something there.
I love Emacs but after ~18 years with it it's basically a death by a thousand paper cuts. It gets tiring to always have to fight for some basic features. :(
Jamstack lists 322 static site generators plus there are probably many homemade solutions using standard unix tools etc. I am wondering if there are any unique selling points not yet covered by less than a dozen projects. Fast compilation and zero dependencies seems no fit to that category. Do not get me wrong, I really appreciate the creativity and variety of open solution, I am just wondering what it needs to get highly ranked on HN. In this case, it is because of the "Rust" keyword?
Super fast. Simple for most usecases. Integrated feed support (Atom). Good-enough translations system. These points may be true for other SSGs as well, but they're personally why i ended up using zola.
As someone who authored one of thoses 322 SSGs, I wonder the same thing :)
It's just a really fun project to work on, quite easy to get something working and the result, even if it sucks, is almost immediately useful for anyone who needs a SSG. It may suck but you know exactly how it works.
Some of us get too excited and actually end up making something other people also want to use.
I think its because of the javascript problem: every second user of a product gets invested enough in the problem space they can't resist making just one tiny modifications. Then six weeks later there they are, editing a video for the homepage of their own project that does the same as the first product but in "their own voice".
I guess if you did it right, you could be static site generator agnostic, or at least cover a variety of popular ones. What would change? Commands to send, directory structure, flavour of templates/markdown?
Nothing is actively stopping it. In fact a lot of people would strongly appreciate it, maybe even contribute. I would really love to see something like that:
- local-first CMS with a strong emphasis on folders/files
- multiple DVCS integrations (git, mercurial, pijul) with commit signatures (PGP)
- support for forge APIs and email-based workflow to simplify the cooperative PR/MR/patch process
- strong translations support, to see at a glance missing/outdated translations
There's been some work in this area, but netlify is really complex and is not meant to be selfhosted. And in any case these CMS overlays for SSGs end up making their own conventions that SSGs then have to comply with. It would be interesting to see an alternative approach where a CMS-as-a-library can be adapted to support any kind of SSG.
Some complicated stuff to deal with when building a content editor for SSGs:
- internal and relative links don't have the same semantics across SSGs, and don't point to the same place depending on the webroot
- content may contain macros/shortcodes, the local editor needs to be aware of that in order to produce meaningful output
- taxonomies and parenthood relationships also vary greatly from one implementation to another
*Take the following with a grain of salt. I've not used this product in production as of yet. I just started investigating it a few weeks ago.*
Statamic sort of fits in this discussion. It's a flat file cms that is by default deployed similarly to wp, but it has 2 distinct use cases that separate it a bit.
1. you can use their ssg module to do ssg things and just use their cms as, well, the cms. you can do this locally and just push the output to your favorite web server.
2. if you are familiar with laravel development, you can drop it in an existing laravel application with minimal effort.
Thanks for the suggestion. i just checked it out and it's not free software so it's not a viable solution unfortunately. There's dozens of startups offering a similar service. What would be interesting is a community-oriented, free-software initiative.
I think it would be cool if it had all that stuff, but also hid the complexity from the users. i.e. wizards to talk them through using an external host via SFTP, or github pages, or wherever.
And if your wp site is fairly large be prepared to go take a nap while it runs. I just installed this plugin on a larger site and it's still churning 30 minutes in.
On the flip side, we run a custom cms with hugo as the SSG on a much larger site and it builds and deploys in under a minute.
WP has it's uses, but speedy sites are not a focus.
This looks really neat. The first thing I look for now after using several different static generators is how they handle images (and other static media, but images are most important since they need optimizing). I'm going to give this project a try!
Next.js is wonderful, but I've had a crazy amount of pain because `<Image>` can't be used if you want to export to purely static (which I strongly prefer), and other options seem to have died (if anybody has one they use or maintain, please let me know!!). I've ended up rolling my own solution in bash that uses Squoosh to crank out set sizes and the like, but it's gross and not useful for others that aren't me, which is a problem when I have to collaborate.
I'm using Hugo, but was looking at Zola earlier today.
It's great to see that they're looking to support next-generation image formats. They're not in Hugo, as a requirement seems to be that dependencies are all fully written in Go, no use of bindings. It's a sensible decision from a maintenance perspective, but still unfortunate.
What Hugo does have, and for which I couldn't find an alternative for in Zola, is something akin to `esbuild` that can build and bundle JavaScript and TypeScript. Is there some way to do this with Zola or does one need to setup a separate build step for that with e.g. `swc`?
> What Hugo does have, and for which I couldn't find an alternative for in Zola, is something akin to `esbuild` that can build and bundle JavaScript and TypeScript. Is there some way to do this with Zola or does one need to setup a separate build step for that with e.g. `swc`?
Not right no. My issue with that is usually people that want a JS build system will want webpack, loaders and other JS dependencies to also work. You end up just executing webpack command from the SSG while the user could just run it themselves, without a layer.
Tangential Related: how do people use static site generators (SSG) when they have more than 1 team member who's publishing site updates? Are they having the SSG trigger off of a git push?
Zola has instructions for how to set up git -> site update automation to Netlify or Vercel through GitHub or GitLab. I setup that process to try that out on both for a website for a local org I volunteer for and it was quick to get going. Not sure how easy a non-technical user might find updates though.
Many people will have a Github Pages or GitLab Pages setup where their static website is hosted by Github or GitLab and generated by their respective continuous integration tools to automagically update the website upon pushing to the repository.
Do you mean in the case of near-simultaneous commits? Continuous Integration (CI) can be setup to build each commit or abandon a build if a newer commit comes in, and then the deploy step would use the latest build available.
After getting sufficiently pissed off at jekyll (I'm not a ruby developer, so dealing with ruby related tooling is a pain every time I need to) I realised that what I wanted was literally just a basic templating engine. I already use one of those pretty often - the c preprocessor. My personal website is just cpp macros / #includes now, and I honestly find it much more productive.
Definitely going to give this one a spin. I was looking around yesterday for a static blog generator and was frustrated with the complexity of many offerings.
A few months ago I tried my hand at this because it had some better defaults. Also, I didn't like camel case variables everywhere in Hugo. Then, I gave up when I realised that Zola does not even allow YAML config files. Nit picks everywhere..
Hey there's some healthy skepticism about YAML on zola's side. In particular, the maintainer believes encouraging people to use a broken/dangerous (in terms of remote-code execution in some implementations) serialization format is not a good idea, even though Rust YAML parser is safe from that.
There's also a concern for maintenance: maintaining the zola codebase to support more serialization formats is more work. If more contributors get involved regularly, it will be less of a problem.
In fact, zola started supporting YAML frontmatter for compatibility reasons lately, but it's explicitly stated in the docs this is not the recommended/supported way to do things.
The name sounds like the Chinese phrase "zou le" which means something like "walked away" or "gone". Kind of appropriate since it's supposed to get out of you way.
There are a lot of homonyms with English and Chinese that you won't get from typical dictionary searches because even the romanized spelling is completely different.
I am not a professional front-ender. I will tell you my experience with all the SSG I have tried.
OK,cool, let's read the documentation.OK , first example, clone this template and blah blah. The template is always like 4 versions behind (the same for 90% of the templates that can be downloaded). Even doing the most simple change it is a pain,it almost feels black-boxy. At that moment I gave up and go back to simple JS/CSS with React if needed.
Among that lot the one which seems the sanest is Next and even then it is too opinionated for my taste.
Anyway, I liked this line from the Github:
> Hugo gets ehh for the template engine because while it is probably the most powerful template engine in the list (after Jinja2) it personally drives me insane, to the point of writing my own template engine and static site generator. Yes, this is a bit biased.
This seems to be the life cycle of static site generators (SSG). It works at first, but you end up wanting to design your own custom SSG once you run up against something that goes against your mental model of how things should work.
I did this exact thing when I got frustrated with Hugo. I made my own custom SSG in order to create my blog.
The other thing that tends to happen with SSGs is that it can be a lot more fun to play around with the tech than actually writing blog posts!
If you're interested you can read here to see how I made an SSG for my blog:
https://joelregus.com/posts/blog/index.html