Scroll-driven everything

---

title: "Scroll-driven everything" date: "2026-05-30" summary: "Why this portfolio uses sticky pinned sections and useScroll for almost every animation — and where that pattern breaks down."

Every section on this site has a different relationship with the scroll wheel.

• The hero's dot mesh tilts and fades based on scroll progress while a Lenis loop smooths the inertia.
• The about section pins itself and reveals paragraphs at scroll-progress thresholds.
• Skills move horizontally as their row enters and leaves the viewport.
• Projects pin and crossfade card-by-card.
• Journey pins and translates a horizontal track.

That's a lot of useScroll calls.

Why pinned sections

Standard reveal-on-enter animations are fine for documents. They're a poor fit for a portfolio that wants to feel like a designed experience. Pinning a section lets you re-use a single viewport's worth of attention for a small story: the user looks once, and as they scroll, you change what they're looking at.

The cost: you spend scroll budget. A 200vh sticky section eats 100vh of "extra" scroll. Use too many and the site starts feeling like a long elevator pitch.

Where it breaks

• Touch devices. Pinned sections work, but the perceived scroll speed is jankier without a smooth-scroll library, and the gesture vocabulary is different.
• Reduced motion. Anyone with prefers-reduced-motion: reduce needs a flat version. Build it from day one — don't bolt it on.
• Keyboard scroll. Arrow keys jump 100px chunks. Tab inside a pinned section can teleport focus outside it. Test with a keyboard early.

The pattern is great when each pinned section earns its keep. When in doubt, ship the regular version.