Improving the quality of the site.

[LukeSmithxyz]

I want to cool off on adding more entries until it is decided which static site generator to use and how to scale up the mainpage.

If you want to contribute in a way that keeps the site unbloated, you can do some of the following:

• Fix grammar, spelling and clarity of published articles. Do not nitpick or apply school-marm rules, e.g. don't "fix" split infinitives or clear dangling modifiers or inane things like that. Clarity is first. You might also want to minimize long-winded instructions. Some list items have what seems like a paragraph.
• Link recipes to other recipes that they already mentioned in the text. Like I did in 58268cd9a969968f5966e85f9bc221d02b861103 where an article on sourdough bread mentioned soughdough starter, which exists in an article already. Links are very good.
• Apply the UNIX philosophy: if you link an article you might want to think about slimming it down to avoid repeating instructions. For example, I made src/pasta.md which is a retard's guide to boiling pasta. You might want to take other dishes that might include pasta and instead of repeating these directions, simply link to this page saying that a required ingredient is "cooked pasta." This saves space, but also keeps from cluttering more experienced cooks with obvious things. Pasta is just an example, this could probably be done with other kinds of directions.

Please do not add your name to the credits for these minor edits. Credits should be related only to recipe content. If you substantially improve a recipe, you may add your name and links to the credit list.

[Ambyjkl]

What are the limitations of blogit other than the relatively slow build speeds?

[Ambyjkl]

Here is one I can personally recommend: https://gohugo.io/

[LukeSmithxyz]

It's broken like 10 times if it runs into a improperly formatted page or something it doesn't know how to handle.

[Ambyjkl]

Also, here is a non-bloated Hugo theme I've used before: https://themes.gohugo.io/hugo-bearblog/

[ghost]

Zola is nice.

[Ambyjkl]

A few more suggestions:

• Use Git LFS for images: https://git-lfs.github.com/
• Preview builds for PRs (things like Vercel make this very easy)
• Automatically generate fallback jpegs for browsers without webp support (e.g. Safari)

[DGKSK8LIFE]

Here is one I can personally recommend: https://gohugo.io/

Hugo is really nice. Though I'm not sure how well it'll integrate with the UI we currently have on our hands.

[m-chrzan]

It's broken like 10 times if it runs into a improperly formatted page or something it doesn't know how to handle.

Any program will fail, more or less silently, on improper input. We should add a CI check that runs the generator and fails if the generator fails, so we don't merge breaking PRs.

[throwaway1037]

I would personally recommend zola.

It's relatively unbloated, supports templates, themeing, and unlike Hugo, has automatic link checking. It's also written in Rust so it's probably more stable than Hugo and probably as fast if not faster.

[DGKSK8LIFE]

Agreed. Github Actions is really nice and can run event-driven (ex: when someone opens a PR). @m-chrzan

[LukeSmithxyz]

Can Zola do tags?

[hallzy]

@m-chrzan @DGKSK8LIFE Looks like someone is ahead of you on this. There is a PR open #351

[throwaway1037]

As far as I know, tags are not built-in, but you can use shortcodes to make a custom tag system.

Once implemented, calling a tag would look something like this:

{{ tags(tags=["dessert", "milk", "sweet"]) }}

---

Another option would be to use taxonomies to make the tags into categories.

Once implemented, you could add the tag categories to the metadata at the start of each markdown file, in TOML format:

+++
tags = ["dessert", "milk", "sweet"]
+++

---

Edit:

This theme for zola implements tags in the latter way.

[hallzy]

Looks like the build is actually broken again. their is a ' in one of the filenames which breaks the makefile #475. Definitely would have been caught by a script that tries to build on PR.

[Ambyjkl]

I think this issue is doing two things at once:

• Automatically detecting PRs which don't build
• Better static site generator

I don't think blogit is should be blamed for invalid pages. A better CI config should catch the broken builds. If it ain't broke, why fix it? I don't see why investing time and effort into porting the code into another static site generator is necessary.

[ghost]

Invalid pages aren't the only issue. Slow build times are also an issue.

[throwaway1037]

Barebones solutions like ssg5 using markdown.pl, or blogit don't scale well because they are inherently minimalist.

I think of it as "the requirements go up, so it's necessary to switch to a program of a higher "bloat level"."

Static site generators like zola are built to handle larger static sites whereas the minimalist tools only scrape by doing the bare minimum of what they have to do. That isn't to say there are bad; on the contrary, they suit their minimalist use-cases.

based.cooking will only get larger over time, and minimalist solutions don't scale very well, or support the features that we are starting to need, like taxonomies, shortcodes, or themeing support, or take forever to build the site.

I'm not suggesting we switch to a fully dynamic, bloated site because that would be stupid. I'm stating that we have new requirements and we need a new tool which can facilitate them.

(The only sites I can think of that actually need to be dynamic are forums and webshops, and even then you could switch to a mailing list or instant messaging program for the forum, or make a static webshop, although that might actually end up being more difficult than a dynamic webshop in the long run.)

[ispringle]

Can Zola do tags?

Zola can indeed do tagging, however they call it a "taxonomy".

I'd definitely recommend Zola. I use it for my SSGs. It builds very quickly, never have issues with it running.

[sylGauthier]

Regarding blogit being slow, it's "slow" because I made it to rebuild everything every time. I figured it would be better at the beginning when modifications to the Makefile and the config were common, but now that the workflow is set up, it could be good to replace the make clean deploy by simply make deploy. By doing that, blogit can theoretically scale infinitely since it would then only build/rebuild the new/modified recipes, leveraging the Makefile smart dependency management. Right now adding a recipe is O(n), by not cleaning up everything, you get O(1). Edit: #487 here you go.

Regarding builds breaking, blogit like most of the tools me and my mates develop, assumes the user is not being retarded. It assumes that all markdown files are properly formatted. Now if some of those assumptions are too strict, I'd say just extend the Makefile to catch more exceptions.

Regarding recipe quality, I spent a few hours fixing and reformatting absolutely everything to my own taste. It includes:

• Proper formatting of servings/times
• Typos
• Removing all traces of personal story/personal pronouns like "I, My", etc
• Putting all "I recommend/my favorite/..." into impersonal Notes
• Removing all images which retrospectively might have been a bad idea, because that's probably the only thing that make opening a PR for this unacceptable
• Removing all cancerous emojis, they serve no purpose, require bloated fonts to render them, break a lot of conversions to different format (in particular latex), and are a pain in the ass to filter out automatically. I think of emojis as some sort of soyspeak for man children.

I didn't bother submitting a PR for this since as you can see, it's probably too autistic/strict for other people's taste, and that's fine. However, some of it has value, like fixing typos and general reformatting. Re-injecting images is probably doable automatically with some scripting so I might give it a go to make something PR-able. For now it's all here.

Finally, to dramatically improve recipe qualities, I suggest developing/using an automatic formatter, ie script/app that reads recipe components semantically and can do some post processing to output a perfectly formatted recipe. Ideas around that include:

• Sanity check of every fields, tags, etc.
• Automatic conversion between measurement system (you ask for ingredients and their quantities separately, in any measurement system, so in the output file you can print all the conversions).
• Semi-automatic recipe linking, you grep all existing recipe's name in the new recipe and if found, you offer the user to make it into a link.

I'm developing a proof of concept of this here. It shouldn't be mandatory to write all recipes using such a tool, of course, but the more people using it, the more the general quality of recipes will improve. Honestly, as much as I hate javascript. this would actually be a valid use for it so that normalfriends who don't want to bother with installing a script or program can just do it from a browser. You'd host it on an isolated page somewhere on based.cooking and would require people to copy-paste the output into github.

[zyansheep]

* Preview builds for PRs (things like Vercel make this very easy)

you can also use IPFS for this (as well as for hosting itself) it won't help with static generation caching though, unless you build some kind of script to fetch already-built files from IPFS :thinking:

[DavGoeck]

I added links to the pasta recipes in #535 and removed the instructions from the recipes when possible and reasonable. Cleaning up some of the tags might also be useful.

[livmackintosh]

Slightly different approach (slightly maximalist in implementation) but I do love Hakyll when it comes to having reasonably predictable builds - if that's a quality you care about. I usually don't worry about my site breaking.

[Unknow0059]

I suggest that the measurement system be consistent, preferably metric.

[lmssieh]

any progress on this @LukeSmithxyz?

[wups]

What's the state of the project? Are the issues of the main page and site generator still unsolved?

If so, I could suggest a simple and very flexible way to build the page without a stubborn static site generator, just using a markdown converter and a script language.

Regarding the main page: Only display the tags and the ten latest recipes and move the index of all recipe links to a separate html file. They still need to be on one page, so one can use ctrl+f to search the recipe titles.

So many people contributed still unmerged recipes. It would be sad to stop the project.

[wups]

Out of curiosity, I created a python script, to see what it takes to build this site.

The resulting script uses only the markdown package, is 69 short lines long and builds all recipe pages, all tag pages and the main page in under a second (using a SSD): 0m00.73s real 0m00.68s user 0m00.04s system

I omitted RSS and Atom. The only thing to change are the template files (it only uses three). Otherwise it's a drop-in replacement. Interested, @LukeSmithxyz ?

[v0iden]

Come on, the project shouldn't end here! I love the idea, sad to see so many recepies that are still unmerged.