What is SASS, Actually?
SASS stands for Syntactically Awesome Stylesheets. It is a CSS preprocessor — a tool that lets you write styles in a more powerful syntax, which then gets compiled into regular CSS that browsers understand. You write SASS, the compiler outputs CSS, and the browser reads the CSS. That middle step is where all the power lives.
Plain CSS works fine for small projects. But once you have hundreds of components, multiple pages, and a design system with consistent colours and spacing, raw CSS becomes hard to manage. SASS solves that by giving you variables, nesting, functions (called mixins), and the ability to split styles into separate files that get stitched together at build time.
It has been around since 2006, which makes it one of the older tools in the frontend ecosystem — but it has stayed relevant because it genuinely makes large stylesheets easier to write and maintain.
The Difference Between SASS and SCSS
This confuses a lot of people. SASS originally used an indented syntax (no curly braces, no semicolons — kind of like Python). Later, a second syntax called SCSS was introduced, which looks exactly like regular CSS but with SASS features added on top.
Today, almost everyone uses SCSS syntax because it is easier to adopt — you can drop your existing CSS into an .scss file and it works immediately. When developers say "I use SASS" they almost always mean they are writing SCSS files. The two names are used interchangeably in practice.
What SASS Actually Lets You Do
Variables
Instead of repeating the same colour or font size twenty times across your stylesheet, you define it once and reference it everywhere:
$primary-color: #2D4A8A; $font-body: 'Inter', sans-serif;
Change the variable in one place and it updates across your entire stylesheet. This is especially useful when a client wants to tweak the brand colour — a change that used to mean hunting through hundreds of lines now takes ten seconds.
Nesting
In plain CSS, styling a button inside a card inside a navigation component requires writing long, repetitive selectors. SASS lets you nest them the way they actually exist in your HTML:
.card { padding: 24px; .card-title { font-size: 20px; } .card-button { background: $primary-color; &:hover { opacity: 0.9; } } }
This reads much more naturally and keeps related styles grouped together instead of scattered across the file.
Mixins
Mixins are reusable style blocks, like functions for CSS. A common use case is responsive breakpoints — instead of writing the same media query over and over, you write a mixin once and include it wherever you need it:
@mixin tablet { @media (max-width: 768px) { @content; } } .hero { font-size: 48px; @include tablet { font-size: 32px; } }
Partials and Imports
SASS lets you split your styles into separate files — one for buttons, one for typography, one for the navigation — and then import them all into a single main file. This keeps your codebase organised and makes it easy for multiple developers to work on different parts of the styles without constantly creating merge conflicts.
Is SASS Still Relevant in 2026?
Yes, though the conversation has shifted a bit. CSS now natively supports many features that used to require SASS — native variables (custom properties), nesting, and colour functions have all landed in modern CSS. Some developers argue that SASS is becoming less necessary.
In practice, we still use SCSS on most projects at Dharmsy, for a few reasons:
- Mixins still do things native CSS can't do easily — especially complex responsive patterns and component variants.
- Legacy projects — a huge portion of live projects use SCSS, so knowing it well matters when working on existing codebases.
- Tooling is mature — SCSS compilers are fast, well-documented, and integrate cleanly with Next.js, Vite, and most build systems.
- Team familiarity — most experienced frontend developers know SCSS well. Switching to a different approach has a real learning curve and switching cost.
The short version: native CSS is catching up, but SCSS is still the faster and cleaner choice for large design systems and team projects.
How We Use SASS at Dharmsy
For projects that use a traditional HTML/CSS architecture (rather than component-based frameworks like React), we use SCSS as our default stylesheet language. We set up a structured folder system: base styles, component styles, layout styles, and a variables file that holds the design tokens (colours, spacing, typography).
For React and Next.js projects, we typically use either CSS Modules with SCSS (scoped styles per component, with SASS features available) or Tailwind CSS, depending on the project's design requirements. Tailwind is great for utility-first designs; CSS Modules with SCSS works better when the design system needs more custom, complex styling that doesn't fit neatly into utility classes.
We don't use SASS for its own sake. We use it because it makes the CSS layer of a project faster to build, easier to maintain, and cleaner to hand off.
Hiring a SASS Developer or a Web Development Team
If you're looking specifically for a developer with SASS/SCSS skills, any competent frontend or full-stack web developer should have them. It's a foundational tool — asking for a "SASS developer" is a bit like asking for a "Git developer." It's expected as part of the skill set, not a specialisation on its own.
What you actually want to look for is a web development team with strong frontend skills, a clear process for building maintainable CSS architecture, and a track record of delivering clean, well-structured UI code.
If you're building a web product, a business website, or a web application and want a team that handles the frontend properly — including the CSS layer — we'd be happy to talk.