dotLottie Web

dotLottie Web is LottieFiles’ official browser player for both classic Lottie .json animations and the newer .lottie archive format, built on a Rust + WASM core (dotlottie-rs) shared with the iOS, Android, and native players. Rendering goes through ThorVG, a vector-graphics engine with the broadest Lottie feature coverage of any web renderer, exposed through Canvas2D, WebGL2, or experimental WebGPU backends behind a single DotLottie API.

The repo is a monorepo whose core vanilla-JS package (@lottiefiles/dotlottie-web) is wrapped by first-party React, Vue, Svelte, Solid, and Web Component packages, plus a DotLottieWorker variant that renders off the main thread via OffscreenCanvas for smooth performance with many concurrent animations.

What You Get

• A single DotLottie class that plays both .json Lottie and .lottie archive formats
• Three swappable rendering backends — Software (Canvas2D), WebGL2, and experimental WebGPU
• DotLottieWorker for off-main-thread rendering via Web Workers and OffscreenCanvas
• First-party dotLottie v2 support for theming, interactive state machines, and embedded audio
• Official wrapper packages for React, Vue, Svelte, Solid, and native Web Components

Common Use Cases

• Rendering marketing/product animations exported from After Effects (via Lottie) directly in the browser
• Building interactive onboarding or micro-interaction animations driven by dotLottie v2 state machines
• Rendering dozens of small animations (icons, loaders) off the main thread with DotLottieWorker to avoid jank
• Shipping the same animation asset across iOS, Android, and web via the shared dotlottie-rs engine

Under The Hood

Architecture: packages/web/src/dotlottie.ts wraps a Rust-compiled WASM module (loaded via wasm-loader.ts) that does the actual Lottie/dotLottie parsing and ThorVG rendering; the JS layer’s job is orchestrating canvas/WebGL/WebGPU context setup (src/webgl, src/webgpu), an event-manager.ts for playback events, and an animation-frame-manager.ts driving the render loop. DotLottieWorker (src/worker) re-hosts the same engine inside a Web Worker using OffscreenCanvas, keeping the public API identical between main-thread and worker rendering.

Tech Stack: TypeScript for the JS SDK layer over a Rust + WASM core (dotlottie-rs, a sibling repo) with ThorVG as the underlying vector-graphics renderer; builds use tsdown/Rolldown with a custom inline-worker plugin (rolldown-plugins/plugin-inline-worker.ts) to bundle the worker script alongside the WASM binary.

Code Quality: The web package has a dedicated Vitest suite (tests/dotlottie.test.ts, tests/worker-canvas-adoption.test.ts, tests/wasm-loader.test.ts, plus Node-specific variants) covering WASM loading, worker/canvas handoff, and the inline-worker build plugin — an unusually thorough test surface for a graphics library, reflecting the complexity of coordinating three rendering backends and a worker mode.

API Design: The public surface centers on one class (new DotLottie({canvas, src})) with the same shape whether targeting Canvas2D, WebGL2, or a Web Worker — switching backends is a one-line import change per the README — while advanced dotLottie v2 features (themes, state machines, audio) stay declarative in the .lottie file rather than requiring extra JS wiring.