A few weeks ago, Strokeline could do this:
CIRCLE browser
RECTANGLE server
ARROW browser -> server
Hit run, and a hand-drawn animation plays.
That was the whole idea, and it works.
Then I watched some professional whiteboard videos on YouTube and noticed the gap.
Mine is correct. Theirs feels alive.
Smooth motion. A board that looks like a real board. Text that is always the right size and always in the right place.
Correct and polished are two different targets. This post is about the second one.
Step one: measure before building
I could have started adding features at random: better pens, fancier boards, more animations.
Instead I did a full read-only review of the whole codebase first. No edits, just a list of what's strong and what isn't.
The result was useful, because it separated two kinds of problems.
What's already solid
The core is a one-way pipeline:
script -> parser -> compiler -> validator -> timeline -> renderer
A few decisions that are paying off:
- The core never imports React, and ESLint enforces it.
- The timeline is a pure function of time, so scrubbing and pausing can't desync.
- Every hand-drawn wobble is seeded from the object's id, so nothing flickers between frames.
- The parser recovers from errors and reports several at once instead of stopping at the first.
That foundation is the reason I can safely build on top of it.
What needs work
Here is the honest list, in normal engineering terms.
Video export runs in real time.
It records the canvas with MediaRecorder, so a 60 second video takes 60 seconds, and a throttled tab can produce dropped frames. The timeline is already deterministic, so the better approach is to render every frame offline at t = frame / fps and encode from that.
Camera zoom and text size fight each other.
Text is scaled against the camera to stay readable, which means it can shrink relative to the object you zoom into. It should scale with the camera and only use a minimum size as a safety net.
No multi-line text.
Right now a paragraph means one text object per line and manual Y math. That is tedious for a person and error-prone for anything generating scripts.
Timeline resolution can get expensive.
Computing an object's starting state re-resolves earlier animations on that object. Fine for small scenes, wasteful for busy ones. It can be a single linear pass.
The ICON statement isn't wired up.
There are 54 icons compiled and ready, but the script language has no way to pick one yet. Small fix, big unlock.
Nothing here is exotic. All of it is fixable, and none of it needs a rewrite.
The real gap: correct is not pro
After going through the list I realized fixing every item would still leave it feeling flat.
Polished whiteboard videos have four things Strokeline doesn't yet:
1. Motion polish
2. A real board
3. A layout engine
4. A design linter
1. Motion polish
Right now strokes reveal at constant speed. A hand doesn't work that way. It starts slowly, speeds up, and settles.
The plan:
- eased reveals with a natural start and finish
- ink that tapers at the ends like real pen pressure
- text wiped in with a soft edge instead of appearing one character at a time
- entrance and exit styles: pop, slide, drop, write, erase
- a very slow camera drift so the frame is never completely frozen
All of it stays a pure function of time, so scrubbing still works.
2. A real board
A flat background color says "software". A board says "someone wrote this".
BOARD chalkboard
STYLE chalk
Grain, vignette, faint eraser smudges, and pen styles like chalk, marker, and pencil. All generated procedurally and cached, so there is no per-frame cost.
3. A layout engine
This is the one I care about most.
The most common way a script looks bad isn't the story. It's the placement. Text half off the edge, two labels overlapping, an arrow cutting through a word.
That happens because every position is hand-computed coordinates. So instead of:
POSITION 960 690
you say what you mean:
CREATE note AS TEXT
TEXT "Then time does the rest"
BELOW title GAP 40
MAXWIDTH 900
FIT WIDTH 900 HEIGHT 120
DRAW 1s
END
The engine measures the real text with the real font, wraps it, shrinks it to fit when needed, and places it relative to something else. No guessing.
4. A design linter
Compilers catch syntax errors. Nothing catches "this looks bad".
So the validator gets a second job: non-blocking warnings.
W_TEXT_OVERLAP
W_TEXT_OFF_SAFE
W_LOW_CONTRAST
W_TEXT_TOO_SMALL
W_ARROW_CROSSES_TEXT
W_DEAD_AIR
Each one says what's wrong, where, and suggests a fix. Click a warning and the editor jumps to the line.
The rule I'm not breaking
Every change has to be additive. Old scripts must render pixel-identical.
So before adding anything visual, I'm building a safety net:
render frames at 0%, 25%, 50%, 75%, 100%
compare against saved snapshots
fail if anything moved
The fastest way to kill a project like this is to make it prettier and quietly break everything that used to work. I've had a parser eat 4GB of RAM once. I don't want a sequel.
The order
Not the most fun order. The most useful one:
1. Safety net (so I can't break things)
2. Layout engine (so text always makes sense)
3. Design linter (so ugly gets caught)
4. Motion polish (so it feels smooth)
5. Boards and pens (so it looks pro)
6. Reusable parts (so scripts get short)
Motion and textures make a good layout look great. They can't rescue a bad one. Layout comes first.
What I'm deliberately skipping for now
Voice-over, subtitles, and music.
Audio sync is a big part of a full video pipeline, but if the picture isn't solid, syncing sound to it just gives you a well-timed bad video. Picture first, then sound.
What I took from this
Last time the lesson was that programs believe things that aren't true.
This time it's simpler: you can't improve what you haven't measured.
If your project feels almost there and you can't say why, don't add anything yet. Read all of it, write down what's true, and fix things in the order that helps most.
More soon, with screenshots.
What would you want from a script-to-animation tool that I haven't mentioned? I'd like to hear it.
Top comments (0)