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:

• Large
• Small
• Pinch
• Dash

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.