Zola: A fast static site generator in a single binary(getzola.org)
getzola.org
Zola: A fast static site generator in a single binary
https://www.getzola.org/
176 comments
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.
Happy to see some Hugo ideas made it into Zola.
Happy to see some Hugo ideas made it into Zola.
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.
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.
I prefer ray-tracers (or other rendering or physics engines), maybe because I'm old or have nothing to blog about.
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.
Edit: noticed you make Cobra too! Damn - I owe you like 1000 man hours of saved work.
spf13, thank you for your vim config, I have been using it for years!
In regards to Hugo, I enjoyed using it at first, I loved how fast it was, but I kept running into issues so I decided to make my own SSG.
In regards to Hugo, I enjoyed using it at first, I loved how fast it was, but I kept running into issues so I decided to make my own SSG.
Hey there, I’m a happy Jekyll user. What frustrated you about it?
Jekyll lost me at “step one, install ruby”
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.
Even shared hosting at the time came with ruby on rails support. Maybe it still does, but ruby was way more popular at the time in general.
Thanks for making Hugo. Hugo is the only SSG I found with a good story regarding i18n.
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.
I absolutely love Hugo and as someone who was completely new to static site generators, it was the easiest to pick up and use in my opinion. Thanks!
> I though this was about the wedding registry site at first.
I didn't even know what a wedding registry was until after the rename. It is named after https://fr.wikipedia.org/wiki/%C3%89mile_Zola
> 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.
I didn't even know what a wedding registry was until after the rename. It is named after https://fr.wikipedia.org/wiki/%C3%89mile_Zola
> 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.
Perhaps we need a meta ssg. An ssgg if you will. Perhaps a dsl for specifying ssgs.
I guess Racket’s proposal of language oriented programming isn’t so kooky after all.
Pollen, written in Racket, is arguably a "dsl for specifying ssgs"
https://docs.racket-lang.org/pollen/
https://docs.racket-lang.org/pollen/
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.
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.
This is a sample Pollen project, annotated by the author using Racket's literate-programming dialect.
https://docs.racket-lang.org/pollen-tfl/
https://docs.racket-lang.org/pollen-tfl/
Don't mess around with Markdown and LaTeX for documentation. AsciiDoc is what you want.
Your post changed my life. Thanks for sharing this about AsciiDoc. It's such a nice tool.
I believe Metalsmith [1] is trying that approach
[1] https://metalsmith.io/
[1] https://metalsmith.io/
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.
[1] https://github.com/Pinjasaur/project-scaffolder
[1] https://github.com/Pinjasaur/project-scaffolder
SSGG*
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.
Are we all thinking of the same xkcd comic at this point?
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
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.
Careful, you might end up with PHP.
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.
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.
JSX seems to fit that bill, and many other languages have a comparable library.
racket scribble might be of interest to you. https://docs.racket-lang.org/scribble/
JSX (or even MDX) might fit the bill!
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.
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.
I mean, it used to literally stand for Personal Home Page, so it sounds like you're using it for its original purpose.
It drives me nuts when people implement template languages on top of PHP. That was its purpose.
Python has had mako for a long time, which does this.
Clojure hiccup: https://github.com/weavejester/hiccup
We don't need to create one if we do not like Hugo. There are other SSGs like Hugo. Jekyll, Gatsby, etc., More here https://jamstack.org/generators/
NextJS is (by far) the best of the bunch, because it isn't limited to SSG.
They are not the right comparison, but we get your point.
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!
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.
Why not varnish then?
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.
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.
Yep, exactly. Wget can do this with the --recursive flag.
There are legit services/plugins that do this with Wordpress for similar reasons.
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.
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.
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.
[0] - https://vnord.net/post/hugo/
[0] - https://vnord.net/post/hugo/
Yep, I got frustrated with Zola, ended up maintaining a couple patches, and eventually ended up writing my own (ad hoc, not generally usable) SSG...
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 :)
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 :)
Already tried; patch that lead to the fork was "not adding this feature," sadly.
> 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-...
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.
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.
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!
This has been my experience also[0]. Instead of writing I wound up a side quest to see if I could get Project Mallard[1] to do what I wanted.
[0] https://twitter.com/jacques_chester/status/13440340126086184...
[1] http://projectmallard.org/
This has been my experience also[0]. Instead of writing I wound up a side quest to see if I could get Project Mallard[1] to do what I wanted.
[0] https://twitter.com/jacques_chester/status/13440340126086184...
[1] http://projectmallard.org/
> 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."
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.
I use hugo but a script that converts my folder based writing style to Hugo markdowns, before build
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.
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.
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.
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.
> why don't you just use WordPress?
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).
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).
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:
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:
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 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)
> a way to build from an API endpoint instead of markdown
Sounds like remote content[0] might work for that?
0: https://www.getzola.org/documentation/templates/overview/#re...
Sounds like remote content[0] might work for that?
0: https://www.getzola.org/documentation/templates/overview/#re...
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.
Again, maybe I haven’t thought about this enough yet.
> 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.
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.
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]
[1] https://github.com/getzola/zola/issues/977 [2] https://zola.discourse.group/t/rfc-internationalization-syst... [3] https://github.com/getzola/zola/pull/1373
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]
[1] https://github.com/getzola/zola/issues/977 [2] https://zola.discourse.group/t/rfc-internationalization-syst... [3] https://github.com/getzola/zola/pull/1373
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.
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].
[1] https://www.11ty.dev
[2] https://github.com/GoogleChrome/web.dev
[1] https://www.11ty.dev
[2] https://github.com/GoogleChrome/web.dev
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.
[1] https://mtm.dev/static
[2] https://mtm.dev/eleventy-social-sharing-images
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.
[1] https://mtm.dev/static
[2] https://mtm.dev/eleventy-social-sharing-images
The main template engine 11ty suggests is Nunjucks, which requires you to trust the template author. https://www.11ty.dev/docs/layouts/ https://mozilla.github.io/nunjucks/templating.html#user-defi...
Zola uses a similar template language called Tera that seems to be a lot safer.
Zola uses a similar template language called Tera that seems to be a lot safer.
On the topic of SSGs, is anyone using styx[1]?
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.
[1]: https://styx-static.github.io/styx-site/ [2]: https://github.com/styx-static/styx/
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.
[1]: https://styx-static.github.io/styx-site/ [2]: https://github.com/styx-static/styx/
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?
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?
[deleted]
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.
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.
[0] https://getpublii.com/
[1] http://runtimeterror.com/devlog/
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.
[0] https://getpublii.com/
[1] http://runtimeterror.com/devlog/
There are starting to appear lots of interesting tools in that space.
See e.g. https://www.sanity.io/ or https://www.contentful.com/
See e.g. https://www.sanity.io/ or https://www.contentful.com/
Everybody seems to be trying that right now!
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)
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)
> Between Wix and Zola is an opportunity, in my opinion.
I strongly agree. There's plenty of niche proprietary tools like that, however i don't know of a collaborative, free-software solution like that.
I strongly agree. There's plenty of niche proprietary tools like that, however i don't know of a collaborative, free-software solution like that.
RapidWeaver [1] is a WYSIWYG SSG for Mac. I used it a few years ago and it was pretty good back then.
[1] https://www.realmacsoftware.com/rapidweaver/
[1] https://www.realmacsoftware.com/rapidweaver/
Blocs app (Mac only) is another alternative. You can even build WordPress themes with it.
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
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
> Zola seem the most popular static site generator that allows you to generate a website without any JS bundle without using some strange hack.
I'd say Gatsby or NextJS are more popular due to being written in JS. They can both produce zero JS websites.
I'd say Gatsby or NextJS are more popular due to being written in JS. They can both produce zero JS websites.
I doubt people who want to avoid javascript will use a javascript based static site builder.
I made that choice, based on two completely separate wishes:
- "I want my visitors to be able to view this static page without enabling JS" and
- "I already know React, I might as well just write this in TSX"
- "I want my visitors to be able to view this static page without enabling JS" and
- "I already know React, I might as well just write this in TSX"
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.
[0] https://news.ycombinator.com/item?id=26358978
[0] https://news.ycombinator.com/item?id=26358978
Isn't that a bit like saying that people who want small web pages wouldn't want to use hugo, as it's a 60 megabyte binary?
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.
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 use Hugo and I have zero Javascript on my static site(s).
I didn’t use any existing theme though. I just added ~30 lines of HTML/template markup. No theme needed really, not for my purposes at least.
I didn’t use any existing theme though. I just added ~30 lines of HTML/template markup. No theme needed really, not for my purposes at least.
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 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.
> by using Go's horrible templating minilanguage
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.
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.
I've used Go's templating a few times, most recently I used it in my own static site generator.
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.
The documentation is hard read and not always clear on how things are supposed to work.
For example:
- If I pass in a struct that contains a map of structs, how exactly can I access this data?
- How can I use the boolean output of a function within an if statement?
- How do the if statements even work? "eq"? "=="? What is the correct syntax here?
I ended up losing a lot of time having of to wrestle with the templating engine because it often would not behave the way I expected it to.
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.
The documentation is hard read and not always clear on how things are supposed to work.
For example:
- If I pass in a struct that contains a map of structs, how exactly can I access this data?
- How can I use the boolean output of a function within an if statement?
- How do the if statements even work? "eq"? "=="? What is the correct syntax here?
I ended up losing a lot of time having of to wrestle with the templating engine because it often would not behave the way I expected it to.
> 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!
Ah, I see. At my first glance I thought it was just normal Go syntax. I’ll have to look into this more, thanks!
> support for its templating language is scarce
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
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.
You can compile Tera to WASM if you want but that's the only solution if you want to use Tera templates outside of Rust.
As mentioned, it is _extremely_ similar to Jinja2 in Python, a good number of Jinja2 templates should be valid Tera and vice-versa.
As mentioned, it is _extremely_ similar to Jinja2 in Python, a good number of Jinja2 templates should be valid Tera and vice-versa.
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).
If i may, what's your usecase?
If i may, what's your usecase?
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.
zola should be really fit for that, let us know if you encounter any issues
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.
I've been using Gatsby recently and it's been pretty good, as long as you're not opposed to node and JS.
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...)
What else did you try before landing on Gatsby?
What else did you try before landing on Gatsby?
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.
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 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.
(not op) I personally love next.js but I guess it'd bee too flexible for some.
What sort of templating support did you find to be scarce with Zola?
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.
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 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.
> 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. 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.
I'd personally go for something like this:
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 am simply illustrating what I would be after.
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.
I'd personally go for something like this:
/articles/
/reasons-to-choose-rust-in-2021/
+ 2020-01-31.html
+ 2020-02-28.html
+ 2020-03-05.html
why-i-left-ruby.html
/resume/
+ 2019-01-17.html
+ 2020-03-15.html
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 am simply illustrating what I would be after.
> That's precisely why I am keeping silent.
(Author of Zola here)
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.
But for example, the big focus for the next version is better i18n support so feedback/opinions are very welcome: https://zola.discourse.group/t/rfc-internationalization-syst... but it is a big chunk of work so it will take some time.
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).
(Author of Zola here)
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.
But for example, the big focus for the next version is better i18n support so feedback/opinions are very welcome: https://zola.discourse.group/t/rfc-internationalization-syst... but it is a big chunk of work so it will take some time.
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.
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 see your single binary static site generator and raise you a single Makefile static site generator:
https://github.com/patrickbr/hagel
https://github.com/patrickbr/hagel
I use Hugo for projects, it’s plenty powerful and easy to automate with data.
For personal stuff, I use org mode. It’s more free form and provides just enough publishing features.
SSGs seems like popular bikeshedding matter.
For personal stuff, I use org mode. It’s more free form and provides just enough publishing features.
SSGs seems like popular bikeshedding matter.
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.
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:
Oh and if you are a Spacemacs user, perhaps give Doom Emacs a try.
[1] https://github.com/alex-hhh/emacs-sql-indent
[2] https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.2...
[3] https://github.com/hlissner/doom-emacs/issues/3787
[4] https://github.com/alex-hhh/emacs-sql-indent/issues/96
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:
(setq org-src-tab-acts-natively t)
(setq org-src-preserve-indentation t)
(setq org-src-fontify-natively t)
Oh and if you are a Spacemacs user, perhaps give Doom Emacs a try.
[1] https://github.com/alex-hhh/emacs-sql-indent
[2] https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.2...
[3] https://github.com/hlissner/doom-emacs/issues/3787
[4] https://github.com/alex-hhh/emacs-sql-indent/issues/96
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.
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.
Sorry I am not a user of either. I think this might be it for Spacemacs:
https://www.spacemacs.org/doc/DOCUMENTATION.html#orgheadline...
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 :/
https://www.spacemacs.org/doc/DOCUMENTATION.html#orgheadline...
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 :/
Let's hug and cry. :D
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.
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 do edit inline code and I have never had this issue. It is indeed a basic feature that should just work.
Most probably a plug-in bug.
Emacs, org and Babel are great to write “live” documents.
Most probably a plug-in bug.
Emacs, org and Babel are great to write “live” documents.
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. :(
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?
What "Rust" keyword? The word "Rust" is not included in the title, or anywhere on the home page.
https://www.getzola.org/documentation/getting-started/overvi...
You're right that it's not mentioned, but Zola is written in Rust. Perhaps others already knew of this?
You're right that it's not mentioned, but Zola is written in Rust. Perhaps others already knew of this?
I really doubt it. (sigh, even if you don't mention Rust anywhere, people always bring this up)
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".
> any unique selling points
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.
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.
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.
What is stopping someone writing an offline GUI for a static site generator? I think that would help a bit with non-technical adoption.
https://getpublii.com/, though it would be nicer if it were built on one of the more popular static site generators instead of reinventing that wheel.
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
- 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.
https://statamic.com/
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.
https://statamic.com/
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.
Yes, hiding away the complexity from the end-user was implicitly part of my checklist ;)
If you can run a local web server, WordPress has a static site generator: https://wordpress.org/plugins/simply-static/
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.
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.
WP2Static is another option.
https://wp2static.com/
https://wp2static.com/
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.
Anyway, thanks for the project!
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.
Anyway, thanks for the project!
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`?
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.
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.
Ah, a familiar name! Thank you for taking the time to answer. I'll look into it, maybe I can get it to work.
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?
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.
[deleted]
Yup, most SSGs have pretty good support for GitHub actions or other CI tools.
Yup, on a merge into a release branch. Netlify makes that workflow a breeze to set up. Zola also has pretty easy integration with netlify.
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.
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.
I use Zola for my project website. It's quite simple to use.
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.
Probably not to everyone's tastes though :D
Probably not to everyone's tastes though :D
I just got my site up with hugo... must resist the urge to poke around with another ssg
mkdocs is pretty easy and simple too:
pip install --user mkdocs
cd your-markdown-directory/../
echo 'site_name: mysite' > mkdocs.yml
ln -s your-markdown-directory docs
mkdocs build && mkdocs serve
# if you don't like the default theme:
mkdocs build -t readthedocs && mkdocs serve
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.
[deleted]
Out of curiosity, why is it "endblock content" everywhere but the base.html page (where it's just "endblock")?
I believe the two are correct syntax and there's no specific reason to use one over the other.
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.
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.
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.
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.
I do my site with .md files and ParseDown. And a smidge of PHP and CSS.
It's mind bogglingly robust and manageable.
I've tried several "simple CMS" packages. This is way better.
It's mind bogglingly robust and manageable.
I've tried several "simple CMS" packages. This is way better.
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