FrontAlign vs Tailwind: A Lighter Utility Framework That Doesn't Need a Second JS Library

Tailwind popularized utility-first CSS, and it's a good idea. Small, composable classes instead of naming things forever. FrontAlign shares that premise — but the two frameworks stop agreeing the moment you need anything beyond static styling.

Same Philosophy, Lighter Footprint

Both frameworks scan your markup and generate only the CSS you actually use. That part is familiar. The difference is what you're left holding afterward.

Tailwind ships CSS. Nothing else. It has no opinion about how a dropdown opens, how a modal traps focus, or how dark mode gets toggled at runtime — and it isn't supposed to. That's a deliberate, honest scope. But it means your project has to solve all of that separately, and every solution you bolt on adds its own dependency, its own bundle weight, its own API to learn.

FrontAlign keeps the utility layer just as lean, but pairs it with a single, dependency-free JS runtime that already knows how to open a modal, animate a collapse, or manage a dropdown — without pulling in anything else.

The Real Difference: What Happens When You Need a Modal

This is where the gap actually shows up. Tailwind has no built-in interactivity, so a modal means reaching for something else entirely.

# Typical Tailwind project needing a modal
npm install @headlessui/react
# ...or
npm install @radix-ui/react-dialog
# ...or wire up Alpine.js / Floating UI for positioning

// Headless UI, wired into your own component
import { Dialog } from '@headlessui/react'
import { useState } from 'react'

function Example() {
  const [open, setOpen] = useState(false)
  return (
    <Dialog open={open} onClose={() => setOpen(false)}>
      <Dialog.Panel className="rounded-lg bg-white p-6">
        <Dialog.Title>Confirm</Dialog.Title>
        {/* your markup, your state, your styling */}
      </Dialog.Panel>
    </Dialog>
  )
}

That's a second package, a second API, and CSS classes you now have to hand-write to match your brand — because the headless library intentionally ships no styling at all.

With FrontAlign, the component is already part of the framework you installed for the CSS in the first place.

import { Modal } from "frontalign"

Modal.confirm({ content: "Delete this file?" })

One import. One call. No second dependency, no separate styling pass, no version mismatch to track between your CSS framework and your component library.

No Utility Chaos

Utility-first CSS has a well-known failure mode: class lists that sprawl past readability, arbitrary values (w-[137px]) that quietly bypass the design system, and dark-mode variants duplicated across every single utility (dark:bg-slate-800 dark:text-slate-100, repeated on every element).

FrontAlign avoids the duplication problem structurally. Brand and theme values live once, as CSS custom properties inside a dedicated theme layer. Dark mode is a single attribute switch — [fa-theme="dark"] — not a parallel set of classes shadowing every utility in your markup. You write bg-surface, not bg-white dark:bg-slate-900.

CSS Built for Brand, Not Just Utility

Tailwind's theme lives in a config file that generates static classes at build time. FrontAlign's theme lives in CSS itself, using OKLCH and relative color syntax, so derived colors — accents, hover states, focus rings — are computed from your one brand color instead of hand-picked shade by shade:

--accent: oklch(from var(--primary) min(calc(l + 0.08), 0.88) calc(c * 0.9) h);

Change --primary once, and every derived token — links, hover states, focus rings, button variants — updates with it. No regenerating a build, no re-picking eight shades by eye.

Side by Side

Side by Side

The Takeaway

Tailwind is a CSS tool, and a good one. FrontAlign is that same utility-first workflow plus the interactive layer most projects end up needing anyway — without asking you to bring in a second library, learn a second API, or re-theme it by hand.

Full documentation on components, theming, and customization is available at frontalign.dev/docs.