← Writing
post

Reach for CSS before JavaScript

A running list of interactions I used to build in JavaScript and now hand to the browser instead.

Most of the JavaScript I've deleted over the years had one thing in common: the platform grew a way to do it natively, and I hadn't noticed. The browser is a faster, more accessible, more resilient runtime than anything I'll ship on top of it. So the question I ask first is now: can CSS do this?

Sticky headers

Years of scroll listeners, replaced by one line:

.toolbar {
	position: sticky;
	top: 0;
}

No layout thrash, no requestAnimationFrame, no listener to clean up.

Reveal-on-scroll

IntersectionObserver is fine, but for the common case there's now animation-timeline:

@media (prefers-reduced-motion: no-preference) {
	.card {
		animation: fade-in linear both;
		animation-timeline: view();
		animation-range: entry 0% cover 30%;
	}
}

The best interaction code is the code you didn't have to write — because it can't have a bug you didn't ship.

When to stop

CSS isn't always the answer. State that outlives a paint, anything that needs to be announced to assistive tech deliberately, coordination across components — that's still JavaScript's job. The point isn't purity. It's asking the cheaper question first.

#css#performance#frontend