DEV Community

Cover image for One year of GSAP being completely free, what changed in the web ?
Ismail Kitmane
Ismail Kitmane

Posted on

One year of GSAP being completely free, what changed in the web ?

In 2025 something unusual happened in the front end ecosystem.

The entire GSAP ecosystem became free. Plugins that had been locked behind paid licenses suddenly became accessible to everyone. That included tools like ScrollTrigger, MorphSVG and SplitText.

For years these tools were mostly used by agencies and studios that could justify the license.

When the paywall disappeared, many expected a major shift in how web animations are built.

And in some ways that did happen.

But not where most people expected.

Adoption Actually Did Explode

If you look at npm statistics, GSAP usage increased significantly after the license change.

It now sits around 2 to 2.1 million downloads per week, which is extremely high for a specialized animation engine.

Image of GSAP's page on npmjs.com

That number alone shows something important.

Developers are installing it.

They are experimenting with it.

They are shipping it in projects.

But when you browse the web, you rarely encounter sites that fully use what GSAP enables.

The gap between installation and visible usage is surprisingly large.

Most Sites Still Animate the Same Way

Despite the adoption numbers, the majority of websites still animate in a very limited way.

Typical animation patterns remain simple:

  • fade in on scroll
  • small translateY entrances
  • hover scale effects
  • simple page transitions

These patterns can be done with CSS alone.

Which means the full orchestration power of GSAP is rarely used.

And the most interesting part is that GSAP is not really designed for those small interactions.

Its real strength appears when animations become systems.

GSAP Is Built for Orchestration

Most animation tools think in terms of individual transitions.

Element appears. Animate.

User clicks something. Animate.

GSAP encourages something very different.

It encourages building timelines where multiple pieces move together.

const tl = gsap.timeline()

tl.from(".hero-title", { y: 80, opacity: 0 })
  .from(".hero-illustration", { scale: 0.8 }, "-=0.3")
  .from(".hero-cta", { opacity: 0 })
Enter fullscreen mode Exit fullscreen mode

That structure becomes far more powerful when applied to SVG.

Complex vector graphics can be broken into pieces and orchestrated like scenes in a film.

This is where GSAP becomes something closer to a motion engine than an animation helper.

The Untapped Power of SVG Storytelling

SVG animation is where GSAP becomes extremely interesting.

You can animate:

  • paths
  • shapes
  • masks
  • morphs
  • entire illustrations

And synchronize them with scroll or timelines.

This opens the door to a style of interface that feels closer to visual storytelling than traditional web pages.

In a world of short attention spans, storytelling matters more than ever.

Landing pages increasingly behave like narratives.

A user scrolls and the product reveals itself piece by piece.

Concepts appear visually instead of through long paragraphs.

Many of the most memorable product pages follow this pattern.

But most teams building those experiences are not using pure GSAP + SVG pipelines.

The Tools Companies Actually Use

When companies want visual storytelling, they usually choose tools like:

  • Rive
  • Slider Revolution

These tools offer something developers often underestimate.

A visual timeline interface.

Designers can build motion without writing code.

But these tools come with tradeoffs.

Rive runs its own runtime and rendering engine.

Slider Revolution produces extremely heavy outputs.

In both cases the resulting payload can become large and opaque.

Ironically, the browser already has a perfect rendering format for vector animation.

SVG.

And GSAP already knows how to orchestrate it.

The Missing Tool

What does not really exist yet is a bridge between those worlds.

Imagine something like this:

A visual animation editor similar to Rive.

But instead of exporting a proprietary runtime, it exports:

  • pure SVG
  • GSAP timelines

The output would be transparent.

Readable.

Native to the web platform.

Developers could tweak the timeline directly in code.

Designers could build the animation visually.

Right now the ecosystem is split between:

developer driven motion systems
and
designer driven animation tools

A graphical timeline editor that outputs GSAP + SVG could connect both worlds.

Why This Matters

Landing pages are evolving.

Static pages are less effective in environments where attention spans are measured in seconds.

Motion driven storytelling is becoming one of the most powerful ways to communicate complex ideas quickly.

Yet the tools used to create those experiences are often heavier than necessary.

The web already has:

  • SVG for vector graphics
  • GSAP for orchestration
  • modern browsers capable of smooth animation

What it lacks is the design interface layer that makes these systems accessible.

One Year Later

Almost a year after GSAP became free, adoption numbers show strong developer interest.

But the web itself still looks mostly the same.

The real potential of orchestrated SVG storytelling is still largely untapped.

Which raises an interesting question.

If the engine already exists, and millions of developers already have it installed…

maybe the next big shift in web animation will not come from another library.

Maybe it will come from the tool that makes GSAP visual.

Top comments (0)