6 ms·

Check out https://www.getzola.org https://www.getzola.org. It's a single executable. It even does syntax highlighting (without using client-side javascript).

Check out https://www.getzola.org https://www.getzola.org. It's a single executable. It even does syntax highlighting (without using client-side javascript). I moved to it from Jekyll/Hugo, because I hate dealing with Ruby and dependencies like you!

bacondude3 6y ago
Thanks for the suggestion! Some of the other commenters have pointed out that Hugo also has standalone binaries, I just didn't notice them last time I looked. What made you choose Zola over Hugo?
- rudedogg 6y ago
  I think the main reason was the built in syntax highlighting, and simplicity. I've decided to move away from themes, and just code simple CSS by hand - so Zola kind of fits that mindset. Hugo definitely has more features. If you think you'll want to do some complex hierarchies in your blog/site, or want a lot of themes to pick from I'd go with Hugo. Hopefully that helps! Edit: I think Hugo used to require Pygments (a pip package), but it looks like that's no longer the case. If it did that probably nudged me towards Zola too.
maybevain 6y ago
I really enjoyed Zola as well. It's sufficiently simple that the learning curve is really gentle but has just enough features to cover all my needs for a static site. Coupling it with Tailwind for styling meant that developing the theme was really smooth (slowest part of changing a template was waiting for the browser to refresh, i.e. < 1s).
b0rsuk 6y ago
There seems to be apathy in Rust community towards using client-side js for syntax highlighting. Rust documentation and The Rust Book uses it for no good reason. Code in examples doesn't change, and the way they are highlighted doesn't change. In my opinion it clashes with the philosophy of the language - that as much as possible should be done before the code is run. Aside from my pedantry, it causes computers to make more unnecessary computations and our civilization emits more carbon. It also affects me because I currently have an old CPU and it takes a few seconds for syntax highlighting to kick in. Every time I press "Back" in my browser, syntax highlighting needs to be recalculated as well. Oh well, on the bright side I have an itch to scratch :-).
- zimpenfish 6y ago
  > Code in examples doesn't change, and the way they are highlighted doesn't change. I'd consider it an accessibility issue - hardcoding the syntax highlighting on the backend makes it more difficult for people to change using accessibility tools. Whereas with js-based highlighting, you can probably just change the theme and get readable output.
  - iudqnolq 6y ago
    If you used semantic class names you could change the theme with just css.
  - detaro 6y ago
    What kind of accessibility tools are you thinking of that would work with JS highlighting, but not server-generated? (Given that generally both would produce roughly the same in-browser DOM, which is what most modern accessibility tools work against)
    - iudqnolq 6y ago
      You seem to be describing accessibility tools for completely blind users, and I think they were describing accessibility tools for users with other sorts of disabilities. For example, someone who uses a custom stylesheet or a browser extension to make the page have higher contrast.
      - detaro 6y ago
        No, the question applies to those just as much.
        iudqnolq 6y ago
        As far as I know, parsing the accessibility tree is primarily limited to screen readers / brail displays. Am I missing something?

bacondude3 6y ago

Thanks for the suggestion! Some of the other commenters have pointed out that Hugo also has standalone binaries, I just didn't notice them last time I looked. What made you choose Zola over Hugo?

rudedogg 6y ago
I think the main reason was the built in syntax highlighting, and simplicity. I've decided to move away from themes, and just code simple CSS by hand - so Zola kind of fits that mindset. Hugo definitely has more features. If you think you'll want to do some complex hierarchies in your blog/site, or want a lot of themes to pick from I'd go with Hugo. Hopefully that helps! Edit: I think Hugo used to require Pygments (a pip package), but it looks like that's no longer the case. If it did that probably nudged me towards Zola too.

maybevain 6y ago

I really enjoyed Zola as well. It's sufficiently simple that the learning curve is really gentle but has just enough features to cover all my needs for a static site. Coupling it with Tailwind for styling meant that developing the theme was really smooth (slowest part of changing a template was waiting for the browser to refresh, i.e. < 1s).

b0rsuk 6y ago

There seems to be apathy in Rust community towards using client-side js for syntax highlighting. Rust documentation and The Rust Book uses it for no good reason. Code in examples doesn't change, and the way they are highlighted doesn't change. In my opinion it clashes with the philosophy of the language - that as much as possible should be done before the code is run. Aside from my pedantry, it causes computers to make more unnecessary computations and our civilization emits more carbon. It also affects me because I currently have an old CPU and it takes a few seconds for syntax highlighting to kick in. Every time I press "Back" in my browser, syntax highlighting needs to be recalculated as well. Oh well, on the bright side I have an itch to scratch :-).

zimpenfish 6y ago
> Code in examples doesn't change, and the way they are highlighted doesn't change. I'd consider it an accessibility issue - hardcoding the syntax highlighting on the backend makes it more difficult for people to change using accessibility tools. Whereas with js-based highlighting, you can probably just change the theme and get readable output.
- iudqnolq 6y ago
  If you used semantic class names you could change the theme with just css.
- detaro 6y ago
  What kind of accessibility tools are you thinking of that would work with JS highlighting, but not server-generated? (Given that generally both would produce roughly the same in-browser DOM, which is what most modern accessibility tools work against)
  - iudqnolq 6y ago
    You seem to be describing accessibility tools for completely blind users, and I think they were describing accessibility tools for users with other sorts of disabilities. For example, someone who uses a custom stylesheet or a browser extension to make the page have higher contrast.
    - detaro 6y ago
      No, the question applies to those just as much.
      - iudqnolq 6y ago
        As far as I know, parsing the accessibility tree is primarily limited to screen readers / brail displays. Am I missing something?