Live data from Hacker News

Zola: A fast static site generator in a single binary

getzola.org

51–60 of 177 posts

Re: Zola: A fast static site generator in a single binary

#51

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.

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

Re: Zola: A fast static site generator in a single binary

#52

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.

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.

Re: Zola: A fast static site generator in a single binary

#53
post #7

I though this was about the wedding registry site at first. Anyway, I liked this line from the Github: > Hugo gets ehh for the template engine because while it is probably the most powerful template engine in the list (after Jinja2) it personally drives me insane, to the point of writing my own template engine and static site generator. Yes, this is a bit biased. This seems to be the life cycle of static site 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

#54

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+…

[deleted]

Re: Zola: A fast static site generator in a single binary

#55
post #17

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?

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.

Re: Zola: A fast static site generator in a single binary

#56
post #7

I though this was about the wedding registry site at first. Anyway, I liked this line from the Github: > Hugo gets ehh for the template engine because while it is probably the most powerful template engine in the list (after Jinja2) it personally drives me insane, to the point of writing my own template engine and static site generator. Yes, this is a bit biased. This seems to be the life cycle of static site 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.

Careful, you might end up with PHP.

Re: Zola: A fast static site generator in a single binary

#57
post #7

I though this was about the wedding registry site at first. Anyway, I liked this line from the Github: > Hugo gets ehh for the template engine because while it is probably the most powerful template engine in the list (after Jinja2) it personally drives me insane, to the point of writing my own template engine and static site generator. Yes, this is a bit biased. This seems to be the life cycle of static site generat…

> 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-...

Re: Zola: A fast static site generator in a single binary

#58
post #7

I though this was about the wedding registry site at first. Anyway, I liked this line from the Github: > Hugo gets ehh for the template engine because while it is probably the most powerful template engine in the list (after Jinja2) it personally drives me insane, to the point of writing my own template engine and static site generator. Yes, this is a bit biased. This seems to be the life cycle of static site 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.

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.

Re: Zola: A fast static site generator in a single binary

#59
post #16

What 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/

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.

Re: Zola: A fast static site generator in a single binary

#60
post #16

What is stopping someone writing an offline GUI for a static site generator? I think that would help a bit with non-technical adoption.

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

Post reply on HN