Earlier quoted context omitted.
> 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 doubt people who want to avoid javascript will use a javascript based static site builder.
Zola: A fast static site generator in a single binary
51–60 of 177 posts
Re: Zola: A fast static site generator in a single binary
#52I 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.
Am I missing something? Org Mode is always so glorified yet it failed a pretty basic use case for me.
Re: Zola: A fast static site generator in a single binary
#53I 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 generat…
Re: Zola: A fast static site generator in a single binary
#54I 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+…
Re: Zola: A fast static site generator in a single binary
#55Tangential 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?
Re: Zola: A fast static site generator in a single binary
#56I 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 generat…
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.
Re: Zola: A fast static site generator in a single binary
#57I 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 generat…
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-...
Re: Zola: A fast static site generator in a single binary
#58I 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 generat…
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.
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.
Re: Zola: A fast static site generator in a single binary
#59What is stopping someone writing an offline GUI for a static site generator? I think that would help a bit with non-technical adoption.
If you can run a local web server, WordPress has a static site generator: https://wordpress.org/plugins/simply-static/
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.
Re: Zola: A fast static site generator in a single binary
#60What is stopping someone writing an offline GUI for a static site generator? I think that would help a bit with non-technical adoption.
- 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