I extracted the SVG animation engine from my project and open-sourced it

I had a small problem that kept getting more annoying.

I wanted SVG diagrams to draw themselves.

Not just fade in. Not just appear. I wanted the strokes to progressively draw, followed by the fills and labels.

I initially used Vivus for the stroke animation. It does that part well.

But the SVGs I was working with weren't particularly clean. They contained strokes, fills, text, and diagram elements. I also wanted to control the animation from a timeline and eventually export the animation as a video.

At some point, I realized the code had become useful enough to pull out of the original project.

So I turned it into @penwell/draw-on.

What it does

The basic API is intentionally small:

const drawing = createDrawing(svg, {
  duration: 2000
})

drawing.play()

But you can also control the animation yourself:

drawing.setProgress(0.25)
drawing.setProgress(0.5)
drawing.setProgress(0.75)

That makes it possible to connect the animation to things like scroll position, a custom timeline, or another animation system.

Strokes, fills and labels

One thing I wanted that wasn't part of my original Vivus setup was a better reveal sequence for normal diagrams.

The idea is:

draw the strokes
       ↓
reveal fills
       ↓
reveal labels

That makes diagrams feel a little less like they're simply being rendered onto the page.

React

There is a React API as well, while the core package stays framework-agnostic.

const { containerRef, play, setProgress } = useSketchDraw({
  svgMarkup,
  duration: 2000
})

Recording

Another reason I extracted it was recording.

draw-on can render the animation to WebM in the browser, so there doesn't need to be a video-generation server sitting behind it.

That's useful for applications that want to turn generated diagrams into short clips.

Demo gifs

Annotate Documents

Draw Diagrams

Notebook Animation

Why open source it?

Honestly, mostly because I think the package is more useful if people can try it against SVGs I haven't seen.

It's currently 0.1.4, and I'm sure there are SVG edge cases waiting to be discovered.

If you use Mermaid, Figma exports, Excalidraw or other SVG-heavy workflows, I'd be particularly interested in hearing what happens when you throw those files at it.

GitHub: penwell/draw-on

npm: @penwell/draw-on on npm

Documentation Website: https://draw-on-nu.vercel.app/

It's MIT licensed, and contributions are welcome.

Comments

[Svg/icons]

Have you tested / references yet? Many production SVGs reuse geometry that way, so resolving those before measuring strokes could be an interesting edge case

[Pratik Singh]

Good catch. I haven’t specifically covered / referenced geometry in the current test suite yet.

Right now, draw-on works directly with the actual drawable elements it finds in the SVG, so reused geometry through / is an edge case I’d want to test explicitly rather than assume it’s handled correctly.

Resolving referenced geometry before measuring and preparing the strokes could definitely be the right direction here. I’ll add this to the edge-case coverage, especially for production SVGs that make heavy use of , symbols, and shared paths.

Thanks for pointing this out, that’s exactly the kind of SVG compatibility case worth catching before relying on the library broadly.