DEV Community: Patrick Mbithi

I Hardcoded a Recursion Demo Into My Binary Converter and I Regret Nothing

Patrick Mbithi — Sat, 11 Jul 2026 07:49:49 +0000

I built a decimal-to-binary converter and then, for no good reason, decided that if you typed in the number 5, it should not just show you the answer. It should show you the call stack.

Here's the actual conversion logic. Nothing fancy:

const decimalToBinary = (input) => {
  if (input === 0 || input === 1) {
    return String(input);
  } else {
    return decimalToBinary(Math.floor(input / 2)) + (input % 2);
  }
};

Classic recursion. Divide by two, keep the remainder, recurse on the quotient, stop at 0 or 1. decimalToBinary(5) becomes decimalToBinary(2) + "1", which becomes decimalToBinary(1) + "0" + "1", which bottoms out at "1". Concatenate it all back up and you get "101". Five in binary. Correct.

The problem is that "correct" doesn't mean "understood." I've watched people (including past me) stare at a recursive function like this and nod along with the base case, nod along with the recursive call, and still have no real mental model of what's happening on the call stack while it runs. The code reads top to bottom. The execution doesn't.

So I hardcoded a demo. If the input is exactly 5, instead of printing the result, the page runs a little animation:

const animationData = [
  {
    inputVal: 5,
    addElDelay: 1000,
    msg: 'decimalToBinary(5) returns "10" + 1 (5 % 2). Then it pops off the stack.',
    showMsgDelay: 15000,
    removeElDelay: 20000,
  },
  {
    inputVal: 2,
    addElDelay: 1500,
    msg: 'decimalToBinary(2) returns "1" + 0 (2 % 2) and gives that value to the stack below. Then it pops off the stack.',
    showMsgDelay: 10000,
    removeElDelay: 15000,
  },
  {
    inputVal: 1,
    addElDelay: 2000,
    msg: "decimalToBinary(1) returns '1' (base case) and gives that value to the stack below. Then it pops off the stack.",
    showMsgDelay: 5000,
    removeElDelay: 10000,
  }
];

Each object is a stack frame. addElDelay is when the frame appears (staggered by 500ms, so 5 shows up first, then 2, then 1, mimicking the calls stacking on top of each other). showMsgDelay is when the explanation swaps in, and it's ordered in reverse: frame 1 gets its message first, at 5 seconds, because it's the base case and returns immediately. Frame 5 doesn't get its message until 15 seconds in, because it's waiting on everything underneath it to finish. removeElDelay is when the frame pops off, again bottom-up.

The whole thing is just three setTimeout calls per frame, driven by forEach:

const showAnimation = () => {
  result.innerText = "Call Stack Animation";

  animationData.forEach((obj) => {
    setTimeout(() => {
      animationContainer.innerHTML += `
        <p id="${obj.inputVal}" class="animation-frame">
          decimalToBinary(${obj.inputVal})
        </p>
      `;
    }, obj.addElDelay);

    setTimeout(() => {
      document.getElementById(obj.inputVal).textContent = obj.msg;
    }, obj.showMsgDelay);

    setTimeout(() => {
      document.getElementById(obj.inputVal).remove();
    }, obj.removeElDelay);
  });
};

Add the frame, wait, swap the text, wait, remove it. No animation library, no framework, just staggered timers and DOM writes. It works, and honestly, watching frame 5 sit there for fifteen seconds waiting for its children to resolve does more for building intuition about recursion than any explanation I could write.

I'm not going to pretend this is good engineering, though. It only works for the input 5. Type in 6 and you just get "110" printed like normal, no ceremony. The IDs on the frames are just the raw numbers, so if two frames in a longer chain happened to share a value, document.getElementById would grab whichever one came first and the animation would break silently. There's also nothing stopping you from mashing the convert button while an animation is mid-run and ending up with a pile of duplicate frames and orphaned timeouts, since nothing gets cleared. I noticed an empty leftover setTimeout at the 20 second mark in an earlier version that did nothing at all. I left it in for a while before realizing it was just dead code from an idea I'd abandoned.

If I were extending this for real, I'd generate the animation data from the actual recursion instead of hand-typing three objects for one specific input. Something like instrumenting decimalToBinary to push and pop from an array as it runs, then replaying that array as the animation timeline. That would work for any input, not just my one carefully staged example. But there's something to be said for the hacky version too. It took maybe twenty minutes to write, and it does exactly one job: making a stranger's mental model of "5 calls 2 calls 1, then it unwinds" click into place.

Sometimes the demo doesn't need to generalize. It just needs to demo.

I built a task manager with zero frameworks, and the "delete confirmation" part took longer than everything else combined

Patrick Mbithi — Wed, 01 Jul 2026 07:06:02 +0000

Title: I built a task manager with zero frameworks, and the "delete confirmation" part took longer than everything else combined

I've been doing a lot of React and Next.js lately, so I gave myself a small constraint for this one: no framework, no build step, just the DOM API and localStorage. A task manager. Add, edit, delete, persist. Sounds like an afternoon project.

It mostly was. Except for one part I didn't expect to be annoying.

The setup

Nothing fancy. One form, toggled open and closed with a hidden class, one container that gets re-rendered every time the task list changes:

const taskForm = document.getElementById("task-form");
const tasksContainer = document.getElementById("tasks-container");
const taskData = JSON.parse(localStorage.getItem("data")) || [];
let currentTask = {};

That currentTask variable is doing more work than it looks like. It's empty when you're adding a new task, and it holds a copy of the task you clicked "Edit" on when you're not. Everything else in the app branches off whether that object has an id or not.

Add and edit share one function, on purpose

I didn't want two nearly-identical functions for creating vs. updating a task, so addOrUpdateTask checks whether the current task already exists in the array:

const addOrUpdateTask = () => {
  if (!titleInput.value.trim()) {
    alert("Please provide a title");
    return;
  }
  const dataArrIndex = taskData.findIndex((item) => item.id === currentTask.id);
  const taskObj = {
    id: `${removeSpecialChars(titleInput.value).toLowerCase().split(" ").join("-")}-${Date.now()}`,
    title: removeSpecialChars(titleInput.value),
    date: dateInput.value,
    description: removeSpecialChars(descriptionInput.value),
  };

  if (dataArrIndex === -1) {
    taskData.unshift(taskObj);
  } else {
    taskData[dataArrIndex] = taskObj;
  }

  localStorage.setItem("data", JSON.stringify(taskData));
  updateTaskContainer();
  reset();
};

If findIndex comes back -1, nothing matched, so it's a new task and gets pushed to the front. Otherwise it overwrites the existing entry in place. One function, one code path, no duplication.

The id itself is a slugified title plus a timestamp, so Fix the Bug!! becomes something like fix-the-bug-1719839213456. Good enough for a localStorage app where nobody's hitting a real database.

Where I actually spent my time

Rendering, storing, deleting, all straightforward. What I underestimated was: what happens when someone opens the form, types half a task, and then clicks the close button?

If I just closed the form, they'd lose their draft with zero warning. Annoying, but not exactly a rare thing to run into. So the close handler checks two things before doing anything: does the form actually have values in it, and are those values different from what's already saved for the current task?

closeTaskFormBtn.addEventListener("click", () => {
  const formInputsContainValues = titleInput.value || dateInput.value || descriptionInput.value;
  const formInputValuesUpdated =
    titleInput.value !== currentTask.title ||
    dateInput.value !== currentTask.date ||
    descriptionInput.value !== currentTask.description;

  if (formInputsContainValues && formInputValuesUpdated) {
    confirmCloseDialog.showModal();
  } else {
    reset();
  }
});

Both conditions matter. If you open the edit form and just close it without touching anything, formInputValuesUpdated is false, so it closes quietly, no dialog. But if you change even one field, both conditions flip true and you get a native <dialog> asking if you want to discard.

I went back and forth on whether this was overkill for a demo project. It's not. The first time I tested the app on my own to-do list and accidentally clicked outside the form, losing a real task I'd typed out, I stopped thinking of it as a nice-to-have.

The one-liner I keep reusing

const removeSpecialChars = (val) => {
  return val.trim().replace(/[^A-Za-z0-9\-\s]/g, '');
};

Strips anything that isn't a letter, number, hyphen, or whitespace, and trims the ends. I run every text input through it before it touches the id or the stored task. It's a small thing, but it's saved me from a handful of "why does this id have three slashes in it" moments in other projects since.

What I'd change next time

updateTaskContainer rebuilds the entire task list's HTML from scratch on every change:

const updateTaskContainer = () => {
  tasksContainer.innerHTML = "";
  taskData.forEach(({ id, title, date, description }) => {
    tasksContainer.innerHTML += `
      <div class="task" id="${id}">
        <p><strong>Title:</strong> ${title}</p>
        <p><strong>Date:</strong> ${date}</p>
        <p><strong>Description:</strong> ${description}</p>
        <button onclick="editTask(this)" type="button" class="btn">Edit</button>
        <button onclick="deleteTask(this)" type="button" class="btn">Delete</button>
      </div>
    `;
  });
};

Fine for a handful of tasks. Once you're past a few hundred, wiping and rebuilding the whole DOM tree on every keystroke-adjacent action starts to show. I'd move to diffing individual task nodes, or honestly just reach for a tiny library at that point rather than hand-roll a virtual DOM for a to-do app.

The onclick attributes inline in the template string also bug me a little, mixing markup and behavior like that isn't something I'd do in anything bigger than this. But for a single-file project with no bundler, it's the path of least resistance, and I'm not going to pretend I have strong feelings about purity here.

Takeaway

Frameworks handle state synchronization for you. Building this by hand made me appreciate exactly how much "handle the close button" and "handle the delete button" and "keep localStorage in sync" actually costs when there's no framework doing it in the background. None of it is hard. There's just more of it than you'd think, and most of it lives in the edges, not the happy path.

Full code's on my GitHub if you want to poke at it. Happy to hear how you'd have handled the unsaved-changes check differently.

What a Calorie Counter Taught Me About Inputs I Didn't Know I Needed to Learn

Patrick Mbithi — Wed, 10 Jun 2026 19:44:00 +0000

A calorie counter sounds like one of those beginner projects that teaches you basic math and maybe some DOM stuff. Set a budget, log meals, subtract, done. I figured I'd knock it out in an afternoon.

The math part took twenty minutes. The rest of it was humbling.

Regex was the first wall

I'd seen regex before and mostly avoided it. This project forced me to actually write some.

The problem is user input. People type things like +200 or - 150 into calorie fields. Technically valid numbers. But if you pass those strings directly to Number(), you get NaN, which breaks everything quietly. The fix is a cleaning function that strips the noise before parsing:

function cleanInputString(str) {
  const regex = /[+-\s]/g;
  return str.replace(regex, '');
}

Simple enough. But I had to actually understand why the + and - need to be inside the character class [] rather than sitting outside it, and what \s is catching, and why the g flag matters. None of that was hard once I looked it up. I just hadn't looked it up before.

The second regex was stranger. Browsers will accept scientific notation in a type="number" field. Type 1e10 and the input won't complain. Your app will then cheerfully try to add ten billion calories to breakfast. So there's a second check that specifically catches that pattern and rejects it:

function isInvalidInput(str) {
  const regex = /\d+e\d+/i;
  return str.match(regex);
}

I would not have thought to look for that on my own. Good thing the curriculum did.

How functions handle failure

The project uses a global isError flag a boolean that resets to false at the start of every calculation, then flips to true inside getCaloriesFromInputs if bad input is found. The main calculation function checks it after gathering all the values and returns early if something went wrong.

It works fine. But sitting with it made me think about the other ways you could handle this. Return null and check for it upstream. Throw an error and catch it. Return an object with a status field. Each approach shifts where the responsibility sits.

I hadn't thought about that before. This project was the first time I had to actually notice the choice being made, even if I didn't make it myself.

Building the DOM on the fly

The "Add Entry" button injects new form fields into whatever meal category the user has selected. It does that with insertAdjacentHTML:

targetInputContainer.insertAdjacentHTML('beforeend', HTMLString);

The HTML is a template literal with the entry number and category name baked into the id and for attributes. That's what keeps labels connected to their inputs as you keep adding rows. If those attributes don't match, clicking a label does nothing.

Before I saw this pattern I would have assumed you'd need a framework for dynamic forms. Turns out you don't. You just need to understand what insertAdjacentHTML does and why the attributes matter.

The clear function almost felt like a reward

After all of that, the form reset was almost relaxing. Loop through the input containers, set innerHTML to an empty string, clear the budget field, hide the output div. Four things. No edge cases. Done.

function clearForm() {
  const inputContainers = Array.from(document.querySelectorAll('.input-container'));
  for (const container of inputContainers) {
    container.innerHTML = '';
  }
  budgetNumberInput.value = '';
  output.innerText = '';
  output.classList.add('hide');
}

I appreciated that.

What I actually took away

Going in, I thought this was a project about arithmetic and maybe some querySelector practice. What it actually drilled was input handling all the ways user input can be malformed, all the places where "valid" and "correct" are two different things, and how much of your validation logic exists specifically to close the gap between what the browser accepts and what your math can safely process.

That's probably obvious to experienced devs. For me, it was the thing I didn't know I was going to learn.

Learning JavaScript With freeCodeCamp: What the RPG Project Teaches You

Patrick Mbithi — Thu, 04 Jun 2026 16:49:45 +0000

tags: javascript, beginners, webdev, freecodecamp

I've tried to "learn JavaScript" more times than I want to admit. Courses, YouTube videos, the usual. I'd get through loops and think I understood them, then open a blank file and have nothing to show for it.

freeCodeCamp's RPG project is different. Not because it's fun (it is), but because it forces you to actually use the concepts instead of just nodding at them.

What you're building

It's a browser-based RPG. You fight monsters -- a slime, a fanged beast, a dragon -- collect gold, buy weapons, manage health. The whole thing lives in index.html with a JavaScript file doing the heavy lifting. No frameworks. No libraries. Just you and the DOM.

Here's what that looks like when it clicks:

const locations = [
  { name: "town square", "button text": ["Go to store", "Go to cave", "Fight dragon"] },
  { name: "store", "button text": ["Buy 10 health (10 gold)", "Buy weapon (30 gold)", "Go to town square"] },
  // ...
];

That array of objects is the entire game state engine. When you first write it out, it looks like a lot of typing. Then you realize: every button, every screen transition, every monster is just pulling from this one structure. That's when data structures stop being an abstract concept.

The thing nobody tells you about arrays of objects

I spent probably 45 minutes confused about why locations[3].name worked but location.name didn't. Obvious in hindsight. At the time it felt like the floor had dropped out.

What actually made it click was the update function -- one function that takes a location object and rewires the whole UI:

function update(location) {
  monsterStats.style.display = "none";
  button1.innerText = location["button text"][0];
  button2.innerText = location["button text"][1];
  button3.innerText = location["button text"][2];
  button1.onclick = location["button functions"][0];
  button2.onclick = location["button functions"][1];
  button3.onclick = location["button functions"][2];
  text.innerText = location.text;
}

Every time the player clicks something, you're not writing new HTML. You're just swapping the data the function reads. That pattern -- separate your data from your rendering -- is something I now see everywhere.

Where it gets genuinely tricky

The combat system. You need to track player health, monster health, the current weapon, and whether the monster is still alive. And you need to update the DOM after every single action without losing track of any of it.

I got it wrong twice before I understood why global variables exist in small programs like this. Not because they're good practice forever -- they're not -- but because the alternative (passing state through every function) gets complicated fast. This project teaches you why people care about state management. Not as a concept. As a problem you personally ran into.

The Easter egg that teaches you something real

There's a secret number guessing minigame hidden in the RPG. The randomness that powers it uses the same Math.floor(Math.random() * X) pattern as the combat system. The first time I noticed I'd written the same two lines in three different places, I understood what "don't repeat yourself" actually means as a constraint, not just advice.

What I'd tell someone starting this project

Don't read ahead. Seriously. The temptation is to look at the full solution when you get stuck on the buyWeapon function or the monster health math. That's the exact moment where fighting through it pays off. Google the specific thing you don't understand. That's different from looking at the answer.

Also, the dragon fight is hard by design. You're probably not missing something. It's just hard.

I'm still early in my JavaScript journey, but this project changed how I think about learning to code. Writing something that runs -- that has a win condition, a lose condition, and a secret cheat code -- is worth more than any number of practice exercises where you guess what the output will be.

If you're somewhere in the middle of the freeCodeCamp JavaScript curriculum and this project is next: you're going to be fine. It's longer than it looks. It's also better than it looks.

Built with: vanilla JS, freeCodeCamp's JavaScript Algorithms and Data Structures curriculum