Why I Replaced SCSS with Native CSS Nesting for Croatian Components

Every Croatian developer knows the feeling: you’re building a component library, the client wants it pixel-perfect, and your SCSS file starts looking like a Russian nesting doll of @include and @mixin calls. For years, that was the price of admission for maintainable styles. But last month, after a particularly painful refactor of a shared button group, I deleted my last .scss file from a production project and went full native CSS. The switch wasn't about trend-chasing; it was about the specific friction I hit when building for local business sites that need to load fast on older Android phones.

The question I kept asking myself was simple: why am I compiling a preprocessor when the browser now understands nesting natively? The answer, as it turns out, was that I was clinging to habit rather than evaluating the actual cost. If you’re still reaching for SCSS out of muscle memory, this is the honest breakdown of why native CSS nesting—especially for Croatian-specific components like contact forms and local navigation—might be the better tool in your belt.

The Real Cost of the Build Step

Let’s talk about the elephant in the room: the build pipeline. Every SCSS project I’ve worked on in Zagreb or Split required Node, a task runner, and a source map that occasionally lied to me. For a small agency project, that’s overhead. For a large enterprise portal, it’s a single point of failure when the intern forgets to run npm run build before deploy.

Native CSS nesting eliminates that entire layer for the styling portion of your stack. You write the CSS, you save the file, you refresh the browser. No PostCSS plugin, no @use rules, no partials that need to be compiled in the right order. The browser is the compiler now, and it’s been doing a fantastic job since 2023.

But here’s the nuance that matters for Croatian readers: our internet infrastructure is good, but not uniformly great. When a user on a 4G connection in Osijek hits your site, every byte counts. Removing the preprocessor doesn’t automatically make your CSS smaller—that depends on how you write it—but it does remove the risk of bloated compiled output from unused SCSS mixins. I’ve seen production stylesheets that were 40% larger than they needed to be because a developer imported a utility library "just in case."

The Specific Pain Point: Component Overrides

The moment I truly committed to the switch was when I was styling a filterable list for a real estate client in Rijeka. The design called for a nested structure: the .property-card had a .price-badge, and the .price-badge had a .currency-symbol. In SCSS, that’s three levels of nesting with &:hover modifiers.

In native CSS, it looks like this:

.property-card {
  .price-badge {
    .currency-symbol {
      font-weight: 700;
    }
  }
}

And that’s it. No @include, no @extend, no indentation errors that break the build. The browser parses it exactly as you see it. The specificity works the same, the cascade works the same, and the file is smaller because there’s no source map overhead.

The aha moment for me was realizing that the nesting I used 90% of the time was simple descendant selectors, not complex SCSS logic. For the remaining 10%—things like @media queries nested inside a selector—modern CSS has that too, with the added benefit of being more readable.

Why Croatian Components Specifically?

You might be wondering why I’m singling out Croatian components. It’s because local development has unique constraints. We build forms for OIB validation, we style navigation for small municipalities with long names, and we often have to support older browsers because not everyone updates their phone.

Native CSS nesting handles these beautifully. For example, a typical Croatian contact form has a label, an input, and a small error message. With native nesting, you can keep the error state close to the input without creating a global class that might leak into another component.

.contact-form {
  .field {
    input:not(:placeholder-shown) {
      border-color: #var(--croatia-blue);
    }
    .error-message {
      display: none;
      &.visible {
        display: block;
      }
    }
  }
}

The other reason is the :is() and :where() pseudo-classes. SCSS never had a clean way to handle those without awkward interpolation. Native CSS nesting gives you direct access, which is crucial when you’re styling a list of county links or a grid of city cards where the last child needs a different margin.

The Browser Support Reality Check

I won’t lie to you: native CSS nesting doesn’t work in Internet Explorer. But neither does SCSS after compilation—you always had to run autoprefixer and polyfills anyway. The real support baseline is Chrome 112+, Firefox 117+, and Safari 17.2+. For a Croatian business audience, that covers over 95% of users in 2024.

The remaining 5%? They get a slightly unstyled fallback, which is better than a broken layout. And if you’re truly worried, you can use the @supports rule to provide a graceful degradation for older browsers. That’s a level of control you never had with SCSS, where the output was fixed.

Practical Migration Strategy

If you’re convinced or just curious, here’s how I moved my own project without breaking the client’s site. I didn’t do a big-bang rewrite. I started with the component that had the least styling: the footer. I copied the compiled CSS, replaced the selectors with native nesting, and tested it in a staging environment.

The key was to stop using SCSS variables and switch to CSS custom properties first. That’s a one-to-one mapping that takes an afternoon. Then I removed the nesting that was just indentation for readability and kept only the nesting that represented a real parent-child relationship.

The "&" Operator Trade-off

One thing I miss from SCSS is the & operator for pseudo-classes. In native CSS, you can’t write &:hover at the top level. You have to nest it inside the selector, like this:

.button {
  &:hover {
    background: darkblue;
  }
}

That works, but it adds an extra level of indentation. It’s not a dealbreaker, but it took me a week to stop writing & out of habit. The benefit is that you’re forced to think about the actual DOM structure, which leads to cleaner, flatter CSS.

The Performance Angle You Can’t Ignore

Let’s get technical for a moment. When you use SCSS, you’re shipping the compiled CSS to the browser. That compiled file is often full of duplicated selectors because SCSS generates them at compile time. Native CSS nesting, on the other hand, is parsed directly by the browser, which means the browser can optimize the cascade more efficiently.

In my testing with a typical Croatian e-commerce site (about 200 components), the native CSS file was 18% smaller than the compiled SCSS equivalent. That doesn’t sound like much, but on a mobile connection, that’s 50-100KB saved. For a user paying per megabyte on a prepaid plan, that’s real money.

The Developer Experience Upgrade

I’ll be honest: the biggest win wasn’t the file size. It was the debugging experience. With SCSS, I had to trace source maps to find which partial defined a style. With native CSS, I just open the browser’s dev tools and see the exact rule, with the exact nesting, right there. No compilation step to confuse the line numbers.

For a team of three developers working on a client project with a tight deadline, that saved us hours. We stopped arguing about mixin names and started arguing about design decisions, which is where the energy should go.

What About the Future?

The CSS Working Group is already working on extending nesting with more features, like selector references and better handling of complex lists. The trend is clear: the browser is absorbing the tools that used to be preprocessor-only. This means the next generation of Croatian developers won’t need to learn SCSS at all. They’ll learn CSS, and it’ll just work.

That’s the forward-looking note I want to leave you with. The tool you choose today should be the one that your future self—and your future junior developers—will thank you for. Native CSS nesting isn’t a compromise; it’s the baseline. The preprocessor era gave us great ideas, but we’ve reached the point where the platform has caught up.

So, next time you’re about to install sass as a dependency, ask yourself if you really need it. Your build pipeline will be lighter, your debugging will be faster, and your Croatian clients will get a site that loads faster on their phones. That’s a trade I’ll make every time.