loke.dev
Header image for Refactoring Legacy CSS: Replacing JS Hacks with Modern Features
css frontend-development refactoring web-standards

Refactoring Legacy CSS: Replacing JS Hacks with Modern Features

Modern CSS features allow you to ditch bloated JS dependencies. Learn how to refactor your legacy stack using container queries, :has(), and native animations.

Published 4 min read

Your console is screaming. ResizeObserver is loop-crashing because your layout logic is fighting your state management. You’re shipping another 40KB of JavaScript just to toggle a .is-active class when a checkbox gets clicked.

Stop it. It’s 2026. The browser isn't a blank canvas waiting for your scripts to paint pixels; it’s a high-performance, declarative engine.

We spent a decade treating CSS as a glorified skin for JS frameworks. We bloated bundles with responsive grids reliant on window.resize listeners and convinced ourselves that managing UI state in JS was the only way to be "modern." We were wrong.

The Migration Tax: Auditing Your Component Debt

Open your src/components folder. Find that accordion or navigation menu you wrote in 2022. Count the lines dedicated to toggling classes. If you’re checking if (element.classList.contains('open')), you’re paying a massive performance tax. You’ve offloaded logic that belongs in the browser's C++ rendering engine onto the main thread.

The path forward isn't adding another utility library. It’s stripping the abstraction layer to reveal the browser features waiting underneath.

Why CSS Container Queries Outperform ResizeObserver

In the jQuery era, if you wanted a card to change layout based on where it lived rather than the viewport, you had to attach an IntersectionObserver or a ResizeObserver to every instance. It was performant suicide.

Now, we have CSS container queries. You define a context, and the component responds to its immediate environment. It’s intrinsic design.

The Old Way (The Heavy Lift):

const observer = new ResizeObserver(entries => {
  entries.forEach(entry => {
    if (entry.contentRect.width < 400) {
      entry.target.classList.add('is-compact');
    } else {
      entry.target.classList.remove('is-compact');
    }
  });
});
observer.observe(document.querySelector('.card'));

The New Way (Native & Declarative):

.card-container {
  container-type: inline-size;
}

@container (width < 400px) {
  .card {
    grid-template-columns: 1fr;
  }
}

The browser handles the math. No ResizeObserver loops. No layout thrashing. Zero JavaScript execution during the resize event.

Killing State Toggles with :has()

I hear the argument constantly: "I need JS to style the parent when the child state changes!"

No, you don't. The :has() selector is the most transformative feature added to CSS in years. It allows you to peer up the DOM tree and style a container based on its descendants.

Want a parent card to glow when a checkbox inside is checked?

.card:has(input[type="checkbox"]:checked) {
  border: 2px solid var(--accent-color);
  background: var(--active-bg);
}

You aren't writing logic; you're writing relationships. By removing the JS toggle, you eliminate an entire class of "sync" bugs where the UI state drifts from the data model. It’s significantly harder to break a selector than it is to break a state-syncing function.

Fluid UI Logic: Beyond Tailwind

People argue that Tailwind makes typography "fast." It doesn't. Writing text-xs md:text-sm lg:text-base isn't design; it’s manual labor.

We can define the relationship between fluid font sizes mathematically using clamp().

h1 {
  font-size: clamp(1.5rem, 5vw + 1rem, 3rem);
}

Utility classes force you into global breakpoints. clamp() lets the browser resolve fluid typography based on available space. It’s cleaner, it avoids the 50KB utility dump, and it works at the component level. A header in a sidebar should scale differently than a hero header. Stop fighting the browser's ability to do math.

View Transitions vs. JS Libraries

When I see projects importing Framer Motion just to animate a route change or a DOM list reorder, I see a lack of trust in the browser. The View Transitions API is the standard now. It handles snapshots, morphing, and layout changes on the compositor thread.

If you're using JS for layout-shifting animations, you're losing. The browser can handle the interpolation.

@view-transition {
  navigation: auto;
}

.item {
  view-transition-name: item-1;
}

Combine this with animation-timeline: scroll() and you’ve moved the logic off the main thread entirely. If your animation library isn't hitting the compositor, it’s a bottleneck.

Reframing the "Specificity War"

Developers cling to heavy frameworks because they fear the "Specificity War." They think that without a system, CSS becomes a chaotic mess of !important tags.

That’s a failure of architecture, not CSS. Use CSS Cascade Layers (@layer). Define an order of precedence.

@layer reset, base, components, utilities;

@layer reset { /* Global resets */ }
@layer base { /* Typography */ }
@layer components { .card { ... } }
@layer utilities { .text-bold { font-weight: bold; } }

Explicitly define your layers. Stop fighting the cascade and start controlling it. You don't need a framework to keep styles sane; you need to understand how the browser resolves them.

Stop reaching for npm install every time you see a UI requirement. We’ve reached a point where the platform is more capable than the libraries built to patch its old holes. If you're still relying on massive dependencies for layout and state, you're just adding a layer of rust to your codebase.

Resources