[HN Gopher] Zola: A fast static site generator in a single binary
___________________________________________________________________
Zola: A fast static site generator in a single binary
Author : ibraheemdev
Score : 188 points
Date : 2021-03-05 14:49 UTC (8 hours ago)
(HTM) web link (www.getzola.org)
(TXT) w3m dump (www.getzola.org)
| freedomben wrote:
| 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!
| stusmall wrote:
| 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.
| vyuh wrote:
| 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..
| jacques_chester wrote:
| 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.
| southerntofu wrote:
| > 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
| jacques_chester wrote:
| 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.
| southerntofu wrote:
| 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?
| jacques_chester wrote:
| 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.
| Keats wrote:
| 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.
| esperent wrote:
| 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.
| mroche wrote:
| > _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.
| regus wrote:
| 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.
| mroche wrote:
| > _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!
| dangoor wrote:
| 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.
| dagmx wrote:
| I've been using Gatsby recently and it's been pretty good, as
| long as you're not opposed to node and JS.
| smt88 wrote:
| 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?
| egeozcan wrote:
| (not op) I personally love next.js but I guess it'd bee too
| flexible for some.
| cercatrova wrote:
| 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
| dagmx wrote:
| 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.
| ibraheemdev wrote:
| What sort of templating support did you find to be scarce with
| Zola?
| mitchmindtree wrote:
| 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/
| pdimitar wrote:
| 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.
| southerntofu wrote:
| > 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/
| pdimitar wrote:
| 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.
| southerntofu wrote:
| > 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.
| pdimitar wrote:
| > _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:
| /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
|
| ^ The above describes only 3 articles, one of each has no
| revisions (why-i-left-ruby.html), one of them has two
| revisions (resume) and another has three (reasons-to-
| choose-rust-in-2021).
|
| However, I am just talking out of my a$$ and can't
| comment if this is easy to integrate or what complexity
| and repercussions would it have to the otherwise free-
| form directory/file structure that Zola encourages.
|
| I am simply illustrating what I would be after.
| Keats wrote:
| > 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).
| pdimitar wrote:
| > _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.
| loughnane wrote:
| I just got my site up with hugo... must resist the urge to poke
| around with another ssg
| possibleworlds wrote:
| 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
| mdpopescu wrote:
| Out of curiosity, why is it "endblock content" everywhere but the
| base.html page (where it's just "endblock")?
| bob1029 wrote:
| 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.
| cambalache wrote:
| 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.
| gadders wrote:
| What is stopping someone writing an offline GUI for a static site
| generator? I think that would help a bit with non-technical
| adoption.
| southerntofu wrote:
| 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
| cujo wrote:
| *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/
| southerntofu wrote:
| 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.
| gadders wrote:
| 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.
| kam wrote:
| 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.
| laurent123456 wrote:
| If you can run a local web server, WordPress has a static site
| generator: https://wordpress.org/plugins/simply-static/
| cujo wrote:
| 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.
| alberth wrote:
| 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?
| harlanji wrote:
| 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.
| stusmall wrote:
| 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.
| kylenoteboom wrote:
| 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]
| ibraheemdev wrote:
| Yup, most SSGs have pretty good support for GitHub actions or
| other CI tools.
| digikata wrote:
| 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.
| swayvil wrote:
| 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.
| CarVac wrote:
| I use Zola for my project website. It's quite simple to use.
| axyz wrote:
| 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
| cpach wrote:
| 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.
| cercatrova wrote:
| > 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.
| ibraheemdev wrote:
| I doubt people who want to avoid javascript will use a
| javascript based static site builder.
| ThePadawan wrote:
| 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"
| cercatrova wrote:
| 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
| dsr_ wrote:
| 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.
| bookmarkable wrote:
| 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.
| cpach wrote:
| There are starting to appear lots of interesting tools in that
| space.
|
| See e.g. https://www.sanity.io/ or https://www.contentful.com/
| badsectoracula wrote:
| 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/
| southerntofu wrote:
| 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
| xemoka wrote:
| I run a few (well, one published, one in the works, a couple one-
| offs for student showcases) websites built with Zola. It's a
| great, little, simple piece of software.
|
| What I like: * Already supports the tooling I
| enjoy - SCSS out of the box, django/jade-like template engine
| (Terra, its sister project), markdown w/ TOML frontmatter
| * Fast - build times are almost instant, dev server builds to
| memory and does live-reload * Gets out of your way - it
| doesn't do more than it can, yet provides enough to work
| * Builds a search index for client-side searching if needed
| * Single Binary - I can pass the executable around with the repo
| and installation and environments are not an issue (ruby and
| python are painful for part-time developers it seems, at least
| with my non-developer academic peers).
|
| I like that it provides a simple base to build on. I have one
| site that uses webpack to generate bundles for a couple JS files
| to allow for modern JS (babel) - all I have to use webpack for is
| JS, Zola handles the rest.
|
| I migrated our Django theme for our previous site in an
| afternoon. I've found that those I work with often don't really
| understand how formatting in a CMS will apply in the published
| result, and often have to go back in and edit their pages for
| conformance - If I have to touch it anyway, I'd rather do it in
| markdown myself, something I enjoy using.
|
| I have students/interns who have picked up markdown faster than
| any other markup or CMS. I've tried mezzanine [^meh] and wagtail
| [^excellent, but heavy for our brochure-ware] in python,
| wordpress is a pain [^either too flexible, or not flexible
| enough, research interns don't easily see how complex theme
| interactions occur] and some others like cockpit [^neat but
| flexible to a fault, yet too rigid for how free-form folks want
| to interact with it]. Markdown is translatable, and usable in
| other tools: it's a great common denominator with a very low bar
| for entry. Students continue to use it after first interacting
| with it on these projects after they've left.
|
| What I'm missing: * a way to build from an API
| endpoint instead of markdown, i.e.: point to an endpoint to get
| the section list, build children as pages. Then I could use
| content from a postgrest instance, or build it from a list of
| remote markdown files... (no, I haven't really thought this
| through very well)
|
| YMMV.
| ibraheemdev wrote:
| > 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...
| xemoka wrote:
| 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.
| cercatrova wrote:
| 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?
| [deleted]
| regus wrote:
| I though this was about the wedding registry site at first.
|
| Anyway, I liked this line from the Github:
|
| _> Hugo gets ehh for the template engine because while it is
| probably the most powerful template engine in the list (after
| Jinja2) it personally drives me insane, to the point of writing
| my own template engine and static site generator. Yes, this is a
| bit biased._
|
| This seems to be the life cycle of static site generators (SSG).
| It works at first, but you end up wanting to design your own
| custom SSG once you run up against something that goes against
| your mental model of how things should work.
|
| I did this exact thing when I got frustrated with Hugo. I made my
| own custom SSG in order to create my blog.
|
| The other thing that tends to happen with SSGs is that it can be
| a lot more fun to play around with the tech than actually writing
| blog posts!
|
| If you're interested you can read here to see how I made an SSG
| for my blog:
|
| https://joelregus.com/posts/blog/index.html
| brainzap wrote:
| I use hugo but a script that converts my folder based writing
| style to Hugo markdowns, before build
| valvar wrote:
| 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/
| CJefferson wrote:
| 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.
| chrisweekly wrote:
| JSX (or even MDX) might fit the bill!
| dukeyukey wrote:
| Careful, you might end up with PHP.
| mikepurvis wrote:
| 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.
| Yoofie wrote:
| 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.
| mikepurvis wrote:
| I mean, it used to literally stand for _Personal Home Page_
| , so it sounds like you're using it for its original
| purpose.
| akvadrako wrote:
| Python has had mako for a long time, which does this.
| ibraheemdev wrote:
| JSX seems to fit that bill, and many other languages have a
| comparable library.
| xfer wrote:
| racket scribble might be of interest to you.
| https://docs.racket-lang.org/scribble/
| laurent123456 wrote:
| 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.
| pembrook wrote:
| > 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."
| jacques_chester wrote:
| > _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/
| remexre wrote:
| 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...
| Lammy wrote:
| > 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-...
| bachmeier wrote:
| 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.
| temp8964 wrote:
| 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.
| bccdee wrote:
| 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.
| temp8964 wrote:
| 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.
| Keats wrote:
| > 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.
| brundolf wrote:
| The thing about an SSG is that it's so trivial to write your
| own (at least for the basic cases). And then you may well get
| more benefit after that point from retaining the ability to
| customize it than you would from having a generalized one that
| you need to wrestle toward your use-case
|
| It's something that _feels_ highly generic, and so programmers
| jump on the chance to genericize it, but may not actually be
| that useful to have as a thing you can grab off the shelf
| the_arun wrote:
| 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/
| chrisweekly wrote:
| NextJS is (by far) the best of the bunch, because it isn't
| limited to SSG.
| spf13 wrote:
| 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.
| waterside81 wrote:
| 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.
| baxtr wrote:
| Hey there, I'm a happy Jekyll user. What frustrated you about
| it?
| regus wrote:
| 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.
| kcartlidge wrote:
| 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.
| mbreese wrote:
| 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.
| patrickmcnamara wrote:
| 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.
| michaelbuckbee wrote:
| There are legit services/plugins that do this with Wordpress
| for similar reasons.
| NotPavlovsDog wrote:
| 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.
| egeozcan wrote:
| Why not varnish then?
| patrickmcnamara wrote:
| 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.
| vidarh wrote:
| 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.
| patrickmcnamara wrote:
| Yep, exactly. Wget can do this with the --recursive flag.
| minitoar wrote:
| Perhaps we need a meta ssg. An ssgg if you will. Perhaps a dsl
| for specifying ssgs.
| mynegation wrote:
| I believe Metalsmith [1] is trying that approach
|
| [1] https://metalsmith.io/
| pinjasaur wrote:
| 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
| StavrosK wrote:
| SSGG*
| yoz-y wrote:
| 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.
| threatofrain wrote:
| I guess Racket's proposal of language oriented programming
| isn't so kooky after all.
| threepio wrote:
| Pollen, written in Racket, is arguably a "dsl for
| specifying ssgs"
|
| https://docs.racket-lang.org/pollen/
| mdtusz wrote:
| 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.
| pvorb wrote:
| Don't mess around with Markdown and LaTeX for
| documentation. AsciiDoc is what you want.
| threepio wrote:
| This is a sample Pollen project, annotated by the author
| using Racket's literate-programming dialect.
|
| https://docs.racket-lang.org/pollen-tfl/
| irrational wrote:
| Are we all thinking of the same xkcd comic at this point?
| pvorb wrote:
| 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.
| jeromenerf wrote:
| 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.
| pdimitar wrote:
| 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.
| jeromenerf wrote:
| 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.
| pdimitar wrote:
| 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. :(
| natrys wrote:
| 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:
| (setq org-src-tab-acts-natively t) (setq org-src-
| preserve-indentation t) (setq org-src-fontify-natively
| t)
|
| And yes, I wasn't amused by this. I had another problem with
| shell mode indentation in org source blocks as well. That
| said, while the lack of cohesion due to decentralised nature
| of Emacs development occasionally surfaces like this, I think
| it would be unfair to not mention that org-mode when not
| buggy - which is more often than not - makes a lot of great
| features accessible. For instance, it automatically connects
| to Postgres, runs my query fragment, and populates an org-
| mode table (which are awesome) with the resulting output - I
| find this feature invaluable.
|
| Oh and if you are a Spacemacs user, perhaps give Doom Emacs a
| try.
|
| [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
| pdimitar wrote:
| 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.
| natrys wrote:
| Sorry I am not a user of either. I think this might be it
| for Spacemacs:
|
| https://www.spacemacs.org/doc/DOCUMENTATION.html#orgheadl
| ine...
|
| 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 :/
| pdimitar wrote:
| 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.
| imjasonmiller wrote:
| 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`?
| Keats wrote:
| > 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.
| imjasonmiller wrote:
| Ah, a familiar name! Thank you for taking the time to answer.
| I'll look into it, maybe I can get it to work.
| smartmic wrote:
| 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?
| ibraheemdev wrote:
| What "Rust" keyword? The word "Rust" is not included in the
| title, or anywhere on the home page.
| endisneigh wrote:
| 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?
| ibraheemdev wrote:
| I really doubt it. ( _sigh, even if you don 't mention Rust
| anywhere, people always bring this up_)
| SiempreViernes wrote:
| 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".
| southerntofu wrote:
| > 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.
| brabel wrote:
| 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.
| wheybags wrote:
| 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
| lqet wrote:
| I see your single binary static site generator and raise you a
| single Makefile static site generator:
|
| https://github.com/patrickbr/hagel
___________________________________________________________________
(page generated 2021-03-05 23:01 UTC)