DEV Community: ggwork

How to Build a Text Case Converter That Actually Handles Edge Cases

ggwork — Tue, 11 Aug 2026 09:20:47 +0000

While working on a collection of browser-based developer tools recently, I kept running into the same problem: I needed to convert text between different case formats constantly. camelCase for JavaScript variables, snake_case for database columns, kebab-case for CSS classes — you name it.

The existing solutions? Most were either bloated web apps with more ads than functionality, or required sending my text to a server somewhere. That felt wrong for something so simple. I wanted a tool that worked entirely in the browser, fast and private.

So I decided to build my own. Spoiler: it was harder than I thought. Here's what happened.

The "Simple" Problem That Wasn't

My initial mental model was straightforward. Take text, apply a bunch of string methods, display the results. How hard could it be?

// My first naive attempt
const upper = text.toUpperCase();
const lower = text.toLowerCase();
const camel = text.replace(/(?:\s|_|-)(\w)/g, (m, c) => c.toUpperCase());

This worked great for "hello world". Then I tried it on real-world input:

parseXMLDoc became parse X M L Doc — terrible
münchen lost its umlaut
Hello123World split in the wrong places
Chinese text like 你好世界 got mangled by the word-splitting logic

That's when I realized case conversion is deceptively tricky. The "simple" regex approach breaks the moment you have anything beyond basic ASCII text.

The Unicode Awakening

Here's what I learned: JavaScript's regular expressions have a secret weapon — Unicode property escapes. They've been around since ES2018, but most developers don't use them.

// Split words properly, keeping Unicode characters intact
function splitWords(s) {
  return String(s)
    .replace(/([\p{Ll}\p{N}])(\p{Lu})/gu, '$1 $2')     // helloWorld -> hello World
    .replace(/(\p{Lu}+)(\p{Lu}\p{Ll})/gu, '$1 $2')      // parseXMLDoc -> parse XML Doc
    .replace(/[_\-\s]+/gu, ' ');                         // snake_case -> snake case
}

The \p{L} and \p{Lu} patterns match any Unicode letter (lowercase and uppercase respectively), not just ASCII. The u flag enables Unicode mode. This single change fixed most of my edge cases.

The AI Collaboration

I built this tool with heavy AI assistance, and it was a mix of impressive and frustrating. Here's how it went:

Where AI excelled: The initial structure, i18n setup, and basic conversion functions came together quickly. I described what I needed and got a solid foundation in minutes.

Where AI struggled: Edge cases. My first prompt produced code that handled "hello world" perfectly but fell apart on real-world input. The AI didn't think about Unicode, didn't consider how parseXMLDoc should split, and assumed all text was ASCII.

The back-and-forth was revealing. I'd test with weird input, find a bug, describe it to the AI, and get a fix. But the fixes were often band-aids — patching one edge case without considering the broader pattern.

My honest take: AI is excellent for scaffolding and common patterns, but you still need to think critically about your domain. The AI didn't know that case conversion involves Unicode normalization, acronym handling, and locale-specific rules. I had to bring that knowledge.

The i18n Decision

One thing I insisted on from the start: full internationalization. The tool targets both Chinese and English speakers, and I wanted it done right.

The approach was simple but effective:

const I18N = {
  zh: { title: "文本大小写转换", copy: "复制" },
  en: { title: "Case Converter", copy: "Copy" }
};

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

Language detection follows a sensible priority: URL parameter overrides everything, then browser language, then defaults to Chinese. It's not perfect — some users might prefer English even with a Chinese browser — but it covers most cases.

The Copy Button Problem

Here's something I didn't expect: the copy button was the hardest part to get right.

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

The navigator.clipboard API is clean but requires HTTPS and secure context. The fallback uses the old execCommand approach, which works everywhere but feels hacky. And in both cases, you need to handle the user feedback — showing "Copied!" vs "Copy failed" — which adds UI complexity.

Performance Considerations

With real-time preview, performance matters. Every keystroke triggers ten different conversions. For normal text, this is instant. But what about pasting a 10MB document?

The solution was surprisingly simple: debounce the input.

let timeout;
input.addEventListener('input', () => {
  clearTimeout(timeout);
  timeout = setTimeout(updateResults, 100);
});

A 100ms debounce means the UI stays responsive even with large inputs. The conversions themselves are O(n) string operations, so they're fast — it's the DOM updates that slow things down.

What I'd Do Differently

Looking back, there are a few things I'd change:

Test with real-world data from the start. I should have created a test suite with edge cases before writing the conversion logic.
Consider locale-specific rules. Turkish has a dotted/dotless I that behaves differently from English. German has ß which converts to SS in uppercase. These are niche but real.
Build the i18n system first. I added it later, which meant retrofitting text throughout the codebase.

The Result

The final tool does what I needed: instant case conversion in the browser, no data leaving the device, supporting ten different formats. It handles Unicode gracefully, works in dark mode, and adapts to both Chinese and English users.

The full implementation lives at craftvo.app if you want to see it in action.

Key Takeaways

Unicode property escapes are your friend. \p{L} and friends make JavaScript regex way more powerful for international text.
AI assistance has limits. It's great for getting started, but you need domain knowledge to catch the edge cases it misses.
Real-time features need debouncing. Even fast operations can lag with large inputs.
Internationalization isn't optional. Your users speak more languages than you think.

Building this tool taught me that even "simple" text operations have hidden complexity. The next time you reach for text.toUpperCase(), remember: there's a whole world of edge cases lurking beneath that simple method call.

Building a Real-Time Base Converter: The Hidden Complexity of a "Simple" Tool

ggwork — Tue, 11 Aug 2026 01:26:36 +0000

Article

You know those moments when you think a task is going to take 20 minutes, and then you're still debugging edge cases four hours later? That was me with a base converter. I mean, how hard can it be? It's just parseInt() and .toString(), right?

Spoiler: it's never just that.

While working on a collection of browser-based developer tools, I needed a base converter that could handle binary, octal, decimal, and hexadecimal conversions in real-time. I thought I'd have it done before my coffee got cold. Instead, I learned more about JavaScript number limitations, BigInt quirks, and input validation than I ever wanted to know.

The "Simple" Problem That Wasn't

The core requirement sounded straightforward: build a tool where you type a number in any base and see it instantly converted to all other bases. Type ff in hexadecimal, and you should see 255 in decimal, 377 in octal, and 11111111 in binary — all updating as you type.

The first version took about 15 minutes. It was beautifully naive:

function convert(value, fromBase, toBase) {
  return parseInt(value, fromBase).toString(toBase);
}

Three lines. What could possibly go wrong?

When JavaScript Numbers Betray You

The first bug appeared with numbers that should have worked fine. I typed 99999999999999999999 in decimal and watched the tool return complete garbage in binary. Not even close to correct — just nonsense.

Here's the thing: JavaScript numbers are IEEE 754 double-precision floating point. They can only precisely represent integers up to 2^53 - 1 (about 9 quadrillion). Anything larger loses precision silently. No error, no warning — just wrong answers.

The solution was BigInt, but it came with its own set of headaches. You can't just swap parseInt() for BigInt() and call it a day. The API is different, you need explicit conversion functions, and you have to handle the fact that BigInt doesn't work with Math functions or the toString() method in the same way.

After some iteration, I ended up with something like this:

function convertValue(value, fromBase, toBase) {
  if (value === '') return '';
  const bigIntValue = parseToBigInt(value, fromBase);
  return bigIntValue.toString(toBase);
}

The key insight was creating a custom parseToBigInt function that handles the base validation and character checking before conversion. This way, I could catch invalid input early and show a friendly error instead of silently producing garbage.

The Validation Rabbit Hole

This is where the project really started to consume my day. Each base has its own set of valid characters:

Binary: only 0 and 1
Octal: 0 through 7
Decimal: 0 through 9
Hexadecimal: 0 through 9, a through f (case-insensitive)

Seems simple, but users will type anything. I've seen people try to enter 2 in binary, 8 in octal, and once someone tried to enter g in hex — which is technically valid for base 17, but definitely not for base 16.

The validation logic ended up being the most important part of the whole tool. Without it, you get silent failures and confusing results. With it, you get a clear error message and a red border on the offending input.

function validateInput(value, base) {
  const validChars = '0123456789abcdefghijklmnopqrstuvwxyz'.slice(0, base);
  const regex = new RegExp(`^[${validChars}]+$`, 'i');
  return regex.test(value);
}

This single function prevented more confusion than everything else combined. The moment someone types an invalid character, they see exactly what's wrong instead of watching numbers transform into something unrecognizable.

The Custom Base Feature That Almost Got Cut

The requirements called for supporting custom bases from 2 to 36. I initially thought this would be trivial — just make the base a variable instead of a constant. But the implementation had a subtle complexity: the custom base input itself needed to be a number input, while the value input needed to be validated against that base.

The tricky part was handling the interaction between the two. If someone changes the base from 16 to 2 while there's a ff in the custom value field, what should happen? I decided to clear the custom value and show a message that the value is invalid for the new base. It's not the most elegant solution, but it's honest and doesn't pretend to do something it can't.

The Real-Time Conversion Architecture

The core challenge was making all conversions happen instantly without creating infinite loops or performance issues. Here's the pattern I settled on:

let isUpdating = false;

function handleInput(event) {
  if (isUpdating) return;
  isUpdating = true;

  const sourceId = event.target.id;
  const value = event.target.value;
  const base = getBaseFromId(sourceId);

  if (!validateInput(value, base)) {
    markInvalid(event.target);
    clearConversions();
    isUpdating = false;
    return;
  }

  const bigIntValue = parseToBigInt(value, base);
  updateAllFields(bigIntValue, sourceId);
  updateBitInfo(bigIntValue);

  isUpdating = false;
}

The isUpdating flag was crucial. Without it, updating one field would trigger updates in others, which would trigger updates back, creating an infinite loop. This is a classic problem in any real-time synchronized form, and the boolean guard is the simplest solution.

Where AI Actually Helped (and Where It Didn't)

I used AI assistance for this project, and it was a mixed bag — which I think is the honest truth about AI-assisted development right now.

What AI handled well:

Generating the initial HTML structure with all the input fields and buttons
Writing the i18n mechanism for Chinese/English support
Creating the responsive CSS with dark mode support
Implementing the copy-to-clipboard functionality

The AI was particularly good at boilerplate and structure. I could describe what I wanted in plain language and get a functional skeleton in seconds.

Where AI struggled:

The first version of the conversion logic was completely broken for large numbers. The AI used parseInt() without any consideration for precision issues. When I pointed out the problem, it suggested using BigInt but then made a mess of the conversion functions, mixing BigInt and regular number operations in ways that threw type errors.

The validation logic also took several iterations. The AI initially used simple character checks that didn't properly account for case-insensitivity or the full range of valid characters in higher bases.

The lesson: AI is great for scaffolding and structure, but you still need to understand the domain deeply enough to catch its mistakes. In this case, the numerical edge cases and validation logic required genuine understanding of both JavaScript's limitations and the mathematical requirements of base conversion.

Performance Considerations

One thing that surprised me was how easy it was to make this performant. The conversions themselves are trivial — even with BigInt, converting a 100-digit number takes microseconds. The real performance concern was DOM updates.

The solution was to batch all DOM updates together and only update what actually changed. Instead of updating every field on every keystroke, I compare the new value with the current value and only update if they're different:

function updateField(id, value) {
  const element = document.getElementById(id);
  if (element.value !== value) {
    element.value = value;
  }
}

This tiny optimization prevents unnecessary DOM mutations and keeps the tool responsive even when pasting in a massive number.

The Bit Operation Feature

The requirements included showing bitwise operations (AND, OR, XOR, NOT, left shift, right shift). This was the feature I almost cut because it seemed unnecessary. But it turned out to be the most interesting part.

The challenge was that JavaScript's bitwise operators work on 32-bit integers, which meant I had to use BigInt for the bit operations too:

function showBitOperations(value) {
  const bigInt = BigInt(value);
  return {
    not: ~bigInt,
    leftShift1: bigInt << 1n,
    rightShift1: bigInt >> 1n,
  };
}

The n suffix on numeric literals for BigInt was a subtle gotcha that took me a minute to remember. Small things like that are where AI assistance actually helped — it caught the missing n before I did.

What I Learned

Never trust JavaScript number precision — always use BigInt for anything that could exceed 2^53
Validation is the most important feature — a tool that gives wrong answers silently is worse than one that refuses to work
The infinite loop guard is non-negotiable — any real-time synchronized form needs a reentrancy guard
AI assistance is a multiplier, not a replacement — it made me 3x faster, but I still needed to understand every line it generated

The Result

After all that, I ended up with a tool that does exactly what I originally wanted: type a number in any base and see it instantly converted everywhere else, with bit operations and byte size displayed below. It's fast, handles huge numbers correctly, and gives clear errors when you type something invalid.

During this process, I built a small browser-based tool to make this workflow easier. If you're interested, you can check it out here.

The next time you use a base converter, spare a thought for the poor developer who had to handle BigInt edge cases and validation regexes. It's never as simple as it looks.

How to Build a Browser-Based YAML Parser Without a Backend

ggwork — Mon, 10 Aug 2026 06:10:22 +0000

How to Build a Browser-Based YAML Parser Without a Backend

Last month, I was debugging a Kubernetes configuration file at 11 PM. The YAML was valid — or so I thought — but something was off. I couldn't tell if it was an indentation issue, a misquoted string, or a subtle anchor reference gone wrong. I opened an online YAML parser, pasted my config, and waited... for my data to upload to some server I didn't trust.

That's when it hit me: why does a simple parsing tool need a backend at all?

The Problem with Existing Solutions

Most online YAML tools have the same problem. They're either:

Server-side parsers that upload your data to unknown infrastructure
Heavy CLI tools that require installation
Over-engineered SaaS platforms with accounts and pricing pages

For a developer who just wants to validate a config file, none of these feel right. I needed something that ran entirely in the browser, respected privacy, and didn't require me to sign up for anything.

So I built one. Here's how it went.

Choosing the Right Library

The first decision was the most obvious one: which YAML parser to use?

I could have written my own parser. I've done it before — for JSON, for CSV, even for a custom query language I invented in a moment of questionable judgment. Writing a YAML parser from scratch is a rabbit hole of edge cases: anchors, aliases, multi-line strings, flow collections, type coercion...

The YAML spec is deceptively complex. I value my sanity.

The real choice was between js-yaml and yaml (the newer package). Both are solid. But js-yaml has been around longer, has better documentation, and — critically for a browser tool — has a single-file CDN build that just works.

// The core of the whole tool — everything else is UI
const parsed = jsyaml.load(inputText);

That's it. That's the magic line. Everything else — the tree view, the error handling, the formatting — is just presentation around this one call.

The Architecture: Keeping It Simple

I'm a firm believer in not over-engineering tools. This project needed to be a single HTML file with inline CSS and JavaScript. No build step, no package manager, no framework.

Why? Because browser-based developer tools should be:

Shareable — you can send one file to anyone
Deployable — drop it on any static host
Debuggable — open DevTools and see everything

The layout is straightforward: a toolbar on top, two panels side by side (input on the left, output on the right), and a status bar at the bottom.

The tricky part was the tree view.

Building the Tree View: A Lesson in Recursion

The tree view was the feature I underestimated. Converting parsed YAML (which is just nested JavaScript objects and arrays) into a collapsible tree sounds simple. But there are subtleties:

How do you distinguish between an empty object and an empty string?
What about null vs undefined vs missing keys?
How do you handle circular references? (Spoiler: YAML can actually produce these with anchors)

function renderTree(data, depth = 0) {
  if (data === null) return '<span class="tree-null">null</span>';
  if (typeof data === 'object') {
    const isArray = Array.isArray(data);
    const entries = Object.entries(data);
    // ... recursively render children
  }
  return `<span class="tree-${typeof data}">${escapeHtml(String(data))}</span>`;
}

The type-based coloring was a nice touch — strings in green, numbers in purple, booleans in red. It makes scanning a complex config much faster than reading raw text.

Error Handling: The Part Nobody Gets Right

Here's where most YAML tools fail: they crash or show a cryptic message when parsing fails.

js-yaml gives you a mark object with line and column information. But the error messages are... let's say, developer-focused. A typical error looks like:

unexpected end of the stream within a double quoted scalar

That's not helpful if you just want to know what line is broken.

I wrapped the error handling to extract position information and display it clearly:

try {
  const parsed = jsyaml.load(inputText);
  // success path
} catch (e) {
  const line = e.mark?.line + 1;
  const column = e.mark?.column + 1;
  // show "Error at line X, column Y" instead of raw message
}

This was one of those "small features that make a huge difference" moments. The difference between "your YAML is broken" and "line 42, column 8 is where things go wrong" is the difference between frustration and a quick fix.

The i18n Surprise

I decided to support both Chinese and English from the start. The tool's audience is developers, and a huge portion of developer content is consumed by non-English speakers.

The implementation was simple — a t() function that looks up keys in a dictionary:

const translations = {
  zh: { title: 'YAML 解析器', parse: '解析' },
  en: { title: 'YAML Parser', parse: 'Parse' }
};
const t = (key) => translations[currentLang][key] || translations['en'][key];

But here's what surprised me: the i18n requirement forced me to write better code.

Because every user-facing string had to go through t(), I couldn't hardcode anything. This meant I had to think carefully about every message, every label, every button. The structure became cleaner because the strings were defined in one place.

If you're building a tool and think "I'll add i18n later" — don't. It's easier to do it from the start.

AI-Assisted Development: The Honest Take

Now for the part I know you're curious about. I built this with AI assistance, and I want to be honest about what that looked like.

What went well:

The AI was excellent at generating the initial structure. I described the layout, the features, and the design tokens, and it produced a working skeleton in minutes. The CSS variables, the dark mode support, the responsive grid — all generated in the first pass.

The i18n dictionary was also AI-generated. I gave it a list of strings and asked for translations, and it produced accurate, natural-sounding translations in both languages.

What went wrong:

The AI's first attempt at the tree view was a mess. It used nested tables (tables! in 2024!) and had no concept of type-based coloring. I had to rewrite that component entirely.

The error handling was also initially naive. The AI just displayed e.message from js-yaml, which produces those cryptic errors I mentioned. I had to explicitly prompt it to extract the line/column information.

The workflow that worked:

I treated the AI like a junior developer. I gave it clear, specific instructions and reviewed everything it produced. When something was wrong, I didn't just say "fix this" — I explained why it was wrong.

"The tree view needs to show types with colors. Strings are green, numbers are purple. Also, the toggle arrows should be clickable to expand/collapse."

This back-and-forth worked surprisingly well. The AI got better with each iteration, and by the end, it was producing code that needed minimal review.

My honest take:

AI-assisted coding is like having a very fast typist who sometimes misunderstands the assignment. It's incredibly productive if you're a good reviewer. It's a disaster if you just accept everything.

For a project like this — a self-contained tool with clear requirements — AI assistance probably saved me 40% of the time. But that time savings came with a cost: I had to be more careful reviewing edge cases and error paths.

Performance Considerations

One thing I learned from previous tools: don't parse on every keystroke.

I added a debounce to the input handler — 300ms after the user stops typing, then parse. This makes the tool feel instant for small files but doesn't choke on large configs.

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

For the file upload, I read the file as text and dump it into the textarea. The browser handles the rest. No need for complex file handling when a textarea does the job.

What I Learned

Building this tool taught me a few things:

1. The browser is a legitimate runtime for developer tools. With libraries like js-yaml available via CDN, there's almost no reason to have a backend for parsing and transformation tools. The privacy benefit is a feature worth marketing.

2. Error messages are a feature, not an afterthought. The difference between "error at line 3" and "unexpected token" is the difference between a tool you use daily and one you bookmark and forget.

3. AI assistance requires strong fundamentals. I could only effectively direct the AI because I knew what good code looked like. The AI didn't teach me recursion or event handling — I had to know that already.

4. Tools should be self-contained. The single-file HTML approach means this tool can be hosted anywhere, shared as a file, or even run locally by double-clicking. That's the kind of portability developers appreciate.

The Result

During this process, I built a small browser-based tool to make this workflow easier. It handles YAML parsing, validation, JSON conversion, and tree-style visualization — all without sending a single byte to a server.

If you work with YAML files for Docker, Kubernetes, or CI/CD pipelines, it might save you a few minutes of frustration.

You can try it here: YAML Parser

Have you built your own developer tools? What was your experience with AI-assisted coding? Let me know in the comments — I'm genuinely curious how other devs are navigating this new workflow.

DEV Community: ggwork

How to Build a Text Case Converter That Actually Handles Edge Cases

The "Simple" Problem That Wasn't

The Unicode Awakening

The AI Collaboration

The i18n Decision

The Copy Button Problem

Performance Considerations

What I'd Do Differently

The Result

Key Takeaways

Building a Real-Time Base Converter: The Hidden Complexity of a "Simple" Tool

Article

The "Simple" Problem That Wasn't

When JavaScript Numbers Betray You

The Validation Rabbit Hole

The Custom Base Feature That Almost Got Cut

The Real-Time Conversion Architecture

Where AI Actually Helped (and Where It Didn't)

Performance Considerations

The Bit Operation Feature

What I Learned

The Result

Tags

How to Build a Browser-Based YAML Parser Without a Backend

How to Build a Browser-Based YAML Parser Without a Backend

The Problem with Existing Solutions

Choosing the Right Library

The Architecture: Keeping It Simple

Building the Tree View: A Lesson in Recursion

Error Handling: The Part Nobody Gets Right

The i18n Surprise

AI-Assisted Development: The Honest Take

Performance Considerations

What I Learned

The Result

Tags