Snap.svg: a jQuery-style JavaScript library for animating SVG

Loading the library with a single script tag

The README's headline install story is one line of HTML, no build step, no module loader. Both the minified and the uncompressed builds live in the `dist/` folder of the repository:

<script src="snap.svg-min.js"></script>

The package is on npm under the name `snapsvg`, with a lowercase s on the end, which differs from the repository name and from the import alias you use later. Bower is still documented as an option, and the README also links raw minified and unminified files directly from the repository for people who would rather not touch a package manager at all:

npm install snapsvg
bower install snap.svg

The split between `snap.svg-min.js` and `snap.svg.js` is worth remembering when something behaves oddly. The minified build is what a page ships, the unminified one is what you read when you are stepping through code in a debugger, and both are the same library rather than a debug and a release variant.

What the repository actually ships

The tree tells you this is an older-style project with its build history still in place. There is `src/` for source, `dist/` for the shipped builds, `demos/` for examples, `doc/` for documentation, and a `test/` folder. Alongside those sit several files that date the project: `bower.json`, `component.json` for the component registry that predates npm's dominance, `dr.json`, a `Gruntfile.js`, a `.travis.yml` rather than a GitHub Actions workflow, and a `template.dot` that looks like a Graphviz template used to generate something in the docs.

There is also a `history.md`, which is the closest thing to a changelog in the repository, since the GitHub releases list is empty. The `CONTRIBUTING` and `NOTICE` files complete an Apache-2.0 project, and the author named in package.json is Dmitry Baranovskiy.

The npm package points `main` at `./dist/snap.svg.js`, so a bundler that follows package.json resolves to the unminified build. The one runtime dependency is `eve`, pinned at `~0.5.1`, which is the small event helper Snap uses for its event layer. Everything else in the dependency list is development tooling.

Bundling requires imports-loader on webpack 2 or 3

This is the part of the README most likely to cost you time, and it is worth reading as a dated document rather than a current recipe. The library touches `window` and `module.exports` at load time, so a bundler needs to be told how to handle it. The README's answer is to install Imports Loader and rewrite both `this` and `module.exports`:

module: {
  rules: [
    {
      test: require.resolve('snapsvg/dist/snap.svg.js'),
      use: 'imports-loader?this=>window,fix=>module.exports=0',
    },
  ],
},
resolve: {
  alias: {
    snapsvg: 'snapsvg/dist/snap.svg.js',
  },
},

Two details in that config matter. The `test` uses `require.resolve` rather than a path string, so the rule matches the exact file the package resolves to. The alias then points the bare import name `snapsvg` at that same file, which is why the import in your own module stays short:

import Snap from 'snapsvg';

The README states this works with webpack 2.x and 3.x and does not cover later versions, so if your project is on a newer bundler you are on your own with the loader options. That is a tooling migration, not an animation problem.

Building from source still runs through Grunt 0.4.0

Snap.svg builds with Grunt, and the README is explicit that it uses Grunt 0.4.0, adding that you may want to reread the Grunt documentation if you have not upgraded in a while. The sequence is the familiar one: install the CLI globally, install the project's dependencies, then run the task.

cd Snap.svg
npm install -g grunt-cli
npm install
grunt

Output lands in the `dist` folder, which is the same folder the CDN and manual-download links point at. During development `grunt watch` reruns the build when a source file changes.

The `package.json` devDependencies match those instructions and add a few names that date the setup: `grunt-contrib-uglify` for the minified build, `grunt-contrib-concat` for joining sources, `grunt-exec` for shelling out, `grunt-prettify`, `dr.js`, plus `mocha`, `expect.js` and `eslint`. The eslint block in the same file disables a long list of rules, including `eqeqeq`, `camelcase`, `no-underscore-dangle` and `strict`, which is a reasonable concession to a library written in an older style and a clear signal about how you will read the source.

Tests run through PhantomJS and a browser page

The testing story is short and entirely browser based. Tests live in the `test` folder, and the documented way to run them is to open `test.html` in a browser. The automatic run scrapes that page with PhantomJS, and the README offers the alternative of installing PhantomJS yourself and running:

grunt test

PhantomJS has been a dormant project for years, and the build badge at the top of the README still points at `travis-ci.org`, a host that has been retired. Neither fact means the test suite is broken, since `test.html` remains runnable by hand, but it does mean the continuous integration described in the README describes a pipeline you would have to rebuild before you could rely on it.

The contribution path has the same vintage. Before opening a pull request you fill out a CLA hosted on snapsvg.io, fork the repository, create a branch, and push it. The rule at the end is specific: pull requests to branches other than `dev`, or without a filled CLA, are not accepted.

git checkout -b my_branch
git push origin my_branch

Knowing that `dev` is the merge target matters if you build automation around the repository, since the default branch is `master`. The last push to the repository was on 2026-06-12.

Where Snap.svg fits against plain SVG DOM code

The honest comparison is not with a framework. Snap.svg is a convenience layer over the SVG DOM, and its value is that it hides the verbosity of `setAttribute` calls and chain method calls the way jQuery did for HTML. If you only need to change a fill colour on hover, three lines of vanilla DOM code are cheaper than adding a dependency.

The case for the library gets stronger once you are animating. Snap gives you easing, matrices, and an event layer through `eve`, and it treats groups, paths and text as first-class objects rather than as attribute bags. For a hero animation, an icon set that reacts to scroll, or a diagram that needs motion along a path, that structure saves more than the dependency costs.

The comparison with a modern animation library is where the age shows. Those tools are usually built around requestAnimationFrame, promise-based timelines and a transform model that batches writes, while Snap.svg drives SVG attributes directly. If you need to animate many elements at once under a frame budget, or you need scroll-linked motion, you are working against the grain of this library. The README itself defers almost everything beyond installation to snapsvg.io, which hosts an About page, a Getting Started page, an API reference and a Slack room, so the API detail is documented off-repository rather than in the file you are reading.

Editorial conclusion

Snap.svg still makes sense if you inherited a project that already uses it, or if you want the Snap chainable style over inline SVG without pulling in a framework. For a new project, check the version first: package.json says 0.5.1, the build is Grunt 0.4.0, the test path runs PhantomJS, and the bundler instructions stop at webpack 3, so budget time for tooling work rather than for the animation code itself. The `dist/` build in the repository is what most pages actually load, and snapsvg.io holds the API reference the README points to.

Frequently asked questions

Official sources

1. adobe-webplatform/Snap.svg on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README