> Slowly add @milk{4%cup} [- TODO change units to litres -], keep mixing
No! Handle units! @milk{4%cup} should be trivially convertible to liters and configured by the user. For harder conversions (volume to mass) keeping a list of ingredients and their densities (configurable of course) would be extremely useful.
On that subject, being able to specify a recipe in terms of ratios and then automatically convert it to scale would be a super power that I can't beat by hand.
For example when I bake I do everything by weight and have all the recipes I like written out by hand with unit conversions. Because measuring by volume isn't easier in 2023 than placing your mixing bowl on a kitchen scale and balancing everything to the mass of your butter and eggs.
"No! Handle units! @milk{4%cup} should be trivially convertible to liters"
No! That's silly and it's not how cooking works! This way you get stupid recipes like on American cooking Youtube channels that just run their volumetric measurements through a converter and end up with recipes that call for 234 grams of flour, 13.5 grams of this or that spice and 78 ml of whatever. Recipes are (well, should be) tuned to the measurement system they use, and packaging availability in the area it targets, so that you get recipes that use e.g. 400ml of coconut milk (because that's the most common can size around here), whole numbers in amounts of ingredients etc. Converting between units in cooking and baking is not simply using a unit conversion calculator on your phone!
(and that's not even mentioning that there are UK, Australian and US cups, tablespoons and teaspoons)
There's a simple and obviously correct answer to this problem: the markup language should support only standard SI and conversions to weird Angloamerican units should be made from those base units.
The direction of conversion doesn't matter. If a recipe starts out with 300 gr of flour, and that gets converted into 1 3/4 cups + 2 tbsp, that's useless (or at least silly and cumbersome) for an imperial unit user. The whole recipe needs to be recalibrated to use imperial units, and that conversion needs to take culture (I should probably say 'locale', I'm not sure what the right term is here) into account, so that it would use 'sticks of butter' in the US and 'grams of butter' in Australia. I don't think this conversion can be automated.
My point is - recipes cannot be converted easily between unit systems. There is more to converting a recipe than applying a ratio table.
I think Cooklang is neat but non-developers are never going to learn it to write recipes. CookTime (my website) allows you to write structured recipes using a GUI, and soon you'll be able to use AI to just enter in random text and images and import them as recipes.
Baking is very suited to ratios, cooking less so. Bakers commonly talk about percent hydration, which is how much water there is compared to the flour.
This is only because most recipes are incredibly imprecise. Chefsteps have gram measurements for almost everything, baking or not, and have a scaling tool built into their recipe view. It's incredibly useful.
At a certain point you run into physical realities of living, growing things. You can use ratios to make homogenized items (mashed potatoes or sauces or caramelized onions or sausage). But even if you had two chicken breasts of the same mass they'll need different amounts of sauce or coating since they'll have different surface areas, and different cook times since they'll have different volumes.
I think any recipe for roasted vegetables has to be by volume of the chop/dice fwiw. There's lots of ways to chop carrots into 20g chunks, but they won't all cook well or evenly, so a 1/4" dice is what you'd call for (even if you call for 600g of carrots)
One problem with cooking is that your pans and heat transfer do not scale. So you cannot just arbitrarily scale up/down recipes, even if you take precise measurements. The result may be way too watery or dry, for example.
My wife makes sourdough, and this frustrated the hell out of me when she started. I asked her what hydration meant, and she said how much water was in it. So of course I told her to do water/water+flour.
Nope, apparently it's just water/flour...which doesn't make sense to me, as it allows 'hydration' to go over 100%.
Why water/water+flour and not water/water+flour+salt+starter? Because water:flour is the key relationship - that's what dictates the outcome. I think some people who do a lot of enriched doughs will give everything as a percentage of the mass of flour, pretty convenient.
Really it's _just_ the ratio, normalized to 100 for convenience
You're right, I meant water+flour+starter denominator. Didn't figure salt would matter enough.
My math brain wants everything as a percentage of a whole, but I see how it's simpler the way it is. Especially since the starter also has some relatively unknown amount of water and flour inside itself.
Once you're going for consistent loaves eg selling them to people who expect them to be the same every day, you do have to factor in hydration of the starter. Usually you keep it the same as the dough for simplicity but there are reasons why it might make sense for them to be different.
Kitchen scales start to have this feature built in at around the $60 point too. Dramatically simplifies bread baking, pickling, and a couple other pure ratio projects.
When I started baking, the precise measurement was the first thing that I threw out. When I did things “by eye” I got better results. I think it’s because the person writing the recipe doesn’t have the same water, flour, starter or salt as you. I take the measurements as “very general guidelines”, now.
Serious American bakers mostly use Diamond brand kosher salt. Serious bakers universally will specify if they're using kosher or table or some other salt, because they pack differently and provide different effects.
You're going to be much closer following mass measurements than volume ones - your flour may have different moisture and protein levels than the author's. But those are minor compared to the >25% variations in flour when measured by volume.
I started using ratios for seasonings and sauces and then using taste to add it to the meat/veggies/whatever as needed and it's been very good at recreating 'good' recipes. So I wouldn't discount it. But it definitely has a bunch more skill because you're playing with more variables than baking.
only if those ratios are defined by weight not volume. a "cup of brown sugar" is a useless measure. For example: I can give you three different cups of brown sugar with the same volume but radically different quantities of sugar in them. "Packed" vs "unpacked" isn't much help because i can do the same thing with both of those too...
> Because measuring by volume isn't easier in 2023 than placing your mixing bowl on a kitchen scale and balancing everything to the mass of your butter and eggs.
Eh, I've tried both and I have to disagree. Pouring milk or oil may be easier with the scale because you have very precise control over the flow rate, but for flour and other dry goods it's far easier to scoop, scrape, and dump a cup than it is to add a bit at a time while avoiding the sudden avalanches that inevitably start as things loosen up.
Honestly I'm the opposite way. for liquids, volumetric measurement is pretty consistent.
However dry goods like flour are hard because so many little things affect the density of the scoop. Vs if I just put it on the scale and scoop it into a bowl/cup on a tared scale, I can get it most of the way there and then just spoon in/out little bits to get to the right mass.
For cooking I find it doesn't really matter but with baking where those ratios are so strict, mass measurements for dry goods is just so much more repeatable.
No, it is not easier to use a cup to scoop. You are very unlikely to be able to consistently get the same amount. Instead you get variable amounts based on how much you packed it, the humidity, and the grind of the flour.
For liquids you don't have precise control over the flow rate so it isn't easier to do over the scale. Although depending on the circumstances it is because you don't have to worry about spillage.
The world is full of both kinds of people. Any attempt on the part of the format to dictate one or the other approach will simply reduce the use of the format. As firmly convinced as you are of the rightness of your position, there is at least an equal number of equally committed champions of the other position, regardless of which position you hold.
Encouraging/facilitating the presentation software to accept data in either format and render it in either format will be the winning solution.
Baking experts seem to be almost universally on the side of mass. It's more divided outside baking (though mostly breaks down along American/everyone else lines). It's really compelling to support both because recipes are legacy systems. I make the dinner rolls I make because my grandma makes them that way, and that's what my family likes. I can and have converted it to mass, because I can measure flour faster that way.
But the amount specified in any unit is an approximation. How much flour that dough needs is dependent on how much moisture is in that dough. That's different in different kitchens, with different flours, at different times of year. My grandma specified five cups of flour, plus more for working the dough, so it will always take more than that. The thing I like isn't five cups of flour, or 600 grams, it's whatever is necessary to achieve the right dough. 600g is a better approximation, because it's more consistent. But ultimately if you want to learn to cook something the way someone else does, you need a lot of qualitative instruction in addition to the quantitative
In my table (in a coffee shop) right now I have a fee recipe books about baking: flour lab, la patisserie de Yann Couvrer, le Grand libre de la viennoiserie, french patisserie by Ferrandi and they all use weights for baking recipes (tho the last one also has volumes).
I have some grandma recipes which are whatever-metric (some sort of pancakes are "one egg, one egg of water, one spoon of flour") but I think it's mostly historical.
Nah, cooking/baking is chemistry and recipes are about faithfully reproducing the reactions as specified. This comes down to reproducibility and reliability which comes down to quality of the ingredients, ease of using the technique, and skill of the person doing it.
And the metric that is most reproducible for liquid or dry ingredients is weight, because it can preserve ratios. That's why professional bakeries, baristas, and chefs don't measure their ingredients by volume since it's inaccurate even for the most skilled technicians. Just like your pharmacist isn't measuring dosage by volume without known and precise densities.
For example I don't think it matters if you measure oil or water by volume since that's rather easy to do. That said, if you want to preserve ratios with the rest of your ingredients you better be doing it by weight or else you won't be faithfully following the recipe.
This is not a subjective comparison. If a recipe is only specified by volume it cannot be followed accurately. Similarly if you want to design your own, you need a notepad to track ratios by weight.
All high level pastry recipes have converted to weights a long time ago since precision is important, but truth is for most recipes exact dosage does not matter so traditional measures from a time when scales were less common and precise survive.
You can use a spoon to transfer into the measuring bowl.
My mom taught me when I was a wee lad that a heaping table spoon was about 20g of flour, and a flat table spoon of sugar is about 10g. I have no idea if this is true, but to get 200g you get approximately ten table spoons, and you just get a bit less or more in the late one.
I still use a spoon to scoop clumpy things or things I need a very small <5g amount of. It's no more dishes than if I'd used cups and tablespoons, typically less, and it's much easier than sifting, which is necessary to get consistent amounts of flour from cups
> specify a recipe in terms of ratios and then automatically convert it to scale would be a super power that I can't beat by hand
Somebody mentioned here a couple of weeks ago that you can use a slide rule to do scale ratios in a recipe. I can't find that link now but here's a build-your-own recipe converter (circular) slide rule that I found:
I would suspect teaching Willow (https://github.com/toverainc/willow#readme) to do that would be much more reasonable in a kitchen setup, for the exact reason guhidalg mentioned: who wants to use oil soaked hands to touch something in the kitchen?
Love this. I would buy this if it was IP-whatever waterproof rated so I can periodically wash off the oils and flours that _will_ get caked on this thing.
If this thing was paired with a mass scale at 1g accuracy with a dynamic range of like 0 to 5kg, I would pay like $50 for this.
Pretty much every recipe written since literally the 1890s / Fannie Farmer already has pulled out ingredients and quantities into their own separate section from steps.
To use cooklang, it appears that I have to rewrite recipes to include ingredients inline. No other recipes tend to use this style, because it is harder to read.
If I write recipes in cooklang, the plain text of the recipes is harder to understand without tools that speak cooklang, forcing me to use the tools to get an understandable format. The output of the CLI tool seems like a better format than the format itself!
> To use cooklang, it appears that I have to rewrite recipes to include ingredients inline. No other recipes tend to use this style, because it is harder to read.
I don't understand. Recipes absolutely include ingredients inline, because unless your recipe is a single ingredient you would need to mention the name of the ingredients that step uses. The option to include measurements with the ingredient is also important for recipes that use the same ingredient in different steps.
The fact that it generates the ingredient list from the instructions is a positive, because you only need to modify the recipe in a single location rather than multiple locations. Those old 1890s cookbooks you mention often have typos in either the ingredient list or instructions because of this.
> If I write recipes in cooklang, the plain text of the recipes is harder to understand without tools that speak cooklang, forcing me to use the tools to get an understandable format. The output of the CLI tool seems like a better format than the format itself!
But that's exactly the purpose of markup language. Nobody is saying XML is easier to read than a table generated from XML. Neither is HTML, LaTeX, or any others. The only exception to this rule I can think of is Markdown, which is at best equally readable in both plaintext and rendered formats.
The output of the CLI tool is suppose to be a better reading format.
What he's saying is that it's easier to have the ingredients in a list at the bottom/top instead of strewn around the text. Yes the tools can generate the list but you need the tools. Or read the entire text to parse out the list yourself.
Sure some recipes require the same ingredient in different steps. Why optimize for an edge case and making the default case harder? It's solved "take half the butter..." and "with 100g of the sugar... Pour the rest of the sugar..." works well for the 2% of recipes you need this in.
> What he's saying is that it's easier to have the ingredients in a list at the bottom/top instead of strewn around the text.
I understand that part. What I'm questioning is how does including an ingredient list also eliminate the need to include the ingredients inline? I don't even know how you'd make a recipe that doesn't say the ingredient names inline.
> Yes the tools can generate the list but you need the tools.
That's kind of the entire point of markup languages though. You define a clear schema that a tool can process to generate a clean or convenient document out of. This is true for pretty much any markup language. If that's an issue for some reason then you can just use plaintext.
> Sure some recipes require the same ingredient in different steps. Why optimize for an edge case and making the default case harder? It's solved "take half the butter..." and "with 100g of the sugar... Pour the rest of the sugar..." works well for the 2% of recipes you need this in.
Begging the question of whether this is actually an edge case. I'd argue it's not. This case covers a huge number of the recipes I use, including simple ones like bread recipes.
I'd also argue that this makes the "default case" easier, as you only need to focus on writing the actual steps involved. You're not going to get any typos or mismatches between your ingredient list and the instructions. That's especially a benefit if you're editing those recipes down the line, which is what I presume the typos in my older cookbooks have.
An argument could be made that it makes reading the markup annoying, but I need to reiterate that markup is primarily for writing.
I didn't see if there was a way to customize ingredients lists, but it a lot of recipes I make and use the ingredients list will be more descriptive of the specific type of ingredient, and in the actual recipe it will just use a general term so it's easier to read, for example the ingredients would read:
* 2¼ cups all-purpose flour, sifted
* 4 medium ripe bananas, mashed
...
and then in the actual recipe it would just say "in a large bowl whisk together the flour, sugar..." and "in a medium bowl, combine bananas, butter, eggs..."
It seems in this lang it seems like it would need to read: "in a large bowl whisk together the all-purpose flour (sifted), sugar..." and "in a medium bowl, combine medium ripe bananas (mashed), butter, eggs..."
It just makes the actual recipe part messier than it needs to be. But like I said, I only skimmed the spec, maybe there is a way to customize and be more descriptive in the ingredients list.
What I'm questioning is how does including an ingredient list also eliminate the need to include the ingredients inline? I don't even know how you'd make a recipe that doesn't say the ingredient names inline.
That isn't what I said though. Like my sibling mentions, of course you mention the ingredient. But you don't list the ingredient at the front as "2 cups of butter, melted" etc. and then in the text you say it again "Mix the two cups of melted butter with the 4 cups of sifted wheat flower...". You use short references and that's it.
This is true for pretty much any markup language. If that's an issue for some reason then you can just use plaintext.
The point of cooklang seems to want to be to read well as plaintext though. Like markdown promises. But cooklang does not seem to succeed in that. I find the embedded ingredient with quantity markup destroys my reading flow and doesn't allow me to use the plaintext to actually use the recipe. I have to use the compiler. In markdown I find the plaintext is all I usually need/use and I never compile it to a nice looking document, except if I am trying to publish it for someone else.
This case covers a huge number of the recipes I use, including simple ones like bread recipes.
YMMV. I don't have many such recipes and the few that do work very well in plain English.
I'd also argue that this makes the "default case" easier, as you only need to focus on writing the actual steps involved.
It seems like you're saying that writing a recipe is done more often than reading it. I would question that very much unless you're someone that is like a professional recipe maker.
An argument could be made that it makes reading the markup annoying, but I need to reiterate that markup is primarily for writing.
See above on markdown. I primarily read my `README.md` et. al. in `vi`, not through generated HTML in a browser. YMMV as always.
> But that's exactly the purpose of markup language. Nobody is saying XML is easier to read than a table generated from XML. Neither is HTML, LaTeX, or any others. [...] The output of the CLI tool is suppose to be a better reading format.
The original vision for angle-bracket markup (SGML) includes support for custom Wiki syntaxes (SGML SHORTREF), tag inference, and other affordances for compact, hand-writable text. In fact, SGML can be seen as a language to specify cues for turning markdown-like text with arbitrary custom extensions into strict fully tagged hierarchical XML.
I've always liked the presentation of Cooking For Engineers. Plenty of instruction, but the table at the end that visually combines the ingredients and techniques is a nice idea for quickly glancing at while cooking.
That's how I originally learned how to cook! I worked through many of those recipes until I was comfortable enough that now I mostly wing it. Wow it's been years since I opened this site up, what a callback!
> To use cooklang, it appears that I have to rewrite recipes to include ingredients inline. No other recipes tend to use this style, because it is harder to read.
I like how it escalates as I scroll further. It has a website, cool. Then it has an app?!
Then finally you reach the footer and click on https://github.com/cooklang, then you see it has a bunch of cooklang libraries, e.g., TypeScript, python, C, etc.!
It even has a VSCode syntax highlighting package!
I appreciate the comprehensiveness of the project. It’s more than a markup language, cooklang seems to be an entire ecosystem.
A feature I think would be helpful would be a reverse shopping list (for lack of a better term) where you can say 'I have ingredients a, b, c... list what recipes do I have all or ≥ n% the ingredients for?'
I just added multi-ingredient keyword search across all of your recipes to Umami (https://www.umami.recipes). If you’re on iOS, I’d recommend checking it out!
Looks promising! I’ll give it a thorough test. Been working on my own recipe clean up tool [1]. Does your app all the scraping and parsing on the client side?
Wow, this is awesome! Your layout, subtle dividers, and serifed font really come together perfectly.
At the moment, Umami's scraping is done server-side. I'd really like to speed it up, so I'm going to start working on a 100% client scraper soon (for the native apps & browser extensions; the web version will always have cross-domain browser restrictions though).
Umami looks great, I just sent it to my wife who just uses Apple notes for recipes right now. I’m curious, how can you offer it for free while having server side processing / syncing etc?
It's few enough users right now that I can cover the couple bucks per month in server costs. If more people start to use it, I'll make it paid (either upfront or subscription, not sure yet), but I'll grandfather all existing users as free.
Interesting, does the server fetch the html itself? Or does the client POST it? The letter would be useful for paywalled sites like Cook‘s Illustrated.
I spent quite some time on ingredient labelling (what’s a unit, quantity etc.). Feel free to ping at hn[at]franz.hamburg
Yep, the client just sends the recipe URL and then the server fetches the HTML. Agreed, it would be better to have the client send the HTML for paywalled sites, which is another reason I just want to do it all on the client.
> I spent quite some time on ingredient labelling (what’s a unit, quantity etc.)
I can relate to you there. It was a long process of trial and error for me to get right, and there are still plenty of edge cases left to handle. Long-term I think AI + NLP will make this kind of thing easier, but for me it wasn't fast, reliable, cheap, or portable enough to run in an iOS app in real time quite yet.
Nice! I dabbled with deep learning and CRF for the sequence tagging. I ran in the same issues you mentioned. Current approach is hand rolled. The „holy grail“ would be linking ingredients mentioned in the directions. So, I could just tap on „…vinegar…“ in an instruction and see that I need 2 tbsp.
This seems primitive. I see there is some understanding that there needs to be "cookware" elements, but how am I supposed to indicate it requires a brick pizza oven or a tandori oven? These aren't trivial cookware. I'd want some way to filter these out without having to go through and indicate the 500 large appliances I don't have before I can see which recipes are feasible.
I could add metadata tags that would indicate just what the dish was (entree, or a fancy breakfast/brunch, or a desert, etc), but since there's nothing like a standard tag if anyone else gets the file those tags are mostly worthless (their software won't be able to sort a bunch of recipes into the correct categories).
There's no way to indicate how many times the recipe has been verified (apparently the vast majority of online recipes are made-up bullshit that even the author hasn't bothered to cook even once).
Even pictures... I might want more than one non-step picture for the recipe.
Naming convention is whacked out. This works for 5 recipe files in a folder. What happens when I have 80,000? Or 2.1 million? r/datahoarder would be disappointed. How many different pot roast recipes is that? Is it only eight dozen, or is it more like 900? Are they all just numbered, 1 through n?
Hell, there are some classic recipes that are seasonal. They want not just "chicken eggs" but "spring chicken eggs" as opposed to summer or fall. How do I filter those out so I don't see them in November?
Putting ingredients inline is interesting. I think I actually see the sense in it. As a reader, I want the ingredients list at the top, but as a writer, I'll think about ingredients as I write the instructions. So, doing it this way potentially saves on jumping back and forth between the instructions and the list, which almost feels like boilerplate.
However, if you want to make shopping list annotations, then you're doing that extra work anyway. In a separate file? It'd be cool if the spec allowed for doing an ingredients list with annotations at the top of the recipe if the writer so chooses. The current syntax works, but not for all people/scenarios.
Note the ingredient sections; crust, filling, topping. Note the step numbers. Note the link to another recipe. Note the step section titles that are represented here in bold and which don't perfectly match with the ingredient sections. Note the footnotes at the end.
Not sure how I'd do most of those things with this markdown spec.
Thanks. I can't figure out how to look at the markdown. I made an account figuring that'd let me edit (so I can view), but the protections apparently have another level.
So, are the components different files? That'd definitely help if there's a component that applies to several recipes, like a sauce or crust. However, it could make things more complicated than some would like if they're working on a smaller project, like a reference notebook or a family cookbook.
> I made an account figuring that'd let me edit (so I can view), but the protections apparently have another level.
Thanks for making an account! You can only edit you own recipes, but I (the admin) can edit any recipe. I guess you tried to edit a recipe you liked, would you like a "Copy and Edit Recipe" feature?
> So, are the components different files?
Components are what CookTime recipes are made of. A recipe has at least one component, and if necessary the author can add additional components to indicate different ingredient quantities for different components. I have thought about having re-usable components across recipes, I just haven't given thought to how to design the UX for it. Glad to hear that someone else would find it useful, I think I'll reprioritize this.
> I can't figure out how to look at the markdown.
In CookTime there isn't a simple textual representation of a recipe (unless you count the big JSON object the browser sends over the wire.). The backend is a relational database of recipes, components, ingredient requirements, nutrition data, etc...
> Power vs simplicity is often a balancing act.
100%, my primary user is my mother-in-law and I have to be extra careful to make everything easy to use for an enthusiastic retiree.
Since you seem to know this space. I'm interested in something people must be working on. I want something that is ingredient property oriented. Examples would be starch, antihistamine, and cultural usage.
The idea would be a recipe generator the uses taste profiles, food textures, but has no standard ingredients. If one only had taro root for flour all recipes would sub that in...
I'm not aware of a specific service to do what you're describing. The closest I can think of is IBM's Watson demo for recipe creation[1].
Can you tell me more about what you're looking for? CookTime's recipe object modeling is very flexible, maybe I can make what you're looking for in a generic way.
I will check out Watson. I'm really just looking to tag ingredients. I could always create my own tag standards for the what I'm curious about.
I have read through this thread to try to make myself more articulate.
I guess I'm thinking of it as an ingredient centered approach. The recipe is secondary to whatever is available. The idea would be the ingredients would have tags for properties. The properties would be the nutritional content, cultural references, mouth feel, taste profile, allergens, ...
The combining of ingredients might have less to do with recipes and more to do with necessities and circumstances.
The flour example is probably the most illustrative. Many grains and roots can be used as flour. If one was using taro root flour all recipes would just accommodate that substitution.
This is an interesting and complicated set of problems. It's similar to problems in the LLM & social network spaces. You have several dimensions, like recipes, ingredients, nutrition, cultural context, etc, and you have gradients to help determine recommendations, which points to a graph DB. But you also have rules when it comes to substitutions (not every substitution is appropriate for every situation), and you might have rules on other dimensions as well. That points to a layer of business logic. But to serve recommendations performantly, you might want to run rules upon writes or on a schedule to persist the results to the DB. Either that or do some sophisticated caching.
This seems like the fallacy of a lot of software development. Make the one time task of writing easier while making the many many multiple more times act of reading/comprehending/using harder.
Because every recipe is written with the ingredients first, so you can get the ingredients ready and confirm you have the complete requirements easily.
If you have them inline, you may or may not want them separately as well. The benefit of the separate listing is that it's the total amount required. Inline, you might have 1 egg being added first, and one egg being added last.
Sure, since it's markup you could sum them to two eggs in an auto generated ingredient list, but for a general text format recipe, I'd like to see the egg in 3 places. In the ingredient list it must show "2 eggs" and then on two different locations in the recipe it will say "add 1 egg".
I agree with that, but if there is an ingredient used in multiple components, then that should be handled separately so you know you need 200g flour for the crust and 100g for the crumble topping. The shopping list or overall ingredient list needs to know you need 300g, but the ingredients list for each component needs to know what you need just for that component so you don't accidentally throw 300g flour into the crumble.
So, I think the primary disconnect I had was that I thought this was a spec for a recipe, but it's actually a spec for a component of a recipe, or an entire recipe that only has one component. The CookTime person replied to me and showed how the spec can be used in a component paradigm, which makes it much more usable.
I actually made a webapp[0] that does a lot of this, but the it's markdown instead of it's own markup language. Benefit of it being online instead of having to run a local server is that you can use other people's recipes (or fork them if you want to alter them). There's also a drag and drop interface for weekly meal planning that makes your grocery list for you instead of having to write them out.
Empty? I can't duplicate that for the life of me. There should be a register and login link, or more if you're logged in. A list of recipes would be completely overwhelming way to browse if you're actually looking for something, you can search by any ingredient and get a list of recipes.
It's definitely something I'm still working on, but has been very usable.
> Empty? I can't duplicate that for the life of me.
My bad. Yes there's the register and login links. I guess I was taken off guard by the hamburger menu redirecting to https://www.reciped.io/links/ and showing the links there.
> A list of recipes would be completely overwhelming
Well it would be a good way to see how many recipes there are.
I mean, I could register, sure. But it's not even clear to me why I'd want to:
- If I want to find interesting new recipes, I don't have to register.
- If I want to keep track of my recipes, so that I can make it them the same way the next time, I don't want to register and record my recipes on your website, because now anyone can alter them.
---
I like the website overall! It's minimalistic, no bloat. And I like how you include the nutrition information!
Thank you for replying! I was trying to duplicate the empty links issue over and over and couldn't figure out anything.
Registering allows you to save recipes & then do meal planning, which creates a saved grocery list for you. I couldn't really figure out a way to do it anonymously without having a list of recipes you wanted to pick from. Drag and drop just seemed easier.
You're right, I definitely need more recipes.
> I don't want to register and record my recipes on your website, because now anyone can alter them.
Anyone can alter them, but realistically it's just for formatting, spelling, or adding a picture. It's like wikipedia where all the edits are saved, so you can just revert any changes.
This is interesting though perhaps a bit over-engineered.
I'd probably find myself less motivated to simply type something out to recipe.txt vs. manage all this but CookCLI does open up some interesting possibilities.
The first thing that came to mind would be that it'd be cool if CookCLI could "halve" recipes automatically. Say you had a recipe for 12 muffins but you only wanted to make 6 or 4, it could automatically divide those quantities and spit out a new recipe or shopping list.
Another cool CLI feature would be unit conversion; converting things like fluid ounces, or cups into ml.
My other piece of feedback is the overloading of {} for ending multi-word ingredient seems a bit off. It's more syntax but I'd still rather have something dedicated for that purpose eg. @(ground black pepper)
> The first thing that came to mind would be that it'd be cool if CookCLI could "halve" recipes automatically. Say you had a recipe for 12 muffins but you only wanted to make 6 or 4, it could automatically divide those quantities and spit out a new recipe or shopping list.
The problem is that scaling recipes doesn't work this way, particularly for baking. Some ingredients don't scale linearly, cooking and mixing time doesn't scale linearly, etc. Savory items also have scaling issues, for example, some dishes include extra liquid that is lost to evaporation while cooking; you would likely not want to scale that up and would end up too much liquid at the end if you did. The opposite can be a problem too, don't scale down liquids in pressure cookers without thinking because you might end up without enough.
You would need a lot of extra metadata to be able to effectively scale recipes.
>My other piece of feedback is the overloading of {} for ending multi-word ingredient seems a bit off. It's more syntax but I'd still rather have something dedicated for that purpose eg. @(ground black pepper)
Yep, or just use the same tag marker at the end of the multi-word thing: #pot, #pressure cooker#, @onions, @ground black pepper@.
Some years ago, I came across a recepie as flowchart graph. This idea appealed to me instantaneously, because a picture to me is a thousand times better than a lettersoup. Especially when I'm not constantly reading the text, but have to check the pots and pans regularly.
I think this markup language could be used as input for an engine that generates nice recepie graphs.
And then an integration into the tandori.dev application?
Just about three weeks ago, I made a fossil repo to keep track of my recipies.
I write them in markdown and use fossil's webserver to be able to access them
while in the kitchen. If I need to see ingridents while i'm out, i activate my
tailscale VPN on my phone and browse to the fossil webserver.
Thankfully i'm not the only one who has oven-engineered a simple solution.
I started to note down recipes as sequence diagrams. This gives me clear insight about duration (incl preparation and waiting times, etc), order of steps and parallelization of steps.
I wrote them with pen and paper.
Recently I experimented with the mermaid extension for markdown. It has its drawbacks but works.
My career was cooking for a long time before I ended up coding for a living and that's the only post I can think of by a programmer who really gets it.
It's pretty funny watching every conversation about food or cooking on HN turn into confident assertions of how it should be done. Meanwhile every attempt to do it smashes right into these problems and, while maybe gratifying for engineers, are virtually worthless to cooks. You can tell by the fact that no cooks use these systems.
Jumping ahead, I want a plugin that automatically applies "standard" volume to mass conversions for me. E.g. 1 C whole wheat flour is 5.5 oz (or 150 g).
This is walking the line of laziness (why don't I just look them up myself), but it sounds great.
Maybe I can combine the web server with a customized GNU units.
You can assume ingredients are mostly water and use 1kg = 1L for conversions, but a lot of ingredients violate this density assumption. You don't have to do the hard work to figure out the densities, the USDA already did it in the FoodCentral database. If you want a service that allows you create define recipes with both mass and volume indications, check out CookTime! Here's a rather complex macaron recipe from one of my friends: https://letscooktime.com/Recipes/Details?id=8a67c391-ddcc-4d...
It would be cool if someone could make a web recipe parser (similar to how Paprika works) that could export in this format, or at least convert another recipe file format to this one.
Surely there are thousands and thousands of units?
Or do you think the software should only support English?
A Vietnamese recipe will often use "gr" for grams (even though SI says that's not correct but what are you going to do?). A Japanese recipe will say something like "1/2パック". And so on.
Any time a recipe says something like "a dash", "a pinch", "a handful", "half can", "a dollop", "a generous pour", "to taste", or "extra large eggs" -- all things that are extremely in real world recipes -- it will be written in the local language.
I don't think the markup language intends every single measurement to be converted into laboratory measures using only official abbreviations, which feels unnecessarily restrictive.
No! Handle units! @milk{4%cup} should be trivially convertible to liters and configured by the user. For harder conversions (volume to mass) keeping a list of ingredients and their densities (configurable of course) would be extremely useful.
On that subject, being able to specify a recipe in terms of ratios and then automatically convert it to scale would be a super power that I can't beat by hand.
For example when I bake I do everything by weight and have all the recipes I like written out by hand with unit conversions. Because measuring by volume isn't easier in 2023 than placing your mixing bowl on a kitchen scale and balancing everything to the mass of your butter and eggs.