SWYoon Labs

A two-pane calculator looks simple: place calculator A next to calculator B and let both accept input. The difficult part is not drawing two keypads. It is deciding exactly which state a key is allowed to change, when an unfinished expression becomes a result, and what should be written to history. Twin Calculator uses an explicit equals button for each pane. It does not continuously evaluate both panes after every keystroke. That choice gives the user a clear commit point, keeps errors inside one calculator, and makes calculation history describe completed actions rather than every temporary input. The short version Each calculator owns its own entry, accumulator, pending operator, and error flag. A digit edits only the focused calculator. The equals action commits only that calculator's pending operation and creates one history record. The other pane remains untouched. Two displays are not enough If the implementation stores only two display strings, it cannot reliably ...

Making captions larger sounds like a CSS task. The difficult part begins after the bar exists: it must follow playback, react immediately after a seek, survive YouTube's single-page navigation, and avoid rewriting the DOM hundreds of times for the same sentence. This article describes the synchronization core of YouTube Big Caption Bar, a Manifest V3 Chrome extension that places a large reading bar above a YouTube video. The design uses the media element as its clock, a sorted transcript as its timeline, binary search as its matcher, and a small amount of state to prevent unnecessary rendering. The short version Read time from the video, normalize cues into one sorted array, locate the active cue with binary search, and touch the DOM only when that cue changes. Reset the whole loop when YouTube navigates to another video. Treat the video element as the source of truth Do not build a separate stopwatch. Playback can pause, buffer, change speed, or jump after the user seeks...

Designing Safe Auto-Cleanup and Trash for a Local-First Notes App Local-first software earns trust by keeping user data on the device. That promise, however, makes deletion design more important—not less. If a cloud service deletes the wrong record, a server backup may exist. If a browser extension permanently removes a note from chrome.storage.local , there may be no second copy. This article explains the design behind Auto-clean and Trash in Simple Side Note. The implementation uses three safety layers: cleanup is opt-in, important notes are excluded, and expired notes move to a recoverable trash area before permanent deletion. Start with explicit product invariants Before writing cleanup code, define rules that must always remain true. These are more useful than a list of UI controls because they can become test cases. For this note app, the invariants are: Auto-clean is off by default. Only unpinned notes can expire. The note currently being edited cannot be cleaned. C...

Drawing over a webpage sounds simple: create a canvas, stretch it across the viewport, and listen for pointer events. That prototype works in a few minutes. Turning it into a usable Chrome extension is a different problem. The overlay must remain sharp on high-density displays, avoid breaking the page when drawing is disabled, preserve annotations while a side panel closes, handle text and erasing, and capture the visible result without sending private page data to a server. I faced those problems while building Markerly, a Manifest V3 extension for drawing, highlighting, typing notes, and saving annotated screenshots. This article walks through the architecture and the design choices that mattered most. Split the extension into three responsibilities The implementation uses three contexts: Context Responsibility Content script Creates the overlay, collects pointer input, and renders strokes Side panel Controls tools, colors, sizes, opacity, capture, and mode Se...