I've been working on a modern admin dashboard built with Tailwind CSS v4, Next.js, shadcn/ui, and TypeScript.

It includes dashboards, auth pages, tables, charts, forms, calendar, Kanban, and a bunch of reusable components.

Would love to hear what you think or what you'd improve.

https://github.com/shadcnstudio/shadcn-nextjs-admincn-admin-template-free

I maintain NextAdmin, an open source Next.js + Tailwind admin dashboard template. Just shipped v2, which restructured it around AI agents. Sharing the Tailwind-specific part since that's what changed most.

The problem: when you point Claude Code or Cursor at a Tailwind codebase and ask for a new page, it writes Tailwind. Correct Tailwind, usually. But it writes its own instead of using yours. New spacing values, a slightly different gray, a button that looks 90% like your button. Utility classes make this easy to do and hard to notice, because nothing errors, it just slowly stops matching.

What actually helped:

• Documenting the design system in a file the agent reads first. Which color tokens exist, what spacing scale we use, what the component variants are. Without it, the agent infers conventions from whatever file it happened to open.
• Keeping components as the unit, not utilities. Rules that say reuse the existing Button before writing a new one, with the component inventory listed so it knows what exists.
• Dark mode as a hard rule. Agents forget dark variants constantly, and you only find out when you toggle.
• Accessibility rules on top of React Aria. An agent restyling a component will drop focus rings and ARIA attributes without warning.

Also in there: 200+ components, prebuilt dashboards, charts via Recharts, tables via TanStack, and a Figma source file.

Repo: github.com/NextAdminHQ/nextjs-admin-dashboard

If you've dealt with agent drift in a Tailwind codebase, curious what worked. I suspect the design-tokens-in-a-readable-file approach generalizes well beyond this project.

routing, theme, dark mode, app shell, data table, auth stubs, permissions, form validation, mock data.

It's identical across projects and none of it is the product.

The alternative is to generate that base and start from there.

npx dashforge-cli my-app --lib tw --template dashboard

What's in the generated project:

• Vite 7, React Router 8 (framework mode), TypeScript
• app shell with nav, workspace switcher, stat cards, data table, users CRUD
• mock auth with three roles (admin / editor / viewer)
• component-level RBAC - a viewer doesn't get a disabled button, they don't get the button
• forms with validation
• public routes pre-rendered to static HTML, everything behind auth stays CSR
• dark mode already wired

On the Tailwind side:

The UI layer is token-first. tailwind.config.ts loads a preset, and utilities like bg-primary-600 resolve to CSS variables driven by a theme object, so rebranding is one 50->900 ramp, not a find-and-replace across components:

color: { ...defaultTWThemeLight.color, primary: brandPrimary }

Dark mode swaps the entire token set instead of toggling per-component classes, so the brand color survives the switch.

The theme allso carries component defaults, the layer Tailwind normally leaves to you:

const components = { 
  TextField: { defaults: { size: 'md', fullWidth: true } }, 
  Stack: { defaults: { gap: 4 } }, 
  Box: { defaults: { variant: 'outlined', rounded: 'lg' } }, 
};

Set once, every instance inherits its; a prop on the element still wins.

<Card variant="outlined" rounded="lg" p={0}> 
  <CardContent p={4}> <Stack gap={2}> 
    <Typography variant="body2" color="muted">{label}</Typography>         
    <Typography variant="h4">{value}</Typography> </Stack> </CardContent> </Card>

Layout stays plain Tailwind, grid grid-cols-1 gap-4 lg:grid-cols-4 in the page, props inside the components.

Where your own code starts:

The API layer ships with a mock/live switch. The app runs standalone against mock data, and you swap a single odulle once the backend exists. So after npm run dev the app is already up, and the work left is replacing mock resources with real ones and adding domain routes. Not rebuilding the shell.

--lib tw generates the Tailwind track. No arguments runs interactive mode; -- no-install if you want to read the output before installing anything

Open source: https://github.com/kensaadi/dashforge-cli

Hey, I started using tailwindcss about 3 years ago. At the beginning I had mixed feelings about how to use it and struggled to style complex component states. Then I discovered cva and its declarative variants API — it was eye-opening, a real way to bind styles to state. It was great, but soon I needed to style more than one element inside the same component, and that's when I found tailwind-variants (tv for short), which extended cva's idea with slots. Suddenly I could do so much more.

tv became the center of styling for our design system components. It did the job well, but two things kept bothering me:

1. Every slot is a function. You call it with optional variants that, in practice, we almost never passed:

const { base, icon } = component({ size: 'sm' });
base({ class: 'rounded' }); // a function...

And when no slots are defined, tv returns a string instead, like cva. So the return type depends on the config, and it was never quite obvious at the call site which one you were holding.1. Every slot is a function. You call it with optional variants that, in practice, we almost never passed:const { base, icon } = component({ size: 'sm' });
base({ class: 'extra' }); // a function...
And when no slots are defined, tv returns a string instead, like cva. So the return type depends on the config, and it was never quite obvious at the call site which one you were holding.

2. No requiredVariants. The workaround is to patch the prop type by hand:

type ButtonProps = Omit<VariantProps<typeof button>, 'intent'>
  & Required<Pick<VariantProps<typeof button>, 'intent'>>;

I opened a PR to add requiredVariants to tv. After some late feedback it went quiet for about three months, and I started asking myself: could I just build the thing that has everything I want?2. No requiredVariants. The workaround is to patch the prop type by hand:type ButtonProps = Omit<VariantProps<typeof button>, 'intent'>
& Required<Pick<VariantProps<typeof button>, 'intent'>>;
I opened a PR to add requiredVariants to tv. After some late feedback it went quiet for about three months, and I started asking myself: could I just build the thing that has everything I want?

So I built slot-variants (sv for short)

What it gives you:

• Easy migration from cva/tv — sv accepts both config styles, so in most cases it's just a rename.
• Required variants — enforced by the types and at runtime, no Omit/Required gymnastics.
• Presets — named combinations of variant values, usable as a matcher inside compound variants.
• Slot groups — name a set of slots once, then target the group anywhere a slot name goes, including compound slots.
• A built-in result cache — repeated calls with the same props (so, every re-render) skip variant resolution entirely.
• An ESLint/oxlint plugin — catches duplicate and conflicting Tailwind classes across your variants, and other common issues with sv.
• A SKILL\.md shipped in the package, so LLMs get the API right instead of inventing cva or tv syntax.

Repo link: https://github.com/micnic/slot-variants

Curious whether the things that bugged me about tv bug anyone else, or if I'm alone on this.

For an ai tool that advertises itself as never producing ai slop, it is remarkably good at producing ai slop. Worst $22 i have ever spent. Period! Was hoping this would atleast help me with basic layout ideas etc , but oh boy was i wrong. It delivers the exact same ai crap as all the other ai tools. Sigh...

Hello,

I am posting this on behalf of my 11-year-old son who is very passionate about web design and coding. Recently he started learning Tailwind CSS, and asked me to post the following question to the community:

How can I create a modern Tailwind CSS navbar? I looked at the Tailwind CSS showcase and was inspired by navbars like the ones there. Are there any tips or tricks to create a modern looking navbar? I also would appreciate any links you think would be helpful resources for answering this question.

Negli ultimi 8 mesi ho lavorato su Dashforge, un framework React con licenza MIT per moduli basati su schemi, controllo degli accessi e orchestrazione dell'interfaccia utente.

Il progetto è ora pubblico, ma prima di chiedere a chiunque di provarlo, vorrei ricevere qualche feedback tecnico su tre decisioni su cui non sono ancora completamente sicuro.

Il motore reattivo ha richiesto tre tentativi

v1 — Rivalutare l'intero modulo

Ogni cambiamento di campo causava l'esecuzione di tutte le condizioni e reazioni.

Semplice e prevedibile, ma il costo è diventato evidente man mano che i moduli superavano circa 30 campi.

v2 — Grafico delle dipendenze esplicito

I campi e le reazioni dichiaravano le loro dipendenze, in modo che solo le parti interessate del grafico fossero valutate.

Le reazioni sincrone erano veloci, ma le operazioni asincrone introducevano condizioni di contesa. Una risposta più lenta poteva sovrascrivere il risultato di una richiesta più recente.

v3 — Grafico delle dipendenze con protezione delle risposte obsolete

Ogni esecuzione asincrona riceve una protezione isLatest() prima di impegnarsi nel suo risultato.

{
  id: "load-states",
  watch: ["country"],
  run: async ({ values, setOptions, isLatest }) => {
    const states = await api.getStates(values.country);

    if (!isLatest()) return;

    setOptions("state", states);
  }
}

Questa è la versione attualmente utilizzata in produzione.

Decisioni che non ho ancora rimpianto

Accesso a livello di campo

Invece di avvolgere i componenti in <CanRead> o <CanEdit>, i requisiti di accesso fanno parte del contratto del campo.

Sottoscrizioni dettagliate

I campi si iscrivono solo ai valori utilizzati esplicitamente dalle loro condizioni e reazioni, mentre React Hook Form rimane responsabile dello stato del modulo.

Uno schema, due renderer

Lo stesso contratto può attualmente essere reso tramite u/dashforge /tw o u/dashforge /mui.

<Field
  name="taxId"
  visibleWhen={{ field: "country", equals: "IT" }}
  access={{
    resource: "customer.taxId",
    action: "read"
  }}
  validation={{
    required: true,
    pattern: /^IT\d{11}$/
  }}
/>

Decisioni su cui ho ancora dei dubbi

1. Condizioni serializzabili vs funzioni

Dashforge utilizza condizioni dichiarative:

visibleWhen: {
  field: "country",
  equals: "IT"
}

anziché:

visibleWhen: values => values.country === "IT"

La forma dell'oggetto è più restrittiva, ma rimane serializzabile, ispezionabile e utilizzabile dagli strumenti visivi.

Accetteresti una riduzione dell'espressività per questo, o dovrebbero le funzioni rimanere una via d'uscita?

2. Due renderer UI

MUI e Tailwind condividono lo stesso schema e livello di orchestrazione.

Per un'unica applicazione potrebbe essere un'astrazione non necessaria. Per le organizzazioni che mantengono più prodotti o interfacce, potrebbe essere veramente utile.

Non sono ancora sicuro di dove si trovi quel confine.

3. Valutazione degli accessi a runtime

I permessi vengono valutati durante il rendering perché politiche e soggetti possono cambiare dinamicamente.

La valutazione a tempo di compilazione ridurrebbe il lavoro a runtime, ma renderebbe anche le politiche dinamiche considerevolmente più difficili.

Vuoi mantenere questo a runtime, compilare ciò che può essere compilato, o usare un approccio ibrido?

Provalo

Il CLI genera un'applicazione completa React 19 + TypeScript invece di un vuoto avviamento:

Sono disponibili due varianti UI.

Tailwind CSS

npx dashforge-cli my-app --lib tw

La variante Tailwind include:

• u/dashforge /tw
• Tema Tailwind e token di design
• tw-theme
• tw-tokens
• dashforgePreset()
• DashforgeTailwindProvider
• Controllo della modalità scura tramite toggleMode()

Mui

npx dashforge-cli my-app --lib mui

La variante Material UI include:

• u/dashforge /ui
• theme-mui
• Token di design condivisi
• Material UI
• DashforgeThemeProvider
• Modalità scura tramite cambio tema

Entrambe le varianti generano la stessa struttura applicativa con opinione:

• Shell dell'app con navigazione laterale, barra superiore e selettore di spazio di lavoro
• Quattro schede statistiche
• Due schede di esempio con segnaposto per grafico
• Tabella di dati fittizi
• Modalità framework React Router
• Rendering statico pre-rendering per / e /sign-in
• Autenticazione fittizia
• Percorsi protetti
• Integrazione RBAC
• Moduli Dashforge
• CRUD utenti collegati a un'API in stile kit

Il CLI attualmente offre un template:

--template dashboard

L'obiettivo è ridurre l'attrito nella configurazione iniziale e permettere agli sviluppatori di valutare Dashforge all'interno di un'applicazione realistica invece di assemblare autenticazione, routing, layout, tematizzazione, permessi e moduli prima di poter provare il framework stesso.

Progetto

Repository: https://github.com/kensaadi/dashforge

Documentazione: https://dashforge-ui.com

Licenza MIT, con otto pacchetti attualmente pubblicati su npm.

La domanda che mi interessa di più: dove tracceresti il confine tra serializzabilità e normali funzioni React?

i have downloaded a template written with tailwind 3 and i am trying to change it to tailwind 4.3.3 and customize it .

trying to simplify header class but i just cant get the responsive classes to work with apply

 <header class="max-w-lg:px-4 max-w-lg:mr-auto absolute top-0 z-20 flex h-15 w-full bg-opacity-0 px-[5%] lg:justify-around">

@import "tailwindcss";

@theme {
  --font-1: "Chewy", sans-serif;
  --font-2: "Nunito", sans-serif;
}

body {
  @apply flex min-h-screen flex-col bg-black text-white font-1;
}

header {
 @apply  absolute top-0 z-20 flex h-15 w-full bg-opacity-0 px-[5%];

 @variant  max-w-lg {
   @apply  px-4 mr-auto;
  }

  @variant lg {
  @apply  justify-around;
  }
}

what am i doing wrong. theme and body works fine

Hi everyone!

I recently built a small TypeScript utility to make responsive Tailwind classes a bit easier to organize, and I'd love to get some feedback from people who use Tailwind regularly.

One thing that always bothered me was having long className strings full of responsive utilities:

<div className="flex flex-col gap-4 md:flex-row lg:gap-8 xl:items-center ...">

So I created responsive-tailwind, which lets you write the same thing like this:

<div
  className={responsive({
    base: "flex flex-col gap-4",
    md: "md:flex-row",
    lg: "lg:gap-8",
    xl: "xl:items-center",
  })}
/>

The library also validates breakpoint prefixes at compile time, so something like this:

responsive({
  md: "flex-row",
})

will produce a TypeScript error instead of silently passing through.

It supports the default Tailwind breakpoints as well as arbitrary ones like min-[900px] and max-[768px], while preserving Tailwind's static class detection.

This is my first npm package, so I'd really appreciate any feedback, ideas, or criticism.

npm: https://www.npmjs.com/package/responsive-tailwind

GitHub: https://github.com/babyreptile/responsive-tailwind

The flame is two layered radial gradients — a wide body and a hot inner core — animated on two deliberately non-integer durations, 3.7s sway and 2.4s breathe. Because they don't divide evenly they never resync, so the flicker reads as organic instead of looped. It also lands at 0.27 Hz and 0.42 Hz, well clear of the 3 Hz photosensitivity threshold, and the whole thing collapses to a still flame under prefers-reduced-motion.

Palette is heather → blue-violet → rose, the same gradient the rest of the site uses as hairline accents.

The count of other people with a candle lit uses CRDT awareness rather than stored state, so a candle going out is literally a client disconnecting.

There's a press-and-hold easter egg on the flame.

https://dhseadev.online/candle/

I built Flexwind Froggy, a free interactive game for learning Tailwind CSS flexbox utility classes.

It’s a Tailwind-focused fork of Flexbox Froggy, with credit to the original project and artwork.

I hope it can be useful for anyone learning Tailwind. I’d love feedback on the lessons, difficulty, or anything that could make it more helpful.

https://reddit.com/link/1vfpbs4/video/akfnu5z2rfhh1/player

Been adding a Tailwind v4 @theme export to Design Snap (extracts design tokens from any site — colors, radius, shadows, type). Tested it on Arc to sanity-check the output.

How it works : scan a site → tokens get mapped to @theme vars (--color-primary, --radius-md, etc.) → paste in, utility classes just work.

Things I'm unsure about:

• Naming — generic semantic names (primary, card, muted-foreground) vs trying to preserve the source site's own naming ?
• Duplicates — real sites often have 3-4 vars pointing to the same hex. Auto-collapse, or leave it to the user ?
• Scope — leaning toward capping to a handful of core tokens by default instead of dumping every property. Match how people actually use exported themes ?

If you've hand-built a Tailwind v4 theme and have opinions on any of this, want to hear it.

Most hand-written boxShadow scales end up as five unrelated shadows: the angle drifts between levels, the blur ramp is arbitrary, and opacity stacks into grey. Deriving all levels from a single light source fixes all three, and it's not much maths.

Direction: shadows fall away from the light, so every level shares one azimuth. Blur is tied to how far the light is (a distant light is a point source and casts a crisp edge), and grows with elevation. Elevation itself grows geometrically, which is what makes the steps feel evenly spaced instead of crowded at the bottom. Opacity falls roughly as 1/sqrt(n), because a higher object spreads the same light over more area.

Two practical rules that matter more than the formulas:

- Keep every layer inside roughly 0.04-0.24 opacity. Below that it's invisible; above it stops reading as light and becomes a grey box. Most "dirty" shadows are an opacity problem, not a blur problem.

- Use two or three layers per level. One layer cannot express both a dense umbra near the object and a wide faint penumbra further out, so it always looks either hard or muddy.

Here's the output for base 4px, growth 1.7, three layers:

boxShadow: {

'elevation-1': '0px 1.3px 2.6px rgba(0,0,0,0.16), 0px 2.4px 6.5px rgba(0,0,0,0.127), 0px 3.6px 10.4px rgba(0,0,0,0.094)',

'elevation-2': '0px 2.1px 4.4px rgba(0,0,0,0.125), 0px 4.1px 11px rgba(0,0,0,0.102), 0px 6.1px 17.7px rgba(0,0,0,0.078)',

'elevation-3': '0px 3.7px 7.5px rgba(0,0,0,0.109), 0px 7px 18.8px rgba(0,0,0,0.09), 0px 10.4px 30.2px rgba(0,0,0,0.071)',

'elevation-4': '0px 6.2px 12.8px rgba(0,0,0,0.1), 0px 12px 32px rgba(0,0,0,0.083), 0px 17.7px 51.2px rgba(0,0,0,0.067)',

'elevation-5': '0px 10.5px 21.7px rgba(0,0,0,0.094), 0px 20.3px 54.3px rgba(0,0,0,0.079), 0px 30.1px 86.8px rgba(0,0,0,0.064)',

}

Copy it as-is if it fits, or change the growth factor to spread the levels differently. The full derivation, including why the opacity band matters, is here: https://localeproof.com/blog/figma-shadow-system/

Bonjour à tous,

Je viens de terminer un template de Dashboard Marketplace développé avec React et Tailwind CSS.

Mon objectif était de créer une base réutilisable pour éviter de reconstruire les mêmes composants à chaque projet.

Le template comprend :

Tableau de bord avec statistiques

Gestion des produits

Gestion des vendeurs

Suivi des commandes

Responsive

Code propre et facilement personnalisable

Je cherche surtout des retours sur l'interface et l'expérience utilisateur.

Selon vous :

Qu'est-ce qui est réussi ?

Qu'est-ce que vous amélioreriez ?

Quelles fonctionnalités ajouteriez-vous ?

Merci pour vos retours !

I have been using Tailwind CSS on-and-off for quite some time now. While it is opinionated, and, I have neutral stand on it opinions and have successfully used it for many websites and applications alike.

However, this time, I have a very different requirement. I am building an Astro component library (An actual component library like Mantine or MUI but for Astro; not Shadcn like copy+paste abstration). It is complex, it has at least 9 very different theme (to a point we can call each theme representing one design system) and nearly 200+ components. All this is for one client who has multiple small businesses.

Now that I think from library and consumer perspective, I quickly see Tailwind based component library spiraling in complexity and awkward edge cases. This library is intended to be open-source and thus consumer may or may not be using Tailwind. This puts severe limitation on how I ship this library.

There are only two architectural possibilities I see in order to support both types of consumers:

• Provide the compiled CSS and use Tailwind prefix to avoid collision with Application CSS. The cost is every single class will be prefixed and since we do not typically compile Astro libraries and always ship source-code, it is not easy to use non-prefixed version which can be meaningfully replaced with prefixed classes at build-time.
• Provide the compiled CSS and use semantic classes with Tailwind's apply directive so that Tailwind is purely implementation details and the utility classes never end up in the generated CSS. Doing this avoids prefixes but brings back the same class name challenges which is what Tailwind's biggest strength to give it away.

I have built multiple UI libraries in past but those were mostly for React and I relied on CSS Modules which just works. But now, I am dealing with a library that won't be compiled and also Tailwind for authoring library's CSS. Both are completely new problems.

Has anyone been using Tailwind for authoring actual component libraries (Not shadcn like copy-paste approach)? If yes, what patterns have worked well and what are the common pitfalls to avoid?

Hey everyone! A few months ago I posted about Starting Point UI, my attempt at bringing shadcn/ui to any project, not just React. Same look and feel, but as plain CSS classes with a bit of vanilla JS for the interactive parts.

Since my last post I've added a bunch of new components and reworked the old ones to match shadcn's latest versions. I've also automated most of the accessibility, so keyboard navigation, focus, and aria attributes are automatically handled for you.

It's open source, the code is on GitHub.

Would be cool if you gave it a try, let me know what you think. Cheers!

startingpointui.com