AI Code Typing Preview — Free JS Editor Animation Snippet

This snippet recreates the now-familiar "AI is writing code" moment seen in Copilot, Cursor, and Claude's own coding tools: a dark code-editor panel where lines of a function appear one character at a time, each token colored the instant it is complete, with a blinking cursor tracking the current write position. The goal was to make something that feels alive rather than mechanical, which meant rejecting the obvious approach — a fixed setInterval typing at a constant interval — in favor of jittered timing and a hand-rolled tokenizer.

Why a constant interval looks fake

A setInterval typing every character at exactly 30ms looks robotic within about two seconds, because real typing — human or AI-generated token-by-token output — is never that uniform. delayFor() computes a fresh random delay for every character: a base of 18 + Math.random() * 42 milliseconds, halved for spaces (since spaces genuinely type faster), with roughly a 35% chance of a much longer pause at the very start of each line to simulate the model "thinking" before committing to the next statement, and a small 4% chance of a random mid-line pause. None of this is expensive to compute, but it is the single biggest factor in whether the animation reads as scripted or organic.

The typing loop: recursive setTimeout via async/await, not setInterval

Rather than a single setInterval ticking at a fixed rate, typeLine() is an async function that awaits a freshly computed sleep(delayFor(...)) promise before appending the next character. This is what lets every single character have its own independent, randomized delay — an interval-based timer can only ever tick at one fixed rate, but a chain of awaited timeouts can vary every step. A monotonically increasing runToken guards against races: clicking Replay while a previous run is still typing increments the token, and every in-flight typeLine call checks its captured token against the current one before continuing, so a stale animation can never keep writing over a fresh one.

A tiny regex tokenizer instead of a syntax-highlighting library

Pulling in a full syntax highlighter for a five-category demo (keywords, strings, comments, numbers, function names) would be overkill, so tokenizeLine() hand-rolls one: an ordered array of { type, regex } rules is tested against the remaining text left-to-right, and whichever rule matches first consumes that chunk. Order is the whole trick — comments and strings are checked before keywords, so the word "function" appearing inside a string or a comment is never mistakenly colored as a keyword, because the string/comment rule already consumed the entire quoted or commented span before the keyword rule gets a chance to run.

Progressive highlighting, not "type first, colorize after"

The easy-but-wrong approach is to type plain characters and run the tokenizer once the whole line is done. Instead, renderHighlighted() re-tokenizes the *entire partial string typed so far* on every single character and rewrites codeEl.innerHTML. This sounds wasteful, but at demo-scale line lengths it is trivial for the browser, and it produces the correct visual effect: a string's green coloring appears the instant its closing quote is typed, not after the whole line finishes, exactly like a real editor's incremental highlighter would behave.

The blinking cursor tracks position, not a static append

The cursor is a small <span> with a step(1) blink animation, and it is physically moved after the current line's code span on each line — codeEl.after(cursor) — then removed once that line finishes typing and effectively "reappears" attached to the next line's code element. Because it is a real DOM sibling of the code span rather than a CSS ::after on the container, it visually sits exactly at the end of whatever has been typed so far, including mid-word.

Lines sliding in with CSS keyframes, not JS-driven positioning

Each new <div class="actp-line"> gets a CSS animation: actp-line-in that fades and slides it up 6px into place the moment it's appended — pure CSS, no per-frame JS work, so it stays smooth regardless of how the typing loop is timed. Separating "how a line enters" (CSS) from "how its characters appear" (JS timing loop) keeps each concern simple on its own.