I use Lenis for smooth scroll in most of my projects, and I'd always assumed it just won a popularity contest against Locomotive Scroll — more stars, more downloads, moved on. So I went looking for the actual reason. What I found was more interesting than "it's more popular," and it ends with a twist I didn't expect.
For years, most smooth-scroll libraries — including older versions of Locomotive Scroll — used what's basically a clever hack: fix a wrapper element, then apply a CSS transform to it on every frame, based on an eased scroll value. It looks smooth. It works.
It also means the page never actually scrolls. The browser's real scroll position stays put; you're just visually translating content around.
That hack quietly breaks a handful of things developers don't notice until they ship: position: sticky — stops working correctly, because the element isn't really moving through a real scroll container scroll-snap — same problem Native browser search (Ctrl+F) and anchor links — can behave unpredictably when the "scroll" is fake Screen readers and accessibility tooling — lose meaningful context GPU load — large, repeated transforms aren't free
Lenis took a different approach on purpose: keep the browser's real, native scroll active, and layer interpolation on top of it — actual scrollTo calls, eased, not a transform illusion. From Lenis's own site:
"What began as an internal tool for syncing WebGL and the DOM is now the default smooth scroll across the industry — even powering libraries like Locomotive Scroll. The smoothness was a happy accident."
That's the origin story, by the way — Lenis wasn't built to "win" the smooth-scroll library wars. It was an internal tool at a WebGL agency (darkroom.engineering) for syncing DOM scroll with WebGL canvases, and the smooth-scroll behavior came along for the ride.
Here's the part that surprised me. I went looking for a "Locomotive Scroll vs Lenis, which is better" comparison. What I found instead: Locomotive Scroll v5 is built on top of Lenis.
Not "inspired by." Not "similar architecture." Built on it. Their own release notes say it directly:
"Version 5 is a complete rewrite of Locomotive Scroll, now built on top of Lenis."
And their docs summarize their own history bluntly: "This library has evolved considerably over the years. From jQuery to vanilla ES6, from custom engines to Lenis foundation."
The reasons they list for the rewrite read like a direct admission of the exact problems the old transform-hack approach caused: "No more greedy CSS transforms breaking your layouts" "Works perfectly with position: sticky — No conflicts, no workarounds" Bundle size dropped from ~12.1kB to 9.4kB gzipped
This isn't really a story about one library beating another. It's a story about the ecosystem converging on a better-solved primitive. Locomotive didn't lose — they made the pragmatic call to stop maintaining their own lower-level scroll engine (which had real, filed bugs — GitHub issues #519 and #532, among others) and build their higher-level features (parallax, intersection detection) on top of infrastructure the community had already gotten right.
For context on scale: Lenis sits at roughly 14k GitHub stars with 35 contributors, npm downloads growing from ~93k/month to ~343k/month over the past year. Locomotive Scroll has ~8.6k stars, 25 contributors. Not a landslide — but a clear enough gap that "we'll build on the leader" made sense for Locomotive's team.
While Lenis and GSAP's ScrollTrigger were winning their category, the browser itself started doing some of this natively. CSS now has animation-timeline: scroll() and animation-timeline: view() — scroll-driven animations with zero JavaScript.
Chrome's had full support since 2023. Safari joined in September 2025. And this is real enough that a design agency wrote publicly: "We've removed framer-motion from three client sites this year because of them [native scroll-driven animations]." That's not a hypothetical threat — that's a JS animation library actually getting removed from production sites.
But — and this is the part that matters — it's not a clean "native CSS wins" story either. The nuance, well put by one source I found:
"Use native CSS when the animation is linear, depends on scroll or viewport position, and doesn't require programmatic timeline control (play, pause, reverse, scrub) or complex sequencing. GSAP remains necessary for advanced animation sequencing, reverse timelines with speed control, and custom physics."