First a quick remark about scope. This is not a full manual for Snap.svg, nor is it a comprehensive comparison with the wider visualization ecosystem. My aim here is narrower and, I hope, more useful: to reintroduce a “classic” SVG library that many people wrote off as abandoned, and to explain why I think it is still a compelling alternative to D3.js for interactive SVG in 2025.

The short version:

• The original Snap.svg repo at Adobe has been effectively frozen for years.
• Over the last decade I’ve been extending a fork of Snap.svg with geometry utilities, interaction primitives, UI‑building helpers, and TypeScript types, while keeping the original API intact.
• On top of that, there is now a growing toolkit for non‑linear warps, 3D‑ish transforms, and Bezier‑based 3D projections.

This post is the first in a series that will unpack those pieces and show how to use them in practice.

---

A brief history: Snap.svg and why it mattered

Snap.svg was originally created by Dmitry Baranovskiy (of Raphaël fame) and hosted at Adobe as part of their web platform work:

• Official Adobe repo: https://github.com/adobe-webplatform/Snap.svg/

The core design assumption of Snap.svg was simple but powerful: if the browser already gives you SVG as a first‑class scene graph (paths, groups, transforms, events, etc.), then the JavaScript library should help you work with that directly, not replace it with its own retained‑mode canvas abstraction.

Concretely, this gave you:

• A thin wrapper around native SVG elements Snap returns a “paper”; you create shapes, group them, style them, and animate them directly as SVG.
• A coherent API for transforms and groupings You work with groups, transforms, and bounding boxes in a uniform way.
• A minimal mental model You are still working with SVG; Snap just makes that pleasant.

That combination made Snap.svg a good fit for icons, dashboards, micro‑interactions, and “SVG as UI” long before “SVG UI” was fashionable.

The official repository, however, has been stagnant for years. No modern builds, no TypeScript, and—crucially—no evolution of the geometry layer. The core ideas are still sound; the ecosystem around them just stopped moving.

---

Why Snap.svg (rather than D3.js) in 2025?

The obvious question is why you would reach for Snap.svg when D3.js (and a crowd of successors) exists.

Very roughly:

• D3 is data‑first. It shines when you have a non‑trivial data model, need a flexible layout pipeline, and want to bind everything to selections.
• Snap.svg is shape‑first. It shines when you already know the shapes you want (icons, widgets, diagrams, controls) and you want to manipulate them as SVG primitives with a rich geometry API.

If what you need is:

• A draggable diagram editor
• Interactive icons, badges, and widgets
• Geometry‑heavy UIs (flow fields, Voronoi overlays, hulls, 3D‑ish curves)
• SVG‑based UI components that you want to ship as part of a design system

…then the friction of going through D3’s data join model can be more of a distraction than a benefit. At that point, a library that says “give me an <svg>, I will give you a useful geometry/animation/interaction layer” is often closer to what you want.

That is exactly the design stance of this fork.

---

The fork: geometry, interaction, UI, and typing on top of Snap.svg

The extended fork lives here:

• Forked + extended Snap.svg: https://github.com/vakarelov/Snap.svg

The central constraint is conservative: the original Snap.svg API remains intact. On top of that, the fork adds:

• Bezier / PolyBezier tooling

• Higher‑level Bezier helpers (including 3D‑ish curves) and utilities for constructing and editing curves.

• Polygon operations

• Convex and concave hulls, SAT‑style overlap checks, and helpers for morphology‑like operations on polygonal regions.

• Robust BBox and geometry helpers

• Bounding‑box extensions that behave well under transforms, plus richer geometry primitives exposed on elements and the paper.

• Element and Paper extensions

• Higher‑level drawing and layout helpers (for example, grid construction and generalized transforms).

• Interaction & GUI primitives

• “Smart drag” behavior, constrained motion, localized warp fields, and Bezier control‑point editing, all expressed in terms of SVG primitives.

• Color palettes and UI utilities

• Practical helpers for building in‑SVG UI: grids, overlays, control panels, labels, etc.

• Comprehensive TypeScript types

• A proper type layer for the Snap API and the new geometry/interaction extensions, which makes working in modern tooling substantially more tractable.

The point is not to turn Snap into something else; it is to make the “shape‑first” approach viable for the kinds of problems front‑end developers actually face now.

---

Towards 3D and non‑linear transforms

So far I have spoken mostly in the abstract: geometry, interaction, “UI helpers”. To make this more concrete, it is useful to look at the new non‑linear transform and 3D‑ish tools, because they stress‑test everything else.

Non‑linear transform gallery

The non‑linear demo page wires Snap into a set of animated “fields” that bend a grid in time:

• Some presets sweep a sine wave along a diagonal axis.
• Others behave like a cantilever, with the grid “hinging” around a line.
• There are radial ripples, bulges, and compound warps combining several effects.

You can see them here:

• Non‑linear transforms: https://htmlpreview.github.io/?https://github.com/vakarelov/Snap.svg/master/demos/non-linear/index.html

Conceptually, each demo defines a time‑dependent transform over the SVG plane and asks Snap to apply it to every point of a grid. Many of these fields internally use 3D transforms (rotations in depth, perspective projection) and then project back to 2D, which is why they feel “3D‑ish” even though they are rendered in plain SVG.

The point is not that every UI will use such warps; it is that the extension layer can describe genuine fields over the SVG plane, rather than only global affine transforms.

Localized warps and “warp fields”

The warp demo takes the same machinery but makes it local and interactive:

• A circular “warp field” is drawn on the stage.
• A smaller “probe” grid can be dragged around inside that field.
• Depending on the preset (twist/pinch, bulge, ripple, 3D sine depth), a localized warp is applied only where the probe intersects the field.

You can try it here:

• Warp fields (localized non‑linear warps): https://htmlpreview.github.io/?https://github.com/vakarelov/Snap.svg/master/demos/warp/warp_demo.html

This is the sort of interaction Snap.svg is particularly suited for: SVG is your scene graph, and the library gives you a programmable metric on that graph. Warp fields are defined declaratively; dragging and bounding‑box helpers do the bookkeeping.

3D Bezier projection demo

Non‑linear warps are one axis of extension; the other is explicit 3D curves and projections. The Bezier projection demo illustrates this:

• You control a 3D Bezier curve via sliders for the Z‑coordinates and direct manipulation of control points in multiple orthographic views.

• The same curve is shown simultaneously in:

• XY, XZ, and YZ orthographic projections

• A perspective camera view

• A custom “isometric‑like” projection

The demo is here:

• 3D Bezier projections: https://htmlpreview.github.io/?https://github.com/vakarelov/Snap.svg/master//demos/bezier/bezier_projection_demo.html

Internally, the curve is represented by an extended Bezier object that supports 3D control points and several projection methods. You can also animate the camera around the curve, orbiting in the XZ plane while maintaining a fixed target.

This is a step towards a full SVG‑based 3D engine for Snap.svg: the geometry layer has to be coherent enough that 3D curves, projections, and camera motion feel like natural extensions of existing 2D concepts (paths, bounding boxes, transforms), not like an unrelated subsystem bolted on the side.

---

Other demos you can click through right now

If you prefer to start from behavior rather than abstractions, the easiest way into the fork is to explore the demos. They are all built directly on the extended Snap API (no hidden frameworks).

Each of these is deliberately written as “just” Snap code: no bundler is required to understand the core ideas, and (once you build the fork) you can view the sources alongside the running demos.

---

Getting started with the fork

The GitHub repository of the extended Snap.svg lives here:

• https://github.com/vakarelov/Snap.svg

A quick path to experimentation is:

1. Clone the repo.
2. Build the distribution bundle.
3. Include the built file in a static HTML page, in the same spirit as the original Snap.svg library.
4. Attach Snap to an existing <svg> and start drawing/manipulating shapes using the extended APIs (geometry helpers, warps, Bezier tools, point utilities, etc.), borrowing patterns from the demo sources.

If you are already using Snap.svg from the original Adobe repo, the existing API should continue to work; the new pieces are additive.

---

What comes next in this series

This post has been mostly conceptual: where Snap.svg comes from, why I think it still deserves attention, and how the fork extends it towards a richer geometry and 3D story.

In the next posts I plan to:

• Walk through the geometry primitives in more detail (Bezier/PolyBezier, polygon operations, hulls, SAT overlap).
• Show how to build interactive widgets with the drag helpers, BBox utilities, and warp fields.
• Dive deeper into the 3D Bezier and camera model, and eventually into the full SVG‑based 3D engine that is being built on top of these pieces.

Questions or gaps? Open an issue in the GitHub repo or ping in the relevant PR—I’m happy to add examples or fill in missing documentation as we go.

This is, in that sense, a reintroduction rather than a eulogy: Snap.svg is not a frozen artifact of the early 2010s, but a living tool that still has quite a bit of headroom for modern interactive SVG work.