I just got back from the Web Directions Dev Summit in Sydney, and if I hear the word “framework” one more time I might throw my MacBook into the harbour. The thing worth talking about is CSS Scroll-Driven Animations. Somewhere along the way it became normal to ship 50KB of JavaScript just to move a div when someone scrolls. That is a Rube Goldberg machine, it wrecks performance, and it is lazy architecture.
At the summit, John Allsopp talked about front-end development hitting a “local maximum.” We lean on our toolkits so hard that we have lost track of what modern browsers do natively. After 14 years in the WordPress trenches I have watched this cycle a few times: we over-engineer a solution, then the platform makes the hack obsolete. Scroll effects are at that point right now.
Why native logic beats the main thread
Traditional JS scroll libraries compete for resources on the main thread. CSS Scroll-Driven Animations hand the work to the compositor thread instead, so a heavy WooCommerce checkout or a slow API call can choke the main thread and the animation still runs smoothly. That resilience is the reason to switch, not the novelty of a new feature.
As I noted in my previous post on native scroll-based animations, dropping heavy JS libraries has become a performance requirement in 2025 rather than a matter of taste.
The old naive approach
// 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 CSS scroll-driven animations version
Instead of a listener that fires 60 times a second, you declare a scroll-timeline and let the browser map animation progress straight to scroll position, with no JS logic involved.
/* 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();
}The official MDN Scroll-Driven Animations guide has the detailed specs.
AI and accessibility
Jono Alderson argued at the summit that frameworks like React are the DVD-by-mail era of Netflix: we are still posting discs when we could stream. That lands for WordPress devs too. We keep adding blocks and plugins for problems the browser already solved. Modern CSS logic is winning in 2025 mostly because it removes the moving parts that break during core updates.
Accessibility is the other half of this. Beau Vass gave a sobering talk on how automated tools create a false sense of accessibility. AI will happily generate animation-timeline code, but it has no idea whether your scrollytelling is making a neurodiverse user motion sick. That check belongs at the start of a build rather than as a topping added at the end. If you use CSS for scroll effects, wrap them in a prefers-reduced-motion media query every single time.
If CSS scroll-driven animations are eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
Stop over-engineering
The postcard from this summit: the web is getting faster, as long as we stop standing in our own way. Reaching for an npm package should not be a reflex. Check the CanIUse stats for scroll-driven animations before you pull in another library, because the platform may already ship exactly what you need.
Ship cleaner code and cut the dependencies you do not need, so your time goes to user friction instead of a race condition in a scroll listener.
