I just got back from the Web Directions Dev Summit in Sydney, and if I hear the word “framework” one more time, I might actually throw my MacBook into the harbour. We need to talk about CSS Scroll-Driven Animations. For some reason, the industry standard has become building Rube Goldberg machines with 50KB of JavaScript just to move a div when someone scrolls. It’s killing performance, and frankly, it’s lazy architecture.
At the summit, John Allsopp talked about reaching a “local maximum” in front-end development. We’ve become so reliant on our toolkits that we’ve lost touch with what modern browsers can actually do natively. I’ve spent 14 years in the WordPress trenches, and I’ve seen this cycle before—we over-engineer a solution until the platform eventually makes our “hacks” obsolete. That is exactly what is happening with scroll effects right now.
Why Native Logic Beats the Main Thread
The problem with traditional JS-based scroll libraries is that they fight for resources on the main thread. When you use CSS Scroll-Driven Animations, the heavy lifting happens on the compositor thread. This means even if your main thread is choked by a heavy WooCommerce checkout or a massive API call, your animations stay buttery smooth. It’s not just about “shiny new features”; it’s about building resilient, high-performance interfaces.
As I noted in my previous post on native scroll-based animations, ditching heavy JS libraries isn’t just a preference—it’s a performance requirement in 2025.
The Old Naive Approach (JS Bloat)
// The main thread killer
window.addEventListener('scroll', () => {
const scroll = window.scrollY;
const element = document.querySelector('.hero-image');
element.style.transform = `translateY(${scroll * 0.5}px)`;
});The Senior Approach: CSS Scroll-Driven Animations
Instead of a listener that fires 60 times a second, we define a scroll-timeline. This allows the browser to map the animation progress directly to the scroll position without a single line of JS logic.
/* Zero JS, Zero Main Thread usage */
@keyframes parallax-up {
from { transform: translateY(0); }
to { transform: translateY(-100px); }
}
.hero-image {
animation: parallax-up linear both;
animation-timeline: scroll();
}You can find more detailed specs on this in the official MDN Scroll-Driven Animations guide.
The Architect’s Critique: AI and Accessibility
During the summit, Jono Alderson argued that frameworks like React are essentially Netflix’s “DVD-by-mail” era—we’re still sending discs when we could be streaming. This rings true for WordPress devs too. We keep adding blocks and plugins that solve problems the browser has already solved natively. Specifically, modern CSS logic is winning in 2025 because it reduces the “moving parts” that break during core updates.
But we can’t talk about progress without talking about accessibility. Beau Vass gave a sobering talk on how automated tools often create a “false sense of accessibility.” AI might be great at generating animation-timeline code, but it doesn’t know if your scrollytelling is inducing motion sickness for a neurodiverse user. Accessibility isn’t a “froghurt topping” you add at the end; it’s the foundation. If you use CSS for scroll effects, always wrap them in a prefers-reduced-motion media query. No exceptions.
Look, if this CSS Scroll-Driven Animations stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Takeaway: Stop Over-Engineering
The “Postcard” from this summit is clear: the web is getting faster, but only if we stop standing in our own way. We need to stop reaching for npm packages as a reflex. Before you pull in another library, check the CanIUse stats for scroll-driven animations. You might find that the platform has already built exactly what you need.
Ship cleaner code, reduce your transient dependencies, and focus on the problems that actually matter—like solving user friction, not debugging a race condition in a scroll listener. Let’s get back to basics.
