Forem: SEN LLC

A GUI Cron Builder — And Why Building Is Way Easier Than Parsing

SEN LLC — Sat, 11 Apr 2026 14:43:53 +0000

A GUI Cron Builder — And Why Building Is Way Easier Than Parsing

My first portfolio entry, Cron TZ Viewer, parses cron expressions and shows the next fire time across timezones. The most common feedback I got wasn't about that tool — it was "I don't know how to write the cron expression in the first place." So here's the reverse direction, and I learned that going from structure to string is dramatically simpler than the other way around.

The first tool I built in this series was a cron parser that shows the next fire time in multiple timezones. Useful, but it assumes you already have a cron expression. The more common problem: "I want this to run every weekday at 9am — what does that look like in cron?" Unless you're already fluent, you always end up looking it up.

🔗 Live demo: https://sen.ltd/portfolio/cron-builder/
📦 GitHub: https://github.com/sen-ltd/cron-builder

Five fields (minute / hour / day / month / day-of-week), six modes each (any, every, value, list, range, range-with-step), live preview of both the cron expression and an English/Japanese description. Click the "View next fire time →" button and it hands the expression off to Cron TZ Viewer via URL query. Vanilla JS, zero deps, no build.

The inverse direction is genuinely simpler

Writing a cron parser means taking 0 9-17 * * 1-5 and figuring out which of */5, 1-10, 1,3,5, 1-20/3, *, or a plain number each field is. That's six patterns per field × five fields, plus error reporting for malformed input. Even a minimal parser gets regex-heavy fast.

Writing the builder side is much simpler because the user has already told you the mode. A single switch does it:

export function buildField(config) {
  if (!config || typeof config !== 'object') return '*'
  switch (config.mode) {
    case 'any':       return '*'
    case 'every':     return `*/${config.step}`
    case 'value':     return String(config.value)
    case 'list':      return config.values.join(',')
    case 'range':     return `${config.from}-${config.to}`
    case 'rangeStep': return `${config.from}-${config.to}/${config.step}`
    default:          return '*'
  }
}

The user clicked "range" in the UI, so you don't have to infer it from the string. That's the whole deal. Whenever you're writing a bidirectional tool — parser + generator over the same grammar — the generator side is usually 3-5× shorter. It's a nice illustration of an asymmetry that shows up in language work everywhere: reconstructing structure from a flat string is hard; the opposite direction is trivial.

`buildCron` is a one-liner that composes the five fields

export function buildCron({ minute, hour, dom, month, dow }) {
  return [
    buildField(minute),
    buildField(hour),
    buildField(dom),
    buildField(month),
    buildField(dow),
  ].join(' ')
}

Destructure the config object, buildField each entry, join with spaces. That's it. This only works because POSIX crontab treats its five fields as a pure product — any combination is valid. AWS EventBridge and quartz cron dialects have cross-field constraints (day-of-month and day-of-week can't both be specified), which would force additional validation here. Plain crontab gives us a free pass.

The explanation text is a 2D field × mode table

The real UX win isn't the cron string — it's the human-readable description next to it. "Every weekday at 9:00 AM" reassures the user their UI state actually matches their intent. That description is built by looking up a label table indexed by field name and mode:

const LABELS = {
  en: {
    minute: {
      any: 'every minute',
      every: (n) => `every ${n} minutes`,
      value: (n) => `at minute ${n}`,
      list: (vals) => `at minutes ${vals.join(', ')}`,
      range: (a, b) => `minutes ${a} through ${b}`,
      rangeStep: (a, b, s) => `minutes ${a} through ${b}, every ${s}`,
    },
    hour: { /* ... */ },
    dom: { /* ... */ },
    month: { /* ... */ },
    dow: { /* ... */ },
  },
  ja: { /* Japanese equivalents */ },
}

export function explainField(config, field, lang = 'en') {
  const L = LABELS[lang]
  switch (config.mode) {
    case 'any':       return L[field].any
    case 'every':     return L[field].every(config.step)
    case 'value':     return L[field].value(config.value)
    case 'list':      return L[field].list(config.values)
    case 'range':     return L[field].range(config.from, config.to)
    case 'rangeStep': return L[field].rangeStep(config.from, config.to, config.step)
  }
}

Fields that deserve named output (months and weekdays) get their own string arrays so value: 1 on the month field renders as January rather than at month 1:

const MONTH_EN = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']
month: {
  value: (n) => `in ${MONTH_EN[n - 1]}`,
  // ...
}

Translating the numbers into names doubles the educational value of the tool for users who don't yet know cron by heart. "At minute 0 of hour 9 on day 1 of the week" vs "at 9:00 AM on Monday" is the difference between useful and opaque.

Linking the two tools via URL query

Once you've built an expression, clicking "View next fire time →" opens the sibling tool with the cron string pre-filled:

const viewerUrl = new URL('https://sen.ltd/portfolio/cron-tz-viewer/')
viewerUrl.searchParams.set('cron', cronString)
window.open(viewerUrl.toString(), '_blank')

Cron TZ Viewer already supported ?cron= in its query string from day one, so integrating the two was literally a single line. Static tools linking via URL query strings is a nice low-effort pattern — no backend, no shared state, no component library to agree on. Whichever tool is older just needs to handle the query param, and future tools can deep-link in.

Tests

14 cases on node --test. Input/output pairs for the core cases:

test('every 5 minutes', () => {
  assert.equal(
    buildCron({
      minute: { mode: 'every', step: 5 },
      hour:   { mode: 'any' },
      dom:    { mode: 'any' },
      month:  { mode: 'any' },
      dow:    { mode: 'any' },
    }),
    '*/5 * * * *'
  )
})

test('weekdays 9 to 17', () => {
  assert.equal(
    buildCron({
      minute: { mode: 'value', value: 0 },
      hour:   { mode: 'range', from: 9, to: 17 },
      dom:    { mode: 'any' },
      month:  { mode: 'any' },
      dow:    { mode: 'range', from: 1, to: 5 },
    }),
    '0 9-17 * * 1-5'
  )
})

test('explain range in en', () => {
  assert.equal(
    explainField({ mode: 'range', from: 9, to: 17 }, 'hour', 'en'),
    'hours 9 through 17'
  )
})

Series

This is entry #12 in my 100+ public portfolio series, and together with Cron TZ Viewer (entry #1) forms a complete cron toolkit.

📦 Repo: https://github.com/sen-ltd/cron-builder
🌐 Live: https://sen.ltd/portfolio/cron-builder/
🏢 Company: https://sen.ltd/

Feedback welcome.

A Bill Splitter Where Unit and Rounding Are Orthogonal (They Usually Aren't)

SEN LLC — Sat, 11 Apr 2026 14:43:00 +0000

A Bill Splitter Where Unit and Rounding Are Orthogonal (They Usually Aren't)

Real-world bill splitting never stops at "total ÷ people." The organizer picks a rounding mode, picks a unit (round everyone up to the nearest $5? the nearest $1?), and then cares about the leftover / shortfall. Most splitter apps conflate these. This one treats rounding mode and unit as independent axes and gets it right.

When I'm organizing dinner for four, "$34.87 each" is not a number anyone wants to hear. What I actually want is "$35 each" or "$40 each" — and I want to know whether that covers the bill or leaves a shortfall. That's two separate decisions: how to round (ceiling / floor / nearest) and to what unit ($1 / $5 / $10 / nearest hundred).

🔗 Live demo: https://sen.ltd/portfolio/warikan/
📦 GitHub: https://github.com/sen-ltd/warikan

Three modes (even, ratio, weighted), three rounding modes, configurable unit, and a live "total collected / difference" readout so you know whether you're overcharging or undercharging. Vanilla JS, zero deps, no build. 70 lines of logic, 12 tests.

The `roundTo(value, unit, mode)` helper

The single observation worth taking away: rounding mode and rounding unit are orthogonal. You might want "ceiling to nearest dollar" or "round to nearest five dollars" — any mode × any unit. Fold them into one helper:

function roundTo(value, unit, mode) {
  const n = value / unit
  let rounded
  if (mode === 'floor') rounded = Math.floor(n)
  else if (mode === 'round') rounded = Math.round(n)
  else rounded = Math.ceil(n)  // default: ceil
  return rounded * unit
}

Divide by unit, apply the chosen rounding, multiply back. Splitting $34.87 and wanting nearest-$5-ceiling: 34.87 / 5 = 6.974 → ceil = 7 → × 5 = 35. You could cram this into Math.ceil(value / unit) * unit inline, but then you'd repeat the expression three times and the UI's "choose rounding" dropdown becomes awkward.

The default is ceiling. It's the safe default for bill splitting — better to have a small surplus than to come up short. When the organizer is covering the gap, they'd rather know they have $2 extra than $2 missing.

Returning `diff` is what makes the UX good

Here's the part most splitter apps miss. If you only show "$35/person," the user immediately does mental math: "4 people × $35 = $140... the bill was $134.87... so I'm $5.13 over." That computation should happen in the tool:

export function splitEvenly(total, count, opts = {}) {
  if (!Number.isFinite(total) || total < 0) return { error: 'invalid total' }
  if (!Number.isInteger(count) || count <= 0) return { error: 'invalid count' }
  const rounding = opts.rounding ?? 'ceil'
  const unit = opts.unit ?? 1
  const per = roundTo(total / count, unit, rounding)
  const totalCollected = per * count
  const diff = totalCollected - total
  return { per, count, total, totalCollected, diff, rounding, unit }
}

The UI then shows three lines:

$35 per person
Total collected: $140
Diff: +$5.13

Positive diff = surplus (green), negative diff = shortfall (red). The organizer's calculus — "do I owe or am I owed?" — is answered at a glance without any mental arithmetic.

Weighted splits via normalization

For scenarios like "splitter group has mixed contributions" (bigger eaters, varying ages, etc.), take a weights array and normalize to the total:

export function splitWeighted(total, weights, opts = {}) {
  const sum = weights.reduce((a, b) => a + b, 0)
  const shares = weights.map((w) => roundTo((total * w) / sum, unit, rounding))
  const totalCollected = shares.reduce((a, b) => a + b, 0)
  const diff = totalCollected - total
  return { shares, weights: weights.slice(), total, totalCollected, diff, rounding, unit }
}

Normalization means [1, 1, 1.5, 2] and [2, 2, 3, 4] produce identical output. Users can think in "$1 buckets" or in percentages — the tool doesn't care. The sum is just a divisor.

The "ratio" mode is a one-liner on top of this:

export function splitByRatio(total, countA, countB, ratio, opts = {}) {
  const weights = [
    ...Array(countA).fill(ratio),
    ...Array(countB).fill(1),
  ]
  return splitWeighted(total, weights, opts)
}

"3 people at 1.5× and 2 people at 1×" becomes [1.5, 1.5, 1.5, 1, 1], then straight into splitWeighted. The three UI modes all funnel into the same core function, which is the usual sign that your abstractions are in roughly the right place.

Input validation: fail fast, return errors

Number inputs from a web form can be anything — NaN, Infinity, negative, non-integer, zero. Guard at the top of every function:

if (!Number.isFinite(total) || total < 0) return { error: 'invalid total' }
if (!Number.isInteger(count) || count <= 0) return { error: 'invalid count' }

Number.isFinite handles both NaN and Infinity. Number.isInteger rejects fractional counts. The count <= 0 check is critical — without it, division by zero produces Infinity, which would then propagate into the UI and visually break the layout.

Weighted mode has its own guard:

if (weights.some((w) => !Number.isFinite(w) || w <= 0)) {
  return { error: 'weights must be positive numbers' }
}

Returning { error } from a pure function, instead of throwing, makes the UI logic cleaner. The render code is if (result.error) showError(result.error); else showResult(result); — no try/catch, no uncaught exceptions, data flow stays explicit.

Tests

12 cases on node --test, covering each rounding mode × each unit × each mode combination:

test('evenly splits 10000 between 4', () => {
  const r = splitEvenly(10000, 4)
  assert.equal(r.per, 2500)
  assert.equal(r.diff, 0)
})

test('ceil rounding when 10000 split by 3', () => {
  const r = splitEvenly(10000, 3, { rounding: 'ceil' })
  assert.equal(r.per, 3334)
  assert.equal(r.diff, 2)  // 3334 * 3 = 10002
})

test('unit 100 rounds up to nearest 100', () => {
  const r = splitEvenly(14200, 4, { rounding: 'ceil', unit: 100 })
  assert.equal(r.per, 3600)
})

test('weighted 1:1:1.5:2 sums to total', () => {
  const r = splitWeighted(10000, [1, 1, 1.5, 2])
  assert.equal(r.shares.length, 4)
  assert.equal(r.shares.reduce((a, b) => a + b, 0), r.totalCollected)
})

test('count=0 returns error', () => {
  assert.ok(splitEvenly(1000, 0).error)
})

A "scale-invariance" test — multiplying every weight by 2 should give the same result — catches normalization bugs that random-number tests would miss.

Series

This is entry #11 in my 100+ public portfolio series.

📦 Repo: https://github.com/sen-ltd/warikan
🌐 Live: https://sen.ltd/portfolio/warikan/
🏢 Company: https://sen.ltd/

"Warikan" is the Japanese word for splitting a bill at a restaurant, usually with the organizer rounding and absorbing any small difference.

Converting Between Japanese Eras and Gregorian Dates — and Why the Boundary Days Matter

SEN LLC — Sat, 11 Apr 2026 14:27:07 +0000

Converting Between Japanese Eras and Gregorian Dates — and Why the Boundary Days Matter

Japan's modern era names (Meiji / Taishō / Shōwa / Heisei / Reiwa) don't transition on New Year's Day. They transition on specific dates, which means "Shōwa 64" is a seven-day era and January 7, 1989 is technically the end of it. A converter that doesn't handle this gets the most interesting dates wrong.

Japan officially uses two year-numbering systems: the Gregorian calendar (2026) and era names (令和8年 — Reiwa 8). Most online converters will tell you "Reiwa 8 = 2026" and leave it at that. But historical dates trip on an edge case that most converters get wrong: eras don't transition on a year boundary. Shōwa ended on January 7, 1989. Heisei began on January 8. So "Shōwa 64 January 7" is a valid date — it's the very last day of Shōwa — and "Shōwa 64 January 8" is not.

🔗 Live demo: https://sen.ltd/portfolio/era-converter/
📦 GitHub: https://github.com/sen-ltd/era-converter

Both directions (Gregorian → era, era → Gregorian), accurate boundary day handling, and the 元年 ("first year") shorthand parsing that shows up in official documents. Vanilla JS, zero deps, no build.

Era data as a list of boundary dates

The era definitions store each transition down to the day, not just the year:

export const ERAS = [
  { id: 'meiji',  name: '明治',  reading: 'めいじ',    start: [1868, 10, 23] },
  { id: 'taisho', name: '大正',  reading: 'たいしょう', start: [1912, 7, 30] },
  { id: 'showa',  name: '昭和',  reading: 'しょうわ',  start: [1926, 12, 25] },
  { id: 'heisei', name: '平成',  reading: 'へいせい',  start: [1989, 1, 8] },
  { id: 'reiwa',  name: '令和',  reading: 'れいわ',    start: [2019, 5, 1] },
]

The "Meiji = 1868" shorthand most references use hides an important fact: most of 1868 was still the Edo period. Meiji began on the day the era proclamation took effect, October 23, 1868. A date like March 15, 1868 isn't Meiji 1 at all — it falls under the previous era. Storing only the year loses this information.

Gregorian → era via tuple comparison

Since [year, month, day] tuples compare like a number when walked left-to-right, you can use a simple comparator and search in reverse through the eras list:

function tupleCmp(a, b) {
  if (a[0] !== b[0]) return a[0] - b[0]
  if (a[1] !== b[1]) return a[1] - b[1]
  return a[2] - b[2]
}

export function gregorianToEra(year, month, day) {
  const date = [year, month, day]
  if (tupleCmp(date, ERAS[0].start) < 0) {
    return { error: 'before Meiji' }
  }
  for (let i = ERAS.length - 1; i >= 0; i--) {
    const era = ERAS[i]
    if (tupleCmp(date, era.start) >= 0) {
      const eraYear = year - era.start[0] + 1
      return { era, year: eraYear }
    }
  }
}

Walk the list from newest to oldest; the first era whose start is <= the input wins. For 1989-01-07, the reverse walk tries Reiwa's start (2019-05-01 — too late), Heisei's start (1989-01-08 — also too late!), and finally Shōwa (1926-12-25 — match). Returns Shōwa year 64.

Era year calculation is year - era.start[0] + 1 — Shōwa started in 1926, so 1989 is Shōwa year 1989 - 1926 + 1 = 64.

Parsing `元年` (first year)

Japanese era strings often use 元 ("origin") instead of 1 for the first year of an era. 平成元年 is Heisei year 1 — this spelling is common in formal documents. The parser accepts both:

export function parseEraString(str) {
  const match = /^(明治|大正|昭和|平成|令和)\s*(\d+|元)(?:年(?:\s*(\d+)月)?(?:\s*(\d+)日)?)?$/.exec(
    str.trim()
  )
  if (!match) return { error: 'unrecognized era format' }
  const [, name, yearStr, month, day] = match
  const era = ERAS.find((e) => e.name === name)
  const year = yearStr === '元' ? 1 : Number(yearStr)
  return {
    era,
    year,
    month: month ? Number(month) : undefined,
    day: day ? Number(day) : undefined,
  }
}

The regex alternation (\d+|元) captures either form, and the post-processing normalizes 元 to 1. Month and day are optional so 令和7年 parses successfully (without month/day info) and so does 昭和62年5月3日 (fully specified).

Range checks: Shōwa 65 doesn't exist

Because Shōwa ended in early 1989, "Shōwa 65" is not a valid era year. The converter validates against the next era's start year:

const nextIdx = ERAS.indexOf(era) + 1
if (nextIdx < ERAS.length) {
  const nextStart = ERAS[nextIdx].start
  if (gregYear > nextStart[0]) {
    return {
      error: `${era.name} ${eraYear}年 out of range (max ${nextStart[0] - era.start[0] + 1})`
    }
  }
}

The error message includes the actual maximum ("max 64") so users can correct their input without guessing. Unhelpful range errors ("out of bounds") are one of my pet peeves in form validation — the user already knew they were out of bounds, they need to know by how much.

Tests

19 cases on node --test. The key ones target the boundary days from both sides, because a single off-by-one in >= vs > silently passes half the tests:

test('Shōwa to Heisei boundary: 1989-01-07 is Shōwa 64', () => {
  const r = gregorianToEra(1989, 1, 7)
  assert.equal(r.era.name, '昭和')
  assert.equal(r.year, 64)
})

test('Shōwa to Heisei boundary: 1989-01-08 is Heisei 1', () => {
  const r = gregorianToEra(1989, 1, 8)
  assert.equal(r.era.name, '平成')
  assert.equal(r.year, 1)
})

test('Heisei to Reiwa boundary: 2019-04-30 is Heisei 31', () => {
  const r = gregorianToEra(2019, 4, 30)
  assert.equal(r.era.name, '平成')
  assert.equal(r.year, 31)
})

test('Heisei to Reiwa boundary: 2019-05-01 is Reiwa 1', () => {
  const r = gregorianToEra(2019, 5, 1)
  assert.equal(r.era.name, '令和')
  assert.equal(r.year, 1)
})

test('parse 令和元年 as Reiwa year 1', () => {
  const r = parseEraString('令和元年')
  assert.equal(r.era.name, '令和')
  assert.equal(r.year, 1)
})

Testing both sides of every boundary is the pattern to internalize here. "Last day of Shōwa" and "first day of Heisei" are the exact same == vs < decision inside tupleCmp, and one test on its own can't distinguish a correct implementation from a wrong one.

Series

This is entry #10 in my 100+ public portfolio series.

📦 Repo: https://github.com/sen-ltd/era-converter
🌐 Live: https://sen.ltd/portfolio/era-converter/
🏢 Company: https://sen.ltd/

Current scope is Meiji onward. PRs adding older eras welcome.

Writing Conway's Game of Life With Uint8Array and Canvas, Including a Gosper Glider Gun

SEN LLC — Sat, 11 Apr 2026 14:22:50 +0000

Writing Conway's Game of Life With Uint8Array and Canvas, Including a Gosper Glider Gun

Conway's rules fit in three lines. Writing them and watching a glider chase itself across the grid — still a what have I just witnessed moment every single time. This version uses a typed array for the grid, canvas for rendering, and ships eight preset patterns so you can jump straight to the Gosper Glider Gun.

Everyone's written Life at some point. I wrote it again because I wanted to do it carefully — typed arrays, toroidal wrap, a proper render loop — and bundle the classic patterns so you don't have to hand-place cells to see something interesting.

🔗 Live demo: https://sen.ltd/portfolio/game-of-life/
📦 GitHub: https://github.com/sen-ltd/game-of-life

Canvas in the middle, control panel below. Eight presets (Glider, Blinker, Toad, Beacon, Pulsar, LWSS, R-pentomino, Gosper Glider Gun), click-to-edit cells, 1–60 steps/sec, generation + live-cell counters, play/pause/step/reset/clear. Vanilla JS, zero dependencies, no build.

Why a `Uint8Array` instead of nested arrays

You have three reasonable grid representations:

Array of arrays (grid[y][x])
Uint8Array flat (cells[y * w + x])
Bit-packed Uint32Array (1 bit per cell)

I went with option 2. Typed arrays give you:

GC-friendly memory: one allocation instead of h+1 arrays of references
Fast snapshotting: next.set(current) copies an entire grid in one call
Cache locality: rows sit contiguous in memory, which matters for the nested neighbor loop

export function createGrid(width, height) {
  return {
    width,
    height,
    cells: new Uint8Array(width * height),
  }
}

Bit-packing is faster still, but the index math gets noisier (cells[i >> 5] |= 1 << (i & 31)), which hurts readability for something that's supposed to be educational. An 80×50 grid is 4000 bytes as a Uint8Array, 500 as bit-packed — not worth the trouble unless your grids are enormous.

Toroidal wrap so small patterns run forever

On a finite grid, a glider marches off the edge and disappears. The classic fix: treat the grid as a torus so the right edge continues into the left edge and the bottom continues into the top.

export function index(grid, x, y) {
  const w = grid.width
  const h = grid.height
  // Toroidal wrap. Double-modulo to handle negatives correctly.
  const xx = ((x % w) + w) % w
  const yy = ((y % h) + h) % h
  return yy * w + xx
}

The ((x % w) + w) % w dance is a common JS gotcha: the % operator preserves sign, so -1 % 80 === -1, which produces an out-of-range index. Adding w before the second % forces a non-negative result and gets you the proper mathematical modulo.

With this in place, a glider exits the right edge and re-enters from the left a few steps later. Small grids stop feeling small.

The `step()` function

The rules themselves are three lines in the middle of a double loop:

export function step(grid) {
  const { width: w, height: h, cells } = grid
  const next = new Uint8Array(cells.length)
  for (let y = 0; y < h; y++) {
    for (let x = 0; x < w; x++) {
      const n = countNeighbors(cells, w, h, x, y)
      const i = y * w + x
      const alive = cells[i] === 1
      if (alive && (n === 2 || n === 3)) next[i] = 1
      else if (!alive && n === 3) next[i] = 1
      // else stays 0
    }
  }
  return { width: w, height: h, cells: next }
}

Critically, this allocates a new Uint8Array for the next generation instead of updating in place. The rule is "everything transitions simultaneously based on the previous state" — if you update in place, cells that have already moved to the next state contaminate the neighbor counts of cells that haven't. Debugging that is miserable; skip the trap and allocate.

It also makes history trivial: push each returned grid onto a stack and you get undo for free.

Gosper Glider Gun as a coordinate list

The most fun preset is the Gosper Glider Gun — the pattern that Bill Gosper constructed in 1970 to answer "is there a finite pattern whose population grows without bound?" (previously a $50 open problem). It cycles with period 30, spitting out a glider each cycle, forever.

I store patterns as lists of live-cell coordinates:

{
  id: 'gosper',
  name: 'Gosper Glider Gun',
  pattern: [
    [0, 4], [0, 5], [1, 4], [1, 5],
    [10, 4], [10, 5], [10, 6], [11, 3], [11, 7],
    [12, 2], [12, 8], [13, 2], [13, 8], [14, 5],
    // ... 36 cells total, spans ~40 columns
  ],
}

And a tiny stamp function places them at an origin:

export function stamp(grid, pattern, originX, originY) {
  for (const [x, y] of pattern) {
    set(grid, originX + x, originY + y, 1)
  }
}

Coordinate-list format has the nice property that sparse and dense patterns use the same code path. For something like the Gosper gun, which is 36 cells spread over a wide area, it reads much better than a dense 2D array.

Play loop: requestAnimationFrame, not setInterval

To run at N steps/sec, the naive approach is setInterval(step, 1000/N). This breaks with browser throttling when the tab is backgrounded — you get inconsistent timing and dropped frames. Much better to drive everything from requestAnimationFrame and compare timestamps:

let lastStepAt = 0
function loop(now) {
  if (running) {
    const stepMs = 1000 / speed
    if (now - lastStepAt >= stepMs) {
      grid = step(grid)
      render()
      lastStepAt = now
    }
    requestAnimationFrame(loop)
  }
}

At speed = 60 it advances every frame; at speed = 1 it polls every frame but only advances once per second. The render is always in sync with the display refresh, so movement looks smooth.

Tests

10 cases on node --test, verifying the classic patterns behave as documented:

Block (2×2) — still life, should be identical after step()
Blinker (3 in a row) — period 2
Glider — diagonal translation after 4 generations
Pulsar — period 3
R-pentomino — goes through 1103 chaotic generations before stabilizing (I only check the first few, since running the full settlement in a unit test is slow)

npm test

Series

This is entry #9 in my 100+ public portfolio series.

📦 Repo: https://github.com/sen-ltd/game-of-life
🌐 Live: https://sen.ltd/portfolio/game-of-life/
🏢 Company: https://sen.ltd/

PRs for new presets welcome.

50 Japanese Traditional Colors, Sorted By Hue — Because the Names Aren't Enough

SEN LLC — Sat, 11 Apr 2026 14:17:44 +0000

50 Japanese Traditional Colors, Sorted By Hue — Because the Names Aren't Enough

The thing you need when browsing a color palette is adjacent colors that look adjacent. Every reference site I could find listed Japanese traditional colors alphabetically, which made scanning for the one I wanted unnecessarily painful. A five-minute switch to hue-order sorting made the same 50 colors feel like a different product.

I keep needing hex codes for Japanese traditional colors — 撫子色 (nadeshiko), 茜色 (akane), 瑠璃色 (ruri). Existing references are ad-heavy and sort by name, which means visually similar colors end up far apart on the page. I wanted a clean, hue-sorted reference where browsing feels like a color wheel.

🔗 Live demo: https://sen.ltd/portfolio/japanese-colors/
📦 GitHub: https://github.com/sen-ltd/japanese-colors

Each card shows the kanji name, its phonetic reading, and the hex code. Click to copy hex to clipboard. Filter by color family (reds / oranges / greens / etc.), or search by kanji, reading, or hex.

Vanilla JS, zero dependencies, no build. Color data is ~50 entries across ~80 lines, plus a handful of small helpers.

Hue-order sorting completely changes the UX

I initially listed colors in category declaration order: 紅 → 朱 → 茜 → 緋 → 紅梅 → 桜 → 撫子 → 珊瑚. Even within "reds", visually adjacent cards were often very different hues, so your eye had to constantly reset as it scanned. The grid felt noisy.

The fix was to convert every color to HSL and sort globally by hue:

export function hexToHsl(hex) {
  const { r, g, b } = hexToRgb(hex)
  const rn = r / 255, gn = g / 255, bn = b / 255
  const max = Math.max(rn, gn, bn)
  const min = Math.min(rn, gn, bn)
  let h = 0, s = 0
  const l = (max + min) / 2
  if (max !== min) {
    const d = max - min
    s = l > 0.5 ? d / (2 - max - min) : d / (max + min)
    switch (max) {
      case rn: h = (gn - bn) / d + (gn < bn ? 6 : 0); break
      case gn: h = (bn - rn) / d + 2; break
      case bn: h = (rn - gn) / d + 4; break
    }
    h /= 6
  }
  return { h: Math.round(h * 360), s: Math.round(s * 100), l: Math.round(l * 100) }
}

colors.sort((a, b) => hexToHsl(a.hex).h - hexToHsl(b.hex).h)

Now the grid walks around the color wheel — red → orange → yellow → green → blue → purple → back toward red — and the difference in browsing feel is dramatic. You stop actively searching; you start sweeping. The ordering reads as natural because human vision uses hue as its primary cue.

It's a nice reminder that for a visual browser, sort-key choice is UX. No amount of typography or spacing fixes a bad order.

Flipping label color by perceived brightness

Each card overlays the color name on a background tinted with the hex. Some colors are very light (桜色 #FEF4F4) and some are very dark (漆黒 #0D0015), so a single label color fails on one extreme or the other.

I flip between dark and light labels using a simple luminance check:

export function isLight(hex) {
  const { r, g, b } = hexToRgb(hex)
  const lum = 0.299 * r + 0.587 * g + 0.114 * b
  return lum > 150
}

The 0.299 / 0.587 / 0.114 coefficients are ITU-R BT.601 luma weights, approximating how bright each RGB channel feels rather than how much light it emits. Green dominates; blue barely contributes. It's a pre-gamma-correction formula — WCAG's sRGB-accurate relative luminance is more correct — but for a 50-color palette where I just need to pick "light" vs "dark" labels, BT.601 is perfectly adequate and a lot shorter.

The 150 threshold is empirical: I tuned it so that the soft pastels (桜色, 生成り) count as "light" and switch to dark text.

Search that accepts kanji, reading, or hex

The search box needs to accept several input types because users have different ways of remembering a color:

Kanji (紅)
Reading in hiragana (くれない)
Hex (B90016)
English category name (red)

A single substring check across all of those fields handles it:

function matches(color, query) {
  const q = query.toLowerCase().replace(/\s/g, '')
  if (!q) return true
  return (
    color.name.includes(q) ||
    color.reading.includes(q) ||
    color.hex.toLowerCase().includes(q) ||
    color.category.toLowerCase().includes(q)
  )
}

The reading field intentionally stores hiragana with no spaces, so なでしこ matches なでしこいろ without the user having to type the suffix. Small detail, makes "I only remember part of the name" forgiving.

Copy-to-clipboard with a fallback

Clicking a card copies its hex to clipboard so you can immediately paste into Figma or your editor. navigator.clipboard.writeText is the modern API, but it can be blocked by the Permissions API, so I keep an old-school fallback:

card.addEventListener('click', async () => {
  try {
    await navigator.clipboard.writeText(color.hex)
    showToast(`Copied: ${color.hex}`)
  } catch {
    const ta = document.createElement('textarea')
    ta.value = color.hex
    document.body.appendChild(ta)
    ta.select()
    document.execCommand('copy')
    document.body.removeChild(ta)
    showToast(`Copied: ${color.hex}`)
  }
})

document.execCommand('copy') is formally deprecated but still ships in every browser, and it works without permission prompts. Keep it as a fallback until it actually stops working.

Testing the data, not the code

The most useful tests for a data-driven tool like this are checks on the data itself. Entering 50 colors by hand means typos are inevitable, and the easy-to-miss kind are: wrong hex length, unknown category id, empty name field:

test('all colors have valid 6-digit hex', () => {
  for (const c of COLORS) {
    assert.match(c.hex, /^#[0-9A-Fa-f]{6}$/)
  }
})

test('all colors have non-empty name and reading', () => {
  for (const c of COLORS) {
    assert.ok(c.name.length > 0)
    assert.ok(c.reading.length > 0)
  }
})

test('all categories are known', () => {
  const validIds = new Set(CATEGORIES.map((c) => c.id))
  for (const c of COLORS) {
    assert.ok(validIds.has(c.category), `unknown category: ${c.category}`)
  }
})

Now adding a new color that references a typo'd category id fails CI immediately. The lesson I keep relearning: when the source of truth is the data, test the data.

Tests

11 cases on node --test, covering data integrity plus:

isLight at boundaries (pure white, pure black, 50% gray)
hexToRgb round-trip
hexToHsl on reference hues (red = 0, green = 120, blue = 240)

npm test

Series

This is entry #8 in my 100+ public portfolio series.

📦 Repo: https://github.com/sen-ltd/japanese-colors
🌐 Live: https://sen.ltd/portfolio/japanese-colors/
🏢 Company: https://sen.ltd/

If you spot a missing color or a wrong reading, issues welcome.

Every Time Format At Once: A Converter That Stops the Unix-Seconds-or-Milliseconds Dance

SEN LLC — Sat, 11 Apr 2026 14:16:34 +0000

Every Time Format At Once: A Converter That Stops the Unix-Seconds-or-Milliseconds Dance

1721462400. Is that seconds or milliseconds? UTC or local? Which Tuesday was that, in my timezone? I've wasted approximately a month of my career on this question. So I built a box where you paste anything and every format shows up at the same time.

Every developer eventually sees a number like 1721462400 in a log. Then comes the micro-calculation: check the digit count to guess seconds vs. milliseconds, punch it into a browser console with new Date(...), stare at the local time, try to work out what that is in Pacific. I wrote a tool that collapses the whole sequence to a single paste.

🔗 Live demo: https://sen.ltd/portfolio/time-converter/
📦 GitHub: https://github.com/sen-ltd/time-converter

One input, nine output rows:

Unix seconds
Unix milliseconds
ISO 8601 (UTC)
RFC 2822 (GMT)
JST (Asia/Tokyo, DST-aware)
PST (America/Los_Angeles, DST-aware)
EST (America/New_York, DST-aware)
CET (Europe/Berlin, DST-aware)
A human relative time ("5 minutes ago", "3 days from now")

Vanilla JS, zero deps, no build. Timezones go through Intl.DateTimeFormat, so DST transitions are automatic.

Auto-detecting the input format

People paste five or six different time representations into this input, and the tool has to figure out which one without asking. The key insight: digit count alone gets you seconds vs. milliseconds vs. microseconds with zero ambiguity.

export function parseTime(input) {
  const s = input.trim()

  // Unix milliseconds (13 digits)
  if (/^-?\d{13}$/.test(s)) return { ok: true, ms: Number(s), format: 'unix-ms' }
  // Unix seconds (10 digits)
  if (/^-?\d{10}$/.test(s)) return { ok: true, ms: Number(s) * 1000, format: 'unix-s' }
  // Unix microseconds (16 digits) — common in tracing
  if (/^-?\d{16}$/.test(s)) return { ok: true, ms: Math.round(Number(s) / 1000), format: 'unix-us' }

  // ISO 8601
  const isoMatch = /^(\d{4})-(\d{2})-(\d{2})[T ](\d{2}):(\d{2})(?::(\d{2})(?:\.(\d{1,9}))?)?(Z|[+-]\d{2}:?\d{2})?$/.exec(s)
  // ...
}

The digit-count trick works because Unix seconds have been ten digits since September 9, 2001 and won't hit eleven digits until 2286. Nobody in this industry is pasting times outside that window. Sixteen digits = microseconds is a little unusual, but tracing tools like TraceEvent frequently use microsecond timestamps, so it's worth handling.

The "ISO 8601 without a timezone" mess

If the input is 2024-07-20T08:00:00 with no timezone, what does it mean? RFC 3339 technically says "local time." But in the real world, 99% of timezone-less ISO strings come from log output and the author meant UTC.

JavaScript's built-in behavior is worse than either interpretation:

new Date('2024-07-20T08:00:00').getTime()
// Returns local-time-interpretation. Same string, different answer
// depending on where your machine is. Nightmare fuel.

So the tool explicitly re-parses with Date.UTC() when no timezone is present:

if (!tz) {
  const t = Date.UTC(
    Number(Y), Number(M) - 1, Number(D),
    Number(h), Number(m), Number(sec), Number(msPadded)
  )
  return { ok: true, ms: t, format: 'iso (UTC assumed)' }
}

And critically, the format label it returns says iso (UTC assumed) — the UI shows that explicitly so the user knows an assumption was made. Silent assumptions in datetime code are a source of endless bugs.

Outsourcing DST to Intl.DateTimeFormat

JST is a permanent UTC+9 so it's easy. PST, EST, and CET all observe daylight saving, and the transition dates change every few years as various legislatures debate abolishing it. Computing this manually is a losing game.

Happily, Intl.DateTimeFormat with the timeZone option does the entire thing for free:

export function formatInTz(ms, tz) {
  const fmt = new Intl.DateTimeFormat('en-GB', {
    timeZone: tz,           // 'America/Los_Angeles', etc.
    year: 'numeric',
    month: '2-digit',
    day: '2-digit',
    hour: '2-digit',
    minute: '2-digit',
    second: '2-digit',
    hourCycle: 'h23',
    timeZoneName: 'short',
  })
  const parts = fmt.formatToParts(new Date(ms))
  const get = (t) => parts.find((p) => p.type === t)?.value ?? ''
  return `${get('year')}-${get('month')}-${get('day')} ${get('hour')}:${get('minute')}:${get('second')} ${get('timeZoneName')}`
}

I use formatToParts rather than format because I need fixed output order regardless of locale conventions. en-GB was chosen for its h23 (00-23) affinity and sane default ordering; it's a pragmatic hack, not a principled choice.

The best part: timeZoneName: 'short' returns PST in February and PDT in July, automatically. Zero logic on my end:

formatInTz(Date.parse('2024-02-01T00:00:00Z'), 'America/Los_Angeles')
// '2024-02-01 00:00:00 PST'

formatInTz(Date.parse('2024-07-01T00:00:00Z'), 'America/Los_Angeles')
// '2024-07-01 00:00:00 PDT'  (D for daylight)

The DST transition crossovers just work.

Relative time: biggest unit first wins

The "5 minutes ago" line is built by walking units in descending order and picking the first one with a non-zero count:

export function humanRelative(ms, nowMs = Date.now()) {
  const diff = Math.floor((ms - nowMs) / 1000)
  const absS = Math.abs(diff)
  const units = [
    { unit: 'year',   seconds: 365 * 24 * 3600 },
    { unit: 'month',  seconds: 30 * 24 * 3600 },
    { unit: 'week',   seconds: 7 * 24 * 3600 },
    { unit: 'day',    seconds: 24 * 3600 },
    { unit: 'hour',   seconds: 3600 },
    { unit: 'minute', seconds: 60 },
    { unit: 'second', seconds: 1 },
  ]
  for (const { unit, seconds } of units) {
    if (absS >= seconds) {
      const n = Math.floor(absS / seconds)
      const suffix = diff >= 0 ? 'from now' : 'ago'
      return `${n} ${unit}${n === 1 ? '' : 's'} ${suffix}`
    }
  }
  return 'just now'
}

Intl.RelativeTimeFormat exists and is great for many cases, but I wanted full control over the unit buckets (e.g., flooring anything under a second to "just now"), so I rolled my own. "1 month" meaning "30 days" is technically wrong but reads correctly for glance-based UI.

Tests

14 cases on node --test. Highlights:

Digit-count detection for seconds / ms / microseconds
ISO 8601 with and without timezone
RFC 2822
Weird inputs that fall through to native Date parser
DST boundary day for formatInTz
Past / future / right-now for relative time

npm test

Intl tests rely on Node 18+'s built-in ICU data, so they pass out of the box on modern Node.

Series

This is entry #7 in my 100+ public portfolio series, and the sister tool to Cron TZ Viewer (entry #1) — same Intl-powered, zero-dependency philosophy, but for single timestamps rather than repeating patterns.

📦 Repo: https://github.com/sen-ltd/time-converter
🌐 Live: https://sen.ltd/portfolio/time-converter/
🏢 Company: https://sen.ltd/

Feedback welcome.

A JWT Debugger That Never Sends Your Token Anywhere

SEN LLC — Sat, 11 Apr 2026 13:36:38 +0000

A JWT Debugger That Never Sends Your Token Anywhere

jwt.io says your token never leaves the browser. You're supposed to take their word for it. I wanted something I could prove by looking at the build — so I wrote one with connect-src 'none' in its CSP header. That's an enforcement, not a promise.

Every time I paste a production JWT into jwt.io, I get a tiny pang of discomfort. Yes, the official site documents that decoding happens client-side. Yes, I believe them. But I have no way to verify that they keep doing that tomorrow. I wanted a tool where "doesn't send your token anywhere" isn't a documentation claim — it's enforced by the browser.

🔗 Live demo: https://sen.ltd/portfolio/jwt-debugger/
📦 GitHub: https://github.com/sen-ltd/jwt-debugger

Three-panel layout (Header / Payload / Signature), time claims rendered as Unix + ISO + relative delta, expired/not-yet-valid warnings, UTF-8 safe. Vanilla JS, zero dependencies, no build step, no network calls anywhere in the source.

Proving "doesn't phone home" without making you audit the source

A user can't reasonably audit JavaScript for absent fetch calls. But the browser can enforce it for them, with one CSP directive:

<meta http-equiv="Content-Security-Policy" content="
  default-src 'self';
  connect-src 'none';
  img-src 'self' data:;
">

connect-src 'none' blocks fetch, XMLHttpRequest, WebSocket, EventSource — all at the browser level. Even if future code (or a compromised dependency, or malicious edits) tries to exfiltrate the token, the browser refuses. That single line is a stronger guarantee than asking anyone to trust the source.

In production it's better to ship this as an HTTP response header so it can't be stripped by HTML edits. The meta-tag version works for a static bucket, which is where I host it.

JWT segments are Base64url, not Base64

Each of the three dot-separated segments uses the base64url variant of RFC 4648:

- instead of +
_ instead of /
Trailing = padding is optional

It's the URL-safe cousin, designed so the token doesn't need percent-encoding to fit in a query string. Decoding means reversing the substitutions and reattaching padding:

export function base64UrlDecode(s) {
  let b64 = s.replace(/-/g, '+').replace(/_/g, '/')
  const pad = b64.length % 4
  if (pad === 2) b64 += '=='
  else if (pad === 3) b64 += '='
  else if (pad === 1) throw new Error('invalid base64url length')

  const binary = atob(b64)
  const bytes = new Uint8Array(binary.length)
  for (let i = 0; i < binary.length; i++) bytes[i] = binary.charCodeAt(i)
  return new TextDecoder().decode(bytes)
}

The important part is the TextDecoder at the end. atob returns a string where each char is one byte of the underlying data, not a properly decoded UTF-8 string. Skip the Uint8Array + TextDecoder step and any multi-byte claim turns into mojibake:

// Token contains { "name": "山田太郎" }
{ name: "å±±ç”°å¤ªéƒŽ" }  // Without TextDecoder
{ name: "山田太郎" }      // With TextDecoder

The pad === 1 check is also deliberate — a base64url payload of length 4k+1 can't exist because the encoding maps 3 bytes to 4 characters. If you see it, the token is truncated.

Time claims: the "relative delta" is the whole point

JWT time claims are Unix seconds (not milliseconds — catches people constantly):

exp — expires at
iat — issued at
nbf — not before
auth_time — authentication time (OIDC)

Looking at 1721462400 tells you nothing, so the UI shows all three representations:

annotations[claim] = {
  value: ts,                                    // 1721462400
  iso: new Date(ts * 1000).toISOString(),       // 2024-07-20T08:00:00.000Z
  delta: ts - nowSec,                           // -3600 (1 hour ago)
}

The UI then turns delta into a human relative time ("5 minutes ago", "in 2 hours"). When debugging live tokens, the single question I always have is "is this token still valid right now?" — and that's exactly what delta answers.

Expired and not-yet-valid conditions become explicit warnings:

if (annotations.exp && annotations.exp.delta <= 0) {
  warnings.push(`exp: expired ${-annotations.exp.delta}s ago`)
}
if (annotations.nbf && annotations.nbf.delta > 0) {
  warnings.push(`nbf: not valid for another ${annotations.nbf.delta}s`)
}

Deliberately no signature verification

This tool does not verify the signature. That's not an oversight — it's a design choice.

Verifying requires a secret (for HS*) or a public key (for RS*/ES*). Asking the user to paste a secret into a browser tool defeats the privacy argument for building this at all.
I don't want to encourage a workflow where people habitually paste HS256 server secrets into browser inputs.
Signature verification belongs on the server. If a client-side tool says "✓ valid", users might assume that means something authoritative. It doesn't.

The tool's job is showing you what's in the token. Whether the token is properly signed is the server's job.

Per-segment error messages

JWT parsing can fail at multiple stages, and you want to know exactly where:

return { ok: false, error: 'token must be a string' }
return { ok: false, error: `expected 3 segments, got ${parts.length}` }
return { ok: false, error: `header: ${e.message}` }
return { ok: false, error: `payload: ${e.message}` }
return { ok: false, error: `header JSON: ${e.message}` }
return { ok: false, error: `payload JSON: ${e.message}` }

Most parse errors in real life are "I copy-pasted and the tail got clipped" or "this got truncated in a log." If you get "expected 3 segments, got 2", the signature is missing. If you get "payload JSON: Unexpected end of input", the payload got truncated. That's the debugging information you actually want.

Tests

13 cases on node --test:

Valid HS256 / RS256 tokens
Base64url -_ character substitution
Zero / one / two padding characters
Japanese payload round-trip
Wrong segment count
Invalid base64 character
Malformed JSON
exp / nbf warning logic

npm test

Series

This is entry #6 in my 100+ public portfolio series.

📦 Repo: https://github.com/sen-ltd/jwt-debugger
🌐 Live: https://sen.ltd/portfolio/jwt-debugger/
🏢 Company: https://sen.ltd/

Security-focused feedback especially welcome.

I Built a Side-by-Side Base64 / URL / HTML / Encoder and Finally Stopped Confusing Them

SEN LLC — Sat, 11 Apr 2026 13:01:46 +0000

I Built a Side-by-Side Base64 / URL / HTML / Encoder and Finally Stopped Confusing Them

There are only four text encoding schemes you run into daily on the web. And yet the moment you feed them anything beyond ASCII, each one starts behaving differently. The only way to internalize the differences, I found, is to see all four results next to each other.

"Is this supposed to be Base64 or URL-encoded?" "Why is 'あ' three bytes in the URL?" "Wait, is it \u{1f389} or \u1f389 for 🎉?" I kept hitting the same wall, so I put all four encodings on one page with a single input box.

🔗 Live demo: https://sen.ltd/portfolio/encoder-diff/
📦 GitHub: https://github.com/sen-ltd/encoder-diff

One input. Four output cards (Base64, URL percent, HTML entities, Unicode \u escape). Radio buttons flip between encode and decode mode — all four cards turn around at once. Errors only paint the offending card red. About 300 lines of vanilla JS, zero dependencies, no build step.

Base64: btoa can't eat UTF-8

Base64 is specified as "a way to represent arbitrary bytes in ASCII." But JavaScript's built-in btoa() only accepts strings where every character code fits in 0–255. Call btoa('あ') and you get InvalidCharacterError.

So you have to encode the string to UTF-8 bytes first, then stuff those bytes into a fake "each char = one byte" string before handing it to btoa:

export function encodeBase64(input) {
  const bytes = new TextEncoder().encode(input)
  let binary = ''
  for (const b of bytes) binary += String.fromCharCode(b)
  return btoa(binary)
}

That intermediate representation is the ugly secret of Base64 in the browser. It's the reason third-party libraries like js-base64 exist: they hide this dance.

Decoding reverses it:

export function decodeBase64(input) {
  const binary = atob(input.trim())
  const bytes = new Uint8Array(binary.length)
  for (let i = 0; i < binary.length; i++) bytes[i] = binary.charCodeAt(i)
  return new TextDecoder().decode(bytes)
}

One gotcha: TextDecoder defaults to replacing invalid UTF-8 with U+FFFD (the replacement character) rather than throwing. If you want strict mode, pass { fatal: true }.

URL percent: see the UTF-8 bytes directly

encodeURIComponent does string → UTF-8 bytes → %XX per byte, in a single step. Which is why one Japanese character becomes three percent-triples:

encodeURIComponent('あ')  // '%E3%81%82'

E3 81 82 is the three-byte UTF-8 encoding of U+3042. If you try to decode just %E3, you get a URIError because those bytes alone aren't valid UTF-8:

decodeURIComponent('%E3')  // URIError: URI malformed

Having all four cards visible makes this kind of thing jump out. Paste half of a URL-encoded Japanese string and you'll immediately see the URL card go red while the other three are fine.

HTML entities: named vs numeric

HTML has three flavors of entity because of course it does:

Named: &, <, "
Decimal numeric: A → A
Hex numeric: A → A

Encoding is the easy direction. The practical minimum for XSS-safe output is five characters:

const HTML_ENCODE_MAP = {
  '&': '&amp;',
  '<': '&lt;',
  '>': '&gt;',
  '"': '&quot;',
  "'": '&#39;',
}

export function encodeHtml(input) {
  return input.replace(/[&<>"']/g, (c) => HTML_ENCODE_MAP[c])
}

Decoding has to handle all three flavors. One regex catches all of them:

export function decodeHtml(input) {
  return input.replace(/&(#(?:x[0-9a-fA-F]+|\d+)|[a-zA-Z]+);/g, (match, inner) => {
    if (inner.startsWith('#x') || inner.startsWith('#X')) {
      return String.fromCodePoint(parseInt(inner.slice(2), 16))
    } else if (inner.startsWith('#')) {
      return String.fromCodePoint(parseInt(inner.slice(1), 10))
    } else if (inner in HTML_NAMED_DECODE) {
      return HTML_NAMED_DECODE[inner]
    }
    return match
  })
}

Note String.fromCodePoint, not String.fromCharCode. The former handles anything above U+FFFF correctly; the latter quietly mangles emoji. 🎉 should decode to 🎉, and it does — but only because we used the right function.

Unicode escape: the `\u1234` vs `\u{10000}` line

JavaScript source syntax has two Unicode escape forms:

\u1234 — fixed four hex digits, BMP only (U+0000 to U+FFFF)
\u{1F389} — variable length, handles the full Unicode range (ES6+)

Encoding means picking based on codepoint:

export function encodeUnicode(input) {
  let out = ''
  for (const ch of input) {
    const cp = ch.codePointAt(0)
    if (cp < 0x80) {
      out += ch  // ASCII: leave alone
    } else if (cp <= 0xffff) {
      out += '\\u' + cp.toString(16).padStart(4, '0')
    } else {
      out += '\\u{' + cp.toString(16) + '}'
    }
  }
  return out
}

for (const ch of input) is load-bearing. If you write for (let i = 0; i < input.length; i++), anything above the BMP splits into two surrogate-pair halves (\uD83C\uDF89 instead of one emoji). for...of iterates by codepoint, which is what you want.

Same trap for codePointAt(0) vs charCodeAt(0) — the latter only returns the upper 16 bits of a surrogate pair, silently corrupting emoji. Anything that walks strings character-by-character in JavaScript should use these two APIs.

What you see with all four side-by-side

Paste <img src="x">🎉 into the input box, and the four cards show:

Scheme	Output
Base64	`PGltZyBzcmM9IngiPvCfjok=`
URL	`%3Cimg%20src%3D%22x%22%3E%F0%9F%8E%89`
HTML	`<img src="x">🎉`
Unicode	`<img src="x">\u{1f389}`

Each one has a different domain of responsibility:

Base64 treats the whole string as one opaque blob — reversible, zero human readability.
URL percent treats one byte at a time (and leaves alphanumerics alone).
HTML entities only touch the characters that would break rendering (the emoji is safe UTF-8, so it's left untouched).
Unicode escape only touches non-ASCII.

That difference is why you use a different one for each job: HTML for XSS-safe rendering, URL for query strings, Base64 for binary-in-JSON, \u for embedding in source code. Putting them side-by-side is the clearest way I've seen to hold that distinction in your head at once.

Tests

21 cases on node --test. Each scheme covers:

Empty string
ASCII
Japanese (multi-byte UTF-8)
Emoji (astral plane)
Round-trip (encode → decode)
Malformed input raises

npm test

Zero dependencies, so package.json has exactly one script entry: "test": "node --test tests/".

Series

This is entry #5 in my 100+ public portfolio series. Previous:

📦 Repo: https://github.com/sen-ltd/encoder-diff
🌐 Live: https://sen.ltd/portfolio/encoder-diff/
🏢 Company: https://sen.ltd/

Feedback welcome.

UUID v7, ULID, KSUID — What's the Difference? I Implemented All Five

SEN LLC — Sat, 11 Apr 2026 07:15:27 +0000

UUID v7, ULID, KSUID — What's the Difference? I Implemented All Five

A side-by-side generator for UUID v4, UUID v7, ULID, NanoID, and KSUID. The point wasn't to ship yet another ID library — it was to understand what each one actually is by writing it.

The standard "please give me a unique ID" answer has split into five. UUID v4 is still everywhere, but UUID v7 is finally standardized, ULID has a loyal following, NanoID is the compact URL-safe choice, and KSUID is what Segment and others reach for when they need high entropy and sortability. Each has subtly different trade-offs, and reading specs didn't help me internalize them. Writing them did.

🔗 Live demo: https://sen.ltd/portfolio/id-generator/
📦 GitHub: https://github.com/sen-ltd/id-generator

The whole thing is about 200 lines of actual ID-generation logic, spread across five files. No dependencies. Let me walk through each and point out the bits I didn't expect until I wrote them.

The one thing all sortable IDs do

If you implement UUID v7, ULID, and KSUID in the same session, you notice they're all doing the same thing:

Write the timestamp first.

That's the entire trick. Everything after that — the specific bit widths, the encoding alphabets, the random suffix lengths — is just engineering taste.

UUID v4: The baseline

export function uuidv4() {
  const bytes = new Uint8Array(16)
  crypto.getRandomValues(bytes)
  bytes[6] = (bytes[6] & 0x0f) | 0x40  // version = 4
  bytes[8] = (bytes[8] & 0x3f) | 0x80  // variant = 10xx
  return bytesToUuidString(bytes)
}

Pure random bytes, with 6 bits stolen for version and variant metadata. Effective randomness: 122 bits. Works everywhere, maximum compatibility. No ordering.

Modern browsers ship crypto.randomUUID(), which does the same thing in C++. Use that in production; implement it yourself to understand what's happening.

UUID v7: RFC 9562, timestamp-first

export function uuidv7(nowMs) {
  const ms = nowMs ?? Date.now()
  const bytes = new Uint8Array(16)
  crypto.getRandomValues(bytes)

  // First 48 bits = timestamp (big-endian Unix millis)
  bytes[0] = (ms / 2 ** 40) & 0xff
  bytes[1] = (ms / 2 ** 32) & 0xff
  bytes[2] = (ms / 2 ** 24) & 0xff
  bytes[3] = (ms / 2 ** 16) & 0xff
  bytes[4] = (ms / 2 ** 8) & 0xff
  bytes[5] = ms & 0xff

  bytes[6] = 0x70 | (bytes[6] & 0x0f)  // version = 7
  bytes[8] = 0x80 | (bytes[8] & 0x3f)  // variant = 10

  return bytesToUuidString(bytes)
}

48 bits of Unix milliseconds, then 12 bits of random (after the version nibble), then 62 bits of random (after the variant bits). Total random bits: 74. That's way less than v4, but the timestamp gives you sortability.

Small numeric subtlety: Date.now() returns milliseconds as a number, and 48 bits (max value ~281 trillion) is still safely within JavaScript's Number.MAX_SAFE_INTEGER (~9 quadrillion). So we can split the timestamp into bytes with arithmetic instead of reaching for BigInt.

ULID: Same structure, shorter string

ULID has almost the same byte layout as UUID v7: 48-bit timestamp + 80-bit random = 128 bits. The difference is the encoding. Instead of hex with dashes (36 chars), it uses Crockford's Base32 (26 chars).

const BASE32 = '0123456789ABCDEFGHJKMNPQRSTVWXYZ'  // no I, L, O, U

function encodeTime(ms) {
  const chars = new Array(10)
  let n = ms
  for (let i = 9; i >= 0; i--) {
    chars[i] = BASE32[n % 32]
    n = Math.floor(n / 32)
  }
  return chars.join('')
}

The Crockford alphabet drops the characters people often confuse when handwriting: I/1, L/1, O/0, U/V. A small concession to human error that costs nothing at the bit level.

Why is Base32 26 chars vs hex's 36 chars? Each base32 char carries 5 bits of info, each hex char carries 4. For 128 bits: 128/5 ≈ 26, 128/4 = 32 (plus UUID's 4 dashes = 36). Better information density by switching alphabets.

NanoID: Sacrifice sortability for size

NanoID goes the opposite direction: give up ordering entirely, maximize string density. Default: 21 characters from a 64-symbol URL-safe alphabet (A-Z, a-z, 0-9, _, -).

export function nanoid(size = 21, alphabet = DEFAULT_ALPHABET) {
  const mask = (2 << (Math.log(alphabet.length - 1) / Math.LN2)) - 1
  const step = Math.ceil((1.6 * mask * size) / alphabet.length)
  let id = ''
  const bytes = new Uint8Array(step)
  while (true) {
    crypto.getRandomValues(bytes)
    for (let i = 0; i < step; i++) {
      const idx = bytes[i] & mask
      if (alphabet[idx]) {
        id += alphabet[idx]
        if (id.length === size) return id
      }
    }
  }
}

Why 21 characters? Because 21 * 6 = 126 bits of entropy, roughly equivalent to UUID v4's 122 bits of real randomness. If you're not going to get ordering anyway, NanoID delivers the same safety in 40% less space.

The mask and step math looks cryptic. What it's doing: when alphabet.length isn't a power of two, simple byte % length introduces bias (some chars would be slightly more likely). The mask trick is unbiased rejection sampling — we generate more bytes than needed, reject the ones out of range, and keep trying until we have enough good chars. step is chosen to minimize the number of retries.

KSUID: Higher entropy sortable

const BASE62 = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'

export function ksuid(nowMs) {
  const secondsSinceEpoch = Math.floor((nowMs ?? Date.now()) / 1000) - KSUID_EPOCH
  // 4 bytes of timestamp + 16 bytes of random = 20 bytes = 160 bits
  const all = new Uint8Array(20)
  // ... write timestamp, then random ...

  // Base62-encode 160 bits into 27 chars via BigInt
  let n = 0n
  for (const b of all) n = (n << 8n) | BigInt(b)

  let out = ''
  while (n > 0n) {
    const r = Number(n % 62n)
    out = BASE62[r] + out
    n = n / 62n
  }
  return out.padStart(27, BASE62[0])
}

KSUID is 32 bits of seconds since 2014 + 128 bits of random. The 2014 epoch shift exists because the full Unix epoch wastes leading bits — nothing ever needs to represent a time before that.

Here's the bug I hit and didn't see coming: the Base62 alphabet has to be in ASCII lexicographic order, which means 0-9 A-Z a-z. My first attempt had A-Z a-z 0-9 because I was thinking about it alphabetically. The tests for sortability failed because string comparison of the generated KSUIDs wasn't preserving numeric order.

For a K-sortable ID, the encoding alphabet itself must be sorted the way strings get compared.

Obvious in retrospect. Would've taken forever to notice without the test.

Effective entropy, compared

The "real" random bits after subtracting version/variant/timestamp fields:

Format	Total bits	Effective random	Sortable
UUID v4	128	122	❌
UUID v7	128	74	✅
ULID	128	80	✅
NanoID	126	126	❌
KSUID	160	128	✅

Two things surprised me:

UUID v7 has the least effective randomness (74 bits). This is a deliberate choice — 74 bits is more than enough when combined with 1 ms timestamps, because you'd need ~4 billion generations in the same millisecond to hit meaningful collision odds.
NanoID has the highest (126 bits). Giving up sortability lets it use every single bit for randomness.

Tests

23 cases on node --test. Per format: format-regex, version nibble, variant bits (where applicable), 1000-item uniqueness, 500-item uniqueness within the same timestamp (for sortable IDs), and for timestamp-first formats, literal sortability checks:

test('sortable by creation time', () => {
  const a = uuidv7(1_000_000_000_000)
  const b = uuidv7(1_000_000_000_500)
  const c = uuidv7(1_000_000_001_000)
  assert.ok(a < b)
  assert.ok(b < c)
})

The KSUID alphabet-ordering bug I mentioned above was caught by exactly this test. Would not have found it manually.

When to use which

After implementing all five, my rule of thumb:

crypto.randomUUID() (UUID v4) — the default. If you don't need sortability and don't care about URL length, stop reading.
UUID v7 — you want ordered IDs and your ecosystem expects a UUID shape. Most mature databases now handle UUID v7 well.
ULID — you want ordered IDs, shorter strings than UUIDs, and don't mind a non-UUID shape.
NanoID — URL slugs, short share codes. Not for DB primary keys.
KSUID — you need a lot of random bits and sortability, and 27 chars is acceptable. Segment.io picked this for logging events for a reason.

Closing

Entry #4 in a 100+ portfolio series by SEN LLC. Previous entries:

Feedback welcome.

Writing a Regex Parser and Tree Visualizer in ~400 Lines of Vanilla JS

SEN LLC — Sat, 11 Apr 2026 06:59:11 +0000

Writing a Regex Parser and Tree Visualizer in ~400 Lines of Vanilla JS

A small tool that turns a regex like ^(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})$ into a color-coded nested tree you can actually read. Plus the old trick of letting the browser's RegExp do the heavy lifting.

Writing regex: manageable. Reading someone else's regex a month later: brutal. regex101 is great for testing behavior but doesn't really show you the shape of the pattern. regexper.com does, but it's starting to feel dated and doesn't quite fit my needs.

So I built a smaller version. Browser-only, zero dependencies, about 400 lines of JavaScript.

🔗 Live demo: https://sen.ltd/portfolio/regex-viz/
📦 GitHub: https://github.com/sen-ltd/regex-viz

The interesting part of the project is the "smart half-measure" at the center of it: parse the regex yourself for visualization, but execute it with the built-in RegExp. I'll walk through each piece.

Three files, three jobs

src/
├── parser.js     # regex string → AST
├── renderer.js   # AST → HTML
└── matcher.js    # built-in RegExp → match ranges

That's the whole engine. The rest is just DOM wiring and CSS.

Part 1: A recursive-descent parser

JavaScript's regex grammar is small and regular enough that a plain recursive-descent parser handles it directly:

regex        = alternation
alternation  = sequence ('|' sequence)*
sequence     = quantified*
quantified   = atom quantifier?
quantifier   = '?' | '*' | '+' | '{n[,m]}' ('?')?
atom         = literal | charClass | group | anchor | predefined | escape
group        = '(' ('?:' | '?<name>')? alternation ')'
charClass    = '[' '^'? char* ']'

Each rule becomes one function in parser.js:

function parseAlternation(state) {
  const branches = [parseSequence(state)]
  while (peek(state) === '|') {
    state.pos++
    branches.push(parseSequence(state))
  }
  if (branches.length === 1) return branches[0]
  return { type: 'alternation', branches }
}

function parseSequence(state) {
  const children = []
  while (state.pos < state.input.length && peek(state) !== '|' && peek(state) !== ')') {
    children.push(parseQuantified(state))
  }
  if (children.length === 1) return children[0]
  return { type: 'sequence', children }
}

The detail I like most: if a sequence has exactly one child, return the child directly instead of wrapping it in a sequence node. Same for alternation. The AST stays small, and the renderer never has to special-case "degenerate" nodes with one child.

Character class parsing was the only slightly annoying bit — - is a literal in some positions and a range separator in others, escapes work differently inside [], and [^] is "everything" despite looking ambiguous. The rule I settled on: check whether the character after - is ] before treating - as a range. Works for every realistic case.

if (state.input[state.pos] === '-' && state.input[state.pos + 1] !== ']') {
  state.pos++ // consume -
  to = state.input[state.pos]
  // ...
}

Part 2: Don't do layout math, let CSS handle it

I almost reached for SVG. It's the "right" medium for a diagram. But then I realized: I'd have to compute the bounding box of every node, lay out children left-to-right or top-to-bottom, position them absolutely, and handle wrapping on narrow screens. That's a lot of code.

Instead, the renderer emits nested <div>s with class names, and CSS does the layout:

case 'sequence': {
  const inner = node.children.map(renderNode).join('')
  return `<div class="rv-node rv-sequence">
    <div class="rv-sequence-row">${inner}</div>
  </div>`
}
case 'alternation': {
  const parts = []
  for (let i = 0; i < node.branches.length; i++) {
    if (i > 0) parts.push('<div class="rv-or-label">OR</div>')
    parts.push(renderNode(node.branches[i]))
  }
  return `<div class="rv-node rv-alternation">
    <div class="rv-alternation-col">${parts.join('')}</div>
  </div>`
}

And the CSS:

.rv-sequence-row { display: flex; flex-direction: row; flex-wrap: wrap; gap: 4px; }
.rv-alternation-col { display: flex; flex-direction: column; gap: 6px; }
.rv-group { border: 1px solid var(--group-color); border-radius: 8px; }

Flexbox handles sequence-as-row, alternation-as-column, nesting, and wrapping on narrow viewports. Zero layout math in JavaScript.

Node coloring is done with border-left: 3px solid var(--literal-color) and different CSS variables per type. Swapping the theme later is one CSS file change.

Part 3: Let the browser execute it

This is where the project gets cheap in the best way. The matcher is this short:

export function matchAll(pattern, flags, testString) {
  const effectiveFlags = flags.includes('g') ? flags : flags + 'g'
  let re
  try {
    re = new RegExp(pattern, effectiveFlags)
  } catch (e) {
    return { ok: false, error: e.message }
  }
  const results = []
  for (const m of testString.matchAll(re)) {
    const start = m.index
    const text = m[0]
    if (text.length === 0) continue  // zero-width match → skip
    results.push({ start, end: start + text.length, text })
  }
  return { ok: true, matches: results }
}

Parsing the regex myself means I can show its structure. Executing it myself would mean writing an NFA/DFA engine, handling backtracking, and almost certainly being slower and buggier than V8's. The two jobs are independent, so I just... don't do the second one.

Two subtleties worth noting:

Force the g flag before calling matchAll. Without it, the call throws. Users don't always remember to include it when their only goal is "highlight every match".
Skip zero-width matches. Patterns like ^, $, (?=foo) match without consuming any characters; if you naively iterate matchAll you'll either loop forever or crash. continue-ing on text.length === 0 is the simplest fix.

Highlighting matches

Given the match ranges, producing highlighted HTML is a straight one-pass stringify:

export function highlight(testString, matches) {
  if (!matches || matches.length === 0) return escapeHtml(testString)
  const out = []
  let pos = 0
  for (const m of matches) {
    if (m.start > pos) out.push(escapeHtml(testString.slice(pos, m.start)))
    out.push(`<mark>${escapeHtml(testString.slice(m.start, m.end))}</mark>`)
    pos = m.end
  }
  if (pos < testString.length) out.push(escapeHtml(testString.slice(pos)))
  return out.join('')
}

The assumption here is that matches are non-overlapping and sorted by position, which matchAll gives us for free.

Tests

51 cases on node --test, grouped into three files for parser / renderer / matcher. No test framework, no dependencies. A lot of the parser tests are one-liners:

test('quantifier {3,5}', () => {
  const ast = okAst('a{3,5}')
  assert.equal(ast.min, 3)
  assert.equal(ast.max, 5)
})

The renderer tests check that the right CSS classes appear in the output HTML (smoke-level, not pixel-perfect). That's enough: if the classes are right, CSS does the rest.

What it doesn't handle

Lookahead / lookbehind ((?=...), (?!...), (?<=...), (?<!...))
Unicode property escapes (\p{Letter})
Backreferences (\1, \2)

All three can still run through the RegExp matcher — they just won't show up in the tree. Parsing them would each require a small extension to parseAtom/parseEscape. On my list if I get requests.

Why rebuild a thing that already exists

Same answer as every portfolio project: fitting the whole codebase in my head is worth more than feature completeness. 400 lines for a regex visualizer means I can reason about every edge case, explain the whole thing in a blog post, and trust that nothing surprising is happening. Every extra abstraction I skip is one less thing a reader has to unpack.

Closing

This is entry #3 in a 100+ portfolio series by SEN LLC. Previous entries:

Feedback, bug reports, and nasty regexes that break it are all welcome.

Writing a TypeScript Type Inference Engine in 300 Lines of Vanilla JS

SEN LLC — Sat, 11 Apr 2026 02:01:51 +0000

Writing a TypeScript Type Inference Engine in 300 Lines of Vanilla JS

A minimal JSON-to-TypeScript interface generator with multi-sample merging and type guard generation. Built to understand how the core of quicktype actually works.

Every time I get a new API endpoint, I do the same small dance: look at a response, eyeball the shape, write a TypeScript interface, copy-paste it into the codebase. quicktype exists and is excellent — but it's also a multi-language beast with a web app that's heavier than I need for this one job.

So I wrote a smaller version. Just JSON → TypeScript, in about 300 lines of vanilla JavaScript. No build step, no dependencies, runs entirely in the browser.

🔗 Live demo: https://sen.ltd/portfolio/json-to-ts/
📦 GitHub: https://github.com/sen-ltd/json-to-ts

Three things turned out to be interesting while building it, and I'll walk through them. They're all about the inference part — not the UI.

Part 1: A tiny AST makes the rest easy

Before anything, I defined the AST the tool uses internally. It's small enough to fit in one paragraph:

type TsType =
  | { kind: 'primitive', name: 'string'|'number'|'boolean'|'null'|'undefined'|'any' }
  | { kind: 'array',     element: TsType }
  | { kind: 'object',    ref: string }     // reference into interface list
  | { kind: 'union',     types: TsType[] }

type Interface = {
  name: string,
  fields: Array<{ key, type, optional, jsdoc? }>
}

That's it. No enums, no literal types, no generics, no intersection types. Keeping the AST narrow means every step downstream (inference, merging, rendering) is short and easy to test.

The one interesting choice: an object's value in the AST is a reference ({ kind: 'object', ref: 'User' }), not an inline structure. The actual interface definition lives in a separate list. This is what lets nested objects become their own named interfaces instead of one giant anonymous blob.

Part 2: `mergeTypes` is the whole trick

Most of the "smart" behavior — detecting optional fields, inferring unions, collapsing multiple API samples into one interface — comes from a single recursive function:

function mergeTypes(a, b, ctx) {
  if (typesEqual(a, b)) return a

  // Two different primitives → union
  if (a.kind === 'primitive' && b.kind === 'primitive') {
    return { kind: 'union', types: [a, b] }
  }

  // Two arrays → merge elements
  if (a.kind === 'array' && b.kind === 'array') {
    return { kind: 'array', element: mergeTypes(a.element, b.element, ctx) }
  }

  // Two object refs → merge their interfaces
  if (a.kind === 'object' && b.kind === 'object') {
    mergeInterfacesInPlace(a.ref, b.ref, ctx)
    return a
  }

  // Mixed kinds → union
  return { kind: 'union', types: [a, b] }
}

Once you have mergeTypes, everything else falls out for free:

Array elements: take the first element, then mergeTypes it with every other element in turn. If they're all the same you get one type. If they're mixed, you get a union.
Multiple samples: treat the user's list of JSON samples as if it were an array of the root type, and apply the same loop. Done.
Optional field detection: happens inside mergeInterfacesInPlace. If a key exists in one interface but not the other, the merged version marks it optional.

That last bit is the piece that makes multi-sample merging feel like magic:

function mergeInterfacesInPlace(aName, bName, ctx) {
  const a = ctx.interfaces.find(i => i.name === aName)
  const b = ctx.interfaces.find(i => i.name === bName)
  const allKeys = new Set([...a.fields.map(f => f.key), ...b.fields.map(f => f.key)])
  const merged = []
  for (const key of allKeys) {
    const fa = a.fields.find(f => f.key === key)
    const fb = b.fields.find(f => f.key === key)
    if (fa && fb) {
      merged.push({ key, type: mergeTypes(fa.type, fb.type, ctx), optional: fa.optional || fb.optional })
    } else {
      // Only in one → optional in the merge
      merged.push({ ...(fa || fb), optional: true })
    }
  }
  a.fields = merged
  ctx.interfaces.splice(ctx.interfaces.indexOf(b), 1)
}

Paste these two samples:

{"id": 1, "name": "A", "email": "a@x"}
{"id": 2, "name": "B", "age": 30}

…and you get:

export interface Root {
  id: number
  name: string
  email?: string
  age?: number
}

email and age are each only in one sample, so they end up optional. id and name are in both so they stay required. No extra code for this behavior — it just falls out of mergeTypes + mergeInterfaces.

Part 3: Generating type guards from the same AST

This is the feature that makes me use my own tool instead of copy-pasting from an online one. From the same AST I emit type guard functions:

export function isRoot(obj: unknown): obj is Root {
  if (typeof obj !== 'object' || obj === null) return false
  const o = obj as Record<string, unknown>
  if (typeof o.id !== 'number') return false
  if (typeof o.name !== 'string') return false
  if (o.email !== undefined && !(typeof o.email === 'string')) return false
  if (o.age !== undefined && !(typeof o.age === 'number')) return false
  return true
}

The generator walks the same AST as the interface generator but emits runtime checks instead of type annotations:

function renderTypeCheck(type, expr) {
  if (type.kind === 'primitive') {
    if (['string', 'number', 'boolean'].includes(type.name)) {
      return `typeof ${expr} === '${type.name}'`
    }
    if (type.name === 'null') return `${expr} === null`
  }
  if (type.kind === 'array') {
    const inner = renderTypeCheck(type.element, '__e')
    return `Array.isArray(${expr}) && (${expr} as unknown[]).every((__e) => ${inner})`
  }
  if (type.kind === 'object') {
    return `is${type.ref}(${expr})`  // call sibling guard
  }
  if (type.kind === 'union') {
    return type.types.map(t => `(${renderTypeCheck(t, expr)})`).join(' || ')
  }
}

Nested objects just call the sibling guard (isAddress(o.address)), which is recursive but stays flat because each interface gets its own named function. For optional fields I prepend an undefined check so the guard doesn't reject correctly-missing keys.

This matters because as User is a lie. At runtime you have an unknown that you're asking the compiler to trust. A type guard turns that lie into a check. For API boundary code I'd rather pay the few extra lines and know the shape actually matches.

The rest

parser.js — 15 lines, wraps JSON.parse into an { ok, value, error } result object.
generator.js — 60 lines, stringifies the AST into TypeScript source. The only trick is wrapping unions inside array types in parens: (string | number)[] not string | number[].
main.js — the DOM glue. Three components: JSON textareas (one per sample), live-updating output pane, URL query sync. Debounced at 200ms so typing doesn't feel laggy.
tests/ — 44 test cases on node --test, no dependencies. Mostly the AST tests; each mergeTypes edge case is one short assertion.

Why rebuild something that already exists

quicktype is ~40,000 lines of TypeScript, supports many target languages, and deals with a huge number of edge cases I'll never hit. This tool is 300 lines and only does TypeScript. It fits in my head.

For a portfolio project specifically — where the point is to show what you can build in a weekend and to teach something in a blog post — "minimal and readable" beats "feature-complete" every time. The code in this article is basically the whole thing. Nothing hidden behind abstractions I don't show.

Closing

This is entry #2 in a 100+ portfolio series by SEN LLC. Previous entry: Cron TZ Viewer and its article. Same spirit: build small, ship fast, write about the interesting bit.

Feedback, bug reports, gnarly JSON samples that break it — all welcome.

You Probably Don't Need a Timezone Library Anymore

SEN LLC — Fri, 10 Apr 2026 12:20:13 +0000

You Probably Don't Need a Timezone Library Anymore

A small, zero-dependency static web tool, and the two things that turned out to be actually interesting about building it.

Every time I hand a cron expression to a teammate in another timezone, I do the same mental math. "0 9 _ _ 1-5 in JST — that's 00:00 UTC, which for PT is… 16:00 the previous day during standard time, 17:00 during DST… hold on, is DST active right now?"

crontab.guru is a wonderful tool, but it only shows one timezone at a time. So I built the thing I wanted: a static page that shows the next 10 runs of any cron expression across UTC / JST / PST / EST / CET in one table, side by side, DST-aware.

🔗 Live demo: https://sen.ltd/portfolio/cron-tz-viewer/
📦 GitHub: https://github.com/sen-ltd/cron-tz-viewer

The whole thing is plain HTML/CSS/JS with no build step and zero runtime dependencies. Total surface area: about 500 lines including tests. The two parts I want to write about are the timezone handling and the algorithm for computing next runs without hanging the browser on @yearly input.

Part 1: You don't need a timezone library anymore

For years, "timezone math in JavaScript" meant moment-timezone or luxon. Both are excellent. Both are also 100+ KB of payload for a tool whose entire UI is a table.

It turns out modern browsers ship a complete IANA timezone database inside Intl.DateTimeFormat. Here's the entire timezone-aware "what's the wall clock right now in Tokyo" function:

const DOW_MAP = { Sun: 0, Mon: 1, Tue: 2, Wed: 3, Thu: 4, Fri: 5, Sat: 6 };

export function wallClock(utcMs, tz) {
  const fmt = new Intl.DateTimeFormat("en-US", {
    timeZone: tz,
    year: "numeric",
    month: "numeric",
    day: "numeric",
    hour: "numeric",
    minute: "numeric",
    weekday: "short",
    hourCycle: "h23",
  });
  const parts = fmt.formatToParts(new Date(utcMs));
  const get = (type) => parts.find((p) => p.type === type).value;
  return {
    year: Number(get("year")),
    month: Number(get("month")),
    day: Number(get("day")),
    hour: Number(get("hour")),
    minute: Number(get("minute")),
    dow: DOW_MAP[get("weekday")],
  };
}

A few things make this work:

formatToParts returns a typed array of { type, value } instead of a locale-formatted string, so you never have to parse "Dec 25, 2026" back apart.
hourCycle: 'h23' forces 24-hour output — no more worrying about whether hour: 'numeric' returned 12 AM or 00.
Any IANA zone just works, including DST transitions. Asia/Tokyo, America/Los_Angeles, Europe/Berlin — all handled by the browser's built-in database.

The rest of the tool formats a single UTC timestamp into all 5 display timezones just by calling this function 5 times. No library. No DST tables I have to keep updated.

Part 2: Don't loop minute-by-minute

My first pass at nextRuns(ast, tz, from, count) looked like this:

// Naive: works, but hangs the browser on @yearly.
while (results.length < count) {
  const wc = wallClock(t, tz);
  if (matches(ast, wc)) results.push(t);
  t += MINUTE;
}

It worked great for */5 * * * *. Then I typed @yearly into the input. 525,600 loop iterations per match × 10 matches = browser frozen for several seconds. Not shippable.

The fix is to skip forward whenever a mismatch tells you that an entire larger unit can't possibly contain a match:

while (results.length < count && i++ < MAX_ITERATIONS) {
  const wc = wallClock(t, sourceTz);

  if (!ast.month.has(wc.month)) {
    t += DAY - (wc.hour * HOUR + wc.minute * MINUTE);
    continue;
  }
  if (!dayMatches(ast, wc.day, wc.dow)) {
    t += DAY - (wc.hour * HOUR + wc.minute * MINUTE);
    continue;
  }
  if (!ast.hour.has(wc.hour)) {
    t += HOUR - wc.minute * MINUTE;
    continue;
  }
  if (!ast.minute.has(wc.minute)) {
    t += MINUTE;
    continue;
  }

  results.push(t);
  t += MINUTE;
}

The idea: if the hour doesn't match, there's no point trying the next minute within this hour — they all have the same hour. Jump to the start of the next hour and try again.

The bug that cost me an hour

The first version of that algorithm did something simpler-looking: t += HOUR on an hour mismatch. Seems reasonable! But I wrote a test that failed:

test("0 0 * * * in JST → JST midnight", () => {
  const runs = runsFor("0 0 * * *", "Asia/Tokyo", ANCHOR_UTC, 2);
  assert.equal(formatInTz(runs[0], "Asia/Tokyo"), "2026-01-02 00:00");
});

Expected the first next run to be 2026-01-02 00:00 JST. Got 2026-01-03 00:00 JST. One full day late.

Walking through the algorithm by hand: start at 00:01 UTC = 09:01 JST. Minute is 1, not 0 → step minute. Loop to 10:00 JST. Hour is 10, not 0 → t += HOUR → 11:00 JST… continue → eventually 00:00 JST next day. Should match. So why the extra day?

Because the hour-skip didn't reset the minute, and so after the first minute-stepping loop ran from 09:01 → 10:00, the subsequent hour skips each kept the minute at 00 — fine. But the next iteration of the top-level loop landed me past the minute I cared about. On the second match, starting from 00:01 JST (the minute after the pushed match), the minute stepping ran from 00:01 → 01:00, then hour stepping ran all the way around the clock to 00:00 the day after.

The fix, which I showed above, is to subtract the current minute before adding an hour:

t += HOUR - wc.minute * MINUTE;

If wc.minute is 23, we add 37 minutes instead of 60. We land exactly on the top of the next hour, where the minute is now 0, and the match logic can keep going from there. Same idea for day skipping: subtract the current hour*HOUR + minute*MINUTE so we land on 00:00 of the next day.

With that change, @yearly returns 10 next runs in ~2 ms. 0 0 29 2 * (Feb 29, leap-year only) returns 10 in ~40 ms — worst realistic case.

I found this bug through a test I wrote because I was vaguely suspicious of the DST-naive hour math. The lesson wasn't really "unit tests save you" — it was more that specifically testing the boundary between units is where cron-like algorithms go wrong.

What's in the repo

src/parser.js — cron string → AST. Pure function, DOM-free.
src/nextRuns.js — AST + timezone + start instant → array of UTC epoch-ms.
src/explain.js — AST → human-readable field breakdown (ja/en).
src/main.js — DOM wiring, URL query sync, language toggle. No logic.
tests/*.test.js — 36 cases running on node --test, zero test deps.
infrastructure/cloudformation/ — S3 + CloudFront + Route53 templates.
.github/workflows/deploy.yml — OIDC deploy on push to main.

No bundler, no linter config, no Prettier, no framework. npm test runs the tests. python3 -m http.server serves the site.

Why this project exists

This is entry #1 in a 100+ portfolio series by SEN LLC. We build small, focused, public things to demonstrate what we actually do. If you find this useful, the repo has an MIT license — fork, hack, ship.

Feedback, bug reports, and corrections welcome. Especially if you've got a nasty cron expression that breaks the parser — I'd like to know.

Forem: SEN LLC

A GUI Cron Builder — And Why Building Is Way Easier Than Parsing

A GUI Cron Builder — And Why Building Is Way Easier Than Parsing

The inverse direction is genuinely simpler

buildCron is a one-liner that composes the five fields

The explanation text is a 2D field × mode table

Linking the two tools via URL query

Tests

Series

A Bill Splitter Where Unit and Rounding Are Orthogonal (They Usually Aren't)

A Bill Splitter Where Unit and Rounding Are Orthogonal (They Usually Aren't)

The roundTo(value, unit, mode) helper

Returning diff is what makes the UX good

Weighted splits via normalization

Input validation: fail fast, return errors

Tests

Series

Converting Between Japanese Eras and Gregorian Dates — and Why the Boundary Days Matter

Converting Between Japanese Eras and Gregorian Dates — and Why the Boundary Days Matter

Era data as a list of boundary dates

Gregorian → era via tuple comparison

Parsing 元年 (first year)

Range checks: Shōwa 65 doesn't exist

Tests

Series

Writing Conway's Game of Life With Uint8Array and Canvas, Including a Gosper Glider Gun

Writing Conway's Game of Life With Uint8Array and Canvas, Including a Gosper Glider Gun

Why a Uint8Array instead of nested arrays

Toroidal wrap so small patterns run forever

The step() function

Gosper Glider Gun as a coordinate list

Play loop: requestAnimationFrame, not setInterval

Tests

Series

50 Japanese Traditional Colors, Sorted By Hue — Because the Names Aren't Enough

50 Japanese Traditional Colors, Sorted By Hue — Because the Names Aren't Enough

Hue-order sorting completely changes the UX

Flipping label color by perceived brightness

Search that accepts kanji, reading, or hex

Copy-to-clipboard with a fallback

Testing the data, not the code

Tests

Series

Every Time Format At Once: A Converter That Stops the Unix-Seconds-or-Milliseconds Dance

Every Time Format At Once: A Converter That Stops the Unix-Seconds-or-Milliseconds Dance

Auto-detecting the input format

The "ISO 8601 without a timezone" mess

Outsourcing DST to Intl.DateTimeFormat

Relative time: biggest unit first wins

Tests

Series

A JWT Debugger That Never Sends Your Token Anywhere

A JWT Debugger That Never Sends Your Token Anywhere

Proving "doesn't phone home" without making you audit the source

JWT segments are Base64*url*, not Base64

Time claims: the "relative delta" is the whole point

Deliberately no signature verification

Per-segment error messages

Tests

Series

I Built a Side-by-Side Base64 / URL / HTML / Encoder and Finally Stopped Confusing Them

I Built a Side-by-Side Base64 / URL / HTML / Encoder and Finally Stopped Confusing Them

Base64: btoa can't eat UTF-8

URL percent: see the UTF-8 bytes directly

HTML entities: named vs numeric

Unicode escape: the \u1234 vs \u{10000} line

What you see with all four side-by-side

Tests

Series

UUID v7, ULID, KSUID — What's the Difference? I Implemented All Five

UUID v7, ULID, KSUID — What's the Difference? I Implemented All Five

The one thing all sortable IDs do

UUID v4: The baseline

UUID v7: RFC 9562, timestamp-first

ULID: Same structure, shorter string

NanoID: Sacrifice sortability for size

KSUID: Higher entropy sortable

Effective entropy, compared

Tests

When to use which

`buildCron` is a one-liner that composes the five fields

The `roundTo(value, unit, mode)` helper

Returning `diff` is what makes the UX good

Parsing `元年` (first year)

Why a `Uint8Array` instead of nested arrays

The `step()` function

JWT segments are Base64url, not Base64

Unicode escape: the `\u1234` vs `\u{10000}` line

Part 2: `mergeTypes` is the whole trick