DEV Community

Cover image for Before You Reach for a Tool, Ask: Can CSS Do This Already?
John Munn
John Munn

Posted on

Before You Reach for a Tool, Ask: Can CSS Do This Already?

#css #webdev #frontend #performance

We’ve spent the last decade building abstraction on top of abstraction. CSS-in-JS, utility-first frameworks, custom design tokens. But somewhere along the way, we started treating CSS itself like a problem to be solved.

And yet, the fundamentals we learned when border-radius still needed a prefix? They’re quietly solving problems that modern tooling still fumbles.

This isn’t nostalgia. It’s about recognizing when the foundational tool does the job better than the layers stacked on top of it.

🎯 Why This Matters Now

Every framework promises to fix CSS. But what if CSS wasn’t broken? What if we just never learned how to use it properly?

When you stop fighting the browser and start working with it, weird things happen. Layouts get easier. Runtime cost disappears. You fix complexity without JavaScript.

This is about fluency. Not purity. Not “just write more CSS.” But knowing when the platform already has the answer—and when that answer is better than your abstraction.

🔧 The Cascade (Yes, Still That)

The Problem: Component styles leaking everywhere.

The Modern Fix: CSS-in-JS, style scoping, runtime wrappers.

The Simpler Fix: Learn the cascade. Use custom properties.

I once tried to fix a button color override in a component library. My one-line change spiraled into an hour of specificity wars. Inline styles, !important, runtime class merging—it all added up to a 200-line diff that still didn’t feel stable.

With custom properties and layered styles, I could’ve handled it in four lines. No bundler config. No cascade hacks. Just variables and intent.

.card {
  --card-padding: 1rem;
  --card-bg: white;
  --card-border: #e5e7eb;
}
.card-compact {
  --card-padding: 0.5rem;
}
.card-dark {
  --card-bg: #1f2937;
  --card-border: #374151;
}
.card {
  padding: var(--card-padding);
  background: var(--card-bg);
  border: 1px solid var(--card-border);
}
Enter fullscreen mode Exit fullscreen mode

Why It Works: The cascade isn’t a bug. It’s inheritance with intention. You don’t need runtime scoping when CSS already gives you variables, overrides, and context-aware defaults—for free.

📐 Grid, Not Just Flex

The Problem: Layouts that sprawl across files, require a PhD to refactor, and bloat your markup with utility soup.

The Modern Fix: Utility classes, layout components, useResizeObserver.

The Simpler Fix: Grid. Seriously.

I once inherited a dashboard layout that required 47 utility classes per row. One breakpoint tweak meant searching six files. We replaced it with Grid in 12 lines. Bundle dropped 6kb. Readability tripled.

.dashboard {
  display: grid;
  grid-template:
    "header header header" auto
    "sidebar main aside" 1fr
    "footer footer footer" auto
    / 200px 1fr 300px;
  gap: 1rem;
  min-height: 100vh;
}
Enter fullscreen mode Exit fullscreen mode

Why It Works: Grid is declarative layout. Not just alignment. You describe intent, not positioning math. No JavaScript. No wrappers. No mystery classes. Just... layout.

🎨 CSS Variables as a State Engine

The Problem: Interactive states requiring JavaScript event handlers.

The Modern Fix: Prop drilling, context APIs, runtime toggles.

The Simpler Fix: Custom properties that respond to selectors—or even high-level themes.

We used to track every hover, active, and dark mode toggle with React state. That meant writing event handlers, passing props, and watching for re-renders—just to change a button color.

Turns out, custom properties can handle most of this entirely in CSS. No state machine. No handlers. No rerenders.

.button {
  --scale: 1;
  --shadow: 0 1px 3px rgba(0,0,0,0.1);
  transform: scale(var(--scale));
  box-shadow: var(--shadow);
  transition: transform 0.2s, box-shadow 0.2s;
}
.button:hover {
  --scale: 1.05;
  --shadow: 0 4px 12px rgba(0,0,0,0.15);
}
.button:active {
  --scale: 0.98;
}
Enter fullscreen mode Exit fullscreen mode

Why It Works: State lives in the DOM. You don’t need a context provider for hover or theme. Use the cascade. Let the DOM flow.

🧮 Intrinsic Design

The Problem: Components that look perfect in Storybook but fall apart in the real app.

The Modern Fix: JavaScript resize listeners.

The Simpler Fix: Intrinsic sizing.

Our product cards were flawless in isolation. But drop them into a CMS-driven layout and suddenly they overflowed, shrank awkwardly, or stacked at weird breakpoints. Fixing it meant media query layers, content guards, and pixel math.

Then we swapped in minmax() with auto-fit, and the problem vanished. No breakpoints. Just fluid, context-aware layout.

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
  gap: 1rem;
}
Enter fullscreen mode Exit fullscreen mode

Why It Works: This isn't “mobile-first.” It’s content-first. Components size to fit their container, not the viewport. That’s not a hack. That’s just... CSS.

🎭 Logical Properties

The Problem: Supporting RTL without rewriting everything.

The Modern Fix: Multiple stylesheets. Conditional CSS-in-JS.

The Simpler Fix: Use logical properties—and stop writing two versions of everything.

A few months ago, we shipped a multilingual app for a Middle Eastern market. Everything looked fine—until Arabic flipped the UI backwards and our layout fell apart.

We had two choices: duplicate every style and re-architect half the layout, or... switch to logical properties.

.button {
  padding-inline: 1rem;
  padding-block: 0.5rem;
  text-align: start;
}
Enter fullscreen mode Exit fullscreen mode

That was it. No rebuild. No dir-specific classes. No expensive localization refactor.

Why It Works: start and end aren’t directions—they’re flow. Which means your layout adapts to language automatically. We shipped the fix in an hour. It saved the sprint.

🌊 Fluid Typography and Spacing

The Problem: Spacing and font sizes that snap awkwardly across breakpoints.

The Modern Fix: Theme configs, pixel-perfect media queries.

The Simpler Fix: clamp().

We had a landing page that looked amazing on desktop—until marketing pulled it up on a tablet and everything looked like it had been hit with a shrink ray. Font sizes collapsed. Spacing crunched. The whole thing felt... cramped.

Instead of adding another set of media queries, we rewrote the spacing and type scale using clamp(). It took an hour. The design smoothed out instantly. Every screen size looked intentional.

:root {
  --font-base: clamp(1rem, 0.34vw + 0.91rem, 1.19rem);
}
.section {
  padding-block: clamp(2rem, 5vw, 8rem);
}
Enter fullscreen mode Exit fullscreen mode

Why It Works: It scales. Smoothly. With math. No breakpoints required. It made a wonky layout feel polished—without adding complexity.

😬 The Button That Broke Your Lighthouse Score

You’ve got a primary button. It’s beautiful. It also pulls in:

  • 12 utility classes
  • 3 context providers
  • A theme switcher
  • 1 inline SVG

Click it, and your CSS bundle balloons by 42kb—just for hover states.

But here’s the thing:

.button {
  padding: var(--padding, 0.75rem 1.5rem);
  background: var(--bg, #2563eb);
  color: var(--fg, white);
  transition: background 0.2s ease;
}
.button:hover {
  --bg: #1e40af;
}
Enter fullscreen mode Exit fullscreen mode

No JS. No tooling. No props. Just... CSS.

If this feels like an oversimplification, ask yourself: why did the simple thing feel impossible?

📉 Real Bundle Size Wins

Swapped:

  • CSS-in-JS → CSS modules with variables
  • 8 Tailwind layers → Grid + custom props

Result:

  • CSS bundle dropped 38%
  • First paint dropped by 400ms
  • Devs stopped rage-pinging the design system channel

🧩 What This Really Comes Down To

You don’t have to give up your framework.

But if you’ve forgotten how CSS actually works—how inheritance flows, how layout engines think, how the cascade helps—you’re going to keep reaching for tools that solve problems the browser already solved.

Modern CSS isn’t magic. It’s mature. It’s modular. And it’s wildly underused.

TL;DR: What You Might Not Need Anymore

Technique Modern Replacement Tries To Solve CSS Can Already Do It?
CSS-in-JS scoping Style encapsulation ✅ Cascade + custom props
Layout components + JS Responsive layout ✅ Grid + minmax()
Theming with context providers Visual state control ✅ Variables + inheritance
ResizeObserver for layout changes Container-based scaling ✅ auto-fit + clamp()
RTL stylesheet duplication Multi-language support ✅ Logical properties

Before You Reach for a Tool...

Ask yourself: can the browser do this already?

Because most of the time, it can. And it probably does it better than the abstraction you were about to install.

Got an old CSS trick that still solves modern problems? Drop it in the comments. Let’s make the fundamentals cool again.

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.