DEV Community: Joe Lin

How to Measure Reaction Time Without Counting the Waiting Period

Joe Lin — Mon, 19 Oct 2026 13:00:03 +0000

A reaction-time test becomes unfair if it measures how long the screen waited before turning green. I built the test as a small state machine: idle, waiting, ready, result, and early. The timer starts only when the ready state begins, so the result represents the click-to-signal interval rather than the random delay.

Random delay prevents anticipation

Starting a round chooses a delay between 1.2 and 4 seconds:

function startWaiting() {
  phase.value = "waiting";
  const delay = 1200 + Math.random() * 2800;
  clearWait();
  waitTimer = setTimeout(() => {
    phase.value = "ready";
    startTime = performance.now();
  }, delay);
}

The random interval makes memorizing a fixed countdown less useful. clearWait runs before scheduling a new timer, which prevents an old round from changing the state after the player has already started another one.

A state machine makes early clicks explicit

The pad handler treats the same click differently depending on the phase:

function onPad() {
  switch (phase.value) {
    case "idle":
    case "result":
    case "early":
      startWaiting();
      break;
    case "waiting":
      clearWait();
      phase.value = "early";
      break;
    case "ready": {
      const ms = Math.round(performance.now() - startTime);
      lastMs.value = ms;
      attempts.value.push(ms);
      phase.value = "result";
      break;
    }
  }
}

An early click cancels the timer and records no fake reaction time. A result click starts the next round. This is simpler to reason about than a collection of booleans such as isStarted, isReady, and hasError, where contradictory combinations are possible.

Use a monotonic clock for elapsed time

The test records performance.now() at the exact transition to ready, then subtracts another performance.now() on the click. That clock is designed for intervals and is not affected by a user changing the wall clock. Rounding to an integer millisecond gives the display a stable unit while preserving the basic measurement.

The computed average is also intentionally transparent:

const avgMs = computed(() => {
  if (!attempts.value.length) return null;
  const sum = attempts.value.reduce((a, b) => a + b, 0);
  return Math.round(sum / attempts.value.length);
});

The best score is saved separately in local storage:

if (bestMs.value === null || ms < bestMs.value) {
  bestMs.value = ms;
  saveBest();
}

Only the best value is restored on mount; the current attempt history is a session concern. Storage errors and quota failures are ignored so a privacy setting cannot break the game.

The limitations are significant. Browser scheduling, display refresh rate, input devices, touch latency, and human anticipation all affect the result. A four-second random delay is not cryptographic randomness, and this is not a medical or scientific reflex measurement. A fast score on one device is not directly comparable with a score on another.

Cleanup is part of measuring correctly

The component calls onBeforeUnmount(clearWait). That is easy to overlook, but a pending timeout is still a future state transition. If the user navigates away while the test is waiting, the old callback should not wake up and mutate a component that is no longer visible. The same cleanup happens when an early click cancels the round.

The phase names also make the user experience testable. An idle pad can start a round; a waiting pad can only produce an early result; a ready pad records a number; and a result pad starts again. I can test those transitions without relying on the color of the button. In a small game, that is often a better test seam than trying to simulate an entire browser repaint.

performance.now() is intentionally paired with a click event, but event timing still includes the browser and hardware pipeline. A high-refresh monitor may show the signal earlier than a low-refresh one, and touch events usually have different latency from a mouse. The right takeaway is relative practice on one setup, not a universal ranking.

The saved best score has a similarly narrow promise. It stores one integer under bgt_reaction_best_v1, catches storage errors, and restores it on mount. It does not sync across devices or prove that a score was produced honestly. That modest scope keeps the game reliable when storage is blocked and keeps the result’s limitations visible.

The rating thresholds are deliberately simple: under 200 ms is fast, under 300 is good, under 400 is average, and everything else is slow. They are labels for feedback, not a scientific classification. Keeping those boundaries in a computed value means changing the copy or adding localization does not alter how elapsed time is recorded.

In other words, the state machine measures one interval, while the rating only interprets it afterward. Keeping those responsibilities separate makes both pieces easier to explain and replace.

That separation also keeps the game responsive when copy changes, localization changes, or a device reports an unusual input event.

The test also benefits from refusing to manufacture a number after an early click. An early result is a distinct phase with no lastMs update, so the average is based only on completed ready-state attempts. That keeps the summary honest and gives the player a clear way to try again instead of quietly adding a penalty or an impossible zero to the history.

In practice, I would use several attempts rather than treating the best result as a personal measurement. The component exposes the average and best values separately for that reason. One unusually quick click can be interesting, but repeated measurements are a better description of how a particular person and device behave together.

I turned this state-machine experiment into a small free tool: Reaction Time Test.

Why CAGR Is Not the Same as Your Actual Year-by-Year Return

Joe Lin — Sun, 18 Oct 2026 13:00:03 +0000

CAGR is useful because it compresses a beginning value, ending value, and time span into one annualized rate. It is also easy to misuse as if an investment grew at that rate every year. I built the calculator to show both the compact percentage and a reconstructed year-by-year path, making that distinction hard to miss.

The core formula describes an equivalent rate

The computed result normalizes the inputs and clamps the number of years:

const b = Number(beginValue.value) || 0;
const e = Number(endValue.value) || 0;
const Y = Math.min(
  Math.max(Math.floor(Number(years.value) || 0), 1),
  80
);
if (b <= 0 || e <= 0) return null;

const cagr = Math.pow(e / b, 1 / Y) - 1;

The formula asks: “What constant annual rate would turn the beginning value into the ending value over Y years?” It does not inspect the path between those endpoints. A portfolio could crash and recover and still have the same CAGR as a smooth line.

Total return answers a different question

The source keeps simple growth separate:

const totalReturn = e / b - 1;
const gain = e - b;

totalReturn is the complete change across the period. cagr is that change annualized with compounding. A 21 percent total return over three years is not a 21 percent annual return; the equivalent annual rate is smaller. Showing both prevents a familiar percentage from being read with the wrong time unit.

The yearly table is a reconstructed path

Once CAGR is known, the tool builds illustrative values:

const rows = [];
for (let y = 0; y <= Y; y++) {
  const value = b * Math.pow(1 + cagr, y);
  rows.push({
    year: y,
    value,
    growth: value - b,
  });
}

This table is not historical data. It is the smooth path implied by the equivalent rate. That makes it useful for explaining compounding, but it should not be mistaken for the actual annual returns that produced the endpoint.

The formatter makes the sign explicit:

function fmtPct(val) {
  if (val === null || val === undefined || isNaN(val)) return "—";
  const pct = val * 100;
  const sign = pct > 0 ? "+" : "";
  return `${sign}${pct.toFixed(2)}%`;
}

Negative CAGR is valid when the ending value is lower, while zero gets no plus sign. The input guard rejects zero or negative endpoints because the logarithmic intuition behind growth rates becomes misleading for this simple ratio model.

The major limitation is what the formula leaves out: deposits, withdrawals, dividends, taxes, fees, inflation, volatility, and cash-flow timing. If money enters or leaves during the period, a money-weighted or time-weighted return measure may be more appropriate. The 80-year cap is also a display boundary, not a statement about finance.

A smooth chart can be honest if it labels the assumption

The reconstructed rows start at year zero, where value equals the beginning value and growth is zero. Each later row compounds the same equivalent rate again. That makes the table a teaching aid: it shows what “annualized” means without claiming that the account actually followed that line.

There is also a useful relationship to check manually. The final row should equal the ending input apart from floating-point and display rounding, because the rate was derived from that endpoint. gain should equal end - begin, while the cumulative growth in the last row should express the same difference. These simple invariants are valuable when changing a financial component; they catch swapped endpoints and off-by-one year loops quickly.

Negative results deserve the same care as positive ones. If the ending value is lower, fmtPct adds no plus sign and the reconstructed path declines each year. That path is still only an equivalent path. A real investment can have negative years followed by recovery, and CAGR alone cannot tell the story of volatility or drawdown.

If a future version adds cash flows, I would not quietly overload these inputs. I would introduce a separate return method and explain its assumptions, because a single “CAGR” label should not start pretending to be an internal rate of return calculator.

The formatter rounds currency-like values to whole units while leaving the percentage at two decimal places. That is a display choice, not a loss of precision in the calculation. Keeping raw numeric fields in the returned result means another presentation—more decimals, a chart tooltip, or a localized currency symbol—can be added without rewriting the formula.

That split between raw result and formatted text is especially helpful when comparing two scenarios: the UI can show friendly numbers while tests still inspect the unrounded cagr, gain, and row values.

The final result remains a model, not a guarantee, and the input values still need context before anyone makes a decision.

I would also avoid comparing CAGR values with different time windows as if they were automatically equivalent. The exponent normalizes each result to an annual rate, but a two-year result and a twenty-year result can have very different uncertainty, volatility, and practical meaning. The component can calculate both because the formula is compact; interpretation still belongs to the person supplying the beginning and ending values.

That boundary is useful for implementation too. The view does not fetch market prices, infer missing dates, or decorate the result with a prediction. It receives three numbers, calculates a reproducible equivalent rate, and exposes the intermediate rows. Fewer hidden inputs make the output easier to audit, even when the financial story behind those inputs is complicated.

I turned this explanation into a small free tool: CAGR Calculator.

How a Scoreboard Keeps Responsive Layout and Game State in Sync

Joe Lin — Sat, 17 Oct 2026 13:00:05 +0000

An online scoreboard is mostly buttons and numbers, but a useful one has to survive team changes, narrow screens, fullscreen mode, and accidental resets. I built the view with a small reactive team model and derived layout values, instead of storing every CSS position as mutable state.

The team list is the source of truth

The initial state is plain data:

const MAX_TEAMS = 18;
const stepOptions = [1, 2, 3, 5];
const teams = ref([
  { id: 1, name: "", score: 0 },
  { id: 2, name: "", score: 0 },
]);

const hasScore = computed(() =>
  teams.value.some((team) => team.score !== 0)
);

Adding a team appends an object with a stable id and refuses to exceed MAX_TEAMS. Removing a team splices the same array. Scores are changed by a delta, so the step control can support one, two, three, or five points without duplicating four button handlers.

Leaders are derived, including ties

The view does not store a “leader” flag on every team:

const leaderIds = computed(() => {
  if (!teams.value.length) return [];
  const max = Math.max(...teams.value.map((team) => team.score));
  return teams.value
    .filter((team) => team.score === max)
    .map((team) => team.id);
});

That naturally handles ties. If two teams have the same highest score, both ids are highlighted. Derived state also avoids stale flags after a score decrement or team removal.

Layout depends on viewport and team count

The number of columns is a computed breakpoint rule:

const maxColumns = computed(() => {
  if (viewportWidth.value <= 768) return 2;
  if (viewportWidth.value <= 1024) return 4;
  return 6;
});

const minLineCount = computed(() =>
  Math.max(1, Math.ceil(teams.value.length / maxColumns.value))
);

The actual CSS variables come from lineCount and columnCount. getGridItemStyle handles an incomplete last row and adjusts it for left, center, or right alignment. That is why the view needs both a responsive width listener and explicit line-count clamping: changing teams can make the previous layout invalid.

LED digits are a rendering adapter

The LED theme does not use a font. It maps each character to segments:

const ledCharacterSegments = {
  0: "abcdef",
  1: "bc",
  2: "abdeg",
  3: "abcdg",
  4: "bcfg",
  8: "abcdefg",
  9: "abcdfg",
  "-": "g",
};

function getLedSegments(character) {
  return ledCharacterSegments[character] || "";
}

getLedCharacters(score) splits the score into characters, allowing negative scores to render the mapped minus segment. An unknown character simply has no segments, which is safer than throwing during a game.

Fullscreen is progressive enhancement

Entering fullscreen first sets the component’s own isFullscreen state, then tries requestFullscreen. If the browser rejects it or does not support it, the CSS mode still works. Escape removes the listener and exits the native document fullscreen when present. That fallback is important on iOS and embedded browsers.

The limitations are practical: state is browser-local, the score has no undo history, and the fullscreen API can be denied by permissions or user gesture rules. A reset uses SweetAlert confirmation, but closing a tab still loses an unsaved match unless the rest of the source’s persistence logic is used. The 18-team cap also makes the layout predictable rather than infinite.

Small defensive rules keep games from becoming layout bugs

clampLineCount is one of those helpers that looks like UI plumbing but protects the actual game. It rounds a user-entered line count, keeps it at least the number of lines required by the current team count, and caps it at the number of teams. After adding or removing a team, syncLineCount recalculates the default unless the player explicitly customized the layout.

The viewport listener follows the same principle. It ignores updates when window.innerWidth has not changed, then synchronizes the grid only when necessary. Without that check, resize events could trigger a stream of redundant reactive updates while someone drags a browser edge. It is not a performance breakthrough, but it keeps the state transitions predictable.

I also like that reset operations are separate. resetScores preserves names, themes, and layout; resetAll returns the whole game to two unnamed teams and the default style. A confirmation dialog protects both actions, but their scopes remain different in the data model. That distinction is exactly what prevents a “reset scores” button from becoming an accidental “erase the match setup” button.

The score itself is not formatted with a fixed width, so a negative value can still be represented as a normal string and then mapped through the minus LED segment. That is a small edge case, but it is a good reminder that a scoreboard is not necessarily a countdown: decrementing below zero should not crash the renderer or silently become an empty display.

The same defensive approach appears in the LED lookup: unknown characters return an empty segment string. A missing mapping becomes a blank glyph rather than an exception that stops every team from rendering.

The responsive calculations also avoid storing pixel coordinates. A team’s position is derived from its index, the current column count, the selected alignment, and the number of empty cells in the final row. When the viewport changes, the same team data can be laid out again. This is less fragile than updating every card’s left and top values and then trying to remember which values belonged to the previous breakpoint.

That is why the scoreboard remains a useful example beyond keeping points. It demonstrates a general Vue pattern: store the smallest meaningful state, derive presentation details from it, and put browser capabilities such as fullscreen behind a fallback. The game remains usable even when a particular visual enhancement is unavailable.

I turned this state-and-layout model into a small free tool: Online Scoreboard.

Why Splitting a Bill Requires an Explicit Rounding Policy

Joe Lin — Thu, 15 Oct 2026 13:00:05 +0000

Dividing a restaurant bill is easy until the cents do not divide evenly, or a group wants every person to pay a whole currency unit. I built the tip splitter with two separate totals: the mathematically exact split and an optional round-up split. That keeps the rounding decision visible instead of hiding a mismatch in the final number.

Normalize people before dividing

The calculator clamps the number of diners:

function changePeople(delta) {
  const next = (Number(people.value) || 1) + delta;
  people.value = Math.max(1, Math.min(99, next));
}

The computed calculation applies similar protection even if a value arrives from a pasted form field:

const b = Number(bill.value) || 0;
const p = Math.max(0, Number(tipPercent.value) || 0);
const n = Math.max(1, Math.floor(Number(people.value) || 1));
if (b <= 0) return null;

The Math.floor prevents a fractional person count, and the lower bound avoids division by zero. A zero bill returns null, which lets the template show an empty state rather than pretending that a blank form is a valid split.

Calculate tip and total independently

The core values are intentionally boring:

const tipAmount = (b * p) / 100;
const total = b + tipAmount;
let perPerson = total / n;
let rounding = 0;
let chargedTotal = total;

Keeping tipAmount and total separate matters when the interface displays a breakdown. A reader can audit whether a percentage was applied to the bill, and the program does not lose the original total just because the display later rounds numbers with toLocaleString.

Round up the person, then explain the difference

The optional policy is:

if (roundUp.value) {
  perPerson = Math.ceil(perPerson);
  chargedTotal = perPerson * n;
  rounding = chargedTotal - total;
}

This is not “round each person independently.” It rounds the shared per-person charge upward, then recomputes the amount collected. rounding is the extra money created by that policy, so the result can say where the difference went. With a total of 100 divided among three people, a whole-unit per-person charge collects 102, not 100.

The formatting helper keeps calculation and presentation apart:

function fmt(val) {
  if (val === null || val === undefined || isNaN(val)) return "—";
  return Number(val).toLocaleString(undefined, {
    minimumFractionDigits: 0,
    maximumFractionDigits: 2,
  });
}

The locale is left to the browser, while the arithmetic stays in ordinary JavaScript numbers. That is convenient for a small tool, but it is also a limitation: binary floating-point can produce tiny internal fractions, and currencies with special minor-unit rules are not modeled. The calculator does not account for tax, per-item ordering, unequal shares, service charges, or a tip base different from the entered bill.

The maximum of 99 people is another deliberate UI boundary, not a mathematical one. Large events need a different allocation model, especially when some attendees pay only for selected items.

The result should expose the policy, not just the answer

I intentionally return both total and chargedTotal. When round-up is disabled, they are equal and rounding is zero. When it is enabled, chargedTotal explains why multiplying the displayed per-person number back by the number of people no longer matches the exact bill. That makes the UI suitable for a real conversation at the table: “Do we want to split exact cents, or should everyone pay a whole unit?”

The presets [10, 15, 18, 20] are convenience values for the tip percentage, not a claim that one percentage is correct. The calculator does not infer tax or service fees, and it does not decide whether the tip should be calculated before or after tax. Those choices belong in the entered bill and the user’s local custom.

For unequal groups, the next feature would not be another rounding flag. It would be an item-level allocation model, because “three people” is not enough information when one person ordered a much more expensive meal. That is a good example of a simple tool’s boundary: making equal splitting precise does not make it fair for every group.

Even with that boundary, separating arithmetic from display is worthwhile. The computed object is small, testable, and easy to inspect, while fmt can change locale presentation without changing who owes what.

The number of people is also changed through a dedicated helper rather than trusting a stepper component to enforce its own bounds. That matters for keyboard input and pasted values, where browser controls can be bypassed. The calculation repeats the lower-bound check, so the UI remains safe even if the state is changed by another component later.

That duplication is intentional validation at the calculation boundary. Form constraints improve the experience, but computed financial output should not depend on a particular input widget behaving perfectly.

It also keeps the result predictable when the bill is edited rapidly.

One subtle benefit of returning rounding explicitly is that the interface can explain a surplus without pretending it is part of the tip. The tip remains tipAmount, the exact bill remains total, and the whole-unit collection is chargedTotal. Those names make it much harder to accidentally display the rounded charge as if it were the restaurant’s original total.

I would keep this policy visible in any test cases too. A normal split should satisfy perPerson * people === total up to floating-point precision, while a round-up split should satisfy perPerson * people === chargedTotal and report the difference in rounding. Testing those relationships is more useful than testing only one sample bill.

I turned this explicit rounding model into a small free tool: Tip & Bill Split Calculator.

How to Generate Bingo Cards Without Accidentally Reusing the Same Words

Joe Lin — Wed, 14 Oct 2026 13:00:06 +0000

Generating a bingo card looks like filling a grid, but the details show up as soon as users request different sizes, custom words, free centers, and multiple cards. I built the generator around a normalized list, a Fisher–Yates shuffle, and a separate play-state model so printable cards and clickable games do not fight each other.

Validate the content before building cells

Custom text is turned into a trimmed list:

const wordList = computed(() =>
  wordText.value
    .split(/\r?\n/)
    .map((word) => word.trim())
    .filter((word) => word.length > 0)
);

const neededWords = computed(() => {
  const totalCells = boardSize.value * boardSize.value;
  return freeCenter.value ? totalCells - 1 : totalCells;
});

The count changes when the free-center option changes. generate refuses to create a word card if there are fewer entries than neededWords. That is better than silently placing blank cells and discovering the problem only after downloading a card.

Shuffle copies, not the source array

The source uses a small Fisher–Yates implementation:

function shuffle(arr) {
  const a = arr.slice();
  for (let i = a.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [a[i], a[j]] = [a[j], a[i]];
  }
  return a;
}

The slice is important. A generator should not reorder the user’s original word list just because it is preparing one card. Fisher–Yates gives every remaining position a random candidate under Math.random; it is not cryptographic randomness, but it is appropriate for a casual game.

Number cards use a column pool:

const numbersPerColumn = size === 5 ? 15 : size;
for (let c = 0; c < size; c++) {
  const start = c * numbersPerColumn + 1;
  const pool = [];
  for (let n = start; n < start + numbersPerColumn; n++) {
    pool.push(n);
  }
  cols.push(shuffle(pool).slice(0, size));
}

The classic five-column card has fifteen numbers per column. Larger boards use a pool equal to the board size. That is a product rule, not a universal bingo standard, so it belongs in the implementation rather than being implied by a generic “random grid” helper.

A free cell is data with behavior

While creating cells, the center is marked and labeled:

const isFree =
  freeCenter.value && row === center && col === center;
cells.push({
  label: isFree ? t("bingoCardGenerator.freeText")
                : String(cols[col][row]),
  marked: isFree,
  free: isFree,
});

Later, toggleMark refuses to toggle free cells and records every other click in history. That history powers undo without trying to infer intent from the current grid.

Winning lines are generated from the board size

The win checker creates horizontal rows, vertical columns, and two diagonals, then tests every cell in a line. connectedLineCount counts completed lines and isCardWon compares it to the configured target. This supports a five-line game without hard-coding a 5×5 scan, and the maximum target is size * 2 + 2.

The limitation is that “random” does not mean unique. Multiple generated cards can share words or number patterns, especially with small custom lists. Word cards require enough distinct input entries, but the tool does not promise globally unique cards across a batch. Very large boards also create a lot of cells and a lot of work for browser-side PNG/ZIP downloads.

Accessibility and unusual board sizes are implementation details

The generator creates column labels with spreadsheet-style letters:

function createColumnLabels(size) {
  if (size === 5) return ["B", "I", "N", "G", "O"];
  return Array.from({ length: size }, (_, index) => {
    let label = "";
    let value = index;
    do {
      label = String.fromCharCode(65 + (value % 26)) + label;
      value = Math.floor(value / 26) - 1;
    } while (value >= 0);
    return label;
  });
}

The special five-column labels preserve the familiar B-I-N-G-O convention. Larger boards use A, B, …, Z, then AA and beyond, so an accessible cell label can still identify a position even when the visual card has no standard letter heading.

The source also computes contrast text color from a six-digit hex color. That is a helpful default for custom themes, but it is not a complete accessibility audit: color contrast for every text/background combination, print output, and user-selected word length still needs testing. A free center is represented as a marked cell from the beginning, which means the play-mode win logic naturally includes it without a special case in every line scan.

The download path is another boundary. Browser canvas and ZIP libraries can handle ordinary batches, but memory use grows with card count and board size. A phone generating many 31×31 image cards may hit a practical limit long before the JavaScript algorithm is mathematically wrong.

The separate mode, cards, and playMode refs are useful here. Generating a new batch can reset the active card and leave the printable data intact; entering play mode does not need to regenerate anything. That separation also makes it possible to download a generated card without marking cells, which is the expected behavior for a printable worksheet.

There is a similar separation between a card’s cells and its history. The cell array describes the current board, while history describes the sequence of manual marks. That means undo can remove the most recent action without trying to reconstruct the whole board from a random seed. It also means a free cell can remain marked when the rest of the card is reset, because resetCard restores each cell to its original free status.

For me, that is the main design lesson: generation and play are related features, but they are not the same state transition. Keeping them separate makes the printable workflow predictable and leaves room for future game rules without changing the code that creates a valid card.

I turned this generator into a small free tool: Bingo Card Generator.

How to Build a Loan Amortization Schedule That Does Not Loop Forever

Joe Lin — Tue, 13 Oct 2026 13:00:04 +0000

A loan calculator that only prints a monthly payment is missing the part people usually need: how much of each payment buys down principal, how much is interest, and what an extra payment changes. I built the schedule with an explicit month-by-month loop, including a guard for inputs that can never repay the balance.

The standard payment is only the starting point

The amortize function handles both ordinary interest-bearing loans and a zero-rate edge case:

function amortize(P, monthlyRate, baseN, extraPmt) {
  let payment;
  if (monthlyRate === 0) {
    payment = P / baseN;
  } else {
    const f = Math.pow(1 + monthlyRate, baseN);
    payment = (P * monthlyRate * f) / (f - 1);
  }
  let balance = P;
  let totalInterest = 0;
  let months = 0;
  const monthly = [];

The zero-rate branch is not optional. The usual formula divides by f - 1; when the rate is zero, that denominator is zero and the result becomes NaN. A principal divided by the number of months is the correct payment for that case.

The loop separates interest from principal

Each month calculates interest on the current balance, then applies the scheduled payment and optional extra amount:

const interest = balance * monthlyRate;
let principalPart = payment - interest + extraPmt;
if (principalPart > balance) principalPart = balance;
if (principalPart <= 0) break;
balance -= principalPart;
totalInterest += interest;
months += 1;
monthly.push({
  interest,
  principal: principalPart,
  balance: Math.max(balance, 0),
});

Clamping the last principal payment prevents the schedule from ending at a negative balance. The principalPart <= 0 check is the more important defensive detail: if a payment cannot cover interest, the balance will never shrink. Without a break, a malformed or impossible loan could make the browser hang in an infinite loop.

There is also a safety cap:

const maxMonths = baseN + 1200;
while (balance > 0.005 && months < maxMonths) {
  // ...
}

The cap is not a financial rule. It is a UI protection against pathological inputs.

Extra payments need a comparable baseline

The computed result runs the schedule once with the extra payment. If an extra amount was entered, it runs a second baseline schedule with zero extra:

if (extraPmt > 0) {
  const base = amortize(P, monthlyRate, baseN, 0);
  savedInterest = Math.max(
    base.totalInterest - totalInterest,
    0
  );
  savedMonths = Math.max(base.months - withExtra.months, 0);
}

That comparison is more useful than claiming an extra payment is “good.” It tells the user how many months and how much modeled interest the choice saves under the same principal, rate, and term.

Yearly rows are an aggregation, not a second calculation

The source walks the monthly array in groups of twelve, accumulating principalPaid, interestPaid, and the remaining balance. This keeps the chart and yearly table faithful to the exact monthly schedule. The headline total payment is P + totalInterest, not simply the advertised payment multiplied by the original term, because extra payments can shorten the schedule.

The limitations are important: rates are fixed, payments are monthly, there are no taxes, insurance, fees, refinancing, or lender-specific rounding rules. A positive extra payment is applied every month, not once. The result is a planning estimate, not a payoff quote from a bank.

Rounding and impossible loans deserve a visible policy

The internal schedule keeps fractional cents while it runs. That avoids accumulating a display-rounding error twelve times a year, but it also means the result may differ by a small amount from a lender that rounds interest on every statement. The UI formatter should be treated as presentation, not as a promise that a bank will accept the exact displayed payment.

The payment <= 0 check in the computed result is another useful boundary. A user can enter a positive principal and a negative rate, or otherwise create combinations that do not resemble a normal loan. Rather than force the loop to produce a confident-looking schedule, the view can return null when the payment cannot cover interest under the selected assumptions.

Extra payments are modeled as a monthly amount, which is a clear choice but not the only real-world choice. Some lenders apply a one-time payment immediately, some recast the payment, and some charge penalties. Those policies cannot be inferred from a generic form. The honest output is therefore “under this recurring-extra-payment model,” not “this is your official payoff date.”

If I needed lender-grade output, I would add a payment-date calendar, per-payment rounding rules, fees, and a configurable extra-payment event list. For a browser explainer, the current monthly array is a better foundation than pretending those details do not exist.

The yearly aggregation also handles a final partial year naturally. It loops until the monthly array is exhausted, so a loan paid off after 37 months produces four rows, with the last row containing only one month. That is more accurate than always multiplying a twelve-month average by four and is a nice example of why retaining the monthly schedule pays off.

Reading a schedule without confusing balance and interest

Each monthly entry carries three different ideas: the interest charged for that month, the principal removed in that month, and the balance left afterward. The yearly rows add the first two fields but carry forward the final balance. That distinction matters because cumulative interest is not the same thing as the current balance, and a chart with both lines can otherwise be surprisingly easy to misread.

The result also calculates payoff years with integer division and a remainder:

const payoffYears = Math.floor(withExtra.months / 12);
const payoffMonthsRem = withExtra.months % 12;

That presentation preserves a schedule such as 30 years and 6 months instead of rounding it to 31 years. It is a small example of keeping the internal month count authoritative while choosing a friendlier display unit afterward.

The extra-payment comparison follows the same principle. It does not pretend the extra amount changes the original contractual rate or term. It runs the same amortization logic twice, then reports the difference in months and modeled interest. If the user changes the extra payment to zero, the comparison disappears rather than showing a fabricated saving.

For testing, I would check the invariants rather than only one expected monthly payment: the balance should never become negative, each monthly principal amount should be no greater than the previous balance, and the final balance should be at or below the small stopping threshold. Those checks correspond directly to the defensive branches in the source and make regressions easier to diagnose.

I turned this amortization loop into a small free tool: Loan Amortization Calculator.

Why a Compound Interest Chart Should Simulate Contributions Period by Period

Joe Lin — Mon, 12 Oct 2026 13:00:06 +0000

A compound-interest formula can give you a final number quickly, but it can also hide whether deposits happen monthly, annually, or not at all. I built the calculator around a small simulation loop so the chart and yearly table explain where the final balance came from.

Normalize the inputs before doing finance math

The computed result converts the form values and clamps the horizon:

const P = Number(principal.value) || 0;
const r = (Number(annualRate.value) || 0) / 100;
const Y = Math.min(
  Math.max(Math.floor(Number(years.value) || 0), 1),
  80
);
const pmt = Number(contribution.value) || 0;
const n = Number(compoundFreq.value) || 1;
const contribPerYear = contributionFreq.value === "monthly" ? 12 : 1;
if (P <= 0 && pmt <= 0) return null;

The || 0 fallback keeps empty form fields from poisoning the chart with NaN. The one-to-eighty-year boundary is a product decision as much as a safety guard: a browser tool should not accidentally render millions of rows because someone pasted an unexpected value.

A period loop makes deposit timing explicit

The main calculation is intentionally straightforward:

let balance = P;
const periodsPerYear = n;
const ratePerPeriod = r / n;
const contribPerPeriod =
  (pmt * contribPerYear) / periodsPerYear;

for (let y = 1; y <= Y; y++) {
  for (let p = 0; p < periodsPerYear; p++) {
    balance =
      balance * (1 + ratePerPeriod) + contribPerPeriod;
  }
  const principalSoFar = P + pmt * contribPerYear * y;
  rows.push({
    year: y,
    principal: principalSoFar,
    interest: balance - principalSoFar,
    balance,
  });
}

This assumes each contribution is distributed evenly across compounding periods. With monthly deposits and monthly compounding, that is easy to understand. With annual contributions and twelve compounding periods, the contribution is divided into twelve equal pieces. That is not the only convention available—depositing at the beginning or end of a period changes the answer—but it is consistent and visible.

The table is a useful invariant

For every row, balance is the simulated account value, principal is the initial amount plus deposits, and interest is the difference. At the end, the same relationship produces the summary:

const totalPrincipal = P + pmt * contribPerYear * Y;
const totalInterest = finalAmount - totalPrincipal;
const multiple =
  totalPrincipal > 0
    ? (finalAmount / totalPrincipal).toFixed(2)
    : "—";

I like this approach because a user can inspect the yearly breakdown instead of trusting a single “you will have X” number. The Chart.js renderer maps the rows into principal and balance datasets, so the graph and table share one source of truth.

Rendering has a browser boundary

The chart code checks typeof window === "undefined" and chartCanvas.value before creating a Chart.js instance. It updates an existing chart when possible rather than creating a new canvas object on every reactive change. That matters in a Vue view with server rendering: chart construction belongs after mount, not during SSR.

The limitation is that this is a nominal, constant-rate projection. It does not model taxes, fees, inflation, variable returns, contribution timing inside a period, or withdrawals. A zero or negative annual rate can still be represented by the loop, but the result should not be read as a forecast. The tool is best used to compare assumptions consistently.

Why the loop is easier to audit than a single formula

There are closed-form annuity formulas for many contribution schedules, but the loop makes the product rules readable. contribPerYear says how many deposits the selected frequency represents, periodsPerYear says how often interest is applied, and the inner loop shows their interaction. When a user changes monthly contributions to annual contributions, the values change in one obvious place rather than in a formula with several timing conventions embedded inside it.

The loop also gives the chart a natural row boundary. Every row is created after one complete simulated year, so the table can report principal, interest, and balance without attempting to reverse-engineer those values from a final total. If a row looks surprising, I can log the period values and inspect the exact sequence of multiplications and deposits.

That transparency is useful even when the model is simple. Financial calculators often look authoritative because the final number has many digits. Showing the principal line and the balance line is a reminder that growth is an assumption multiplied repeatedly, not a promise. I would rather expose that assumption than hide it behind a more impressive formula.

One more practical detail is the handling of an existing Chart.js instance. The renderer updates labels and datasets when growthChart already exists, and creates it only when the canvas is ready. That avoids stacking canvases after every keystroke. When the component unmounts, destroying the chart is just as important as creating it; otherwise a reactive page can retain event handlers and canvas state after navigation.

This also gives the result a useful debugging shape. If the final amount looks wrong, I can compare the annual rows before inspecting the chart at all. A sudden jump in one row usually points to an input-frequency assumption or a period calculation, while a visually distorted chart may only be a rendering problem. Keeping the numerical rows independent from Chart.js means the finance logic remains understandable in a plain JavaScript test, without needing a canvas or a browser.

The calculator therefore answers a narrow question well: what happens when this starting amount, contribution pattern, rate, and compounding frequency are repeated for this bounded number of years? That is more honest than presenting one universal “compound interest formula” while silently assuming a deposit schedule. Changing one assumption at a time is the safest way to use the output.

I turned this simulation into a small free tool: Compound Interest Calculator.

How to Accumulate Safe Listening Dose Instead of Guessing Headphone Time

Joe Lin — Sun, 11 Oct 2026 13:00:04 +0000

“How many hours is safe?” has no single answer until volume is part of the question. I built a listening-time calculator that records each session, converts decibels into an allowed duration, and adds the day’s dose. The useful lesson is that a running health estimate needs a time boundary and an honest model, not just a big green percentage.

The reference point is an exponential rule

The source anchors the calculation at 85 dB for eight hours:

const REFERENCE_DB = 85;
const REFERENCE_HOURS = 8;

function allowedHours(db) {
  return REFERENCE_HOURS / Math.pow(2, (db - REFERENCE_DB) / 3);
}

function dosePercent(minutes, db) {
  const hours = Math.max(0, Number(minutes) || 0) / 60;
  return (hours / allowedHours(db)) * 100;
}

Each increase of three decibels halves the allowed time in this model. At 88 dB the same eight-hour intuition is no longer appropriate; at 100 dB the permitted duration becomes very short. Keeping the formula in named functions makes the assumption reviewable instead of hiding it in a template expression.

A volume slider is only an estimate

The tool supports direct dB input and a percentage mode. Percentage mode maps the control through a curve:

function estimateDbFromPercent(percent, maxDb) {
  const p = clampNumber(percent, 0, 100, 60) / 100;
  const max = clampNumber(maxDb, 85, 115, 103);
  const floorDb = 45;
  return Math.round(
    (floorDb + (max - floorDb) * Math.pow(p, 0.72)) * 10
  ) / 10;
}

This is not pretending that every phone reports calibrated sound pressure. It is a user-facing estimate with bounded inputs. clampNumber prevents a malformed value from producing NaN, and the maximum is limited to 115 dB so an accidental slider value does not create an absurd result.

Records are daily, not an infinite history

Adding a session stores the calculated dose and a local timestamp:

records.value.push({
  id: `sl_${Date.now()}_${Math.floor(Math.random() * 10000)}`,
  db,
  minutes,
  dosePercent: Math.round(dosePercent(minutes, db) * 10) / 10,
  listenTime: parseLocalInput(form.listenLocal),
  inputMode: inputMode.value,
});
filterTodayRecords();
persistRecords();

The computed total is simply the sum of stored doses:

const todayDosePercent = computed(() =>
  records.value.reduce((sum, record) => sum + record.dosePercent, 0)
);

On load and whenever the date key changes, records are filtered with getDateKey. That avoids showing yesterday’s exposure as today’s dose while still allowing the browser to keep the small saved state in localStorage.

The chart communicates overage differently

The doughnut chart uses one data shape until the dose passes 100 percent. Once it does, it switches from “dose plus remaining” to “100 plus overage.” That prevents a 160% dose from making the safe portion visually larger than the whole. A one-minute timer updates nowTick, which lets midnight trigger the date filter without requiring a page refresh.

There are real limitations. The dB percentage mapping is an estimate, headphones and phones measure differently, and the formula is an educational exposure model rather than medical advice. Records are also local to one browser and are discarded from the active list when their local calendar day changes. A user crossing time zones may see the boundary move, because getDateKey uses the device’s local date.

Why the daily boundary is part of the UX

The tool stores a date alongside records, but it does not trust that field alone when loading. It recalculates the date key from each listenTime and filters against the current local day. That choice is safer than assuming a saved JSON object is still current after the browser has been closed overnight. It also makes the behavior easy to explain: the summary is a view of records whose timestamps belong to today on this device.

The doughnut chart has its own edge-case policy. Dose is clamped to a display range of zero through 150 percent. Below 100, the slices are dose and remaining allowance. Above 100, the slices become a full 100 percent baseline plus the amount over. This is not changing the stored math; it is preventing the visualization from implying that an over-limit dose has “negative remaining” space.

I would not use the chart color as the only warning. The computed status class changes at 80 and 100 percent, and the text also reports safe, near-limit, or over-limit states. That redundancy matters for readers who cannot distinguish the colors or who are reading the page with a screen reader. A health-oriented interface should make the numeric dose and the assumption behind it available even when the chart is ignored.

The form also resets the local timestamp after a successful add. That tiny interaction detail reduces a common data-entry error: entering several sessions while accidentally reusing the time of the first one. The stored record keeps both the original input mode and the resolved dB value, so later display or debugging can tell whether a number came from direct dB entry or the estimate curve.

What the dose number does and does not mean

The dose percentage is additive because each record represents a share of the allowed exposure at its own level. A short loud session can therefore consume more of the day’s allowance than a much longer quiet session. The implementation does not average the dB values first; that would lose the important fact that the allowed duration changes nonlinearly with level.

The current dB value also drives the “remaining hours” text separately from the accumulated records. It calculates the remaining dose as Math.max(0, 100 - todayDosePercent) and applies that fraction to allowedHours(currentDb). Once the total reaches or exceeds 100 percent, the remaining value cannot become negative. That is a display and guidance boundary, while the individual records still retain their calculated dose values for the chart and list.

This separation is useful when explaining the interface to someone implementing a similar feature. A progress bar can be bounded for readability, but the underlying measurements should remain inspectable. It also avoids a misleading reset: changing the current form’s volume does not rewrite older records. Only a newly added record uses the current dB estimate and minutes.

Finally, the local persistence is intentionally modest. persistRecords stores JSON under one versioned key and catches storage failures, while loadRecords falls back to an empty list if the saved value cannot be parsed. There is no account, cloud backup, or device synchronization. That keeps the tool private and simple, but a user should not treat it as a permanent medical record.

I turned the calculation into a small free tool: Safe Listening Time Calculator.

Why Two’s Complement Conversion Needs More Than `parseInt`

Joe Lin — Sat, 10 Oct 2026 13:00:04 +0000

When I first wrote a signed-binary converter, the obvious implementation was “call toString(2) and let JavaScript do the rest.” That works for positive integers, but it hides the two decisions a useful converter must expose: whether a value fits a chosen width, and which interpretation of the leading bit the reader wants. The Be Good Tool converter keeps those steps explicit.

A bit width changes the valid range

For N signed bits, the range is -2^(N-1) through 2^(N-1)-1. The source checks that before formatting:

function limitNum(num, numLen) {
  const baseNum = 2 ** (numLen - 1);
  const maxNum = baseNum - 1;
  const minNum = 0 - baseNum;
  let checkResult = num > maxNum || num < minNum ? 0 : 1;
  const maxNum2 = baseNum;
  const minNum2 = 0 - baseNum;
  if (checkResult === 0 && num <= maxNum2 && num >= minNum2) {
    checkResult = 2;
  }
  return checkResult;
}

The second check distinguishes a value outside the signed range but still inside the unsigned boundary. That gives the UI enough information to explain the failure instead of silently wrapping. For eight bits, 127 is valid signed input, 128 is not signed input, and -128 is valid signed input. Treating those as a symmetric abs(value) check would be wrong.

Padding is part of the representation

The converter first uses the magnitude:

function toBinary(num) {
  return Math.abs(num).toString(2);
}

function fillBitWith_0_Signed(numBinary, bitLen) {
  return numBinary.padStart(bitLen, "0");
}

Padding is not cosmetic. Without it, 5 could be displayed as 101, but the eight-bit complement of the same number needs 00000101. The selected width determines which bit becomes the sign bit and therefore changes the meaning of every later operation.

One’s complement and two’s complement are string algorithms

The source keeps the bits as strings so leading zeroes survive:

function notString(numBinary) {
  const out = [];
  for (let i = 0; i < numBinary.length; i++) {
    parseInt(numBinary[i]) ? out.push("0") : out.push("1");
  }
  return out.join("");
}

function one2two(numFullBinary) {
  const bits = numFullBinary.split("");
  for (let i = numFullBinary.length; i > 0; i--) {
    if (parseInt(numFullBinary[i - 1])) bits[i - 1] = "0";
    else {
      bits[i - 1] = "1";
      return bits.join("");
    }
  }
  return numFullBinary;
}

notString flips each bit for one’s complement. one2two walks from the right, turning trailing ones into zeroes until it finds a zero to turn into one. It is the same carry propagation a hardware adder performs, but visible in JavaScript. Returning the original all-ones string documents the fixed-width overflow case instead of expanding the result.

Converting back requires choosing an interpretation

For a two’s-complement bit string, the first bit has negative weight:

function bin2Dec_2(para) {
  const bits = (para || inputNumber.value + "").toString().split("");
  let value = bits[0] * -(2 ** (bits.length - 1));
  for (let i = bits.length - 2; i >= 0; i--) {
    value += bits[bits.length - 1 - i] * 2 ** i;
  }
  return value;
}

The UI also reports ordinary parseInt(numBin, 2), one’s-complement decimal, and the recovered source patterns. That is useful when debugging a protocol or a fixed-width serialization, because the same characters can represent different numbers under unsigned, one’s-complement, and two’s-complement rules.

The limitation is deliberate: input is restricted to safe JavaScript integers and a positive bit length. Extremely large widths can make 2 ** (N - 1) lose numeric precision, and a binary string is still validated as characters rather than a BigInt. This is a teaching and inspection tool, not an arbitrary-precision binary library.

The awkward zero and overflow cases matter

Fixed-width representations contain edge cases that are easy to hide in a polished result. The source treats "-0" specially while producing complement output, because one’s complement has both positive and negative zero patterns while two’s complement does not. That is exactly the kind of detail a generic integer conversion API will erase.

There is another useful distinction in the reverse direction. bin2Dec_res first validates that every character is either "0" or "1", then reports an unsigned parseInt result. Only when the leading bit is one does it add the signed one’s- and two’s-complement interpretations. This ordering lets a reader compare representations without claiming that one interpretation is universally correct.

The converter also groups decimal-looking output with spaces using format, but that formatting is presentation only. It must never be fed back into the binary validation path because spaces are not bits. Separating the displayed grouping from the stored string is a small rule that prevents copy-and-paste bugs.

If I extended this implementation, I would use BigInt or a dedicated bit-string arithmetic layer for widths beyond safe-number precision. I would also make signed versus unsigned mode a first-class label rather than relying on the result rows. The current version is intentionally compact, but its explicit range check is already a good reminder: representation is part of the input, not an afterthought.

Why keeping both directions in one tool helps

The forward and reverse operations also make a useful sanity check for each other. I can enter a decimal value, choose a width, copy the displayed bit pattern, and send that pattern through the binary-to-decimal path. For a valid signed pattern, the two’s-complement interpretation should return the expected value, while the ordinary unsigned interpretation may deliberately return something else. Seeing both numbers makes the sign bit concrete instead of leaving it as a rule to memorize.

The width must remain attached to that experiment. 00000101 and 101 contain the same visible one bits, but they do not describe the same fixed-width signed representation. In the shorter string, the first bit is one and therefore carries negative weight under the signed two’s-complement function. This is why the converter pads before calculating complements and why trimming leading zeroes would destroy useful information.

I also prefer the explicit loops here over relying on JavaScript bitwise operators. JavaScript bitwise operators coerce values to signed 32-bit integers, which would make an apparently arbitrary bit-length input quietly behave like a 32-bit operation. The source’s string operations avoid that particular coercion and make the selected width visible in every result. They do not solve arbitrary precision, but they preserve the educational behavior the interface promises.

I turned this implementation into a small free tool: Two’s Complement Calculator.

How a Tool Directory Stays Useful When It Has Too Many Tools

Joe Lin — Fri, 09 Oct 2026 13:00:04 +0000

The hardest part of a small utility site is not adding one more calculator. It is helping a visitor find the right one without making them learn the site's architecture first. I built the Be Good Tool home page as a real Vue view, and the interesting engineering problem became keeping navigation, search, metadata, and responsive layout connected without duplicating the catalogue.

The home page is data, not a pile of links

The view imports a list composable and turns it into translated links:

const List = useList(store.state.isSSR);
const linkList = computed(() => getExchangeList(t));

useList supplies the main catalogue while getExchangeList(t) supplies the exchange-related links. Keeping those sources separate matters: the component can render a common navigation shell while each list owns its own data shape and translation keys. The computed wrapper also means a locale change can produce new labels without rebuilding the page manually.

I use the store's isSSR flag when creating the list because this view is rendered both on the server and in the browser. A composable that reads browser-only state during server rendering can produce a different first HTML tree, which is exactly the kind of mismatch that looks random in production. Passing the rendering mode explicitly makes that boundary visible.

Search and navigation have different jobs

The template contains a SearchBox component for discovery, but it still renders ordinary router-link elements for navigation. That distinction is easy to miss. Search is an input interaction; a catalogue link is a stable URL that the browser, keyboard, crawler, and back button can understand. I do not turn the whole directory into click handlers just because the page feels like an app.

The page also has announcement links and a few disabled “coming soon” entries. They are intentionally not fake routes. A disabled anchor with href="#" communicates that an item is visible but unavailable, instead of sending a visitor to a broken route. The trade-off is that those placeholders need careful accessibility treatment later; a real button or non-link element would be better if the item is never actionable.

Structured data must agree with the visible page

The view emits two JSON-LD blocks. The first describes the store:

const jsonld = JSON.stringify({
  "@context": "https://schema.org",
  "@type": "Store",
  name: t("message.site_name"),
  url: t("message.canonical"),
  description: t("message.description"),
  brand: "Be Good Tool",
  priceRange: "$",
});

The important detail is that url, name, and description come from the active locale. Metadata that always points at one language while the visible page changes language is internally contradictory. The component also includes an @type: "Review" object, so changing this view requires checking both the rendered content and the generated head/schema output.

Responsive visuals are part of the information design

The banner uses a desktop image and a mobile source:

<picture>
  <source media="(max-width: 768px)" :srcset="newBg" />
  <img class="banner__bg" :src="bg2" :srcset="`${bg2} 1440w`" sizes="100vw" />
</picture>

This is a small but practical performance choice. A phone does not need to download the exact same composition as a wide screen, and <picture> lets the browser make that decision before JavaScript runs. It also leaves an actual img fallback for browsers that do not use the media source.

The limitation is that a directory can still become overwhelming as the catalogue grows. Computed lists do not solve information architecture, and the current disabled placeholders are not a substitute for a proper category or filter model. The home page also embeds a hard-coded address and telephone number in JSON-LD, so those values must be reviewed whenever the business information changes.

What I would test before adding more entries

I would test this page at three different boundaries: server rendering, a language switch, and a narrow viewport. In the first case I want the list and metadata to exist without browser globals. In the second I want every translated URL to stay stable while labels change. In the third I want the <picture> source and the grid styles to avoid horizontal scrolling. These are not glamorous tests, but directory regressions are often navigation regressions rather than algorithm bugs.

I would also keep the source of each card explicit. A home page that copies every tool title into one giant component eventually develops spelling drift: the route says one thing, the card says another, and the search result says a third. The current view already moves in the better direction by delegating list data to useList and exchange links to getExchangeList. If categories or ranking are added later, I would extend those data providers instead of creating another parallel array in the template.

That approach keeps the home page a composition layer. It can decide where a section appears and how it responds, while the data and translation layers decide what a link means. For a growing utility site, that separation is more valuable than another decorative banner.

I turned this catalogue into the live home page: Be Good Tool Home.

Bulk Buy Calculator

Joe Lin — Thu, 08 Oct 2026 13:00:04 +0000

The shelf tag says “30% off,” so the bulk option must be cheaper—right? That shortcut ignores the units that expire, the cupboard space they occupy, and the cash that could have stayed in savings. I built this calculator around a less exciting but more useful question: after waste, storage, and opportunity cost, what does each usable unit really cost?

The inputs are deliberately personal. The tool does not invent an average household waste rate. You provide the expected waste, daily usage, shelf life, storage cost, and annual opportunity-cost rate, then inspect the assumptions behind the verdict.

Start With Two Comparable Purchases

The form asks for a single-unit price, bulk unit price, bulk quantity, daily usage, shelf life, expected waste rate, monthly storage cost, and opportunity-cost rate. Calculation is disabled until the two prices, quantity, and daily usage are positive:

const canCalc = computed(() =>
  singlePrice.value > 0 &&
  bulkPrice.value > 0 &&
  bulkQty.value > 0 &&
  dailyUse.value > 0
);

The discount badge is only a headline comparison:

const discountPct = computed(() => {
  if (!singlePrice.value || !bulkPrice.value ||
      singlePrice.value <= 0 || bulkPrice.value < 0) {
    return null;
  }
  return ((singlePrice.value - bulkPrice.value) / singlePrice.value) * 100;
});

The real calculation begins with the quantity that is expected to be wasted. If you buy 20 units and enter a 10% waste rate, wasted is two and usableQty is 18. The waste rate slider runs from 0 to 80 percent, but the meaning still comes from your habits: food expiry, changing needs, duplicate supplies, and anything else that makes a purchased unit unusable.

Turn Hidden Costs Into the Same Currency

The core is a direct accumulation of costs:

const qty = bulkQty.value;
const wasted = qty * (wasteRate.value / 100);
const usableQty = qty - wasted;
const wastedMoney = wasted * bulkPrice.value;

const daysToConsume = usableQty / dailyUse.value;
const monthsToConsume = daysToConsume / 30;
const storageTotal =
  (storageCost.value ?? 0) * monthsToConsume;

const totalUpfront = bulkPrice.value * qty;
const oppCost =
  totalUpfront *
  (oppCostRate.value / 100) *
  (monthsToConsume / 12);

const totalBulkCost =
  totalUpfront + wastedMoney + storageTotal + oppCost;
const effectiveUnitCost = usableQty > 0
  ? totalBulkCost / usableQty
  : totalBulkCost / qty;

Storage is charged for the time needed to consume the usable quantity, using 30 days per month. Opportunity cost is simple annualized interest on the entire upfront bulk payment for that same duration. This is not compound interest and it does not model a changing balance; it is an intentionally understandable estimate.

The comparison baseline is the single-unit price multiplied by the full bulk quantity:

const totalSingleCost = singlePrice.value * qty;
const savings = totalSingleCost - totalBulkCost;
const roi = totalSingleCost > 0
  ? (savings / totalBulkCost) * 100
  : 0;

The result therefore answers “what if I bought this many units individually?” rather than “what if I bought only the units I will use?” That keeps the comparison fair to the actual quantity on the receipt.

Break-Even Waste Is a Sensitivity Question

The displayed break-even waste rate tells you how much waste would erase the apparent savings:

const oppCostNoWaste =
  totalUpfront *
  (oppCostRate.value / 100) *
  (monthsToConsume / 12);
const numerator =
  totalSingleCost - totalUpfront -
  storageTotal - oppCostNoWaste;
const denominator = qty * bulkPrice.value;
const breakEvenWaste = denominator > 0
  ? (numerator / denominator) * 100
  : -1;

There is a subtle approximation here. The comments in the source explicitly simplify the formula by ignoring how changing waste changes the consumption time, and therefore storage and opportunity cost. The number is a useful “how fragile is this deal?” indicator, not a mathematically exact solution to the full model.

Shelf life is checked separately. The warning computes qty - dailyUse * shelfLife, clamps it at zero, and reports leftover units. It does not subtract the waste rate in this warning, so treat it as a simple usage-versus-expiry signal rather than a second waste forecast.

The controls expose the assumptions instead of hiding them in a recommendation. Waste is a percentage slider, storage can be zero, and opportunity cost is an annual percentage slider; the English labels even explain that the waste estimate should come from your own habits. Results then show effective unit cost, wasted money, storage total, opportunity cost, both purchase totals, savings, ROI, and the break-even waste rate. That list is useful for a quick sensitivity check: if opportunity cost is nearly zero but storage is high, changing the interest rate should not magically make the deal good.

The Verdict Has a Clear Threshold

The labels are intentionally modest. Bulk buying is Worth It only when savings are positive and ROI is at least 5 percent. A negative saving is Not Worth It; all remaining cases are Borderline. That last category matters when a tiny discount disappears after one bad assumption.

Try changing only one input at a time. If moving waste from 5% to 15% flips the verdict, the purchase is sensitive to behavior, not a guaranteed bargain. Also remember that the tool rounds displayed numbers to one decimal place, so use the underlying assumptions rather than the visual rounding when comparing very close deals.

I turned this calculation into a small free tool: Bulk Buy Calculator. It is a quick way to make expiry, storage, and tied-up cash visible before a discount turns into clutter.

Gadget Replacement Calculator

Joe Lin — Wed, 07 Oct 2026 13:00:05 +0000

“Should I replace this device?” sounds like a price comparison, but a cheap upgrade can still be a poor decision if the current device is inexpensive to keep or the new device carries a large manufacturing footprint. I built this calculator for a more explicit comparison: put the financial break-even point beside a rough carbon payback point, then see whether both axes agree.

The result is not a universal upgrade rule. It is a transparent model whose assumptions you can change: device type, resale value, repair cost, satisfaction score, expected lifespan, manufacturing CO₂, power draw, and daily usage.

The Current Device Is a Monthly Cost Model

The form supports smartphones, laptops, tablets, and desktop PCs. Selecting a type updates two defaults:

const CO2_DEFAULTS = {
  smartphone: 70,
  laptop: 300,
  tablet: 90,
  desktop: 700,
};
const POWER_DEFAULTS = {
  smartphone: 5,
  laptop: 15,
  tablet: 8,
  desktop: 80,
};

function setDeviceType(key) {
  deviceType.value = key;
  mfgCo2.value = CO2_DEFAULTS[key];
  powerWatts.value = POWER_DEFAULTS[key];
}

If no positive resale value is entered, the calculator estimates one with straight-line depreciation from the purchase price:

const resale = currentResale.value > 0
  ? currentResale.value
  : Math.max(
      0,
      purchasePrice.value *
        (1 - ageMonths.value / (newLifespan.value * 12))
    );

That fallback is intentionally visible in the source: it uses the new device's expected lifespan as the time scale for the estimate. The keep-cost model then adjusts remaining months by the satisfaction score, never allowing less than one month:

const remainingMonths = Math.max(
  (expectedLifeMonths - ageMonths.value) * (perfScore.value / 10),
  1
);
const monthlyDepreciation = resale / remainingMonths;
const monthlyCostKeep = monthlyRepair.value + monthlyDepreciation;

The new device's monthly cost is simply its price divided by its expected lifespan in months. If keeping the old device is cheaper per month, there is no financial benefit and moneyBreakEven becomes -1. Otherwise the upfront amount is the new price minus the resale value, divided by monthly savings and rounded up.

Carbon Payback Uses an Explicit Assumption

The carbon side estimates annual savings from reduced power use:

const co2PerKwh = 0.5;
const extraPowerWatts =
  powerWatts.value * (efficiencyLoss.value / 100);
const annualCarbonSaved =
  (extraPowerWatts / 1000) *
  usageHours.value *
  365 *
  co2PerKwh;
const carbonBreakEven = annualCarbonSaved > 0
  ? Math.ceil((mfgCo2.value / annualCarbonSaved) * 12)
  : 9999;

The 0.5 value is treated as kilograms of CO₂e per kilowatt-hour, described in the interface as a world-average estimate. It is not a measurement of your local grid. Manufacturing emissions are editable because the built-in reference values—roughly 70 kg for a phone, 300 for a laptop, 90 for a tablet, and 700 for a desktop—are estimates rather than certified product data.

The model asks a narrow question: if the current device consumes efficiencyLoss percent more power than a replacement, how long would the saved electricity take to offset manufacturing emissions? It does not count transport, recycling, repair parts, battery degradation, or the rebound effect of using a more powerful device.

The Verdict Is a Two-Axis Policy

The calculator labels a result replace only when financial break-even is positive and at most 24 months and carbon payback is at most 36 months. It labels a result keep when the money calculation does not favor replacement or takes more than 36 months, and carbon payback is over 48 months. Everything else is borderline:

const moneyFavorsReplace =
  moneyBreakEven > 0 && moneyBreakEven <= 24;
const carbonFavorsReplace =
  annualCarbonSaved > 0 && carbonBreakEven <= 36;
const moneyFavorsKeep =
  moneyBreakEven < 0 || moneyBreakEven > 36;
const carbonFavorsKeep = carbonBreakEven > 48;

if (moneyFavorsReplace && carbonFavorsReplace) {
  verdict = "replace";
} else if (moneyFavorsKeep && carbonFavorsKeep) {
  verdict = "keep";
}

Those thresholds are policy choices, not laws of economics or climate science. The UI also shows both monthly costs, the calculated break-even months, manufacturing carbon, annual carbon saved, and the two small bar comparisons, so you can disagree with the label without losing the underlying numbers.

The interface keeps the two questions visible instead of collapsing them into one score. The financial card reports the monthly cost to keep and the monthly amortized cost of the new device, while the carbon card reports manufacturing emissions and annual savings. A device can therefore be financially attractive but environmentally slow to pay back, or the reverse. The borderline state is not a calculation failure; it is the expected output when the chosen thresholds disagree or neither side is decisive.

Where the Model Can Mislead

Straight-line depreciation is a convenient approximation, not a resale-market forecast. A device can have a sudden battery failure, retain value unusually well, or be worth nothing while still working. The satisfaction score changes the remaining-life estimate, which makes it a subjective input rather than a measured performance benchmark. A device older than the assumed lifespan is clamped to one remaining month instead of producing a special “already beyond life” state.

Carbon payback becomes infinite when annual savings are zero, and all carbon values are estimates. Treat the result as a conversation starter and sensitivity test: change the resale value, repair cost, efficiency loss, and usage hours to see which assumptions actually control the recommendation.

I turned this model into a small free tool: Gadget Replacement Calculator. It is useful when a purchase decision needs more than “the new one has a lower monthly payment.”