DEV Community: ggwork

Building a Position Averaging Calculator: Getting the Math Right Matters

ggwork — Tue, 01 Sep 2026 01:37:42 +0000

Last week, I found myself staring at a spreadsheet trying to figure out my average cost after buying the same stock three times at different prices. You know the drill — you buy at 10, it drops, you buy more at 8, then it dips again and you're thinking about averaging down further. The math isn't hard, but it's tedious, and I kept second-guessing whether I was accounting for fees correctly.

The Problem with Existing Solutions

I searched for online calculators, and honestly, most of them were disappointing. Either they required sign-up, were buried in financial portal websites with more ads than functionality, or they ignored trading fees entirely. A few had the fee calculation, but they made assumptions that didn't match how my broker actually charged me.

The real issue? Most calculators ignore the fact that your break-even price isn't just your average cost. When you sell, you pay fees too. So if your average cost is 9.0051, you can't actually break even by selling at 9.0051 — you need to sell slightly higher to cover the sell-side fees.

That's the gap I wanted to fill.

The Core Math

The calculation itself is straightforward weighted averaging, but the fee handling is where things get interesting. Here's the essential logic:

function compute(buys, currentRaw, commRate, stampRate, transferRate, minComm, sym) {
  let totalShares = 0, totalCost = 0;

  for (const { price, shares } of buys) {
    const amt = price * shares;
    const fee = amt * (commRate + transferRate) / 100;
    const actualFee = Math.max(fee, minComm);
    totalCost += amt + actualFee;
    totalShares += shares;
  }

  const avgCost = totalCost / totalShares;
  // Break-even includes sell-side fees
  const sellFeePerShare = avgCost * (commRate + stampRate + transferRate) / 100;
  const breakEven = avgCost + sellFeePerShare;

  return { totalShares, totalCost, avgCost, breakEven };
}

The key insight here is the break-even calculation. Most tools stop at avgCost, but that's misleading. If you sell at your average cost, you'll actually lose money because of sell-side fees. The break-even price needs to be slightly higher — it's the price where your sell proceeds (after fees) exactly equal your total buy cost (including buy fees).

Why I Chose Pure Frontend

I could have built this with a backend. I could have added user accounts, saved calculation history, all that stuff. But honestly, this is a privacy-sensitive calculation. Do you really want your stock positions floating around on some server?

Pure frontend means:

No data leaves the browser
No server costs for me
Instant load times
Works offline

The trade-off? No persistent history, no cross-device sync. For this use case, that's a trade-off I'm comfortable with. If you need to save results, just screenshot it.

The AI-Assisted Development Experience

This is where it gets interesting. I built this with heavy AI assistance, and the experience was... educational.

What AI Got Right

I described the requirements conversationally: "I need a calculator that takes multiple buy records with price and shares, calculates weighted average cost including fees, and shows break-even price." The AI generated a solid initial structure — the HTML layout, the dynamic row addition, the basic styling. It even handled the dark mode CSS without me asking.

Where AI Struggled

The first version had a subtle bug in the fee calculation. It was applying the minimum commission to every trade individually, which is correct, but it was also applying the minimum to the sell fee estimation in the break-even calculation. That's wrong — the minimum commission should only apply if the trade actually happens.

Here's the conversation that followed:

Me: The break-even price is too high. If I buy 100 shares at 10 with a 5 yuan minimum commission, the break-even shouldn't include the minimum commission because the sell fee is proportional to the sell amount.

AI: You're right. Let me fix the break-even calculation to use the percentage rate only, not the minimum.

This is the pattern I've noticed with AI coding — it's great at generating the 80% solution, but the edge cases and financial logic accuracy require human domain knowledge. The AI doesn't "know" that minimum commissions don't apply proportionally; it just patterns from typical code.

Another AI Miss: Input Validation

The AI initially assumed all inputs would be valid numbers. It took me pointing out that someone might type "abc" or leave a field empty before it added proper validation. And even then, the first validation attempt was too aggressive — it blocked legitimate edge cases like zero shares (which should be an error, but the error message was confusing).

The Refinement Process

After the initial AI-generated version, I went through several iterations:

Fixed the fee calculation — the minimum commission logic needed adjustment for the break-even price
Added input validation — with clear error messages in Chinese (the tool targets Chinese-speaking users)
Improved the UX — the first version had all inputs on one line, which was cramped on mobile. I restructured to a grid layout that stacks on small screens.
Added the optional current price field — this lets users see floating profit/loss without needing a separate calculator

The floating P&L calculation was another spot where I had to correct the AI:

// AI's first version — wrong
const floatPL = currentPrice * totalShares - totalCost;

// Correct version — includes sell fees
const sellFee = currentPrice * totalShares * (commRate + stampRate + transferRate) / 100;
const floatPL = currentPrice * totalShares - sellFee - totalCost;

The difference matters. If you're showing someone their unrealized profit, it should reflect what they'd actually get if they sold right now, not a naive price-minus-cost calculation.

Lessons Learned

1. Domain Knowledge Still Matters

AI can write code, but it can't know that in Chinese stock markets, there's a stamp tax on sells (0.05%) that doesn't apply to buys, or that some brokers have a 5 yuan minimum commission. These domain-specific rules are where human input becomes critical.

2. Test with Real Numbers

The AI generated test cases, but they were too clean. I had to create edge cases myself:

What if the user enters a price of 0?
What if shares are negative?
What if the commission rate is 0 but the minimum is 5?
What about very small trades where the minimum commission dominates?

These edge cases exposed bugs that would have shipped otherwise.

3. AI Is Great for UI, Less Great for Logic

For this project, the AI's HTML/CSS was immediately usable. The JavaScript logic needed multiple rounds of correction. I've found this pattern holds across projects — AI excels at structure and boilerplate, but business logic requires careful human review.

The Result

After several hours of iteration, I had a working tool that handles the edge cases I care about:

Multiple buy records with dynamic add/remove
Commission, stamp tax, and transfer fees included in cost
Break-even price that accounts for sell-side fees
Optional current price for floating P&L
Dark mode (because I'm a developer, of course I added dark mode)
Pure frontend — no data leaves the browser

The calculation runs in milliseconds, the UI is responsive, and the whole thing is a single HTML file. No build step, no dependencies, no server.

Final Thoughts on AI-Assisted Development

This project reinforced my belief that AI coding tools are incredibly useful, but they're not a replacement for understanding the problem domain. The AI saved me maybe 60% of the time compared to writing everything from scratch, but the remaining 40% required me to actually understand what the tool needed to do.

The pattern I've settled into:

Describe the problem clearly to the AI — the more specific, the better
Review all generated logic carefully — especially anything involving money or dates
Create edge case tests — the AI won't do this for you
Iterate with targeted prompts — "fix the fee calculation" works better than "something's wrong"

If you're building a similar tool, whether it's a calculator or something else, the same principles apply. AI gets you 80% there quickly, but the last 20% is where the real engineering happens.

During this process, I built a small browser-based tool to make this workflow easier. It's free to use, handles all the fee calculations correctly (I hope), and respects your privacy since everything runs locally in your browser. If you're curious, you can find it here.

Now if you'll excuse me, I need to go check whether my actual average cost matches what the calculator says. Spoiler: it probably won't, because my broker's fee structure is apparently a mystery even to their own support team.

How to Calculate Exact Age in the Browser Without Cheating with Math

ggwork — Mon, 31 Aug 2026 09:41:34 +0000

While working on a utility site recently, I needed a precise age calculator. Sounds trivial, right? Pick two dates, subtract, done. Except it's not. The moment you try to calculate "25 years, 3 months, and 12 days" accurately, you realize that naive date arithmetic is a rabbit hole of edge cases.

Let me walk you through the engineering decisions that turned a seemingly simple tool into a proper date-handling exercise.

The Problem with Simple Subtraction

Here's the trap I initially fell into:

const ageInMilliseconds = Date.now() - birthDate.getTime();
const ageInYears = ageInMilliseconds / (365.25 * 24 * 60 * 60 * 1000);

This works... until it doesn't. The 365.25 days approximation drifts. Leap years aren't uniform. And try explaining to a user born on February 29th why their age is "wrong" on non-leap years.

The real issue is that calendars aren't arithmetic — they're cultural constructs with rules. Months have different lengths. Leap years follow a specific pattern. You can't just divide milliseconds by a constant and get a meaningful answer.

The "Correct" Way: Component-wise Calculation

The key insight is to calculate years, months, and days separately, adjusting for borrows like you learned in elementary school subtraction:

function calculateAge(birthDate, targetDate) {
  let years = targetDate.getFullYear() - birthDate.getFullYear();
  let months = targetDate.getMonth() - birthDate.getMonth();
  let days = targetDate.getDate() - birthDate.getDate();

  if (days < 0) {
    months--;
    days += daysInMonth(targetDate.getFullYear(), targetDate.getMonth() - 1);
  }
  if (months < 0) {
    years--;
    months += 12;
  }
  return { years, months, days };
}

This is the part that matters — the borrow logic. When your birthday hasn't happened yet this month, you borrow days from the previous month. When it's not your birthday month yet, you borrow months from the previous year. Simple, elegant, and handles all the calendar weirdness correctly.

The Birthday Problem

The next challenge was calculating days until the next birthday. The naive approach:

const nextBirthday = new Date(today.getFullYear(), birthDate.getMonth(), birthDate.getDate());

This breaks for people born on February 29th. What's their birthday in non-leap years? March 1st? February 28th?

The pragmatic answer: check if the birthday exists in the current year; if not, use March 1st. It's not perfect, but it's predictable and defensible:

function getBirthdayInYear(year, birthMonth, birthDay) {
  const date = new Date(year, birthMonth, birthDay);
  if (date.getMonth() !== birthMonth) {
    return new Date(year, 2, 1); // March 1st
  }
  return date;
}

The Real-Time Seconds Problem

Here's where things get interesting. I wanted to show total seconds alive, and it needed to tick in real-time. The naive approach would recalculate everything every second. That's wasteful and causes jank.

The solution: calculate the static values once, then only update the seconds display:

let totalSeconds = initialSeconds;
setInterval(() => {
  totalSeconds++;
  document.getElementById('totalSeconds').textContent = formatNumber(totalSeconds);
}, 1000);

This is a micro-optimization, but it's the kind of thinking that prevents your tool from feeling sluggish. The rest of the calculation happens once; only the seconds counter updates.

The AI Collaboration Experience

Now for the part that made this project actually fun — building it with AI assistance. I've been experimenting with using AI as a pair programmer for utility tools, and this was a perfect test case.

The First Attempt

I gave the AI my requirements: "Create a single-file HTML age calculator with precise year/month/day calculation, total days/hours/minutes, and next birthday countdown."

The AI's first attempt was... surprisingly good. It nailed the structure, the styling, and the basic logic. But it had one critical bug: it used the millisecond division approach for age calculation. The output looked right for most dates, but it was subtly wrong for edge cases.

The Iteration Process

This is where the real collaboration began. Instead of pointing out the bug directly, I asked:

"What happens for someone born on February 29th, 2000, calculating age on March 1st, 2024?"

The AI paused, recalculated, and immediately recognized the issue. It suggested the component-wise approach. But its first implementation had a bug in the borrow logic — it didn't handle the case where the target date's month has fewer days than the birth month's day.

I had to guide it through the borrow logic step by step. The AI was great at generating code quickly, but it struggled with the edge case reasoning that comes naturally to experienced developers. It would optimize for the common case and miss the exceptions.

What Worked Well

The AI excelled at:

Generating the complete HTML structure with proper i18n support
Creating responsive CSS with dark mode support
Writing the structured data for SEO
Implementing the real-time seconds counter

Where I Had to Step In

The AI struggled with:

Calendar edge cases (February 29th, month-end boundaries)
The borrow logic in date arithmetic
Understanding that not all dates are valid in all years

The i18n Trap

One thing the AI got right from the start: proper internationalization. It automatically used a key-value system with data-i18n attributes and a JavaScript dictionary. This was smart because it anticipated the need for multiple languages without over-engineering.

The language detection logic is simple but effective:

const lang = new URLSearchParams(window.location.search).get('lang') 
  || navigator.language.startsWith('en') ? 'en' : 'zh';

URL parameter takes priority, then browser language, then default to Chinese. This pattern is simple enough to be maintainable but powerful enough for edge cases.

Lessons Learned

1. Calendar math is deceptively complex. What looks like a simple subtraction problem has more edge cases than you'd expect. Always test with boundary dates.

2. AI is a great pair programmer, but not a replacement for understanding. The AI generated code quickly, but I had to understand the domain deeply to guide it correctly. It's like having a brilliant intern who's fast but needs supervision.

3. Real-time features need incremental updates. Don't recalculate everything when you only need to update one value. Think about what actually needs to change.

4. Internationalization should be baked in from the start. Retrofitting i18n is painful. Designing for it from day one is barely any extra work.

The Result

I ended up with a clean, single-file tool that handles all the date edge cases correctly. It's fast, responsive, and works in both Chinese and English. The whole thing is about 300 lines of HTML/CSS/JS — no frameworks, no dependencies.

During this process, I built a small browser-based tool to make this workflow easier. You can find it at craftvo.app if you want to see the final result.

The real takeaway isn't about age calculators specifically. It's about the mindset: don't trust naive arithmetic when dealing with human constructs like calendars. And when using AI assistance, remember that it's a tool for accelerating your thinking, not replacing it. The best results come from understanding the problem deeply and using AI to execute your understanding faster.

Building an ASCII Table Tool: Why I Ditched the Spreadsheet and Made My Own

ggwork — Mon, 31 Aug 2026 01:57:27 +0000

I was debugging a network protocol implementation last month when I hit a wall. I needed to quickly verify what byte value corresponded to a specific control character — was it 0x1B for ESC or was that 0x1C? My go-to approach was to open a random ASCII chart website, but every single one I found was either:

Buried in ads and popups
Missing the control characters entirely (you know, the actually useful ones)
So cluttered with unnecessary features that the table was half the screen

So I did what any reasonable developer would do: I spent an afternoon building my own. Because apparently I enjoy reinventing wheels.

The Initial Approach: Data First, UI Later

The first decision was the data structure. I needed all 128 standard ASCII characters (0-127), each with:

Decimal, hex, octal, and binary representations
HTML entity (for the printable ones)
Standard name (like "Capital A" or "Line Feed")

I started by hardcoding an array of objects:

const ASCII_CHARS = [
  { dec: 0, name: 'NUL', control: true },
  { dec: 65, name: 'Capital A', char: 'A' },
  // ... 126 more entries
];

This was tedious but straightforward. The real challenge came with control characters — you can't just display \x00 and expect users to know what it means. I needed proper names: NUL, SOH, STX, and so on.

The AI Collaboration: Where It Helped and Where It Didn't

This is where AI-assisted development got interesting. I described the requirements to Claude — "I need an ASCII table with all 128 characters, multi-format display, search, and copy functionality" — and it generated a solid foundation on the first try.

The data generation was where AI really shined. I asked it to generate the complete character metadata, and it produced accurate names, hex codes, and HTML entities. This saved me probably 30 minutes of manual data entry and potential typos.

But here's where it went wrong: the AI's first version had a subtle bug. It was using String.fromCharCode() directly to display characters, which works fine for printable characters but breaks for control characters — they render as invisible or garbled. The AI didn't catch this because it never actually rendered the table.

I had to step in and add explicit handling:

function formatChar(dec) {
  if (dec < 32 || dec === 127) return '␀'; // Use visual placeholder
  return String.fromCharCode(dec);
}

This is the difference between "code that compiles" and "code that actually works." The AI was great at generating the skeleton, but it missed the edge cases that only become obvious when you're looking at a rendered page.

Performance: The Sticky Header Problem

One thing I insisted on was a sticky table header — when you're scrolling through 128 rows, you need to see what column you're in. This turned out to be surprisingly tricky.

The naive approach is position: sticky; top: 0 on the th elements. But this breaks when the table is inside a scrollable container with a border. The header would scroll away or get clipped by the container's overflow.

The fix was to ensure the scroll container is a direct parent with proper overflow settings:

.table-wrap {
  overflow: auto;
  max-height: 600px;
}

th {
  position: sticky;
  top: 0;
  z-index: 1;
}

Simple in hindsight, but it took me a few iterations to get the z-index right — otherwise the sticky header would appear under the table rows when scrolling.

Search: The Unexpected Complexity

Search seemed straightforward: filter by decimal, hex, or name. But I quickly realized that users think in different formats. Some search for "65", others for "0x41", others for "A", and others for "Capital A".

The solution was to normalize the input and search across multiple fields:

function filterRows(query) {
  const q = query.toLowerCase().trim();
  if (!q) return allRows;

  return allRows.filter(row => 
    row.dec.toString().includes(q) ||
    row.hex.includes(q.replace('0x', '')) ||
    row.name.toLowerCase().includes(q)
  );
}

The AI initially generated a search that only matched exact decimal values — completely missing the use case where someone types "A" or "0x41". I had to iterate on the prompt: "Search should be fuzzy, matching partial strings across multiple fields."

The Copy Feature: Clipboard API Gotchas

Click-to-copy sounds simple, but there's a catch: the Clipboard API only works in secure contexts (HTTPS or localhost). Since this is a static tool, I need to handle the fallback for HTTP environments:

async function copyHex(hex) {
  try {
    await navigator.clipboard.writeText(hex);
    showStatus(`Copied: ${hex}`);
  } catch (err) {
    // Fallback for older browsers
    const textarea = document.createElement('textarea');
    textarea.value = hex;
    document.body.appendChild(textarea);
    textarea.select();
    document.execCommand('copy');
    document.body.removeChild(textarea);
  }
}

The AI didn't consider this edge case at all — it just used navigator.clipboard without any error handling. This would have silently failed for users on HTTP.

Mobile Responsiveness: The Table That Wouldn't Fit

Tables are inherently non-responsive, and ASCII tables are no exception. With 7 columns (DEC, HEX, OCT, BIN, CHAR, NAME, HTML), it's impossible to fit everything on a 320px screen.

My solution was progressive disclosure:

@media (max-width: 600px) {
  .hide-sm { display: none; }
}

This hides the HTML entity column on small screens. Not perfect, but functional. The table becomes scrollable horizontally if needed, but at least the essential columns are visible.

What AI Got Right (and What It Didn't)

AI nailed:

Generating the complete character dataset with zero typos
Setting up the basic table structure and i18n scaffolding
Producing a clean, consistent CSS foundation

AI struggled with:

Edge cases (control characters, clipboard fallbacks)
Understanding the actual user experience (search that works the way people think)
Performance considerations (sticky headers, DOM rendering at scale)

The pattern I've noticed: AI is excellent at generating the "happy path" but consistently misses the "sad path" — the error handling, edge cases, and browser quirks that make production code actually production-ready.

The i18n Decision

Since I'm building this for a global audience, I needed both Chinese and English support. The lightweight approach was a simple dictionary-based system:

const I18N = {
  zh: { title: "ASCII 表", searchPlaceholder: "搜索..." },
  en: { title: "ASCII Table", searchPlaceholder: "Search..." }
};

This is intentional — I didn't want to pull in a full i18n library for a single tool. The trade-off is that adding a new language requires duplicating all strings, but for a tool with maybe 20 user-facing strings, it's manageable.

Lessons Learned

AI is a great pair programmer, not a replacement. It saved me time on boilerplate and data generation, but I still needed to understand the domain well enough to catch its mistakes.
Edge cases are where the real work lives. Any developer can render an ASCII table. Making it actually useful — with proper control character handling, intuitive search, and graceful fallbacks — is the difference between a toy and a tool.
Sometimes the old ways are fine. I briefly considered using a framework like React or Vue, but for a static reference tool, vanilla JS was simpler, faster to load, and had zero dependencies to maintain.
Performance matters even for simple tools. The sticky header and efficient filtering make the tool feel instant. Users notice when a "simple" tool is sluggish.

The Result

During this process, I built a small browser-based tool to make this workflow easier. It's a single HTML file with no dependencies — just open it in a browser and it works. The complete ASCII table (0-127) with multi-format display, fuzzy search, category filtering, and click-to-copy functionality.

If you find yourself constantly opening random ASCII chart websites that are cluttered with ads, or if you just want a clean, fast reference tool, you might find it useful. Try it here.

The irony isn't lost on me — I spent four hours building a tool that saves me maybe 30 seconds each time I need to look up a character code. But those 30 seconds add up, and now I have a tool that works exactly the way I want it to. Sometimes reinventing the wheel is worth it.

How I Built a Compound Interest Calculator Without Any Backend

ggwork — Sun, 30 Aug 2026 02:20:57 +0000

While working on a side project recently, I needed a way to help users quickly understand how their savings could grow over time. Nothing fancy — just input a principal, an interest rate, and a timeframe, and see the future value. But here's the thing: I didn't want to spin up a server, manage a database, or deal with API rate limits. I wanted something that would work instantly, even on a slow connection, and that wouldn't cost me a cent in hosting.

So I built a compound interest calculator that runs entirely in the browser. No backend. No dependencies. Just pure JavaScript and a bit of math.

The "Why Not Just Use an Existing Tool?"

Good question. There are plenty of compound interest calculators out there. But most of them are either:

Buried in a finance website with a million other widgets
Require JavaScript from external CDNs that might fail
Don't let you customize the compounding frequency
Or my personal favorite: they call an API to do the math. Seriously. A compound interest calculation is about 10 lines of code, and some sites will make a network request to compute it.

I wanted something self-contained. A single HTML file that could be hosted anywhere, even on a static file server, and just work. Plus, I'm an indie developer — I enjoy reinventing wheels when the wheel design is fun.

The Math (It's Not That Scary)

The core formula for compound interest with regular contributions isn't as intimidating as it looks:

FV = P(1 + i)^N + PMT × ((1 + i)^N − 1) / i

Where:

P is the initial principal
i is the periodic interest rate (annual rate divided by compounding periods per year)
N is the total number of periods (years × periods per year)
PMT is the periodic contribution amount

The tricky part? When i is zero. If you have a 0% interest rate, the formula ((1+i)^N − 1) / i becomes 0/0, which is undefined. Classic division by zero situation.

function compute(p, rPct, years, n, monthlyAdd, sym) {
  const i = rPct / 100 / n;
  const N = n * years;
  const PMT = monthlyAdd * 12 / n;

  const principalFV = p * Math.pow(1 + i, N);
  const contribFV = i > 0 
    ? PMT * (Math.pow(1 + i, N) - 1) / i 
    : PMT * N;  // fallback for 0% interest

  const fv = principalFV + contribFV;
  const invested = p + monthlyAdd * 12 * years;
  const interest = fv - invested;

  return { fv, invested, interest, series: generateSeries(...) };
}

That fallback for i = 0 was something I initially got wrong. The AI I was working with (more on that in a bit) wrote the formula without the edge case, and the first time I tested with 0% interest, I got NaN displayed. That's not a great user experience.

The Decision: Pure Frontend vs. API

Let me explain why I went with pure frontend:

Cost: Zero server costs. Host it on any static host (GitHub Pages, Netlify, even a simple CDN).
Privacy: Users' financial data never leaves their browser. No tracking, no analytics, no "we store your data for research purposes."
Speed: Instant response. No network latency.
Reliability: No server to crash, no API to rate-limit.

The trade-off? I can't update the calculation logic without redeploying. But honestly, the math for compound interest hasn't changed in centuries. I think it's safe.

Building the Chart Without a Library

The second challenge was the growth chart. Most people would reach for Chart.js or D3. But I wanted to keep this dependency-free. So I wrote a tiny SVG chart generator.

function drawChart(series, sym) {
  const width = 600, height = 200;
  const maxVal = Math.max(...series);
  const points = series.map((v, i) => {
    const x = (i / (series.length - 1)) * width;
    const y = height - (v / maxVal) * height;
    return `${x},${y}`;
  }).join(' ');

  return `<svg viewBox="0 0 ${width} ${height}">
    <polyline points="${points}" fill="none" stroke="#3b82f6" stroke-width="2"/>
  </svg>`;
}

That's the essence of it. A polyline with points scaled to fit the viewBox. It's not going to win any design awards, but it shows the growth curve clearly, and it's about 15 lines of code.

The challenge here was handling the edge case where all values are zero. If maxVal is 0, you get a division by zero in the scaling. I had to add a check: if the max is 0, just draw a flat line at the bottom.

The AI-Assisted Development Experience

Now, the part I promised I'd talk about: building this with AI assistance. I used ChatGPT for most of the initial implementation, and honestly, it was a mixed bag.

What I asked for:

"Write a compound interest calculator in vanilla JavaScript. It should take principal, annual rate, years, compounding frequency, and monthly contribution. Return the future value and a series of values for each year to plot on a chart."

What I got:

A pretty solid implementation of the formula, with the series generation, and a basic chart. The AI handled the core math correctly on the first try — which was impressive. But here's where it went wrong:

The 0% interest edge case — as I mentioned, it returned NaN without the fallback.
The series generation — it initially generated points for every compounding period, not every year. For daily compounding over 30 years, that's 10,950 points in the SVG. The chart was... let's say "visually noisy."
Input validation — it didn't handle negative numbers or non-numeric input gracefully.

How I iterated:

I went back with specific feedback:

"The 0% case returns NaN. Also, I only want yearly points in the series for the chart, not every compounding period."

The AI fixed both issues. But it introduced a new one: it started generating the series using a different formula than the main calculation, so the chart didn't match the final value. Classic inconsistency bug.

At that point, I stepped in and rewrote the series generation to use the same iterative formula as the main calculation. This is where I think the human still has an edge — understanding that two separate code paths computing the "same" thing will inevitably drift apart.

What AI Got Right vs. Where I Had to Step In

AI handled well:

The core math formula
The HTML/CSS structure for the form
The SVG chart generation (once I specified the requirements clearly)

Where AI struggled:

Edge cases (zero interest, zero principal, zero contribution)
Consistency between different parts of the calculation
Understanding the UX implications of its choices (like generating 10,000 data points)

My honest take: for a tool like this, AI-assisted development saved me maybe 60-70% of the time. It's excellent for getting a working skeleton quickly. But the last 30% — the edge cases, the polish, the consistency — that's where I had to bring my own experience.

Lessons Learned

Always test the edge cases. The AI didn't, and I nearly shipped a calculator that showed NaN for a very valid input (0% interest).
Keep it dependency-free when you can. For a single-purpose tool, a full charting library is overkill. A polyline SVG does the job.
The "periodic contribution" assumption matters. I chose to model contributions at the end of each period (which is standard for most investment scenarios). But this is a subtle detail that affects results, and it's worth documenting for users.
AI is a great pair programmer, not a replacement. It wrote the first draft in minutes. But I had to review every line with a skeptical eye.

The Final Result

During this process, I built a small browser-based tool to make this workflow easier. It's a single HTML file that calculates compound interest with optional monthly contributions and displays a growth chart. You can try it out if you want to see the approach in action.

The whole thing is about 200 lines of HTML/CSS/JavaScript. No build step, no dependencies, no server. Just open the file and it works.

If you're building similar utility tools, I'd encourage you to think about whether you really need a backend. For calculation-heavy tools, the browser is surprisingly capable. And with AI to help you scaffold the initial implementation, you can go from idea to working tool in a single afternoon.

Just remember to test the edge cases. The AI probably didn't.

Building a Date Difference Calculator: The Hidden Complexity of Time

ggwork — Fri, 28 Aug 2026 06:25:52 +0000

I was working on a project timeline feature when I hit an unexpected wall. The requirement seemed simple: "Show how many days are between these two dates." Easy, right? (end - start) / 86400000. Done.

Except it wasn't done. Because "days between" means completely different things depending on whether you're planning a sprint, calculating payroll, or tracking a contract period. And that's before we even get into time zones.

The Problem with "Just Subtract the Dates"

Here's the thing that trips up most developers (myself included): a date difference isn't just one number. It's several different numbers, each answering a different question:

Total days: The raw duration in 24-hour blocks
Calendar breakdown: How many full years, months, and days? (Spoiler: it's not just totalDays / 365)
Working days: How many weekdays? (Because weekends don't exist when you're on a deadline)

I needed all three, and I needed them to be accurate. Existing libraries like date-fns or dayjs handle some of this, but they're heavy for what I needed. Plus, I'm a bit of a minimalist when it comes to dependencies — adding a 50KB library to calculate what should be a few simple functions felt like using a chainsaw to cut a piece of string.

So I decided to build it myself. Because apparently I enjoy reinventing wheels.

The Time Zone Trap

The first thing that bit me: time zones. JavaScript's Date object is notoriously tricky with this. If you parse "2026-08-01" with new Date("2026-08-01"), you get UTC midnight — but if you're in a different timezone, that's actually the previous evening for you.

The fix was to use datetime-local inputs and parse everything in local time. No UTC conversions, no getTimezoneOffset() gymnastics. Here's the core parsing function that saved my sanity:

function parseLocal(dt) {
  if (!dt) return null;
  const d = new Date(dt);
  return isNaN(d.getTime()) ? null : d;
}

That's it. The datetime-local input format (YYYY-MM-DDTHH:mm) is designed to be parsed as local time, so new Date() handles it correctly. The key insight: don't try to be clever with timezones when you don't need to be.

The Calendar Breakdown Problem

Now for the interesting part. I needed to break down a date range into years, months, and days. This sounds straightforward until you realize that months have varying lengths, and "1 month from January 31" is genuinely ambiguous.

I went with a calendar-push approach: increment the start date by years until you can't go further without exceeding the end date, then months, then days. Here's the logic that made it work:

function calendarBreakdown(start, end) {
  let y = 0, mo = 0, d = 0;
  let temp = new Date(start);

  while (addMonths(temp, y + 1) <= end) y++;
  temp = addMonths(new Date(start), y);
  while (addMonths(temp, mo + 1) <= end) mo++;
  temp = addMonths(temp, mo);
  d = Math.floor((end - temp) / 86400000);

  return { y, mo, d };
}

The addMonths function handles the edge cases — like February 29 — by clamping to the end of the month. It's not perfect (what is, with dates?), but it gives results that match human intuition about calendar spans.

Working Days: The Weekend Problem

The workday calculation sounded easy: iterate through dates, skip Saturdays and Sundays. But here's a subtlety that caught me: should the workday count include the start and end dates? Most people think "between" means excluding endpoints, but in business contexts, you usually want inclusive counting.

I went with inclusive counting, and the implementation is refreshingly simple:

function countWorkdays(start, end) {
  let count = 0;
  const cur = new Date(start);
  while (cur <= end) {
    const day = cur.getDay();
    if (day !== 0 && day !== 6) count++;
    cur.setDate(cur.getDate() + 1);
  }
  return count;
}

The getDay() method returns 0 for Sunday and 6 for Saturday, so checking for those two values handles the entire weekend logic. No arrays, no constants, no lookup tables.

Where AI Actually Helped

Now, the part you're probably curious about: how much of this did I build with AI assistance?

I'll be honest — I used Claude for a significant portion of this. The interesting part was the iterative process. My first prompt was something like: "Write a date difference calculator that shows days, hours, and workdays."

What I got back was... technically correct but practically useless. It used UTC everywhere, which would have been fine if I was building for a server, but this was a browser tool. The AI didn't think about timezones because I didn't ask it to.

The back-and-forth went something like:

Me: "The dates are off by one day when I test with local times."
AI: "Ah, you need to use local time parsing. Here's the fix." (And it was right.)
Me: "Now the calendar breakdown doesn't match what I expect for ranges crossing month boundaries."
AI: "You need to use a calendar-push approach instead of just dividing total days."

The AI was genuinely helpful for catching edge cases I hadn't considered and for refactoring the logic. But it also made mistakes — the first version of the workday calculator excluded the start date, which I had to catch and fix.

My honest take: AI is excellent at generating correct code for well-defined problems, but it's terrible at understanding what "well-defined" means for your specific use case. You still need to be the domain expert.

The Tool That Emerged

During this process, I built a small browser-based tool to make this workflow easier. It's a date difference calculator that handles all three modes — total days, calendar breakdown, and workday counting — with a clean interface that doesn't require any server-side processing.

The UI is deliberately minimal: two date inputs, a checkbox for workday mode, and a results panel. The entire thing runs in the browser with zero dependencies, which means it's instant and works offline.

One design decision I'm particularly happy about: defaulting to showing "today → 30 days from now" as an example. It gives users immediate feedback and demonstrates the tool's capabilities without requiring them to figure out the interface first.

Lessons Learned

Time zones are the root of all evil. If you don't need to handle them, don't. Local time parsing with datetime-local inputs sidesteps an entire class of bugs.
"Days between" is ambiguous. Always clarify whether you need total days, calendar days, or working days. They're all different numbers.
AI is a pair programmer, not a replacement. It caught edge cases I missed, but it also missed cases I caught. We complemented each other.
Dependencies aren't always worth it. For something this focused, a few well-written functions beat a library every time.

The tool is live at craftvo.app if you want to see the final result. It's free, it's fast, and it handles the date math so you don't have to.

Now if you'll excuse me, I need to go explain to my PM why "2 days" and "48 hours" are apparently different numbers.

Building a Braille Translator in the Browser: When Unicode Bit Manipulation Meets AI Pair Programming

ggwork — Fri, 28 Aug 2026 02:20:50 +0000

While working on a collection of browser-based utility tools, I stumbled upon an interesting challenge: building a Braille translator. Not because I have any personal connection to Braille — I'm just a developer who loves Unicode puzzles. But the problem turned out to be more fascinating than I expected, with a hidden layer of complexity that made me rethink how I approach character encoding.

The Problem Nobody Asked Me to Solve

I was building a suite of small, focused web tools. You know the type — URL encoders, JSON formatters, maybe a base64 decoder. Useful, boring, done a thousand times. But Braille? That's different.

Here's the thing: most "Braille translators" online are either:

Flash relics from 2005 that barely work on modern browsers
Server-side tools that require uploading your text somewhere
Overly complex accessibility suites when all you need is "text → Braille → text"

I wanted something that runs entirely in the browser, works offline, and doesn't send sensitive text to a server. Because apparently, I enjoy reinventing wheels.

The Moment I Realized Braille is Just Binary

Here's what blew my mind: Braille isn't some mystical code. It's literally binary.

A Braille cell has 6 dots, arranged in 2 columns and 3 rows. Each dot is either raised or flat. That's 2^6 = 64 possible combinations. And in Unicode, those 64 combinations map directly to code points U+2800 through U+283F.

The mapping is beautifully simple:

// Dot 1 is bit 0, dot 2 is bit 1, dot 3 is bit 2, etc.
const brailleCodePoint = 0x2800 + dotPatternNumber;

So if you know the dot pattern for a letter, you just add the corresponding number to 0x2800. The letter 'a' is dot 1, so it's 0x2800 + 1 = 0x2801, which is ⠁. The letter 'b' is dots 1 and 2, so it's 0x2800 + 3 = 0x2803, which is ⠃.

Wait, did I just say "the letter 'a' is dot 1"? Because that's where the fun begins.

The Alphabet Is Not What You Think

Here's where my initial assumptions fell apart. I thought I'd just create a simple dictionary mapping letters to their Unicode Braille characters. Then I discovered the actual Braille alphabet pattern:

a = dot 1
b = dots 1,2
c = dots 1,4
d = dots 1,4,5
e = dots 1,5

The first 10 letters (a-j) follow a pattern, then k-t add dot 3 to the first 10, and u-z follow another pattern. It's almost systematic, but not quite. There's a method to the madness, but you can't derive it from a simple formula — you need the actual mapping.

I initially tried to write a clever algorithmic solution. That lasted about 15 minutes before I gave up and hardcoded the mapping. Sometimes the simple solution is the right one.

The Number Problem: A Trap for the Unwary

Just when I thought I had it figured out, I hit the numbers issue.

In Braille, the letters a-j double as numbers 1-0. But you can't just type "123" and get Braille numbers — you need a special number sign (⠼) before them. So "123" becomes "⠼⠁⠃⠉", not just "⠁⠃⠉".

This creates an interesting ambiguity: if you see "⠁⠃⠉" without the number sign, is it "abc" or "123"? The answer is context-dependent, which makes bidirectional translation genuinely tricky.

My solution: when translating text to Braille, detect digits and prepend the number sign once for a run of consecutive digits. When translating Braille to text, if the number sign appears, treat the next characters as digits until you hit a space or non-letter character.

function textToBraille(text) {
  let result = '';
  let inNumber = false;

  for (const char of text.toLowerCase()) {
    if (char >= '0' && char <= '9') {
      if (!inNumber) {
        result += BRAILLE_NUMBER_SIGN;
        inNumber = true;
      }
      result += BRAILLE_MAP[char];
    } else {
      inNumber = false;
      result += BRAILLE_MAP[char] || char;
    }
  }
  return result;
}

This was one of those moments where I realized: "I'm not just building a translator, I'm building a state machine."

The Dot Pattern Visualization

Now for the part that made this tool actually useful: showing the dot patterns. Because if you're learning Braille, just seeing "⠓" doesn't help — you need to know that's dots 1, 2, and 5.

The visualization is straightforward once you have the dot pattern number:

function getDots(codePoint) {
  const value = codePoint - 0x2800;
  const dots = [];
  for (let i = 1; i <= 6; i++) {
    if (value & (1 << (i - 1))) {
      dots.push(i);
    }
  }
  return dots;
}

Bit manipulation. Again. It's like binary is following me around.

AI-Assisted Development: The Good, The Bad, The Ugly

Now for the part I'm most honest about: I used AI to build much of this. And it was a mixed experience.

The first prompt I gave was something like: "Create a Braille translator with text to Braille and Braille to text conversion, with a reference chart."

The AI nailed the basic structure in one shot. It created the HTML layout, the CSS styling, the i18n system — all the scaffolding. I was impressed.

But then came the bugs.

Bug #1: The Case Sensitivity Trap

The AI initially made the translation case-sensitive. "HELLO" would produce different results than "hello". In Braille, there's no such thing as lowercase — it's all one case. The AI hadn't thought about normalizing input to lowercase before mapping.

Bug #2: The Number Sign Placement

The AI's first attempt at numbers was a disaster. It would put a number sign before every single digit, so "123" became "⠼⠁⠼⠃⠼⠉" instead of "⠼⠁⠃⠉". That's like writing "one hundred twenty three" as "one-one-hundred-twenty-three". Technically understandable, but completely wrong.

Bug #3: The Reverse Translation Mapping

The biggest issue was reverse translation. The AI had a static map for text-to-Braille but didn't properly handle the reverse lookup. When I asked it to translate Braille back to text, it would get stuck on ambiguous characters. Is "⠁" an "a" or a "1"? Without context, you can't tell.

The AI's solution was to always treat it as a letter unless the number sign appeared. That's actually correct, but the AI couldn't articulate why it made that choice — it just happened to be right.

Where I Had to Step In

The AI was great at generating boilerplate and basic logic, but it kept making the same class of mistakes: not understanding the domain. It didn't know that Braille is case-insensitive, that numbers need special handling, or that the dot pattern visualization would be the most useful feature for learners.

I had to:

Explain the number sign rule explicitly, multiple times
Provide the actual Braille mapping table (the AI kept hallucinating wrong patterns)
Design the dot visualization myself — the AI's first attempt was a mess of nested divs that looked like a CSS nightmare

The lesson? AI is great for generating code, but it's terrible at understanding domain-specific rules it wasn't explicitly trained on. Braille is a niche topic, and the AI's training data apparently had conflicting information about it.

The i18n Challenge

Building bilingual support (Chinese/English) added another layer of complexity. The tool needed to work for both Chinese and English speakers, which meant:

All UI strings needed translation
The language switcher needed to persist (I used localStorage)
The Braille reference chart needed to be language-agnostic (it is — Braille is Braille)

The i18n system itself was straightforward:

const i18n = {
  zh: {
    title: '盲文翻译器',
    textInput: '文本输入',
    brailleOutput: '盲文输出',
    // ...
  },
  en: {
    title: 'Braille Translator',
    textInput: 'Text Input',
    brailleOutput: 'Braille Output',
    // ...
  }
};

The tricky part was making the AI understand that the default language should be Chinese, not English. It kept defaulting to English and I had to keep reminding it. Classic "works on my machine" situation.

Performance Considerations

For a tool like this, performance is almost a non-issue. The entire translation is O(n) — you're just iterating over characters and doing a lookup. Even a 10,000-character document would translate in milliseconds.

But there was one performance consideration: the reference chart. Rendering 26 letters + 10 digits + punctuation as individual DOM elements adds up. I used a simple CSS grid with auto-fill columns, which handles responsiveness gracefully without JavaScript. No virtual scrolling needed for 60 items, but it's worth thinking about if you ever scale this to include contractions (the full Braille system has hundreds of contractions).

The "Why" Behind the Architecture

I chose vanilla JavaScript over React or Vue for a few reasons:

Zero dependencies — this tool needs to work forever, even if npm packages disappear
Single file — easy to embed, easy to share, easy to deploy
No build step — I can just open the HTML file and it works

The trade-off? I had to write more boilerplate for things like state management and event handling. But for a tool this small, it's the right call. A React app with a build step would be overkill for what's essentially a <textarea> with a mapping function.

What I Learned

Bit manipulation is everywhere — even in something as human as Braille
Domain knowledge beats clever code — you can't algorithmically derive the Braille alphabet; you need the actual mapping
AI is a junior developer — great at scaffolding, bad at domain-specific edge cases
Simple tools are underrated — sometimes the best solution is a single HTML file that just works

The Final Product

The result is a browser-based Braille translator that:

Converts text to Braille and back
Shows dot patterns for each character
Handles numbers correctly (with the number sign)
Works in both Chinese and English
Has a complete reference chart

During this process, I built a small browser-based tool to make this workflow easier. You can find it here if you're curious.

The best part? I learned something unexpected about Braille — it's not a mystery code, it's just binary with a different face. And that's the kind of discovery that makes building these little tools worthwhile.

P.S. If you're wondering why I chose this project: I wanted to build something that would make me think about Unicode in a new way. Mission accomplished. The fact that it might actually help someone learn Braille is just a bonus.

From "What's the MIME for That?" to a 200+ Entry Reference Tool

ggwork — Wed, 26 Aug 2026 06:08:25 +0000

You know that moment when you're building an upload feature and you need to validate file types, and you find yourself Googling "what's the MIME type for .webp" for the fifth time that week? That was me last month. I was working on a file upload handler and kept hitting the same wall: I'd remember common ones like image/jpeg, but then I'd need something obscure like .avif or .m4a and I'd be back to searching.

The worst part? The answers were scattered across MDN docs, Stack Overflow threads from 2012, and random GitHub gists with questionable accuracy. I wanted a single source of truth I could reference quickly.

The "Just Build It" Temptation

I considered just hardcoding the few types I needed. But I knew that was a band-aid. I'd be back in the same spot next week with a different project. So I did what any reasonable developer would do: I decided to build a comprehensive reference tool.

Because apparently I enjoy reinventing wheels.

The Data Problem

The first challenge was obvious: I needed a solid MIME type database. Not just the common ones — I wanted coverage across documents, images, video, audio, archives, code, fonts, and "other" stuff that doesn't fit neatly anywhere.

Here's what I learned: there's no official "MIME type registry" that's both comprehensive and easy to consume. The IANA registry is the authority, but it's a massive HTML table that's painful to scrape. I ended up cross-referencing:

The IANA registry (for official types)
MDN's MIME type documentation (for practical usage)
My own experience (for the "what people actually use" factor)

The data structure ended up being refreshingly simple:

{ ext: '.webp', mime: 'image/webp', cat: 'img', desc: 'WebP 图片' }

That's it. Four fields. No relational database, no API calls — just a plain array in JavaScript.

The Search Logic: Simpler Than You'd Think

The search was the fun part. I wanted bidirectional lookup — type an extension and get the MIME, or type a MIME and get extensions. My first approach was embarrassingly over-engineered. I was thinking about fuzzy matching, Levenshtein distances, the whole nine yards.

Then I realized: developers searching for MIME types aren't typos. They know exactly what they're looking for. They just need quick verification. So I kept it simple:

Strip leading dots from the input
Case-insensitive substring matching
Check against extension, MIME type, and description

The debounce was the only "fancy" part — 200ms to prevent the render function from firing on every keystroke. The whole search logic fits in about 15 lines.

The AI Collaboration Experiment

Here's where things got interesting. I decided to build this with AI assistance — not as a gimmick, but because I genuinely wanted to see how well it could handle a well-specified, self-contained project. This felt like the perfect test case: clear requirements, no external dependencies, pure frontend.

I gave the AI a detailed spec: the exact data structure, the interaction patterns, the UI layout, even the SEO tags. The first attempt was... surprisingly good. It nailed the structure and the search logic on the first try.

But it completely missed the dark mode support. Classic "works on my machine" situation — the AI assumed everyone uses light mode.

The iteration process was where the real value came through. I'd say "add prefers-color-scheme media queries" and it would generate the CSS. Then I'd notice the category badges were unreadable in dark mode, and it would fix those specific color values. It was like pair programming with a very fast, slightly forgetful junior developer.

The part where I had to step in? The data. The AI's initial MIME database was thin — maybe 60 entries. I had to explicitly list the file types I wanted covered: "add these: cpp, java, py, go, rs, woff, woff2, ttf, otf..." That's the kind of domain knowledge that AI still can't fully replicate.

The i18n Surprise

I initially thought internationalization would be the hardest part. I was planning a full i18n library integration. But for a tool like this, a lightweight approach made more sense:

const i18n = {
  zh: { title: 'Content-Type 查询', searchPlaceholder: '输入扩展名或MIME...' },
  en: { title: 'Content-Type Lookup', searchPlaceholder: 'Enter extension or MIME...' }
};

Just a simple dictionary with a language switcher. The descriptions in the database stay in their original language — which actually makes sense because MIME types themselves are language-agnostic. The tool is for developers, and developers know what image/jpeg means regardless of their native language.

The Copy Interaction

The click-to-copy feature was a requirement I initially underestimated. I thought navigator.clipboard.writeText() was a solved problem. Turns out, it has a subtle gotcha: it only works in secure contexts (HTTPS or localhost). For a tool that people might open as a local HTML file, I needed a fallback.

The fallback is the old-school approach:

const textarea = document.createElement('textarea');
textarea.value = mime;
document.body.appendChild(textarea);
textarea.select();
document.execCommand('copy');
document.body.removeChild(textarea);

It's deprecated, but it works everywhere. The lesson here: don't assume modern APIs are universally available, even for a "modern" tool.

Performance: The "It's Just an Array" Moment

I spent way too long thinking about performance optimization. Should I use a Map? A binary search tree? Index the data by extension?

Then I realized: the entire dataset is 215 entries. The search runs in milliseconds even with a naive filter. The only performance consideration that actually mattered was the debounce on the search input, and even that was more about avoiding excessive DOM updates than actual CPU usage.

The table rendering? I'm just regenerating the HTML string and setting innerHTML. It's not React, but it's also not 10,000 rows. Sometimes the simplest solution is the right one.

The Stats That Matter

One feature I'm glad I added: the result counter. It shows "X results out of Y total entries." It sounds trivial, but when you're searching for something and get zero results, seeing "0 results out of 215 entries" is much more reassuring than just "No results found." It confirms the tool is working — you just searched for something that doesn't exist in the database.

Speaking of no results: I made sure to include a friendly empty state. Because nothing kills developer trust faster than a blank screen with no explanation.

What I'd Do Differently

If I were to rebuild this, I'd probably add a "random MIME type" button. Not because it's useful, but because it's fun. Sometimes you want to test how your code handles unexpected input.

I'd also consider adding copy feedback per-row instead of a global status message. Right now, clicking any row copies the MIME and shows a status bar message. It works, but a per-row "copied!" tooltip would be more immediate feedback.

The Verdict on AI-Assisted Development

This project was a genuine test of AI-assisted development, and my honest take is: it's great for boilerplate and structure, but it still needs a human for judgment calls.

The AI handled the CSS layout, the search logic, the i18n structure, and even the SEO meta tags without complaint. It made mistakes — the dark mode oversight being the biggest one — but they were easy to catch and fix.

What the AI couldn't do was understand the subtle requirements that come from real-world usage. It didn't know that .docx is more common than .doc in 2024. It didn't know that application/x-www-form-urlencoded deserves a spot in the database even though it's not a file extension. Those insights come from experience, not from training data.

The Takeaway

I built this tool because I was tired of searching for MIME types. The process taught me that even "boring" developer tools have interesting engineering decisions lurking beneath the surface. The data structure matters more than the algorithm. The UX details (like the result counter and empty states) matter more than the feature list.

And if you're wondering: yes, I still Google MIME types sometimes. But now I have a better starting point.

During this process, I built a small browser-based tool to make this workflow easier. If you're dealing with the same problem, you can find it at Craftvo's Content-Type Lookup. It's just a plain HTML file with vanilla JS — no build tools, no frameworks, no server. Open it, search, copy, move on with your life.

Tags: mime-types, web-development, javascript, developer-tools, ai-assisted-development

Building a Base64 Tool That Actually Handles UTF-8 (Without Losing Your Mind)

ggwork — Tue, 25 Aug 2026 06:54:20 +0000

The Problem That Started It All

I was working on a project that required sending configuration data between different services. The payload contained Chinese characters, emojis, and the occasional accented character from a French colleague's name in the comments. Classic stuff.

The first time I tested it, everything worked. The second time, I got back a string of Ã© and â€™ instead of actual text. You know the drill — mojibake. The kind of thing that makes you question every life decision that led you to this moment.

The root cause? I was using btoa() and atob() directly on strings containing non-ASCII characters. These functions only handle Latin-1 (ISO-8859-1) natively. Feed them a Chinese character and they'll happily mangle it into something that looks like it fell out of a corrupted file.

Why Not Just Use an Existing Tool?

I could have opened any of the dozens of online Base64 converters. But I had specific requirements:

I needed something that handles UTF-8 correctly (the mojibake problem above)
I wanted it to work offline
I didn't want to paste sensitive config data into some random website
I was tired of tools that required clicking a "Convert" button when I just wanted live feedback

So I decided to build a small browser-based tool. Because apparently I enjoy reinventing wheels.

The UTF-8 Problem (The Part That Actually Matters)

Here's the core issue with btoa() and atob():

// This works fine
btoa("hello world");

// This throws an error or produces garbage
btoa("你好世界");

The fix is straightforward but easy to miss if you're in a hurry:

function encodeUTF8(str) {
    return btoa(String.fromCharCode(...new TextEncoder().encode(str)));
}

function decodeUTF8(base64) {
    return new TextDecoder().decode(
        Uint8Array.from(atob(base64), c => c.charCodeAt(0))
    );
}

The TextEncoder converts the string to UTF-8 bytes, and String.fromCharCode(...) turns those bytes into a string that btoa() can handle. The decode path reverses this process.

One gotcha: for very large inputs, String.fromCharCode(...array) can blow the call stack. In production, you'd want a chunked approach. But for typical text inputs, this works fine.

The Real-Time Conversion Decision

The most interesting design decision was whether to convert on every keystroke or wait for user action.

Option A: Real-time conversion

Pro: Instant feedback, feels magical
Con: Can be janky with large inputs, potentially wasteful

Option B: Manual conversion button

Pro: Predictable, performant
Con: Extra click, feels dated

I ended up going with a hybrid: real-time by default, but with a manual override. Users can toggle it off if they're pasting a massive file. The implementation is simple — just listen to the input event and debounce:

let debounceTimer;
input.addEventListener('input', () => {
    if (!realTimeToggle.checked) return;
    clearTimeout(debounceTimer);
    debounceTimer = setTimeout(convert, 150);
});

The debounce is critical. Without it, every keystroke triggers a full conversion cycle, which causes noticeable lag on longer inputs.

The Encoding/Decoding Direction Problem

Here's something I didn't think about until I started building: when you swap between encode and decode modes, what happens to the existing input?

If someone types "hello" in encode mode, then switches to decode mode, should "hello" be decoded as Base64? That would produce garbage. The sensible behavior is to clear the input when the mode changes.

But wait — there's a more interesting UX pattern. What if the user wants to decode something they just encoded? They'd have to copy the output, switch modes, and paste it back. That's annoying.

This is where the swap button comes in. Instead of manually copying and switching, one click moves the current output into the input field and flips the mode. It's a small touch, but it makes the tool feel much more fluid.

The Error Handling Trap

Decoding invalid Base64 is a surprisingly common failure mode. Users paste in text that looks like Base64 but isn't — maybe it has a space in it, or they copied a URL fragment by accident.

The naive approach:

try {
    const result = atob(input);
    // ...
} catch (e) {
    showError("Invalid Base64");
}

This works, but it's not very helpful. The better approach is to validate the input format first and give specific feedback:

function isValidBase64(str) {
    if (str.length % 4 !== 0) return false;
    return /^[A-Za-z0-9+/]*={0,2}$/.test(str);
}

This catches the most common issues: wrong length and invalid characters. The error message can then tell the user what's wrong rather than just "that didn't work."

What the AI Got Right and Wrong

I built this tool with AI assistance, and I want to be honest about the experience.

What the AI nailed:

The initial structure and layout
The i18n setup with language detection
The dark mode implementation using CSS variables
The basic encode/decode logic

Where I had to step in:

The first version of the UTF-8 handling was wrong. The AI used encodeURIComponent as a workaround, which produces a URL-encoded string that isn't proper Base64. It worked for basic cases but broke with certain character combinations.

I had to explain the issue and iterate:

"The current implementation uses encodeURIComponent which produces incorrect Base64. We need to use TextEncoder/TextDecoder instead. Here's the correct approach..."

The AI then generated the correct implementation. But here's the thing — I only knew it was wrong because I'd hit this exact bug before. If I hadn't, I would have shipped broken code.

The lesson: AI is great at scaffolding and boilerplate, but you still need to understand the domain well enough to catch subtle bugs.

The i18n Decision

I'm building this tool for a global audience, so I needed English and Chinese support. The requirement was simple: detect the browser language, allow a URL override, and default to Chinese.

The implementation was straightforward:

const translations = {
    'zh': {
        'title': 'Base64 编码/解码',
        'encode': '编码',
        'decode': '解码',
        // ...
    },
    'en': {
        'title': 'Base64 Encode/Decode',
        'encode': 'Encode',
        'decode': 'Decode',
        // ...
    }
};

function detectLanguage() {
    const urlLang = new URLSearchParams(window.location.search).get('lang');
    if (urlLang === 'en' || urlLang === 'zh') return urlLang;
    return navigator.language.startsWith('zh') ? 'zh' : 'en';
}

The t('key') function then looks up translations:

function t(key) {
    return translations[currentLang][key] || translations['zh'][key] || key;
}

Simple, but it works. No external dependencies, no build step, just a plain object.

Performance Considerations

For a tool like this, performance is mostly about not being stupid. The main concerns:

Large inputs: A 10MB file will freeze the browser if you try to process it synchronously on every keystroke. The debounce helps, but you might also need to cap the input size.
String operations: String.fromCharCode(...array) is fine for typical inputs but will throw a RangeError for arrays larger than about 65K elements. For robustness, you'd chunk it:

function bytesToBinaryString(bytes) {
    let result = '';
    const chunkSize = 0x8000;
    for (let i = 0; i < bytes.length; i += chunkSize) {
        result += String.fromCharCode.apply(null, bytes.subarray(i, i + chunkSize));
    }
    return result;
}

DOM updates: Don't update the output textarea on every keystroke. Batch updates or use requestAnimationFrame if needed.

What I Learned

The "it works on my machine" moment: The first version of the tool worked perfectly with English text. It wasn't until I tested with Chinese characters that the encoding bug surfaced. This is a reminder to always test with the character sets your users will actually use.

The "it's always a CSS issue" moment: The dark mode implementation initially had a bug where textareas kept a light background in dark mode. It was a specificity issue — the background property on textarea was overriding the CSS variable. The fix was to use the variable consistently:

textarea {
    background: var(--bg-input);
    color: var(--text);
}

The "AI is a junior developer" moment: AI-assisted development is powerful, but it's not a replacement for understanding the fundamentals. The AI could write the code, but I had to know enough to catch the subtle bugs. It's like having a very fast junior dev who occasionally makes confident mistakes.

The Result

During this process, I built a small browser-based tool to make this workflow easier. It handles UTF-8 correctly, supports real-time conversion, and works entirely in the browser — no data ever leaves your machine.

The full implementation is a single HTML file with inline CSS and JavaScript, which makes it easy to deploy or even save locally for offline use.

Final Thoughts

Base64 encoding seems simple until it isn't. The UTF-8 handling is the kind of thing that looks trivial in theory but causes real production issues. If you're building anything that processes text, take five minutes to test with non-ASCII characters. Your future self will thank you.

And if you're using AI to write code, remember: it's a tool, not a replacement for understanding. The best workflow is to use AI for the parts that are tedious and mechanical, then apply your own knowledge to catch the subtle issues.

You can try the tool at Craftvo if you're curious about the implementation.

Building a Countdown Timer Without External Dependencies: A Vanilla JS Journey

ggwork — Tue, 25 Aug 2026 01:12:48 +0000

There's something oddly satisfying about building a tool that thousands of people might use daily, especially when you decide to do it with zero dependencies. No React, no Vue, no moment.js — just good old-fashioned vanilla JavaScript, HTML, and CSS.

Last month, I needed a countdown timer for an upcoming project deadline. I could have downloaded any of the hundreds of countdown apps available. But as developers, we often find ourselves thinking, "I could build this myself in an afternoon." Spoiler alert: it took longer than an afternoon, but the journey was worth it.

The Problem with Existing Solutions

Most countdown timer tools online are either:

Bloated with features I didn't need (who needs a countdown with confetti animations?)
Require desktop installation (I wanted something browser-based)
Have terrible mobile responsiveness (nobody wants to pinch-zoom on a timer)
Are riddled with ads and tracking scripts

I wanted something simple: set a date, see the time remaining, get a visual progress indicator. That's it. No account creation, no email signup, no "premium features" paywall.

The Architecture Decision: Why Vanilla?

When I started planning, I caught myself reaching for React out of habit. But then I thought about it — this is a single-purpose tool with minimal state. Do I really need a virtual DOM for a timer?

The answer was no. Here's my reasoning:

// The entire state management for this app
let targetDate = null;
let eventName = '';
let startDate = null;

That's it. Two variables and a timer interval. Adding React would have meant:

A build process
Bundle size overhead
More complexity than the actual problem requires

Sometimes the simplest solution is the right one. This was one of those times.

The Core Challenge: Time Calculation

The heart of any countdown timer is the time calculation logic. It sounds simple — subtract one date from another — but there are edge cases that'll bite you if you're not careful.

function updateCountdown() {
    const now = new Date();
    const diff = targetDate - now;

    if (diff <= 0) {
        // Handle expired state
        showExpired(Math.abs(diff));
        return;
    }

    const days = Math.floor(diff / (1000 * 60 * 60 * 24));
    const hours = Math.floor((diff % (1000 * 60 * 60 * 24)) / (1000 * 60 * 60));
    const minutes = Math.floor((diff % (1000 * 60 * 60)) / (1000 * 60));
    const seconds = Math.floor((diff % (1000 * 60)) / 1000);

    // Update DOM
}

The tricky part? Timezone handling. If someone in Tokyo sets a target date, and someone in New York views it, the calculations need to be consistent. I initially used new Date() everywhere, but quickly realized I needed to be more careful with how I stored and compared dates.

The "Works on My Machine" Moment

Here's where things got interesting. I tested the timer locally, and everything worked perfectly. Then I deployed it, and a user in Australia reported that the countdown was off by a day.

Classic "works on my machine" situation.

The issue? I was using local timezone offsets implicitly. When a user selected a date in their local timezone, I needed to store it as a timestamp (UTC) to ensure consistent calculations across timezones.

// The fix: convert to UTC timestamp when storing
const targetTimestamp = new Date(dateInput.value).getTime();

This was a humbling reminder that even "simple" time calculations have hidden complexity.

AI-Assisted Development: The Honest Truth

Now, here's where I need to be completely transparent. I used AI tools (mostly Claude and ChatGPT) throughout this project. Here's how it actually went — the good, the bad, and the ugly.

What AI Did Well

The initial skeleton: I described my requirements — a single-file HTML tool with dark mode support, i18n, and responsive design — and the AI generated a solid starting point in minutes. The CSS variables structure, the basic layout, and the initial JavaScript logic were all well-structured.

The i18n implementation: I asked for a lightweight internationalization system that supported English and Chinese, with language detection based on URL parameters and browser settings. The AI came up with a clean solution:

const i18n = {
    zh: { title: '倒计时器', days: '天', hours: '时' },
    en: { title: 'Countdown Timer', days: 'days', hours: 'hrs' }
};

Dark mode: The media query for prefers-color-scheme was generated perfectly. No complaints there.

Where AI Struggled

The timezone bug: I spent two hours debugging a timezone issue that AI kept getting wrong. Every time I described the problem, it would suggest a fix that worked for the specific case but broke another edge case. Eventually, I had to reason through it myself and implement the solution manually.

Progress bar logic: The AI's initial implementation of the progress bar was mathematically incorrect for the "expired" state. It took several iterations of me explaining the requirements before it got the logic right.

Performance optimization: The AI initially used setInterval with DOM updates every 100ms, which caused unnecessary reflows. I had to point out that we only need to update once per second, and that we should batch DOM updates.

The Iterative Process

Working with AI felt like pair programming with a very enthusiastic junior developer. It's fast, eager, and sometimes confidently wrong. Here's what my workflow looked like:

Describe the feature: "I need a preset button that sets the target date to next New Year's Day"
Get the initial implementation: AI generates code that mostly works
Test and break it: Find the edge case that fails
Report the bug: Describe what happened and what should have happened
Iterate: Repeat until it works correctly

For example, the "New Year" preset initially set the date to January 1st of the current year, which meant it was always in the past. The fix required understanding the business logic:

function setNewYearPreset() {
    const now = new Date();
    const nextYear = now.getFullYear() + 1;
    targetDate = new Date(nextYear, 0, 1); // January 1, next year
}

The "Aha" Moment: Single File Architecture

One of my best decisions was keeping everything in a single HTML file. Here's why:

No build step: Edit, save, refresh. That's the entire development loop.
Easy deployment: Just upload one file to any static host.
Instant sharing: Users can save the file locally and use it offline.
Performance: No network requests for assets — everything is inline.

The trade-off? The file gets large (around 15KB for this project), but for a utility tool, that's perfectly acceptable. Users get instant load times with zero requests.

The Progress Bar Problem

The progress bar was trickier than expected. If the user sets a start date, we can show progress. But what if they don't? I needed to handle three states:

No start date set → Show no progress bar
Start date in the past → Calculate progress as (now - start) / (target - start)
Target date passed → Show 100% (or switch to "expired" visual)

The AI kept overcomplicating this. It wanted to create a full state machine. I simplified it to:

function updateProgress() {
    if (!startDate) return;
    const total = targetDate - startDate;
    const elapsed = now - startDate;
    const percent = Math.min(100, Math.max(0, (elapsed / total) * 100));
    // Update progress bar width
}

Sometimes the simplest solution is the right one, even if it doesn't handle every edge case perfectly.

Lessons Learned

1. AI is a multiplier, not a replacement: It made me 3x faster at writing boilerplate code, but I still needed to understand the domain deeply to catch its mistakes.

2. Time is always more complex than you think: Timezones, daylight saving, leap years — these aren't edge cases, they're the norm. Always test with real-world dates.

3. Single-file apps have a place: For utility tools, the simplicity of deployment and usage outweighs the benefits of a build system.

4. Performance matters, even for simple tools: The difference between updating the DOM every 100ms vs. every 1000ms might not seem like much, but it affects CPU usage and battery life on mobile devices.

5. Dark mode isn't optional anymore: Users expect it. The prefers-color-scheme media query is your friend.

The Result

After about three days of work (two of which were debugging timezone issues), I had a working countdown timer that:

Works entirely in the browser
Supports English and Chinese
Has dark mode
Is fully responsive down to 320px
Updates in real-time
Handles expired states gracefully
Weighs less than 20KB total

During this process, I built a small browser-based tool to make this workflow easier. You can try it here: Craftvo Countdown Timer

Final Thoughts

Building a countdown timer taught me that "simple" tools often have hidden complexity. It also showed me that the right tool for the job might be simpler than you think — sometimes a single HTML file is all you need.

The AI-assisted development experience was genuinely positive, but it's not magic. It's like having a fast, enthusiastic pair programmer who sometimes needs guidance. The key is knowing enough to catch its mistakes and guide it in the right direction.

And remember: it's always a timezone issue. It's always a timezone issue.

Building an ASCII Art Generator with AI: The Good, The Bad, and The Figlet

ggwork — Mon, 24 Aug 2026 09:36:02 +0000

The Problem

I was staring at my terminal during a deploy, waiting for the build to finish, when I realized something: I'd been typing figlet "Hello World" into my terminal for years to generate ASCII art for commit messages and README files. But every time I wanted to share that art with someone who wasn't a developer, I hit a wall.

"Just install figlet," I'd say.

"Install what now?" they'd reply.

The problem wasn't that ASCII art tools don't exist online. The problem was that the ones I found were either bloated with ads, required JavaScript frameworks that made the page take forever to load, or couldn't handle non-Latin characters gracefully. I wanted something that just worked in a browser tab, no installation, no server, no fuss.

So I decided to build my own. Because apparently I enjoy reinventing wheels.

The AI-Assisted Development Journey

Here's where things get interesting. I've been using AI pair programming for a while now, and this project felt like the perfect test case: it's well-defined, has clear requirements, and involves a lot of repetitive font data that would be tedious to type manually.

The Initial Prompt

I started by describing the requirements to an AI assistant in pretty specific terms:

Build a single-file HTML tool that converts text to ASCII art. 
Must have multiple fonts (Block, Slant, Small, Standard, Mini). 
Real-time preview. Copy to clipboard. Download as .txt. 
Support dark mode. Chinese/English i18n. Vanilla JS only.

The AI came back with something surprisingly decent. It had the basic structure right, the font data was embedded, and the rendering logic was clean. But there were issues.

Where AI Got It Wrong

The first problem was character handling. The AI assumed that all input would be uppercase English letters. When I tested with lowercase, numbers, and special characters, it just... broke. Not crashed, but silently dropped characters.

// What the AI initially wrote (simplified)
function getChar(char, font) {
    return font[char.toUpperCase()] || '  '; // Silent failure
}

The problem? This returns empty strings for any character not in the font data. A user typing "Hello World" would get "HELLO WORLD" in ASCII art, which isn't terrible, but a user typing "Café" would lose the "é" entirely.

My fix: I had to explicitly handle non-ASCII characters by falling back to the original character output, so the user sees something rather than nothing.

// The fix
function getChar(char, font) {
    if (char === ' ') return font[' '] || ['  '];
    if (!font[char.toUpperCase()]) return [char]; // Show original char
    return font[char.toUpperCase()];
}

The second issue was line wrapping. The AI's initial implementation would create a massive horizontal scroll for long text. I wanted automatic wrapping at a configurable width.

The AI's approach was to just let it overflow. My approach was to split the input into chunks of N characters before passing to the renderer:

function wrapText(text, width) {
    const lines = [];
    for (let i = 0; i < text.length; i += width) {
        lines.push(text.slice(i, i + width));
    }
    return lines;
}

This is simple, but it breaks words. For an ASCII art tool, that's actually fine — you're not reading prose, you're looking at a banner.

What AI Got Right

Honestly, the AI handled the font data brilliantly. Typing out 5 different fonts × 36 characters × 5-7 lines each would have taken me an hour. The AI generated all of it in seconds, and the quality was surprisingly good.

It also nailed the i18n pattern on the first try. I asked for a simple language toggle, and it implemented a clean dictionary pattern:

const translations = {
    'zh-CN': { title: 'ASCII Art 生成器', inputLabel: '输入文本', ... },
    'en': { title: 'ASCII Art Generator', inputLabel: 'Input Text', ... }
};

The Iteration Loop

Here's what the real workflow looked like:

Prompt: "Add a character set selector" → AI adds a dropdown with "Standard", "Wide", "Narrow" options
Test: I type "Hello" and switch to "Wide" → Nothing changes
Debug: I look at the code and realize the font data doesn't have a "Wide" variant
New prompt: "The character set selector doesn't work because there's no wide font data. Generate a wide variant of the Standard font"

This back-and-forth happened maybe 5-6 times for various features. Each iteration was faster than if I'd written the code from scratch, but I had to know what to ask for. The AI couldn't anticipate that the character set selector needed actual font data behind it.

Key Technical Decisions

Why Vanilla JS?

I could have used React or Vue, but for a single-file tool, that's overkill. Vanilla JS keeps the file self-contained — no build step, no dependencies, just open the HTML and it works. This is important for a tool that people might want to save locally or use offline.

The Font Data Structure

The core of the tool is the font data. Each font is an object where each key is a character and each value is an array of strings (one string per line of the character):

const fonts = {
    standard: {
        'A': ['  ██  ', ' ████ ', '██  ██', '██████', '██  ██'],
        'B': ['█████ ', '██  ██', '█████ ', '██  ██', '█████ '],
        // ... 36 more characters
    }
};

This structure makes rendering trivial:

function renderLine(text, font) {
    const lines = [];
    for (let row = 0; row < font['A'].length; row++) {
        let line = '';
        for (const char of text) {
            line += (font[char.toUpperCase()] || [char])[row] || ' ';
        }
        lines.push(line);
    }
    return lines.join('\n');
}

Copy to Clipboard

The hardest part of the whole project was clipboard functionality. The navigator.clipboard.writeText() API requires a secure context (HTTPS or localhost), and it returns a Promise that can reject.

async function copyToClipboard(text) {
    try {
        await navigator.clipboard.writeText(text);
        showFeedback('Copied!');
    } catch (err) {
        // Fallback for older browsers
        const textarea = document.createElement('textarea');
        textarea.value = text;
        document.body.appendChild(textarea);
        textarea.select();
        document.execCommand('copy');
        document.body.removeChild(textarea);
        showFeedback('Copied!');
    }
}

The fallback is ugly but necessary — you never know what browser someone's using.

The "Wait, That's a CSS Issue" Moment

Spoiler: it was a CSS issue. It's always a CSS issue.

The ASCII art looked perfect in the <pre> tag, but when I copied it to the clipboard and pasted it into a terminal or Discord, the spacing was off. The culprit? The font-family in the <pre> tag used system fonts that rendered wider than standard monospace fonts.

The fix was to force a specific monospace font stack and set a fixed font-size:

.result-box pre {
    font-family: 'Courier New', Courier, monospace;
    font-size: 12px;
    line-height: 1.2;
    letter-spacing: 0;
}

This ensures that what you see is what you get when you paste elsewhere.

Lessons Learned

1. AI Can't Read Your Mind

The AI didn't know that "character set selector" meant I wanted different font widths. I had to be specific about what each feature should do and what data it needed. The more context I gave, the better the output.

2. Test Edge Cases Early

The AI-generated code handled common cases well but fell apart on edge cases: empty input, very long text, special characters, and mixed language input. I should have tested these before asking for new features.

3. Font Data is the Hard Part

Writing the rendering logic is easy. Getting 5 fonts × 36 characters of perfectly aligned ASCII art is the real work. AI made this feasible — I would have given up on the third font otherwise.

4. Keep It Simple

Despite all the features I listed, the core functionality is just: take text, look up characters in a font object, render as a string. Everything else is sugar on top.

The Result

During this process, I built a small browser-based tool to make this workflow easier. It's a single HTML file with no dependencies, works offline, and handles the basics well. You can check it out at Craftvo's ASCII Art Generator if you're curious.

The tool supports 5 fonts, real-time preview, copy/download functionality, and automatic wrapping for long text. It handles non-ASCII characters by falling back to the original character, so "Café" renders as "Café" rather than "CAF" with a missing character.

Final Thoughts

AI-assisted development for this project was a net win. The AI handled the tedious parts (font data generation, boilerplate CSS) and I handled the architectural decisions and edge cases. But it wasn't magic — I still had to know what to ask for and how to test the results.

The best workflow was iterative: prompt, test, debug, refine. Each cycle took minutes rather than hours, and the end result was better than anything I would have written alone in the same timeframe.

If you're thinking about building a similar tool, my advice is: let the AI do the heavy lifting, but don't trust it blindly. Test everything, especially the edge cases, and be prepared to fix the things it gets wrong.

Now if you'll excuse me, I need to generate an ASCII art banner for my next commit message.

Building a Morse Code Translator: When Retro Communication Meets Modern Web APIs

ggwork — Mon, 24 Aug 2026 06:47:26 +0000

While working on a collection of browser-based tools recently, I found myself needing a Morse code translator. Not because I'm secretly a ham radio enthusiast or planning to send distress signals from my basement, but because I kept running into situations where I needed to decode or encode Morse code quickly.

The existing solutions were... fine, I guess. But they were mostly mobile apps with more ads than functionality, or websites that felt like they were designed in 1998 and never updated. I wanted something that worked entirely in the browser, had a clean interface, and could actually play the audio tones — not just show the dots and dashes. Because apparently I enjoy reinventing wheels.

The "Simple" Problem That Wasn't

Here's the thing about Morse code translation: it sounds trivial. Map letters to dots and dashes, reverse the mapping, done. But once you start thinking about the details, it gets interesting.

First, there's the timing. Morse code isn't just about the symbols — it's about the spaces between them. A dit is one time unit, a dah is three units, the gap between letters is three units, and between words it's seven units. Get the timing wrong and your "translation" sounds like someone mashing a telegraph key with no rhythm.

Then there's the audio playback. The Web Audio API gives you incredible control, but it also has this tendency to make you feel like you're writing assembly language when all you want is a simple beep.

And finally, there's the bidirectional nature of the UI. Type text, get Morse. Type Morse, get text. Both happening in real-time, with the ability to swap directions. It's the kind of problem that seems simple until you actually try to build it.

The Architecture Decisions

Let me walk you through the key decisions I made, starting with the most important one: keeping everything in a single HTML file.

Why single-file? For a tool like this, a single-file architecture makes sense. There's no build step, no server required, and users can literally save the file and run it offline. It's the ultimate in portability. The trade-off is that you can't use any external libraries — everything has to be vanilla JavaScript and CSS. Which, honestly, is fine for this scope.

The Morse mapping. The core data structure is straightforward:

const MORSE_MAP = {
  'A': '.-', 'B': '-...', 'C': '-.-.', 'D': '-..', 'E': '.',
  'F': '..-.', 'G': '--.', 'H': '....', 'I': '..', 'J': '.---',
  // ... rest of alphabet and numbers
};

The reverse mapping is derived programmatically — no need to maintain two separate objects that could drift out of sync.

The bidirectional conversion. This was trickier than I expected. When you're converting text to Morse, it's straightforward: uppercase everything, map each character, join with spaces. But going the other direction requires parsing the Morse code with its spaces and slashes:

function morseToText(morse) {
  return morse
    .split('/')
    .map(word => word.trim().split(' ')
      .map(code => REVERSE_MORSE[code] || '')
      .join(''))
    .join(' ');
}

Simple, but effective. The slash separates words, spaces separate letters.

The Audio Playback Challenge

This was where things got interesting. I wanted to play the Morse code as actual sound — the characteristic beeps you hear in old war movies. The Web Audio API can do this, but it requires careful timing management.

The first approach I tried was scheduling all the tones upfront using AudioContext's time-based scheduling. This worked, but it had a problem: if the user wanted to stop playback mid-way, I'd have to track every scheduled oscillator and disconnect them all. It got messy fast.

function playMorse(morseCode, wpm, frequency) {
  const ditDuration = 1200 / wpm; // milliseconds
  const context = new AudioContext();
  let time = context.currentTime;

  // Schedule all tones upfront
  for (const char of morseCode) {
    if (char === '.') {
      playTone(context, time, ditDuration / 1000, frequency);
      time += ditDuration / 1000;
    } else if (char === '-') {
      playTone(context, time, (ditDuration * 3) / 1000, frequency);
      time += (ditDuration * 3) / 1000;
    }
    time += ditDuration / 1000; // gap between symbols
  }
}

The better approach was to use setTimeout to schedule each tone individually, making it easy to cancel with clearTimeout when the user hits stop. The trade-off is less precise timing, but for a tool like this, that's acceptable.

When AI Actually Helped (And When It Didn't)

I'll be honest: I used AI assistance for parts of this project, and the experience was mixed.

Where AI excelled: The initial scaffolding. Describing the UI layout, the i18n system, and the basic conversion logic to Claude got me a solid foundation in minutes. The AI was particularly good at generating the complete Morse code mapping table — all 36 characters plus punctuation — without any errors. That's the kind of tedious, error-prone work that AI handles perfectly.

Where AI struggled: The audio playback timing. My first prompt to Claude produced code that technically worked but sounded wrong. The timing between letters was too short, making everything sound like one continuous tone. It took several iterations of "no, the gap between letters needs to be longer" before the AI finally got the timing right.

The real lesson? AI is great for generating boilerplate and well-known logic patterns, but you still need to understand the domain well enough to verify the output. The AI didn't know Morse code timing standards — I had to tell it.

The i18n Approach

Given that I'm building a collection of tools for a global audience, internationalization was non-negotiable. But I didn't want to pull in a full i18n library for what's essentially a two-language tool.

The solution was a lightweight dictionary-based approach:

const i18n = {
  en: {
    'title': 'Morse Code Translator',
    'text-input': 'Text Input',
    'morse-output': 'Morse Code',
    // ...
  },
  zh: {
    'title': '摩斯电码翻译器',
    'text-input': '文本输入',
    'morse-output': '摩斯电码',
    // ...
  }
};

The language detection follows a specific priority: URL parameter > browser language > default. It's not perfect — there's no way to handle languages beyond English and Chinese without adding more dictionaries — but it covers the main use cases.

The CSS That Made Me Question My Life Choices

Let me talk about the CSS for a moment. I wanted the tool to look modern and clean, with proper dark mode support. The approach was CSS variables with prefers-color-scheme:

:root {
  --bg: #ffffff;
  --text: #111827;
  --primary: #3b82f6;
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #1a1a2e;
    --text: #e2e8f0;
    --primary: #60a5fa;
  }
}

This worked perfectly... until I realized the accent-color property for range inputs doesn't respect CSS variables in all browsers. Classic "works on my machine" situation. The fix was to explicitly set the accent color using the variable, which works in modern browsers but required a fallback for older ones.

Lessons Learned

1. Timing precision matters more than you think. When I first built the audio playback, I was using setTimeout with the calculated durations. But the actual timing was off because setTimeout isn't precise — it fires when it can, not when you ask it to. For a tool that needs to generate Morse code at a specific WPM, this is a real problem. The solution was to use the Web Audio API's built-in scheduling whenever possible, falling back to setTimeout only when necessary.

2. Don't trust AI with domain-specific knowledge. The AI was confident when it generated the audio timing code, but it was wrong about the standard timings. Morse code has specific rules: dit = 1 unit, dah = 3 units, gap between symbols = 1 unit, gap between letters = 3 units, gap between words = 7 units. The AI didn't know these standards and made up its own timing scheme.

3. Single-file architecture is underrated. For small tools, the simplicity of a single HTML file is unmatched. No build process, no dependencies, no deployment headaches. Just open the file and it works.

The Result

During this process, I built a small browser-based tool to make this workflow easier. It handles bidirectional translation, plays audio with adjustable speed and tone, includes a complete reference chart, and works entirely offline. You can find it here: Craftvo's Morse Code Translator

The code is about 400 lines of JavaScript, 200 lines of CSS, and one HTML file. It's not the most impressive engineering feat, but it solves a real problem in a clean way.

Final Thoughts

Building tools like this reminds me that sometimes the most interesting engineering problems come from the simplest requirements. Morse code translation sounds trivial, but it touches on character encoding, audio synthesis, timing precision, and internationalization. Each of these presents its own challenges, and solving them together makes for a satisfying engineering exercise.

And yes, I did test it by sending "SOS" in Morse code. Because I'm a responsible engineer who tests thoroughly. That's my story, and I'm sticking to it.

Tags: webdev, javascript, webaudio, tools, i18n

How to Parse TOML in the Browser Without a Backend

ggwork — Mon, 24 Aug 2026 01:49:44 +0000

While working on a configuration-heavy project recently, I kept running into the same annoying problem. I'd receive TOML config files from teammates or clients, and I needed to quickly verify the structure, check for syntax errors, or convert them to JSON for debugging. Opening a terminal, installing a parser, and writing a script for a one-off check felt like overkill.

I tried using online tools, but most were either cluttered with ads, required uploading my config to a server, or only supported JSON/YAML. For a format that's supposed to be "obvious and minimal," the tooling around it felt anything but.

So I did what any reasonable developer would do: I built my own browser-based TOML parser. Because apparently I enjoy reinventing wheels.

The Problem With Existing Solutions

Before diving into code, let me explain why existing tools weren't cutting it.

Most online parsers have a fundamental flaw: they send your data to a server. For config files containing API keys, database credentials, or internal service endpoints, that's a non-starter. Even for non-sensitive data, the round-trip adds latency and breaks the flow of quick debugging.

The other issue was format support. Many "universal" config converters handle JSON and YAML well but treat TOML as an afterthought. When they do support it, the error messages are often cryptic — just "parse error" without line numbers or context.

I wanted something that:

Runs entirely in the browser (no uploads)
Parses TOML 1.0.0 spec correctly
Gives helpful error messages with line numbers
Shows results in both JSON and tree view

Choosing the Right Parser Library

The first decision was which TOML library to use. I evaluated two options:

// Option 1: smol-toml (ESM, modern)
import { parse } from 'https://esm.sh/smol-toml';

// Option 2: @iarna/toml (UMD, battle-tested)
const { parse } = require('@iarna/toml');

I went with smol-toml for a few reasons. It's actively maintained, follows the TOML 1.0.0 spec strictly, and provides detailed error messages with line/column info. The ESM format works cleanly with modern browser imports.

But there's a catch: if the CDN fails or the user is offline, the tool breaks. I needed a fallback strategy.

Handling CDN Failures Gracefully

This was one of those "it worked on my machine" situations that almost bit me in production. I initially loaded the library with a simple import statement:

import { parse } from 'https://esm.sh/smol-toml';

The problem? If that CDN request fails, the entire script crashes. No error message, no graceful degradation — just a blank page.

The fix was wrapping the import in a dynamic import with error handling. If the library fails to load, I show a clear message and fall back to a minimal built-in parser for basic cases:

let tomlParser = null;

async function loadTomlParser() {
  try {
    const module = await import('https://esm.sh/smol-toml');
    tomlParser = module.parse;
  } catch (e) {
    showError('Failed to load TOML parser library. Check your connection.');
    tomlParser = fallbackParser; // minimal built-in
  }
}

The fallback parser handles basic key-value pairs and simple tables, but for complex nested structures, it honestly struggles. The lesson here: always plan for dependency failures, even with CDNs.

Building the Tree View

The most interesting part was the tree visualization. JSON output is straightforward — just stringify the parsed object with indentation. But a collapsible tree view requires recursive rendering.

Here's the core of the tree renderer:

function renderTree(obj, indent = 0) {
  if (Array.isArray(obj)) {
    return obj.map(item => renderTree(item, indent + 1)).join('');
  }

  if (typeof obj === 'object' && obj !== null) {
    return Object.entries(obj).map(([key, val]) => `
      <div>
        <span class="tree-toggle" onclick="toggleNode(this)">▸</span>
        <span class="tree-key">"${key}"</span>: 
        ${typeof val === 'object' && val !== null 
          ? `<div class="tree-children">${renderTree(val, indent + 1)}</div>`
          : `<span class="tree-${typeof val}">${formatValue(val)}</span>`}
      </div>
    `).join('');
  }

  return `<span class="tree-${typeof obj}">${formatValue(obj)}</span>`;
}

The recursive approach works well for most cases, but I hit a performance wall with deeply nested structures. A config with 5+ levels of nesting and large arrays would freeze the browser momentarily. The fix was adding a depth limit — if the tree goes beyond 10 levels, I collapse it by default and let users expand manually.

The AI-Assisted Development Process

Full disclosure: I used Claude to help build this. Here's how the collaboration actually went.

First attempt: I described the tool requirements in detail — the layout, the features, the i18n support, the dark mode. The AI generated a complete HTML file in one shot. It looked impressive at first glance.

The problems emerged immediately:

The tree view didn't handle arrays properly (showed them as objects)
Error messages from the parser weren't being captured with line numbers
The i18n implementation was incomplete — some strings were hardcoded in Chinese

The iteration loop:

I'd test a specific interaction
Report the bug to the AI with a screenshot or error message
Get a fix, but sometimes a new bug would appear elsewhere

The most frustrating part was the AI's tendency to over-engineer. It kept adding features I didn't ask for — like a settings panel and localStorage persistence — while missing the core error handling.

What the AI nailed:

The CSS design system with variables for dark mode
The responsive layout (grid to single column below 640px)
The basic parsing logic with debounced input

Where I had to step in:

Error handling edge cases (empty input, malformed TOML, circular references)
The tree view's array rendering
Making error messages actually helpful with line numbers

A Key Lesson: Debouncing Matters

When I first wired up the input to parse on every keystroke, it was laggy. Not because parsing is expensive, but because rendering the tree view on every change was wasteful.

let debounceTimer;
input.addEventListener('input', () => {
  clearTimeout(debounceTimer);
  debounceTimer = setTimeout(parseAndRender, 300);
});

A simple 300ms debounce made the tool feel instant. This is one of those "obvious in hindsight" optimizations that makes a huge difference in perceived performance.

What I'd Do Differently

If I were building this again, I'd spend more time on the error messages. The TOML spec has specific error cases — unclosed strings, invalid dates, duplicate keys — and each deserves a clear, actionable message. The library gives me the line number, but converting that into "you forgot to close a quote on line 12" requires more work than I initially thought.

The Result

During this process, I built a small browser-based tool to make this workflow easier. It's a single HTML file that handles TOML parsing, JSON conversion, tree visualization, and error reporting — all locally in the browser. If you're dealing with TOML configs regularly, you can check it out at Craftvo.

The real takeaway here isn't the tool itself — it's the process. Building browser-based dev tools that respect user privacy (no server uploads) is increasingly important. And with AI assistance, what used to take days can now take hours. The catch is that AI gives you a working solution, not a correct one. The debugging and edge-case handling still require human judgment.

That's the honest truth about AI-assisted development: it's a great rubber duck, but it's not a senior engineer. Yet.