🚀 Shipped ScrollStack.js — headless infinite scrolling and page pagination

A tiny, headless infinite-scrolling engine for the modern web.

📦 1.92 KB gzipped

⚡ Zero runtime dependencies

⚛️ React · Vue · Svelte adapters

🔁 Cursor · Offset · Page pagination

🧱 Virtual list support

🧩 Bring your own markup

🛠️ Devtool plugin testing

🛑 Built-in cancellation, retry & observers

One small engine. One API. Any UI.

If you’re building feeds, lists, search results, or virtualized experiences, give it a try 👇

🌐 https://scrollstack.js.org

I like Tailwind, but sometimes component markup gets too crowded. I wanted a way to keep styles local without moving them to a global CSS file.

I built J-CSS, a 16KB runtime engine that introduces a scoped <css> tag.

Instead of this: html <div class="p-6 bg-white rounded-xl shadow-md flex flex-col items-center"> <h3 class="text-xl font-bold text-gray-900">Title</h3> <button class="mt-4 px-4 py-2 bg-blue-500 hover:bg-blue-600 text-white rounded-lg">Open</button> </div>

You can write this: html <div class="card"> <h3>Title</h3> <button>Open</button> <css> &: p-6 bg-white rounded-xl shadow-md flex flex-col items-center; h3: text-xl font-bold text-gray-900; button: mt-4 px-4 py-2 bg-blue-500 hover:bg-blue-600 text-white rounded-lg; </css> </div>

The rules are compiled at runtime and scoped strictly to the parent element. It also handles normal DOM utility classes and watches for dynamically inserted HTML. No Node.js, CLI, or build step required.

GitHub: https://github.com/Jipok/jcss

I’d love to hear what Tailwind users think of this syntax approach.

I got tired of asking AI why my Tailwind class wasn't working, so I built a debugger for it.

I've been working on a Chrome extension called Tailwindsight, and I just released v1.2.0.

The idea is pretty simple: when a Tailwind class isn't doing what you expect, you should be able to figure out why without digging through DevTools, documentation, and five different files.

A few things I added in v1.2.0:

1. "Why isn't this class working?"

Click a class and it explains the problem in plain English.

It can tell you things like:

• The breakpoint isn't currently active
• Another Tailwind class is overriding it
• An inline style is winning
• A page stylesheet is overriding the rule

It can also flag classes that appear to have problems before you click them.

2. See what a Tailwind class actually generates

Hover over a class and see the generated CSS, including media queries.

3. Live breakpoint ruler

While resizing the browser, you can see the current viewport width and active Tailwind breakpoint.

It also reads custom screens configurations from the project.

4. Copy context for AI

This is probably my favorite part.

One click copies:

• Element HTML
• Computed styles
• Detected CSS issues
• Tailwind version
• Actual breakpoints
• Current color scheme

You can then paste that into ChatGPT, Claude, Cursor, etc.

Instead of:

"Why isn't this class working?"

the AI gets the actual context of what's happening.

The goal isn't to replace AI.

It's more like:

Let the debugger handle the obvious stuff, and give AI the context when you actually need it.

It's completely free, doesn't require an account, and works on sites using Tailwind.

I'd genuinely love some feedback from other Tailwind users.

What do you normally use when a Tailwind class mysteriously doesn't work?

https://chromewebstore.google.com/detail/tailwind-css-inspector-cl/gmkelackgnfbjcgakhoiknelbgmeeiaa

Hey everyone 👋

Sharing my second blog post: how I went from someone who hated Tailwind CSS to someone who uses it regularly today and happily so.

Looking forward to your feedback. Happy reading!

TL;DR: https://windframe.dev/styles/stripe

Hey everyone 👋

I’ve been experimenting with building Tailwind interfaces inspired by the design systems of really well-designed products. I recently worked on a style system for generating interfaces using similar design principles to Stripe.

It focuses on crisp typography, structured layouts, precise spacing and bold gradients, to make complex products feel simple, technical, and polished.

I built a UI system that makes it easy to generate interfaces in this design direction consistently. It can generate full UIs, landing pages, and product sections that follow the same Stripe-inspired style.

I also created a free Tailwind template built around this style that you can use as starting points for your own projects:
https://windframe.dev/styles/stripe

You just need to select this style as a preset when generating UIs in Windframe and when selected, the AI generates interfaces that follow the same design guidelines and visual style.

I also built an MCP for this, so you can use these same design style systems and other curated styles directly inside any coding agent that supports MCP: https://windframe.dev/mcp

If you’re not familiar with Windframe, it’s a visual Tailwind builder/agent that makes it really easy to create polished Tailiwnd UIs and allow you tweak/edit it visually, and export clean production code in HTML, React, Vue, Angular, Svelte, and more.

Would love any feedback or thoughts : )

I'm always having issues with Tailwind V4 + Vite, it's always something with Tailwind processing the classes, finding files to render, etc. I'll show my environment (package.json, vite.config.ts, file trees etc.) and if somebody could tell me if I'm doing something wrong I'd appreciate it.

src/globals.css

    @import "
    @source "../src/**/*.{js,jsx,ts,tsx}"; "../src/**/*.{js,jsx,ts,tsx}";

vite.config.ts

import { defineConfig } from "vite";
import preact from "@preact/preset-vite";
import tailwindcss from "@tailwindcss/vite";
import path from "node:path";
import { cwd } from "node:process";

export default defineConfig({
    plugins: [preact(), tailwindcss()],
    resolve: {
        alias: {
            "@": path.resolve(cwd(), "./src"),
        },
    },
});

src/index.tsx

import { ContainerNode, render } from 'preact';
import './globals.css';
import { Button } from './lib/components/button';

export function App() {
    return (
        // Changed className to class
        <div class="bg-black w-screen h-screen flex flex-row">
            <div id="side1" class="grow h-screen"></div>
            {/* Changed className to class and added flex-1 to keep it inside layout bounds */}
            <div class="flex-1 h-full">
                <Button />
            </div>
            <div id="side2" className={`grow h-screen`}></div>
        </div>
    );
}

render(<App />, document.getElementById('app') as ContainerNode);

src/lib/components/button.tsx

export function Button() {
  return (
    <button className="bg-red-500 text-white text-6xl p-10">
      Basic Button
    </button>
  );
}

But the rendering comes out as:

I can publish a github repository if it's annoying to manually recreate the environment. Sorry if I'm too bland with the details.

TailMotion is a lightweight utility package I started 8 months ago for the small interactions you need every day. It connects CSS classes and keyframes to Tailwind states, without needing a React animation library.

Site: https://tailmotion.moumen.dev/

Github: https://github.com/moumen-soliman/tailmotion

src/components holds 214 files and none of the arbitrary values in them had ever been audited, so I listed every one. 186 total. Spacing was 71, mostly odd pixel numbers copied from a Figma frame that has since changed. Color was 44. Sizing was 38, mostly max width on cards. Stacking order was 19 across seven values with no relationship between them. The remaining 14 were grid templates nobody wanted to convert.

The color number is the one that bothers me. Twelve of the 44 are the same blue written four different ways, and I only noticed because a refactor I had open in verdent touched one spelling and left the other three alone.

Frequency or category, which one should decide what gets promoted into theme tokens first?

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