Tailwind and the Rise of NSOs

Introduction

Tailwind CSS promised something radical — the ability to style rapidly without leaving your HTML or JSX. It did away with naming arguments and separated “what” from “how” through utility-first design. And it worked — in the beginning.

But speed has consequences. As our applications scaled, we began to see clear structural weaknesses in real-world Tailwind usage. Patterns that felt elegant in prototypes became fragile, entangled and opaque under pressure.

Problems We Observed

The problems weren’t about Tailwind itself, but how raw Tailwind usage broke down in larger systems including (but not necessarily limited to);

  • entanglement – styling logic became deeply interwoven with business logic. Long className strings blurred the line between structure and behaviour;

  • duplication – common patterns were rewritten constantly. No semantic reuse, no central style contract;

  • inconsistency – similar components were styled differently. Developers copied classes from one place to another with subtle, unintended deviations;

  • opacity in reviews – className strings became difficult to audit. There was no way to tell what a block meant, only what it did;

  • lack of visual grouping – properties had no order. Layout sat next to decoration, spacing next to interaction. You had to read every class to understand intent;

  • scalability bottlenecks – As pages grew and designs matured, the lack of structure created friction — not just for contributors, but for reviewers and maintainers etc.

Tailwind gave us the power to build. But it gave us no rules to govern what we built.

What We needed

We weren’t looking to replace Tailwind — we believed in its model. But we needed to wrap it in structure. We needed;

  • a way to encapsulate styles into reusable, named blocks;

  • a way to enforce semantic clarity;

  • a format that allowed us to group, sort, and annotate Tailwind classes;

  • a way to prevent style duplication and clarify styling responsibility; and,

  • a bridge between developer speed and architectural clarity

This is why we created the Named Style Object — or NSO.

What is an NSO?

An NSO is a Named Style Object — a clearly scoped, reusable style block declared in raw CSS (or structured TS object form or a hybrid of both), following Sentinel’s canonical grouping rules. It applies Tailwind utility tokens, but presents them in an organized, readable and maintainable structure.

Here is an example;

				
					.auth-header {

  /* 1. Layout */

  display: flex;
  justify-content: center;

  /* 3. Text */

  font-weight: theme(fontWeight.bold);
  color: theme(colors.white);

  /* 5. Visual Decoration */

  text-shadow: 1px 1px 2px black;
}

It tells us what it styles, how it’s structured, and why it exists — all at a glance.

The V4 Shift — From Pain to Precision

Tailwind v4 introduced a major upgrade: @theme blocks and full design token access through custom properties. This changed everything. Now we could;

  • create custom design tokens (–color-link, –shadow-navbar);

  • access Tailwind values in any CSS declaration via theme(…);

  • control themes, spacing, colours and shadows semantically; and,

  • write raw CSS and still live inside the Tailwind design system.

This was the missing link. The upgrade that made NSOs not just helpful — but essential.

We no longer needed to choose between “utility speed” and “architecture.” Tailwind v4 let us have both — if we brought discipline to the format.

NSOs are that discipline.

Named Style Objects are covered in full in the next section — including formatting rules, canonical groupings, usage conventions and class-based scoping.