Hiya! This tool turns a set of Markdown-formatted recipes into a lightweight, responsive, searchable website for your personal use as a reference while cooking, or for sharing with family and friends. It's not intended as a cooking blog framework: there's no RSS feed, no social sharing buttons, and zero SEO.
Nyum is somewhat opinionated, expecting recipes to be written as a series of steps, each with the relevant ingredients alongside an instruction. I first came across this way of doing it via the cuisine LaTeX package (which I then, many years ago, built a custom LaTeX template around), ending up preferring this structure over the more commonly found all-ingredients-first-then-a-block-of-instructions approach. (In the process of recently graduating from university, I found myself contemporaneously graduating from wanting to use LaTeX for everything, which was part of the impetus for cobbling this thing together.)
1. Up and down arrows for the search box autocomplete don't work.
2. The cornerstone of static sites is their timeless simplicity. The software stack here is complicated. The authoring and publishing experience deserves to be as stable and timeless as reading any of the stuff that gets put inside. The process for putting new stuff in should be described in full detail in a document that lives on the same site. <https://news.ycombinator.com/item?id=25676628>
1. Good suggestion, that's something I had in mind as a potential future improvement! Since my personal use case for search is mostly on my phone – sort of as a shortcut, right before starting to prepare the dish I'm searching for – arrow keys didn't make the "add before publishing" checklist.
2. I generally agree – but in the comment you've linked, it seems to me like you're arguing in favor of conveniences that CLI-focused static site generators can't easily provide. I've tried to keep things as simple as they can be in the CLI context I'm targeting: Pandoc has been around for quite a while, it's available for pretty much any system as a stand-alone binary, and it's one of the leaders in its niche. And Bash is everywhere. Compare with, say, Jekyll, which requires Ruby and Bundler. That can be a whole can of worms if your OS supplies an outdated version of Ruby (I've been burned before!).
Thanks for the entertaining the topic of discussion.
Regarding #2:
> it seems to me like you're arguing in favor of conveniences that CLI-focused static site generators can't easily provide
I'm not sure why not. I'm talking about a specification of the process (transformations) that the site generator applies to the input, and a (slightly more relaxed) description of what steps the human operator needs to perform. This is something that people usually relegate to some out-of-band channel, like the README of a disconnected repo—at least for the latter part; they usually omit the first part entirely.
Highlighting an extremely relevant piece from a blog post from an HNer that I recently came across:
> the first wall I hit [trying to update the website] was that I: Forgot [...] the esoteric Hugo conventions (has documentation, but it's not easy to parse at a glance) [...] not sure how I could have remembered all of the Hugo-isms, especially since I don't update this site very often and don't do static site generator work outside of this.
Take also, as an example, TBL's comments about the first rough proposal for the WWW:
> [This is a...] hand conversion to HTML of the original MacWord (or Word for Mac?) document written in March 1989 [...] Other versions which are available are: The original document file (I think - I can't test it)
Both MacWord and Word for Mac probably seemed "safe" at the time. In a contemporary timeframe, you could have probably also put a copy in the hands of the last dozen or so people in your phone's contacts, and they'd have been able to use it effectively. That you wouldn't expect to be able to do the same with Pandoc is an indicator of the gulf of overcomplexity that I'm referring to.
(Note Cory's takeaway from his blog post: "let's build it up again from scratch, but simpler.")
Very interesting. I have been thinking about converting my recipes to a Markdown format. I am not sure I would use your tooling because I have my own workflows and publishing destinations
However, I am very interested in using shared markdown standards for various special use cases. I encourage you to focus a little thought on presenting your Markdown for Recipes as it’s own thing.
Here's a demo instance: https://doersino.github.io/nyum/_site/index.html
Nyum is somewhat opinionated, expecting recipes to be written as a series of steps, each with the relevant ingredients alongside an instruction. I first came across this way of doing it via the cuisine LaTeX package (which I then, many years ago, built a custom LaTeX template around), ending up preferring this structure over the more commonly found all-ingredients-first-then-a-block-of-instructions approach. (In the process of recently graduating from university, I found myself contemporaneously graduating from wanting to use LaTeX for everything, which was part of the impetus for cobbling this thing together.)