Tailwind CSS & SCSS

Overview

Stylesheets rarely fail on day one. They fail in month eight, when nobody is sure whether deleting a rule will break another page, so new rules get appended instead. The file grows, specificity wars start, !important appears, and eventually someone proposes a rewrite.

Preventing that is an architecture problem, not a tooling problem. Tailwind and SCSS are both good tools; which one we reach for depends on the project and, more importantly, on who will maintain it after us.

Choosing between them

Tailwind CSS

Utility-first, with the significant advantage that the production stylesheet only contains classes actually used — typically 10–20 KB compressed for a full site, and it does not grow as pages are added. Constraints come from the config, so spacing and colour stay consistent by default. It suits component-based front ends, teams shipping quickly, and projects where several developers touch the same UI.

The honest downside is markup verbosity, and a real learning curve for developers or content editors used to reading class names as descriptions. We manage that with component extraction rather than by scattering @apply everywhere, which recreates the problem Tailwind exists to solve.

SCSS

Better where the project is a traditional server-rendered site, where an existing team knows Sass, or where a complex design system needs mixins, functions and loops to generate its variants. Nesting, partials and a clear file structure keep large stylesheets navigable — provided nesting stays shallow. Nesting five levels deep produces selectors nobody can override, which is how specificity wars start.

We also frequently use both: SCSS for the design system foundation and complex component logic, Tailwind utilities for layout and spacing.

Design tokens

Whichever tool is used, the foundation is the same. Colour, spacing, typography scale, radii, shadows, breakpoints and z-index layers are defined once as tokens and referenced everywhere. Tokens live in the Tailwind config or as SCSS variables and CSS custom properties, so they are available to both the build and the runtime.

The payoff is concrete: a brand colour change is one edit, dark mode is a token set rather than a parallel stylesheet, and a designer's spacing scale is enforced by the tooling instead of by review comments.

Keeping CSS small

• Tailwind's content scanning removes unused utilities automatically; we make sure the content paths are right, because a misconfigured path silently ships everything or purges something needed.
• For SCSS, unused CSS is found and removed rather than left "just in case".
• Critical CSS inlined for the first screen, the rest loaded without blocking render.
• No CSS-in-JS runtime unless the project genuinely requires it — runtime style injection costs main-thread time on every render.
• A size budget on the stylesheet, checked in the build.

Dark mode and theming

Built on tokens from the start, not retrofitted. Colours are defined in semantic pairs — surface, text, border, accent — so the dark theme is a token swap rather than a second set of components. We respect the user's system preference by default, offer an explicit toggle, and check contrast in both themes, since a palette that passes AA in light mode frequently fails in dark.

Maintainability

• A documented component library so the same button is not implemented four ways.
• Naming conventions agreed and enforced — BEM for SCSS projects, clear component boundaries for Tailwind.
• Linting in the build, so ordering and formatting are automatic rather than argued about.
• Shallow nesting and low specificity, so overriding a style never requires a fight.
• Handover documentation that explains the token system, because the next developer's first question is always "where do I change the brand colour".

How we work

1. Extract tokens from the design before building anything, and agree them with the designer.
2. Build the base components first, then compose pages from them.
3. Enforce the stylesheet budget and linting in CI.
4. Document the system and walk the client's team through it at handover.

What you get

• A token-driven design system, not a pile of one-off rules.
• A small, stable production stylesheet that does not grow with every new page.
• Dark mode and theming that were designed in rather than bolted on.
• Documentation that lets another developer pick the project up without a rewrite.

Any stylesheet is maintainable at launch. The test is whether a developer who has never seen it can safely change a colour eight months later.