Devlog #01: Building the Scaling Engine
Hello everyone,
Welcome to Devlog #01 of the Recipe Scaler project! Hope you all are doing great!
This devlog focuses on building:
- A non-linear scaling engine
- A client-side parser fallback
- A normalization pipeline
- A dedicated print stylesheet
Everything runs through standard vanilla JS modules using localStorage.
Where Scaling Became Complicated
I spent a lot of time figuring out how ingredients behave when recipes are resized.
The problem comes with ingredients like:
- Baking powder
- Yeast
- Stabilizers
- Binders
- Salt
- Strong seasonings
These ingredients do not always increase at the same rate because they affect recipe chemistry.
Simple multiplication can change texture, rise, or flavor.
I built different scaling behavior for sensitive ingredients.
Standard ingredients scale normally, while sensitive ingredients use a dampened scaling formula:
Adjusted Amount = Original Amount × (0.7 + Ratio × 0.3)
This keeps larger batches closer to the original recipe.
The First Bug
The scaling system works, but the serving input currently has an issue.
If a user enters a negative number, the value can bypass validation and enter the calculation system.
This creates impossible results like:
-2.5 teaspoons of baking powder
The next fix is forcing every value through the same validation system and adding a minimum limit so servings cannot go below 1.
When Recipe Links Hit a Wall
I wanted users to paste a recipe link and have the app automatically pull information from the webpage.
That idea ran into a problem because browser security prevents client-side code from directly reading data from external websites without additional server support.
Instead of adding a backend only for recipe fetching, I built a fallback system.
When importing a link fails, users can paste raw recipe text into the app.
The parser detects:
- Whole numbers
- Fraction characters like
½, ¼, and ¾
- Fraction formats like
1/2
Why The Parser Still Needs Work
The parser is fragile because it relies on:
Amount → Unit Keyword → Ingredient Name
Simple recipes work, but real-world formatting creates problems.
Words like:
are not always recognized correctly.
Another example:
Juice of 1 lemon
can be mistaken as an instruction because it does not follow the normal amount-first format.
The parser needs better handling for how people write recipes.
Trying To Clean Up Repeated Ingredients
Recipes often mention the same ingredient multiple times.
Example:
1 cup butter
2 cups butter
should become:
3 cups butter
To handle this, I built a normalization pipeline.
The system currently:
- Removes extra whitespace
- Converts names to lowercase
- Removes simple plural endings
- Creates internal ingredient identifiers
This allows variations like:
egg
eggs
large eggs
to match closer together.
Descriptions still confuse the system because ingredient names do not always match perfectly.
There is also an editor issue where saving changes rebuilds the page after every keystroke, causing the input field to lose focus.
The next update will focus on separating state updates from UI rebuilding.
Wrapping Up
The main features are working, but the user experience still needs improvement because of:
- Input validation bugs
- Cursor focus issues
- Parser failures
- Ingredient matching problems
Thank you for following along with the development process.
If you notice any bugs, feel free to comment.
Next update will focus on fixing the parser and improving editing stability.
