DEV Community: ggwork

How to Build a Client-Side Chinese Converter with OpenCC (No Server Needed)

ggwork — Sun, 06 Sep 2026 07:06:17 +0000

While working on a browser-based utility project recently, I hit a surprisingly tricky problem: I needed to add Chinese Simplified ⇄ Traditional conversion to a tool. The catch? I didn't want to send users' text to a server, and I definitely didn't want to maintain a backend just for text transformation.

The obvious answer was to find a JavaScript library that could handle this entirely in the browser. But as I started researching, I realized this was more nuanced than I initially thought.

The Problem with Existing Solutions

Let me be honest: there are plenty of Chinese converter tools out there. The issue is that most of them either:

Rely on server-side APIs – which means your text leaves the browser. For a privacy-focused tool, that's a non-starter.
Use naive character mapping – where each character is mapped individually. This works for most cases but completely misses phrase-level conversion.

Here's what I mean by phrase-level conversion. Consider the word "软件" (software). A naive character-by-character conversion would give you "軟件" in Traditional Chinese. But that's wrong for Taiwan – they say "軟體". Similarly, "鼠标" (mouse) should become "滑鼠" in Taiwan, not "鼠標".

This is the classic trap of Chinese conversion. It's not just about character mapping; it's about regional vocabulary differences. And that's precisely where OpenCC shines.

Why OpenCC?

OpenCC (Open Chinese Convert) is the gold standard for Chinese conversion. It's been around for years, maintained by the open-source community, and used by major projects. The key features:

Phrase-aware conversion – it understands context and converts whole phrases, not just characters
Region-specific output – separate conversion rules for Taiwan vs. Hong Kong Traditional
Two-way support – both Simplified → Traditional and Traditional → Simplified

The problem? OpenCC is primarily a Python/C++ library. Using it in the browser requires a JavaScript port. That's where opencc-js comes in – it's a direct JavaScript implementation that runs entirely client-side.

The Architecture Decision

I wanted this tool to work entirely in the browser. No server, no API calls, no text leaving the user's device. This meant:

Load the conversion engine via CDN
Package the dictionaries locally
Cache converter instances to avoid re-initialization

The first decision was how to load the library. I went with the UMD build from a CDN:

<script src="https://fastly.jsdelivr.net/npm/opencc-js@1.4.1/dist/umd/full.js" onerror="window.__openccFailed=true"></script>

The onerror handler was crucial – if the CDN fails to load, we need to show a graceful error message instead of a broken tool. This is something I learned from experience: always plan for network failures, even in client-side tools.

The Core Implementation

The API is refreshingly simple. Once the library loads, creating a converter is straightforward:

const converter = OpenCC.Converter({ from: 'cn', to: 'tw' });
console.log(converter('汉字')); // "漢字"

The from and to parameters accept region codes: cn for mainland China, tw for Taiwan, hk for Hong Kong. This gives us four conversion directions:

Simplified → Traditional (Taiwan): {from: 'cn', to: 'tw'}
Simplified → Traditional (Hong Kong): {from: 'cn', to: 'hk'}
Traditional (Taiwan) → Simplified: {from: 'tw', to: 'cn'}
Traditional (Hong Kong) → Simplified: {from: 'hk', to: 'cn'}

But there's a performance consideration. Creating a converter isn't free – it loads and initializes the dictionary data. Creating a new converter on every conversion would be wasteful. The solution is simple caching:

const converterCache = new Map();

function getConverter(from, to) {
  const key = `${from},${to}`;
  if (!converterCache.has(key)) {
    converterCache.set(key, OpenCC.Converter({ from, to }));
  }
  return converterCache.get(key);
}

This way, the first conversion in each direction pays the initialization cost, but subsequent conversions are instant.

The AI-Assisted Development Experience

Here's where things got interesting. I built this tool with heavy assistance from Claude AI, and the experience was... educational.

What the AI Got Right

The initial scaffolding was surprisingly good. I described the requirements – a browser-based converter with four conversion directions, copy functionality, and dark mode support – and the AI produced a working skeleton within minutes. The CSS was particularly well-handled, including the prefers-color-scheme media query for dark mode.

What the AI Got Wrong

The first version had a critical flaw: it was trying to use opencc-js as an ES module, which doesn't work with the UMD build. The error was subtle – the import statement looked correct, but the module resolution failed at runtime.

The AI also initially tried to create a new converter on every conversion, which would have been a performance disaster. It took a specific prompt to add caching:

"Cache the converter instances so they're only created once per direction."

The Back-and-Forth

The real value of AI assistance came from iteration. For example, the AI initially handled the CDN failure case poorly – it just let the page break. I had to explicitly ask:

"What happens if the CDN fails to load? Add error handling."

That's when we added the onerror callback and a status message system. The AI wouldn't have thought about this on its own – it was focused on the happy path.

The Hard Problem: Regional Differences

The most interesting engineering challenge wasn't technical – it was linguistic. Consider these conversions:

"软件" → Taiwan: "軟體" (not "軟件")
"鼠标" → Taiwan: "滑鼠" (not "鼠標")
"网络" → Taiwan: "網路" (not "網絡")

These aren't character-level transformations. They require word-level knowledge. OpenCC handles this through its extensive dictionary system, but it means the conversion isn't always predictable. This is actually a feature – it's what makes the output sound natural to native speakers.

For the UI, this meant I couldn't just label the options generically. Users need to know that "Simplified → Traditional" isn't enough – they need to choose between Taiwan and Hong Kong variants. The UI needed to be explicit about these regional differences.

Performance Considerations

The full.js build of opencc-js is about 2MB – it includes all the dictionaries. That's a significant download, but it's a one-time cost. Once loaded, the conversion itself is fast:

First conversion after load: ~50-100ms (dictionary initialization)
Subsequent conversions: <5ms

The caching strategy was crucial. Without it, every conversion would pay the initialization cost. With it, the tool feels instant after the first use.

What I Learned

1. Client-side libraries have hidden costs. The 2MB dictionary download is worth it for privacy, but it's a real trade-off. If I were building this for a high-traffic site, I'd consider lazy-loading the library only when the user actually needs conversion.

2. Regional variants are a UX problem, not just a technical one. Users often don't know whether they need Taiwan or Hong Kong Traditional. The tool needs to make this distinction clear without overwhelming them.

3. AI assistance works best with specific prompts. The AI didn't anticipate edge cases like CDN failures or performance issues. But when I asked for specific improvements, it implemented them correctly. The collaboration worked because I knew what questions to ask.

The Result

During this process, I built a small browser-based tool to make this workflow easier. It handles all four conversion directions, works entirely client-side, and respects user privacy by never sending text to a server.

The tool is part of a larger collection of browser-based developer utilities I've been building. If you're curious, you can find it at Craftvo. But more importantly, if you're dealing with Chinese text conversion in your own projects, OpenCC is worth a serious look – it's the difference between output that looks machine-translated and output that reads naturally.

Tags: javascript, chinese, opensource, webdev, i18n

How I Built a Birthday Number Generator That Actually Makes Sense (Sort Of)

ggwork — Fri, 04 Sep 2026 05:37:50 +0000

Last week, I found myself staring at my calendar, wondering if there was any meaningful way to derive lottery numbers from a birthday. Not because I believe in lucky numbers — I'm a developer, I believe in deterministic algorithms — but because I kept seeing friends post their "birthday numbers" on social media, and I wanted to understand the logic (or lack thereof) behind it.

So I did what any reasonable developer would do: I built a tool for it.

The Problem: Random Isn't Random Enough

Here's the thing about lottery number generators — most of them just use Math.random(). That's fine if you want truly random numbers, but it's boring. Nobody feels a connection to a number that came from a JavaScript PRNG seed.

What people actually want is a story behind their numbers. "My birthday gives me these numbers" sounds way better than "a random number generator gave me these numbers." It's the difference between having a meaningful ritual and just gambling.

The challenge: how do you map a date like 1990-05-20 to a valid set of lottery numbers in a way that feels intentional, produces valid ranges, and doesn't require a server?

The "Algorithm" (I Use That Term Loosely)

Let me walk you through the logic, because it's actually a fun little puzzle.

For a Double Color Ball (双色球), you need 6 red balls (1-33) and 1 blue ball (1-16). For 3D/P3, you need 3 digits (0-9).

The naive approach would be something like:

// Don't do this
const redBall = year % 33;

This fails immediately because:

1990 % 33 = 10 — fine, but what about the month and day?
You need 6 unique numbers, and simple modulo arithmetic will produce duplicates fast
map33 needs to handle negative numbers and zero gracefully

The actual solution came from a classic programming trick I remembered from implementing hash functions:

const map33 = (n) => ((n - 1) % 33 + 33) % 33 + 1;

This is the "true modulo" pattern — it handles negative numbers correctly, which matters more than you'd think. When you're deriving numbers from date components and custom lucky numbers, you can easily end up with negative intermediate values.

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

Full disclosure: I built most of this with an AI assistant. Here's what that actually looked like.

What AI Got Right

I started with a prompt like: "Build me a tool that takes a birthday and generates lottery numbers. It should map date components to valid ranges and support custom lucky numbers."

The AI immediately understood the domain. It knew about 双色球's structure (6+1), it knew about 3D's 3-digit format, and it generated the map33 function correctly on the first try. That's genuinely impressive — it's not just pattern-matching; it's understanding the constraints of the problem.

Where It Stumbled

The first version had a critical bug: it didn't handle duplicate numbers. If your birthday somehow produced the same number twice (which happens more often than you'd think), you'd end up with 5 red balls instead of 6. The AI's solution was to just... not handle it. Classic.

I had to prompt it specifically: "What happens if the date components map to the same number? How do you ensure 6 unique red balls?" That's when it added the deduplication logic with a "fill from the edges" approach — if you can't get enough unique numbers from the date, it pulls from the extremes (1 and 33) to fill the gaps.

The CSS Nightmare

Here's where AI really struggled: the styling. The tool needed to work in both light and dark mode, look decent on mobile, and present the numbers in a way that felt like a lottery ticket.

The AI's first CSS attempt was a mess. It used fixed pixel values everywhere, didn't handle the prefers-color-scheme media query properly, and the ticket layout broke on mobile. I had to iterate on the CSS more than the JavaScript — which, if you've done any web development, you know is the real truth of frontend work.

The final version uses CSS custom properties for theming:

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

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

This made the dark mode transition trivial — no JavaScript, no class toggling, just good CSS architecture.

The Architecture Decision: Zero Dependencies

I made a deliberate choice early on: this tool would have zero dependencies. No React, no Vue, no build step. Just vanilla HTML, CSS, and JavaScript in a single file.

Why? Because the tool is so simple that any framework would be overkill. The entire logic is about 50 lines of JavaScript. Adding React to this would be like using a flamethrower to light a candle.

But here's the trade-off I had to accept: no framework means I'm responsible for everything. State management? That's just a variable. DOM updates? That's innerHTML. Internationalization? That's a dictionary object and a language detector.

The i18n was actually a fun challenge. The tool needs to support both Chinese and English, and I didn't want to load a library for that. The solution was a simple dictionary pattern:

const I18N = {
  zh: { title: "生日幸运数字选号器", gen: "生成号码" },
  en: { title: "Birthday Number Picker", gen: "Generate" }
};

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

Language detection via URL parameter first, then falls back to browser settings. It's not perfect — someone with a Chinese browser but English preference gets the short end — but it covers 95% of cases without any external services.

The "Why" Behind Every Decision

Why client-side only?

Privacy. If someone enters their birthday, that's personal data. Sending it to a server feels unnecessary and potentially creepy. With everything client-side, the data never leaves the browser. It's also faster — no network requests, instant response.

The trade-off: I can't track usage patterns or improve the "algorithm" based on user behavior. But for a fun utility tool, that's a good trade.

Why the specific number mapping?

I could have done something more complex — like hashing the date string and using the hash as a seed. But that feels too opaque. The whole point is that the user can see the connection between their birthday and the numbers. So I kept it transparent:

Year's last two digits → maps to a red ball
Month → maps to a red ball
Day → maps to a red ball
Custom lucky numbers → each maps to a red ball
Blue ball comes from a combination of all components

This way, when someone asks "where did this number come from?", you can actually explain it.

Why the disclaimer?

Because I have to be responsible. This tool is for entertainment, and it's easy for people to get superstitious about numbers. The disclaimer is front and center:

本工具按趣味规则将日期转换为号码，与开奖毫无关联，中奖概率不因此而改变。请理性购彩，量力而行。

It's not legal advice — I'm not a lawyer — but it's honest. The tool doesn't change your odds. It just makes the numbers feel meaningful.

Performance: Because Even Simple Things Can Be Slow

The whole tool runs in microseconds, but I still thought about performance:

No framework runtime: The page loads instantly because there's nothing to parse
No external assets: No CDN fonts, no icon libraries, no analytics scripts
Efficient DOM updates: Only update the result container when generating new numbers

The entire page is under 4KB of HTML, CSS, and JavaScript. That's smaller than a single image file. It loads faster than you can blink.

What I Learned

1. AI is great at constraints, bad at edge cases

The AI understood the problem domain well but kept missing edge cases: duplicates, empty input, invalid dates. I had to explicitly ask about these. It's like pair programming with a brilliant but inexperienced developer — you have to think about what they're not thinking about.

2. CSS is still the hardest part

Every time. The JavaScript logic was solved in minutes. The CSS took hours. And the most important part wasn't the layout — it was the theming system that respects user preferences.

3. Simplicity is a feature

I could have made this a full app with accounts, saved numbers, and sharing features. But the constraint — single file, no dependencies, instant load — forced better decisions. The tool does one thing and does it well.

4. Entertainment tools need to be honest

There's a fine line between fun and misleading. The tool is explicitly labeled as entertainment, and the disclaimer is prominent. You can have fun with numbers without pretending there's magic involved.

The Result

The tool works. You pick a date, optionally add lucky numbers, and get a set of numbers that feel connected to your birthday. It's not going to change your odds of winning — nothing will — but it makes the ritual more meaningful.

If you're curious, you can try it here: Birthday Number Picker

The entire thing is a single HTML file. No build step, no dependencies, no server. Just a date input, a few math functions, and a CSS custom property for dark mode.

And honestly? That's exactly what a tool like this should be.

How to Build a Chemical Equation Balancer with Linear Algebra in Vanilla JavaScript

ggwork — Fri, 04 Sep 2026 02:29:34 +0000

While working on a collection of browser-based developer tools, I kept running into the same problem: I needed to balance chemical equations for a chemistry study tool, and every existing solution was either a heavy external API call or a clunky desktop app. I wanted something that worked entirely in the browser — no server, no dependencies, just pure math and JavaScript.

The result was a small single-file tool that solves this with linear algebra. Here's how I approached it, including the parts where my AI assistant confidently led me astray.

The Problem: Balancing Equations Is Linear Algebra in Disguise

Balancing a chemical equation like H2 + O2 = H2O is essentially solving a system of linear equations. Each element gives you one equation, and you're solving for the coefficients that make atoms conserved on both sides.

For H2 + O2 = H2O:

Hydrogen: 2a = 2c
Oxygen: 2b = c

Where a, b, and c are the coefficients for H2, O2, and H2O respectively.

The trick is that this is an underdetermined system — you have more variables than equations. The solution is a vector in the null space of the coefficient matrix. Find that vector, scale it to integers, and you're done.

Parsing Chemical Formulas: The Part That Made Me Question My Life Choices

The math is elegant. The parsing is where things get ugly.

Chemical formulas have nested parentheses: Al2(SO4)3 means 2 Al, 3 S, and 12 O. I needed a parser that could handle this recursively.

My initial approach was a simple regex-based parser. That worked for flat formulas like H2O but completely broke on anything with parentheses.

The better approach: a recursive descent parser that processes the formula character by character.

function parseFormula(formula) {
    const counts = {};
    let i = 0;

    function parseGroup(multiplier = 1) {
        let localCounts = {};
        while (i < formula.length) {
            if (formula[i] === '(') {
                i++;
                const subCounts = parseGroup();
                // Handle subscript after closing paren
                let subMult = 1;
                if (/\d/.test(formula[i])) {
                    subMult = parseInt(formula[i]);
                    i++;
                }
                for (const [elem, count] of Object.entries(subCounts)) {
                    localCounts[elem] = (localCounts[elem] || 0) + count * subMult;
                }
            } else if (formula[i] === ')') {
                i++;
                return localCounts;
            } else if (/[A-Z]/.test(formula[i])) {
                let elem = formula[i++];
                if (/[a-z]/.test(formula[i])) {
                    elem += formula[i++];
                }
                let count = 1;
                if (/\d/.test(formula[i])) {
                    count = parseInt(formula[i]);
                    i++;
                }
                localCounts[elem] = (localCounts[elem] || 0) + count;
            }
        }
        return localCounts;
    }

    const result = parseGroup();
    // Apply top-level multiplier if needed
    return result;
}

The key insight: handle the (SO4)3 pattern by recursively parsing inside parentheses, then multiplying all counts by the subscript. This small function handles the recursive structure elegantly.

Gaussian Elimination: Where the AI Saved My Sanity

The linear algebra part is where most implementations fail. Here's the core idea:

Build a matrix where rows are elements and columns are compounds
Reactants get positive coefficients, products get negative
Find the null space vector using Gaussian elimination
Scale to smallest integer coefficients

The AI assistant was actually quite good at this part. It generated a solid Gaussian elimination implementation on the first try. The issue was everything around it.

The AI Collaboration: A Story of Confident Mistakes

Here's where I need to be honest about the AI-assisted development experience. I'm using this process for all my tools now, and it's a mixed bag.

What the AI did well:

The Gaussian elimination algorithm was correct on the first attempt
The basic structure was solid
The i18n setup was clean

What the AI got wrong:

It initially parsed formulas incorrectly for compounds with multiple capital letters like NaCl — it treated Na as N followed by a
It didn't handle the case where coefficients could be zero (which means an element appears on only one side)
The UI was ugly — I had to add proper styling and dark mode support myself

The parsing bug was particularly frustrating. The AI kept assuming element symbols are single letters followed by optional lowercase. That works for H2O but breaks for NaCl or CaCO3.

I had to explicitly show it the pattern for multi-letter element symbols:

// Wrong: /[A-Z][a-z]?/ - only handles one lowercase letter
// Right: /[A-Z][a-z]*/ - handles Na, Ca, Mg, etc.

The "Works on My Machine" Moment

The first version worked perfectly for all my test cases. I was ready to ship it.

Then I tried Fe + O2 = Fe2O3.

The AI's implementation gave me 4Fe + 3O2 = 2Fe2O3 — which is correct, but the intermediate steps were wrong. The matrix had a zero row that wasn't being handled properly, and the AI's "solution" was to add a special case.

The real fix was understanding that the null space computation needs to handle rank deficiency properly. When you have more compounds than elements, there's always a non-zero solution. But when you have fewer, you might get a trivial solution.

Performance and Edge Cases

The algorithm runs in O(n³) where n is the number of compounds. For typical chemistry equations (up to 10 compounds), this is instantaneous. No performance concerns.

But there are edge cases that will break any implementation:

H2O = H2O (already balanced) — should return coefficients of 1
C6H12O6 = C6H12O6 (same compound on both sides) — trivial solution
Equations with fractional coefficients that can't be scaled to integers

The last one is interesting. Some equations legitimately have fractional solutions, but for chemistry, we want integers. The AI initially just returned the fractional solution without trying to scale it.

The Final Architecture

The tool ended up being a single HTML file with three main components:

Parser: Converts chemical formulas to element counts
Solver: Uses Gaussian elimination to find minimal integer coefficients
Renderer: Displays the balanced equation with proper subscripts and a conservation table

The conservation table was a nice touch — it shows that hydrogen starts with 4 atoms and ends with 4 atoms, so you can visually verify the balancing worked.

Lessons Learned

On AI-assisted development: The AI is a powerful pair programmer, but it's not a replacement for understanding the problem. I had to debug the parser logic myself because the AI kept making the same mistake. It's great for generating boilerplate and standard algorithms, but domain-specific logic still requires human oversight.

On the math: Linear algebra is everywhere in programming. This project was a reminder that understanding the math behind the problem leads to cleaner solutions than brute-force approaches.

On chemical formulas: Parsing is always harder than it looks. The recursive descent approach handles all the edge cases but requires careful implementation.

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 parsing, balancing, and verification entirely in the browser. No API calls, no server-side processing, just math and JavaScript.

The tool is part of my collection of browser-based utilities at Craftvo. If you're working with chemistry or just want to see the implementation, it's all vanilla JavaScript — feel free to peek at the source.

The next time you need to balance an equation, remember: it's just linear algebra wearing a chemistry costume. And like most things in programming, the parser is the part that'll make you question your career choices.

Tags: javascript, chemistry, algorithms, linear-algebra, webdev

Building a Lottery Bet Calculator: A Lesson in Combinatorics and AI-Assisted Development

ggwork — Thu, 03 Sep 2026 07:58:36 +0000

As a developer, I've learned that the strangest requests often lead to the most interesting technical challenges. Last month, a friend asked me a simple question: "How many combinations are there if I pick 7 red balls and 2 blue balls in the lottery?"

Twenty minutes later, I was deep in a rabbit hole of combinatorial formulas, probability theory, and the surprisingly complex world of lottery betting systems. And because apparently I enjoy reinventing wheels, I decided to build a tool to solve this problem properly.

The Problem That Started It All

The original question was straightforward: calculate how many bets you'd need to place to cover all combinations of a "复式" (compound) lottery bet. In Chinese lottery systems like Double Color Ball (双色球), you can select more numbers than the base requirement, and the system generates all possible combinations.

The math is simple combinatorics:

For a compound bet selecting 7 red balls from 33, you need C(7,6) = 7 combinations
Multiply by the number of blue balls you've selected
Each combination costs ¥2

But here's where it gets interesting: there's a second betting system called "胆拖" (dan-tuo), where you designate certain numbers as "bold" (胆) that must appear in every combination, and others as "drag" (拖) that fill in the remaining slots.

This isn't just simple C(n,k) — you need to account for the bold numbers taking up slots. The formula becomes C(dragCount, 6 - boldCount) × blueCount.

Why Not Just Use Excel?

My first instinct was to throw together a quick spreadsheet. But then I thought about the users: lottery enthusiasts who might not be comfortable with Excel formulas, and who need quick answers on their phones while standing in line at the lottery shop.

I wanted something that works anywhere, requires no installation, and gives instant feedback. A browser-based tool was the obvious choice. Pure HTML, CSS, and JavaScript — no build step, no dependencies, no server.

The Math That Almost Broke Me

Here's where the "fun" began. The naive approach to calculating combinations is:

function combination(n, k) {
    return factorial(n) / (factorial(k) * factorial(n - k));
}

This works fine for small numbers, but C(33,6) involves factorials that quickly exceed JavaScript's safe integer limit. I know, I know — "BigInt exists," but I wanted to keep things simple and fast.

The solution? Use the multiplicative formula with integer division at each step to avoid overflow:

function combination(n, k) {
    if (k > n) return 0;
    k = Math.min(k, n - k);
    let result = 1;
    for (let i = 1; i <= k; i++) {
        result = result * (n - k + i) / i;
    }
    return result;
}

This works because each intermediate result is always an integer. The key insight is that you're multiplying and dividing in a specific order that keeps the numbers manageable. It's a classic combinatorial computing trick that I'd read about but never actually needed until now.

The AI Collaboration: Where It Helped and Where It Failed

This project was my first serious attempt at AI-assisted development, and it was... educational.

What AI Got Right

I described the requirements to Claude in a single, detailed prompt: the four calculation modes, the input validation rules, the output format, and the technical constraints. The AI generated a complete, working HTML file with all the JavaScript logic in one go. The core math was correct, the UI was clean, and it even included dark mode support and i18n scaffolding.

Where It Stumbled

The first version had a critical bug in the 胆拖 (dan-tuo) mode. The AI initially calculated the combinations as C(totalSelected, 6), not accounting for the fact that bold numbers are guaranteed to appear. The formula needed to be C(dragCount, 6 - boldCount), which is a subtle but crucial difference.

I caught this by manually testing edge cases:

// Test: 4 bold numbers, 3 drag numbers
// Should be C(3, 6-4) = C(3, 2) = 3 combinations
// AI's first attempt: C(7, 6) = 7 combinations (wrong!)

The AI's second attempt was correct, but it took a specific, detailed prompt to get there: "The bold numbers are always included, so the drag numbers only need to fill 6 - boldCount slots."

The Validation Logic

Another issue was input validation. The AI generated reasonable checks but missed some edge cases:

Bold count can't be 0 (that's just a regular compound bet)
Bold + drag must be at least 7
Drag count must be at least 1

I had to add these constraints manually. It's not that the AI couldn't handle it — it just didn't think about all the edge cases without being prompted.

The Architecture Decisions

Pure Frontend, No Build Step

I deliberately avoided any framework or build tool. The entire tool is a single HTML file with embedded CSS and JavaScript. This means:

Zero dependencies: No npm install, no CDN links, nothing that could break
Instant loading: The file is tiny and loads immediately
Works offline: Once loaded, it doesn't need a network connection
Easy to maintain: One file, one place to look for everything

The trade-off is that I can't use modern JavaScript features like modules or JSX, but for a tool this size, it's not a limitation — it's a feature.

The Mode Switching Logic

The UI needs to show different input fields depending on the selected mode. I initially considered having separate forms for each mode, but that would mean duplicating a lot of code. Instead, I used a dynamic input system:

const CONFIGS = {
    'ssq-fu': { fields: ['redCount', 'blueCount'], label: '双色球复式' },
    'ssq-dt': { fields: ['boldCount', 'dragCount', 'blueCount'], label: '双色球胆拖' },
    'd3-g3': { fields: ['numCount'], label: '3D组三复式' },
    'd3-g6': { fields: ['numCount'], label: '3D组六复式' }
};

When the user selects a mode, the script dynamically renders the appropriate input fields. This keeps the code DRY and makes it trivial to add new modes in the future.

The 3D Lottery Modes

The 3D/排列三 lottery has two compound bet modes that trip people up:

组三 (Group 3): Two numbers are the same, one is different. Formula: k × (k-1)
组六 (Group 6): All three numbers are different. Formula: C(k, 3)

These formulas aren't obvious to most people, so the tool serves a real educational purpose here. I've had users message me saying "I never understood why 组三 gives more combinations than 组六 for the same numbers" — and the tool makes it concrete.

Performance Considerations

For this tool, performance is a non-issue. The heaviest calculation is C(33,6) ≈ 1.1 million, which JavaScript handles in microseconds. But I still made deliberate choices:

No floating point arithmetic: All calculations use integers to avoid precision issues
No DOM manipulation during calculation: The result is built once and inserted, not updated incrementally
Debounced input handling: The calculate button is explicit, not automatic on every keystroke, to avoid unnecessary work

What I Learned

1. Edge Cases Are the Real Work

The math formulas are simple. The real work was thinking through all the boundary conditions:

What happens when bold count equals 5? (You need exactly 1 drag number)
What happens when bold count equals 0? (It's a compound bet, not dan-tuo)
What's the maximum reasonable input? (33 red balls, 16 blue balls for Double Color Ball)

Most of these came from manual testing, not from the AI or from the spec.

2. AI Is a Great Junior Developer

Using AI for this project felt like working with a competent junior developer who's fast but needs supervision. It:

Writes clean, well-structured code quickly
Makes subtle logic errors that are easy to miss
Needs specific, detailed instructions to handle edge cases
Excels at boilerplate and repetitive patterns

The key is knowing when to let it run and when to step in. For the core math logic, I reviewed every line. For the CSS and HTML structure, I let it do its thing.

3. Sometimes the Simple Solution Is the Best

I could have made this a React app with TypeScript, testing, and CI/CD. But the simplest solution — a single HTML file — is actually the most robust. It can't have dependency issues, it can't fail to build, and it works on any device with a browser.

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

The Takeaway

Building this tool taught me that:

Combinatorics in JavaScript requires careful thought — the naive factorial approach fails for real-world inputs
AI assistance is most effective when you understand the problem domain — I caught the dan-tuo bug because I understood the math, not because the AI told me
Small tools deserve the same engineering rigor — just because it's a single file doesn't mean it shouldn't be well-architected

And yes, my friend got his answer: 7 red balls and 2 blue balls gives you 14 combinations, costing ¥28. The tool is there if he ever needs to calculate something more complex.

Meta Description: Building a lottery bet calculator taught me about combinatorial math, JavaScript integer precision, and the realities of AI-assisted development. Here's what I learned about working with AI on real engineering problems.

Tags: javascript, webdev, ai, productivity, mathematics

How to Minify and Beautify HTML, JS, and CSS in the Browser Without a Backend

ggwork — Wed, 02 Sep 2026 01:17:04 +0000

While working on a project recently, I needed to clean up some minified JavaScript that was basically unreadable. The code worked fine, but trying to debug it was like reading hieroglyphics without the Rosetta Stone. I opened my browser's dev tools, copied the code, and started searching for a quick way to format it.

The first thing I found was a bunch of online tools. Some were great, but they all had the same problem: I'd paste my code into a random website and hope they weren't logging my snippets. For work projects, that's a non-starter. For personal projects, it's still uncomfortable.

I wanted a simple solution without relying on external services. Something that runs entirely in the browser, works offline, and doesn't send my code anywhere. Because apparently I enjoy reinventing wheels.

The "Just Use a Library" Approach

Before building anything, I considered my options. Writing a full HTML/JS/CSS parser from scratch? Absolutely not. That's a rabbit hole of edge cases that would consume weeks.

The pragmatic choice was js-beautify, a battle-tested library that handles all three languages. It's the same engine behind many popular online formatters, so I knew it handled edge cases I'd never think about.

The harder question was minification. js-beautify handles formatting, but for minification I had options:

Terser - Excellent for JS, but doesn't handle HTML or CSS
Clean-css - Great for CSS, but nothing else
html-minifier-terser - Handles HTML but pulls in a lot of dependencies

Each library would need its own integration and error handling. That's three different APIs to learn and maintain.

The Trade-off That Sounded Wrong but Worked

Here's where I made a decision that initially felt wrong: I used js-beautify for both beautification AND minification.

Wait, what? js-beautify doesn't minify. You're right. But here's the thing — for a browser-based tool, the minification doesn't need to be production-grade. It needs to:

Remove comments
Collapse whitespace
Remove unnecessary newlines
Keep the code valid

For most use cases — cleaning up copied snippets, reducing file size for quick sharing, making code more compact — that's enough. If someone needs aggressive minification with dead-code elimination, they should use a proper build tool anyway.

The trade-off was clear: js-beautify gives me one consistent API for all three languages, and I can control the output through its options. The minification won't beat Terser's compression ratio, but it's reliable and simple.

Setting Up the Core Logic

The heart of the tool is surprisingly small. Here's the essence:

function beautifyCode() {
  const code = document.getElementById('input').value;
  const lang = document.getElementById('lang').value;
  const indent = document.getElementById('indent').value;
  const opts = { indent_size: indent === '\t' ? 1 : parseInt(indent), indent_char: indent === '\t' ? '\t' : ' ' };

  try {
    let result;
    if (lang === 'html') result = html_beautify(code, opts);
    else if (lang === 'js') result = js_beautify(code, opts);
    else result = css_beautify(code, opts);
    document.getElementById('output').value = result;
    updateStats(code, result);
  } catch (e) {
    showStatus('error', 'Failed to format code. Check for syntax errors.');
  }
}

For minification, I configure the same library with different options:

function minifyCode() {
  const code = document.getElementById('input').value;
  const lang = document.getElementById('lang').value;
  const opts = { indent_size: 1, indent_char: ' ', preserve_newlines: false, max_preserve_newlines: 0, wrap_line_length: 0 };

  if (lang === 'js') {
    // Remove comments before minifying
    opts.jslint_happy = true;
    opts.space_after_anon_function = true;
  }

  try {
    let result;
    if (lang === 'html') result = html_beautify(code, { ...opts, indent_inner_html: true });
    else if (lang === 'js') result = js_beautify(code, opts);
    else result = css_beautify(code, { ...opts, selector_separator_newline: false });
    document.getElementById('output').value = result;
    updateStats(code, result);
  } catch (e) {
    showStatus('error', 'Failed to minify code.');
  }
}

The trick is realizing that minification and beautification are the same operation with different settings. Set preserve_newlines to false and wrap_line_length to 0, and the beautifier produces compact output. Not perfect minification, but solid enough for a browser tool.

The CDN Problem I Didn't Expect

The first version loaded js-beautify from jsdelivr. It worked perfectly in my testing. Then I deployed it and waited for feedback.

A few days later, I got a message from a user in China: "The tool doesn't work. The button does nothing."

I opened the console and saw it immediately: ReferenceError: html_beautify is not defined.

The CDN was blocked. jsdelivr is frequently blocked or slow in mainland China, and my user couldn't load the library at all. The page rendered fine, but every button silently failed.

This is the kind of bug that's easy to miss if you're only testing from one region. The fix was two-fold:

Switch to a CDN that's more reliable in China (staticfile.org)
Add a fallback that shows a clear error message if the library fails to load

<script src="https://cdn.staticfile.org/js-beautify/1.15.1/beautifier.min.js" 
        onerror="window.__beautifierFailed=true"></script>

Then in the click handlers:

function checkLib() {
  if (window.__beautifierFailed || typeof html_beautify === 'undefined') {
    showStatus('error', 'Code formatter library failed to load. Check your internet connection.');
    return false;
  }
  return true;
}

Spoiler: it was never a CSS issue this time. It was a CDN availability issue. Classic "works on my machine" situation.

Handling the Edge Cases

With the core logic working, I started testing edge cases. Here's what broke:

Empty input: Clicking "Beautify" with nothing in the textarea should do nothing, not throw an error.

Invalid syntax: Paste in broken code and js-beautify sometimes throws, sometimes produces garbage. I needed to catch errors and show a friendly message.

Very large files: A 2MB minified file can freeze the browser. I added a size check and a warning.

Special characters: The library handles these fine, but my statistics calculation needed to use byte counts, not character counts. Chinese characters in comments or strings would throw off the size calculation.

The statistics display was a nice touch that users appreciated:

function updateStats(input, output) {
  const inBytes = new Blob([input]).size;
  const outBytes = new Blob([output]).size;
  const ratio = inBytes > 0 ? Math.round((1 - outBytes / inBytes) * 100) : 0;
  document.getElementById('stats').textContent = 
    `Original: ${formatSize(inBytes)} → Result: ${formatSize(outBytes)} (${ratio}%)`;
}

new Blob([input]).size gives me the exact byte count, which handles Unicode correctly.

Building This With AI Assistance

I used AI assistance throughout this project, and it was a mixed bag. Here's the honest breakdown.

What AI handled well:

The initial structure and CSS styling. I described the layout I wanted, and it generated a clean, responsive design with dark mode support in minutes.
The i18n setup. I asked for a lightweight translation system, and it produced a clean t() function with data-i18n attributes.
The statistics calculation. It got the Blob approach right on the first try.

What AI got wrong:

The first version of the minify function was a mess. Here's what it generated:

// AI's first attempt (wrong)
function minifyCode() {
  const code = document.getElementById('input').value;
  // ... setup ...
  const result = code.replace(/\s+/g, ' ').trim();
  // This breaks strings, regexes, and template literals!
}

This naive whitespace removal would destroy JavaScript. It would break template literals, regex patterns, and string concatenation. I had to explain that minification requires understanding the language structure, not just regex replacement.

The AI also initially ignored the CDN fallback issue entirely. I had to explicitly ask for error handling around the library loading.

Where I had to step in:

The CDN fallback logic (AI didn't consider regional availability)
The error handling for invalid input (AI assumed valid input)
The performance considerations for large files (AI didn't think about it)
The minification strategy (AI suggested using regex, which was wrong)

What I Learned

1. Browser-only tools have a real place. For quick formatting tasks, sending code to a server is overkill and a privacy concern. A client-side tool is instant, private, and works offline.

2. "Good enough" is often the right call. My minification isn't as aggressive as a dedicated minifier, but it handles 95% of use cases with one library instead of three.

3. CDN choice matters more than you think. If you're building a global tool, test from multiple regions. A library that works in the US might be completely inaccessible elsewhere.

4. AI is a great pair programmer, not a replacement. It handled the boilerplate and styling perfectly. But it didn't understand the domain-specific pitfalls of code manipulation. I had to know enough to catch its mistakes.

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 HTML, JavaScript, and CSS formatting in both directions — minify and beautify — with customizable indentation, file statistics, and a clean interface. Everything runs locally in your browser, so your code never leaves your machine.

If you're dealing with unreadable minified code or want to compress your CSS before deployment, it might save you a few minutes. You can find it at craftvo.app.

The next time you're staring at a wall of minified JavaScript, remember: you don't need to send your code to a random server just to make it readable. A few lines of JavaScript and a good library can do it right in your browser. And if you're building something similar, don't forget to test your CDN from more than one continent.

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