Anime.js v4: A JavaScript Animation Engine for DOM, SVG and Objects

What Anime.js animates, and who reaches for it

Anime.js targets one specific gap: animation that spans several kinds of target at once. The README states that it "works with CSS properties, SVG, DOM attributes and JavaScript Objects." That is a wider surface than a CSS transition library covers, and a narrower one than a full rendering engine. If your motion lives entirely in CSS, you do not need it. If your motion is a value that multiple elements read from, such as a shared progress number driving several transforms, the JavaScript object target is the part that matters.

The audience is front-end engineers who want imperative control over timing. The package keywords list timer, timeline, animatable, draggable, scope, engine, scroll, easings, cubic-bezier, spring, splitText, CSS, SVG, WAAPI, Canvas and WebGL, which sketches the intended scope better than the README prose does. The examples directory backs that up: there are folders for canvas-2d, threejs, svg-line-drawing, svg-graph, text, draggable-playground and several timeline stress tests. That range is the honest description of the project. It is a general motion engine, not a CSS helper.

The v4 module surface and the animate() call

V4 is built around named imports from the animejs package. The README gives this example, and it is the clearest statement of the API shape in the repository:

import {
  animate,
  stagger,
} from 'animejs';

animate('.square', {
  x: 320,
  rotate: { from: -180 },
  duration: 1250,
  delay: stagger(65, { from: 'center' }),
  ease: 'inOutQuint',
  loop: true,
  alternate: true
});

Read that call carefully, because it encodes the design. The first argument is a selector, so the engine resolves DOM nodes itself. The second is a configuration object where each key is either a property to animate (x, rotate) or a control parameter (duration, delay, ease, loop, alternate). The from syntax on rotate sets a starting value rather than a target, and stagger with from: 'center' distributes the delay outward from the middle of the matched set. That single object is the whole mental model. There is no chain of setter calls and no separate timeline object in the basic case.

Timelines exist as a separate concept, and the package exports map confirms the engine is split into submodules: the root entry plus ./timer and ./animation, each with its own types, require and import targets. So you can import the timer alone if you only need scheduling. The exports map is also where the practical constraint lives, which the next section covers.

Installing Anime.js and animating your first element

The README does not spell out a consumer install command; it points to the V4 documentation at animejs.com and shows the import. The package name on npm is animejs, and the repository uses npm for its own tooling: the README says to run npm i first, then the development scripts with npm run <script>. For a consuming project the install is the standard npm form:

npm install animejs

Then import the pieces you need. The example below is a first real use: a square element moved along x with a staggered delay. Save it as an ES module and load it from a page that has at least one element matching the selector.

import { animate, stagger } from 'animejs';

animate('.square', {
  x: 320,
  rotate: { from: -180 },
  duration: 1250,
  delay: stagger(65, { from: 'center' }),
  ease: 'inOutQuint',
  loop: true,
  alternate: true
});

What you should see: every matched element translates 320 pixels on x and rotates from -180 degrees, over 1250 milliseconds, with the middle element starting first and the delay spreading outward at 65 milliseconds per step. The loop and alternate flags make it run forward and back indefinitely. If nothing moves, the usual cause is that the script ran before the elements existed, since the selector is resolved when animate is called.

For a no-build page, package.json declares jsdelivr and unpkg fields pointing at ./dist/bundles/anime.umd.min.js, so a UMD bundle is published. The README does not show the script-tag form, so check the documentation before wiring that up.

The repository's own workflow, for anyone working on the library rather than with it:

npm i
npm run dev

The dev script watches src/**/*.js, bundles the ESM version to lib/ and writes type declarations to types/. Other scripts listed in the README are build, dev:test, test:browser, test:node and open:examples.

Where the exports map and module type will bite you

The package is declared "type": "module" with a main of ./dist/modules/index.cjs and a module of ./dist/modules/index.js. The exports field gives the root entry four conditions: types, require, import and default, with default falling back to the CJS build. Submodules ./timer and ./animation follow the same pattern. This is a correct dual-package setup, and it is also the most likely source of a first-hour problem.

If your toolchain predates exports-map support, or if a test runner resolves through main rather than exports, you can end up loading the CJS build in one place and the ESM build in another. Two copies of the library in one page means two independent engines, and animations registered against one will not be visible to the other. The symptom is not an error; it is animation that starts and never advances, or a timeline that ignores a callback. Check your bundler's resolution before you assume the library is at fault.

The second constraint is that the published package ships only dist. The files field is ["dist"], so the src directory is not in the tarball. You cannot patch a single source file inside node_modules and expect it to survive a reinstall, and you cannot import from a deep src path. Everything you consume comes through the exports map or the UMD bundle.

V3 to V4 is a rewrite, not a version bump

The README links a dedicated page titled "Migrating from v3 to v4" on the repository wiki. The existence of that page, and the fact that the v4 README's only code example uses named imports of animate and stagger rather than a default export, tells you the API changed shape. The v4 entry point is a set of named functions, and the animation description is a configuration object with a from key for start values.

This is the real cost of adopting the project today. Any existing v3 code in your repository will need to be rewritten call by call, and the migration guide is where the mapping lives. The README does not enumerate the breaking changes itself, so the wiki page is not optional reading; it is the only migration reference the project supplies.

There is a mitigation worth noting. Because the published artifacts are ESM, UMD, CJS and IIFE builds under dist, a legacy page can keep running against the UMD bundle while new code uses the module build. The README does not document that as a supported migration path, so treat it as a bundling decision you make yourself rather than a guarantee from the project.

When Anime.js is the wrong tool

Anime.js is imperative. You call animate with a selector and a configuration object, and the engine mutates the matched elements. It does not derive motion from your application state, and it does not re-run when a component re-renders. In a framework where the DOM is owned by a renderer, that means the animation engine and the renderer are both writing to the same attributes. The README says nothing about framework integration, and the examples directory contains no React, Vue or Svelte example, so there is no documented pattern to copy.

If your motion is a function of state, a declarative animation layer that participates in the render cycle will fit better, and you should not adopt Anime.js for that job. The same applies if your animation needs are limited to hover states and page transitions that CSS handles. Pulling in a JavaScript engine to do what a transition property already does adds a dependency and a resolution problem for no gain.

The other boundary is lifecycle. The README does not document how to cancel or dispose a running animation, and it does not document what happens to animations whose target elements are removed from the DOM. If your UI mounts and unmounts elements frequently, verify that behaviour on animejs.com before you build on it. The examples include a timeline stress test and a 50K star timeline, which suggests the project cares about throughput, but throughput is not the same as teardown correctness.

Anime.js against a declarative motion library

The natural alternative is a declarative animation library for a component framework, where motion is expressed as props on a component and the library subscribes to the render cycle. The difference in approach is where the animation state lives. In Anime.js, state lives inside the engine and is addressed by selector or target reference; the configuration object you pass to animate is a one-time description, and the engine owns the clock from then on. In a declarative library, the target values come from your component's props, and the library interpolates toward whatever the current props say.

That distinction decides most adoption questions. If your animation values are computed at runtime and change often, the declarative model avoids the bookkeeping of restarting an imperative animation on every change. If your animation is a self-contained sequence, an intro, a logo animation, a scroll-driven SVG draw, the imperative model is simpler because there is no state to synchronize. The repository's own examples sit firmly on the second side: an animejs-v4-logo-animation, an svg-line-drawing, a typewriter, a set of scroll-driven scopes.

A second alternative is the browser's own Web Animations API, which package.json lists among the keywords, implying Anime.js builds on or interoperates with it. If your needs fit WAAPI directly, you avoid a dependency entirely. Anime.js earns its place when you need stagger, timelines, SVG attribute animation and object animation in one consistent API, which WAAPI does not cover uniformly.

Licence, maintenance and the upgrade bill

Anime.js is MIT licensed, stated in package.json and linked from the README as LICENSE.md. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence obligation; this is not legal advice, and if you vendor or fork the code you should confirm the notice survives in your distribution.

The repository is not archived, and the last push was on 2026-06-22, which is the same date as the v4.5.0 release. The two prior releases, v4.4.0 and v4.4.1, landed on 2026-04-29 and 2026-04-30, so the release cadence over that window is a patch pair followed by a minor bump roughly seven weeks later. The README notes that the project is funded through GitHub Sponsors and calls itself "100% free." Sponsorship is the sustainability model, not a paid tier, so there is no commercial support contract attached to adoption.

The upgrade cost you should budget for is the v3 to v4 migration, not future minor versions. The 4.4.x to 4.5.0 step is a minor release within the same major line, which is the cheap kind of upgrade. The expensive one already happened, and if you are on v3 you are paying it before you start.

Editorial conclusion

Adopt Anime.js if you need one animation API across DOM, SVG and plain JavaScript objects, and you are starting on v4 or can absorb the v3 to v4 migration. Do not adopt it if you need a declarative, state-driven animation layer or a component-scoped styling system; Anime.js is imperative and does not track your framework's render state. Before committing, verify three things: that your bundler resolves the exports map in package.json (the package is type module with separate require and import entries), that every animation call in your existing code matches the v4 API rather than the v3 one, and that the specific SVG or Canvas behaviour you depend on is documented on animejs.com, since the README itself documents almost nothing beyond a single example.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes