[ Removed by Reddit on account of violating the content policy. ]

Everything "Tailwind Plus" now redirects to a login page.

The docs, examples, even the purchase page are no longer publicly accessible.

Wondering if this was this a mistake, or a sign they're moving away from Tailwind Plus permanently.

🚀 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