Coder Legion - Recent posts tagged tailwindcss

Your Flex Child Won't Shrink, and overflow: hidden Isn't the Fix (It's min-width: 0)"

Thu, 22 Oct 2026 15:08:46 +0000

You build a dashboard. Sidebar on the left, content on the right, a table or a code block inside. It looks perfect with your sample data.

Then a user pastes a long URL into a field, and the whole page grows a horizontal scrollbar. The sidebar gets squeezed, the layout breaks, and you start adding overflow: hidden to everything until the symptoms go away.

There is a one-line fix, and it is not overflow: hidden.

The Layout That Breaks

<div class="layout">
  <aside class="sidebar">Menu</aside>
  <main class="content">
    <pre>https://example.com/a-very-long-url-with-no-break-points-in-it-at-all-1234567890</pre>
  </main>
</div>

.layout {
  display: flex;
}
.sidebar {
  width: 240px;
  flex-shrink: 0;
}
.content {
  flex: 1;
}

.content is told to take the remaining space with flex: 1. Nobody told it to stay inside that space, and that is the entire problem.

Why It Happens

Flex items and grid items have a default of min-width: auto. For a flex item, auto means:

Do not shrink narrower than the smallest size your content can be.

For a paragraph of normal words, the smallest size is the longest single word, because the line can wrap between words. For a long URL, a <pre> block, a wide table or an image, there is nowhere to wrap, so the smallest size is the full width of the content.

So the browser is not ignoring your layout. It is obeying a rule you never knew existed: the item refuses to shrink below its content, and the overflow spills into the page.

Why `overflow: hidden` Looks Like a Fix (Sometimes)

Setting overflow to anything other than visible changes how min-width: auto is calculated. The automatic minimum becomes 0 for that item. That is why overflow: hidden on the right element makes the bug vanish.

It works by accident, and it has a cost: it clips content, can cut off focus outlines and dropdowns, and does nothing useful if you put it on the wrong element. Fixing the cause is cleaner.

Fix 1: min-width: 0 on the Flex Child

.content {
  flex: 1;
  min-width: 0;
}

You are telling the item that it is allowed to shrink below its content. Now .content stays inside its space, and the long URL can be scrolled, wrapped or cut off by something you control:

.content pre {
  overflow-x: auto;
}

In Tailwind, the utility is min-w-0:

<main class="flex-1 min-w-0">
  <pre class="overflow-x-auto">...</pre>
</main>

Fix 2: Grid's 1fr Has the Same Trap

.layout {
  display: grid;
  grid-template-columns: 240px 1fr;
}

1fr is not "one equal share, and no more". It is shorthand for minmax(auto, 1fr), so the column cannot get narrower than its content. The same long URL stretches the column and the page.

.layout {
  display: grid;
  grid-template-columns: 240px minmax(0, 1fr);
}

minmax(0, 1fr) allows the column to shrink to nothing if it has to. A useful side note for Tailwind users: grid-cols-2 and its siblings already compile to repeat(2, minmax(0, 1fr)), which is why many people never meet this bug in the grid, and then meet it as soon as they write a custom template column.

Fix 3: Truncating Text With an Ellipsis Inside Flex

This one catches almost everybody:

.row {
  display: flex;
  gap: 8px;
}
.title {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

It does not truncate, because the flex item sizes itself to the text. Add min-width: 0 to .title and the ellipsis appears. In Tailwind, truncate min-w-0 on the same element does it.

Fix 4: Long Words Need the Right overflow-wrap

For user-generated text such as comments, names and pasted links, allow breaking inside a word:

.comment {
  overflow-wrap: anywhere;
}

overflow-wrap: break-word looks equivalent, but it does not change the item's minimum size calculation, so inside a flex or grid item it can still leave the layout stretched. anywhere does take the break points into account, and the item can shrink.

Which One When

Symptom	Fix
Flex child pushes the page wider	`min-width: 0` on that child
Grid column grows past its space	`minmax(0, 1fr)` instead of `1fr`
Ellipsis not appearing in a flex row	`min-width: 0` plus the truncation rules
Long pasted word or URL	`overflow-wrap: anywhere`
Wide table or code block	Own scroll container with `overflow-x: auto`

The Rule

Flex and grid items refuse to shrink below their content by default. If something inside a layout can be wider than the space it is given, tell the container it is allowed to shrink with min-width: 0 or minmax(0, 1fr), and decide where the overflow should scroll or wrap.

Quick audit: open your app and paste a 200-character string with no spaces into every input that is later displayed. Then widen a table to 40 columns. If the page grows a horizontal scrollbar, you have found a missing min-width: 0.

I test every layout in my Next.js and Tailwind templates against this kind of hostile content, because real users do paste long strings, and a dashboard has to survive it.

Get the templates: https://pixelanas.gumroad.com

What is the ugliest layout bug a single piece of user content has caused you? Drop it in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Build a Slide-In Mobile Menu in TanStack Start with Tailwind v4

Sun, 18 Oct 2026 18:49:44 +0000

A mobile menu that pops in and out works, but it feels unfinished. In this article we turn it into a drawer that slides in from the right with a fading backdrop, using only Tailwind classes and no animation library. We also keep it usable for keyboard and screen-reader users, lock the page scroll while it is open, and respect the reduced-motion setting.

This is part of the TanStack Start Basics series. It builds on the responsive Header and the separate NavLinks component from the previous part.

You can view the video Here

In the previous part, the mobile menu lived in the Header, underneath the flex container, and the hamburger button toggled it. Delete it. This is the code to remove:

{open && (
  <nav
    id="mobile-menu"
    aria-label="Mobile"
    className="border-t md:hidden"
  >
    <NavLinks
      listClass="flex flex-col px-6 py-2"
      linkClass="block py-3 text-base font-medium text-neutral-600 hover:text-black"
      onNavigate={() => setOpen(false)}
    />
  </nav>
)}

When open is false, React removes this menu from the page completely. A CSS transition needs an element that exists in both the start and end states, so there is nothing to animate. The fix is a side panel that is always on the page, which we slide off screen with Tailwind.

Always render the panel

Here is the side panel. It replaces the old menu in the same position in the header. It uses a cn helper, so you will also need this function in the utils file in your lib folder. If you use shadcn/ui, you already have it. Otherwise, install clsx and tailwind-merge (npm i clsx tailwind-merge) and add:

// src/lib/utils.ts
import type { ClassValue } from 'clsx'
import { clsx } from 'clsx'
import { twMerge } from 'tailwind-merge'

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

The panel also uses the X icon, so add these imports at the top of Header.tsx if you don't have them yet:

import { X } from 'lucide-react'
import { cn } from '@/lib/utils'

<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl md:hidden',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

Make it jump in and out

To move the panel on and off the screen, add Tailwind's translate classes with a ternary on open:

open ? 'translate-x-0' : 'translate-x-full',

Add it as a second argument to cn on the <nav>:

<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl md:hidden',
    open ? 'translate-x-0' : 'translate-x-full',
  )}
>
  {/* the close button and NavLinks stay the same */}
</nav>

The panel now jumps on and off the screen, but it doesn't slide yet.

You may have noticed the helper function cn. It joins class names, skips the ones that are false, and if two Tailwind classes conflict, the last one wins.

Add the backdrop

Next, a dark layer behind the panel. Clicking it closes the menu, which is what people expect from a drawer. It sits one layer below the panel (z-40 against z-50) and covers the whole screen. When the menu is closed it must not catch clicks, so pointer-events-none is not optional here. Without it, an invisible full-screen layer would swallow every tap on the page. Put it right above the <nav>:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>

This is how it should look in your code:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>
<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl md:hidden',
    open ? 'translate-x-0' : 'translate-x-full',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

Make it slide

Now the fun part, and it takes two classes. transition-transform tells the browser to animate changes to the position, duration-300 makes it take 300 milliseconds, and ease-out makes it start fast and settle gently. The backdrop gets the same treatment, but it fades, so it uses transition-opacity.

Add this to the panel:

transition-transform duration-300 ease-out

Add this to the backdrop:

transition-opacity duration-300

Your code should look like this:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 transition-opacity duration-300 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>
<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl transition-transform duration-300 ease-out md:hidden',
    open ? 'translate-x-0' : 'translate-x-full',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

One Tailwind v4 detail: translate-x-* sets the CSS translate property, not transform. In v4, transition-transform includes translate, so this works. If a slide ever refuses to animate, check that your transition covers translate.

Hide the closed panel

It looks right, but there is a catch. The panel is only parked off screen. Press Tab with the menu closed and focus disappears into links you can't see, and a screen reader will still read them out. The fix is the invisible class when the menu is closed.

If we add invisible and nothing else, the panel vanishes the instant you close it, and the slide-out never shows. So we also tell the transition to animate visibility, not just position. The browser keeps the panel visible until the slide finishes, then hides it.

Make two changes to the panel:

Replace transition-transform with transition-[translate,visibility].
Replace translate-x-full with invisible translate-x-full.

Your code should look like this:

<div
  aria-hidden="true"
  onClick={() => setOpen(false)}
  className={cn(
    'fixed inset-0 z-40 bg-black/50 transition-opacity duration-300 md:hidden',
    open ? 'opacity-100' : 'pointer-events-none opacity-0',
  )}
/>
<nav
  id="mobile-menu"
  aria-label="Mobile"
  className={cn(
    'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl transition-[translate,visibility] duration-300 ease-out md:hidden',
    open ? 'translate-x-0' : 'invisible translate-x-full',
  )}
>
  <button
    type="button"
    onClick={() => setOpen(false)}
    aria-label="Close menu"
    className="mb-6 ml-auto block rounded p-2 hover:bg-gray-100"
  >
    <X className="size-6" />
  </button>
  <NavLinks
    listClass="flex flex-col gap-4"
    linkClass="text-lg text-gray-600 hover:text-black"
    onNavigate={() => setOpen(false)}
  />
</nav>

Stop the page from scrolling

With the drawer open, scrolling still moves the page behind it, which feels sloppy. We already have an effect that listens for the Escape key, so we extend it: lock scrolling when the menu opens, and unlock it in the cleanup. Replace the useEffect from the previous part, the one that closes the menu on Escape, with this:

useEffect(() => {
  if (!open) return

  const onKeyDown = (e: KeyboardEvent) => {
    if (e.key === 'Escape') setOpen(false)
  }

  document.addEventListener('keydown', onKeyDown)
  document.body.style.overflow = 'hidden'

  return () => {
    document.removeEventListener('keydown', onKeyDown)
    document.body.style.overflow = ''
  }
}, [open])

The cleanup function runs when the menu closes and also if the Header ever unmounts, so the page can never get stuck locked.

Respect reduced motion (optional)

Some people turn on "reduce motion" in their system settings because animation makes them dizzy. Tailwind gives us a variant for that, motion-reduce:, so honoring it costs one class per element. If that's you, add motion-reduce:transition-none to the panel and the backdrop, like so.

Panel:

className={cn(
  'fixed inset-y-0 right-0 z-50 w-72 bg-white p-6 shadow-xl transition-[translate,visibility] duration-300 ease-out motion-reduce:transition-none md:hidden',
  open ? 'translate-x-0' : 'invisible translate-x-full',
)}

Backdrop:

className={cn(
  'fixed inset-0 z-40 bg-black/50 transition-opacity duration-300 motion-reduce:transition-none md:hidden',
  open ? 'opacity-100' : 'pointer-events-none opacity-0',
)}

Test it and wrap up

Open the menu: the panel slides in and the backdrop fades.
Click the backdrop: the menu closes.
Open it again and press Escape: it closes.
Open it and click a link: it navigates and closes.
Close the menu and press Tab: focus skips the hidden links.
Open the menu and try to scroll the page: it stays put.
Turn on reduced motion in your system settings: the menu appears with no animation.

Let's recap. We always render the panel and move it with translate. The backdrop fades and closes the menu. transition-[translate,visibility] keeps the slide-out visible, then hides the panel from keyboards and screen readers. We locked the page scroll, and we respect reduced motion. All of it is plain Tailwind classes and one small effect.

Good to know and what to try next

A gotcha: a fixed element is positioned against the viewport unless an ancestor has a transform, filter or backdrop-filter. If your header uses backdrop-blur, move the backdrop and panel outside the <header> element or the drawer will be sized to the header instead of the screen.

Tell screen readers the menu state: the hamburger button from the previous part should announce whether the menu is open. Add aria-expanded and aria-controls (the <nav> already has id="mobile-menu"), and keep the label constant, because the state comes from aria-expanded and a label that flips between "Open" and "Close" can make it get announced twice. If your button already has a label like "Open menu", change it to a fixed one:

<button
  type="button"
  onClick={() => setOpen((o) => !o)}
  aria-expanded={open}
  aria-controls="mobile-menu"
  aria-label="Menu"
>
  {/* your hamburger icon */}
</button>

Try next:

Close the menu automatically when the window grows past the md breakpoint, so the scroll lock can never be left on.
Move focus to the Close button when the menu opens, and back to the hamburger when it closes.
Swap the slide for a left-side drawer by changing right-0 to left-0 and translate-x-full to -translate-x-full.

Next in the series: error handling and a proper not-found page.

Responsive Navigation in TanStack Start: Hamburger Menu and Desktop Navbar

Fri, 16 Oct 2026 02:14:20 +0000

A header that works on a phone and on a desktop is one of the first things every site needs. In this part of the TanStack Start Basics series, we'll build one with inline links on wide screens, a hamburger menu on small ones, and a few accessibility details that are easy to skip.

You can watch the video here: Responsive Navigation. Everything below is the written version.

Write the links once

Start with a single list of links that both menus will read from:

// src/lib/nav.ts
export const navLinks = [
  { to: '/', label: 'Home' },
  { to: '/products', label: 'Products' },
  { to: '/about', label: 'About' },
  { to: '/contact', label: 'Contact' },
] as const;

The as const lets TypeScript treat every to as an exact route, so a typo is a compile error and not a broken link.

Think mobile first

Tailwind is mobile first. Classes without a prefix apply to every screen size, and a prefix such as md: applies from that width upward. So the plan is to style the phone version first, and then add the desktop changes on top:

hidden md:block is hidden on phones and shown from 768px up (the desktop links)
md:hidden is shown on phones and hidden from 768px up (the menu button and the mobile menu)

A separate NavLinks component

Both menus need the same list of links, so it gets its own component. Start with the props type:

// src/types/index.ts
export type NavLinksProps = {
  listClass: string;
  linkClass: string;
  activeClass?: string;
  onNavigate?: () => void;
};

Then the component:

// src/components/NavLinks.tsx
import { Link } from '@tanstack/react-router';
import { navLinks } from '@/lib/nav';
import type { NavLinksProps } from '@/types';

export default function NavLinks({
  listClass,
  linkClass,
  activeClass = 'text-black underline underline-offset-4',
  onNavigate,
}: NavLinksProps) {
  return (
    <ul className={listClass}>
      {navLinks.map((link) => (
        <li key={link.to}>
          <Link
            to={link.to}
            activeOptions={{ exact: link.to === '/' }}
            className={linkClass}
            activeProps={{ className: activeClass }}
            onClick={onNavigate}
          >
            {link.label}
          </Link>
        </li>
      ))}
    </ul>
  );
}

The two class props let each menu style the list its own way. activeClass has a default, so most callers can leave it out, and onNavigate is optional, so the desktop menu doesn't need it. Because the component lives in its own file, you can reuse it later, in a footer for example, without copying anything.

The header

// src/components/Header.tsx
import { useEffect, useState } from 'react';
import { Link } from '@tanstack/react-router';
import { Menu, X } from 'lucide-react';
import NavLinks from '@/components/NavLinks';

export default function Header() {
  const [open, setOpen] = useState(false);

  useEffect(() => {
    if (!open) return;
    const onKeyDown = (e: KeyboardEvent) => {
      if (e.key === 'Escape') setOpen(false);
    };
    window.addEventListener('keydown', onKeyDown);
    return () => window.removeEventListener('keydown', onKeyDown);
  }, [open]);

  return (
    <header className="border-b bg-white">
      <div className="mx-auto flex h-16 max-w-6xl items-center justify-between px-6">
        <Link to="/" className="text-lg font-bold">
          My Store
        </Link>

        <nav aria-label="Main" className="hidden md:block">
          <NavLinks
            listClass="flex items-center gap-6"
            linkClass="text-sm font-medium text-neutral-600 hover:text-black"
          />
        </nav>

        <button
          type="button"
          onClick={() => setOpen((o) => !o)}
          aria-label={open ? 'Close menu' : 'Open menu'}
          aria-expanded={open}
          aria-controls="mobile-menu"
          className="flex size-11 items-center justify-center rounded-md md:hidden"
        >
          {open ? <X className="size-6" /> : <Menu className="size-6" />}
        </button>
      </div>

      {open && (
        <nav
          id="mobile-menu"
          aria-label="Mobile"
          className="border-t md:hidden"
        >
          <NavLinks
            listClass="flex flex-col px-6 py-2"
            linkClass="block py-3 text-base font-medium text-neutral-600 hover:text-black"
            onNavigate={() => setOpen(false)}
          />
        </nav>
      )}
    </header>
  );
}

If you skip this, you'll notice a bug: you tap a link, the page changes, and the menu stays open. The header lives in a layout route, and a layout stays mounted while the pages inside it change, so its state is never reset.

The fix is to close the menu in the link's click handler, which is where the user's action happens. React's documentation recommends handling things caused by a user action in the event handler for that action, and not in an effect. So NavLinks gets an optional onNavigate prop, and only the mobile menu passes () => setOpen(false).

This also closes the menu when you tap the link for the page you're already on, which an effect that watches the path would miss. If you also want the menu to close when the user presses the browser's back button, you can add an effect that watches the path on top of this, but the click handler covers the main case.

Active links

Link knows when it points at the current page, and activeProps lets you style that state. Every path starts with a slash, so the home link would look active everywhere. activeOptions={{ exact: true }} fixes that, and the code above applies it only to the home link.

Accessibility basics

Use a real button for the toggle, with type="button", so the keyboard can reach it
Label it with aria-label, and update the label with the state
Use aria-expanded and aria-controls so assistive technology knows whether the menu is open
Close the menu with the Escape key
Give each nav its own label, so a screen reader user can tell them apart

Use it in the layout

// src/routes/_appLayout.tsx
import { createFileRoute, Outlet } from '@tanstack/react-router';
import Header from '@/components/Header';

export const Route = createFileRoute('/_appLayout')({
  component: AppLayout,
});

function AppLayout() {
  return (
    <>
      <Header />
      <main className="mx-auto max-w-6xl px-6 py-8">
        <Outlet />
      </main>
    </>
  );
}

Try it

Open your browser's device toolbar and drag the width between 375px and 1024px. The hamburger should appear below 768px, and the inline links above it. Tap a link in the mobile menu and check that it closes.

What's next

In the next part, we'll look at slide-in animation and a dark mode toggle. If you got stuck anywhere, leave a comment on the video.

Why Your Tailwind Classes Work in Development and Silently Vanish in Production

Thu, 15 Oct 2026 12:05:37 +0000

Almost every Tailwind developer hits this exact bug once, usually right after a deploy, and the confusing part is that nothing about it looks wrong in the code, nothing throws an error, and it worked completely fine five minutes earlier on the same machine.

The Code That Looks Completely Reasonable

function StatusBadge({ status }: { status: 'success' | 'warning' | 'error' }) {
  const color = status === 'success' ? 'green' : status === 'warning' ? 'yellow' : 'red';

  return (
    <span className={`bg-${color}-100 text-${color}-800 px-2 py-1 rounded`}>
      {status}
    </span>
  );
}

In development, this renders exactly as expected, colored badges for each status, built dynamically from a single reusable component instead of three separate hardcoded ones. Then you deploy, and every badge renders as a plain, unstyled span. No color, no padding in some setups, nothing, depending on exactly what else got purged alongside it.

Why This Happens: Tailwind Doesn't Actually Execute Your Code

Tailwind doesn't run your JavaScript to figure out which classes you're using. It scans your source files as plain text, looking for strings that match known utility class patterns, and only generates CSS for the classes it actually finds written out, literally, somewhere in that scanned text.

className={`bg-${color}-100 text-${color}-800`}

Tailwind's scanner sees the literal text bg-${color}-100, not bg-green-100, bg-yellow-100, or bg-red-100. Template literal interpolation happens at runtime, in the browser or on your server, long after Tailwind's build step has already finished scanning your source files and generating the final CSS. Since none of the three actual color classes your component needs ever appears as literal, complete text anywhere in your codebase, Tailwind never generates CSS for any of them, and the class names that do get applied to the DOM at runtime simply don't exist in your stylesheet at all.

Why This Specifically Survives Local Development

This is the part that makes the bug genuinely sneaky rather than just a misunderstanding: in development mode, especially with certain dev server configurations or cached builds from before the dynamic class was introduced, you can sometimes see the correct styling anyway, either because an earlier full build still has the class generated from some other literal usage elsewhere in the project, or because of how some dev tooling handles incremental rebuilds. The failure shows up specifically in a clean production build, which scans and purges from scratch, with nothing left over from earlier development sessions to accidentally mask the problem.

The Fix: Always Write Complete Class Names, Literally

function StatusBadge({ status }: { status: 'success' | 'warning' | 'error' }) {
  const styles = {
    success: 'bg-green-100 text-green-800',
    warning: 'bg-yellow-100 text-yellow-800',
    error: 'bg-red-100 text-red-800',
  };

  return (
    <span className={`${styles[status]} px-2 py-1 rounded`}>
      {status}
    </span>
  );
}

Every complete, literal class name Tailwind needs now appears as actual text somewhere in the source file, bg-green-100, bg-yellow-100, bg-red-100, text-green-800, and so on, even though the specific one that gets applied is still chosen dynamically at runtime based on status. Tailwind's scanner finds all three as literal strings during the build, generates CSS for all three, and the correct one gets applied correctly regardless of which branch of the mapping object actually executes.

The Rule That Generalizes Beyond This One Example

Tailwind only generates CSS for class names that exist as complete, literal text somewhere in your scanned source files, string concatenation and template literal interpolation don't count, no matter how confident the resulting string looks at runtime. This applies to any dynamic styling pattern, not just color variants, conditionally built spacing classes, responsive variants built from a variable, state-based classes constructed from a prop, all of them need the complete literal class name written out somewhere Tailwind's scanner can see it, usually in a lookup object exactly like the one above, rather than assembled through string interpolation.

I keep every dynamic variant mapped out explicitly like this across the component libraries in my Next.js and Tailwind templates, specifically because this exact bug is so easy to reintroduce months later when someone, often future-you, refactors a component back toward the more compact-looking interpolated version without remembering why it was written the longer way.

Get the templates: https://pixelanas.gumroad.com

Go check your own codebase for className={...${variable}...} patterns building Tailwind classes dynamically. If you find one, do a clean production build and actually look at it, don't trust how it renders in dev. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Setting Up Our Frontend with TanStack Start

Tue, 08 Sep 2026 15:45:44 +0000

We've finished our backend series — a Directus instance running on a VPS managed by Coolify, backed by PostgreSQL and Redis, with a products collection already built and secured with roles and permissions.

Now it's time to build a frontend to actually display that data. For this, we're using TanStack Start, Tailwind CSS, and shadcn/ui. This post covers getting TanStack Start installed and running.

What Is TanStack Start?

Straight from the official docs:

TanStack Start is a full-stack React framework powered by TanStack Router. It provides full-document SSR, streaming, server functions, client/server builds, and more. With Vite and Rsbuild support, it's ready to develop and deploy to the hosting provider or runtime you want.

In short: it offers the same kind of full-stack capability as frameworks like Next.js or Remix, built on top of TanStack Router.

Creating the Project

First, create a folder for your app. I'm naming mine app_fe — "fe" for front end.

Naming convention tip: I use <app-name>_fe for all my frontend project folders — so an e-commerce project would be store_fe. Makes the folder's purpose obvious at a glance.

From inside that folder, run:

npx @tanstack/cli@latest create .

Note the trailing dot. Since we created the folder ourselves beforehand, the dot tells the CLI to install directly into the current directory. Omit the dot if you'd rather the CLI create a new folder for you.

Walking Through the Setup Prompts

The CLI will walk you through a series of choices:

Prompt	Selection
Select Framework	React
Select Toolchain	ESLint
Select Deployment Adapter	None (self-hosting on our own VPS)
Include demo/example pages?	No
What add-ons would you like?	shadcn/ui
Initialize a new git repository?	Yes
Continue with these settings?	Yes

Wait for the install to finish.

Running the App

Navigate into your app directory (if you aren't already there) and run:

npm run dev

Open your browser to http://localhost:3000. Congratulations — your TanStack Start app is up and running.

Editing the Home Page

Open src/routes/index.tsx. Delete everything inside the div, and save — your home page should now be completely blank. This file is your landing page, the first thing visitors see.

Add an h1 tag inside the empty div:

<h1>Home</h1>

Save, and you'll see "Home" rendered on the page. Now let's add some Tailwind styling:

<h1 className="font-bold text-5xl text-slate-700">Home</h1>

Save again — notice Tailwind works right out of the box, no extra configuration needed.

File-Based Routing

TanStack Start runs on TanStack Router, which uses file-based routing. Every file added to the routes folder automatically becomes a navigable page.

Adding an About Page

Create src/routes/about.tsx:

<div className="p-8">
  <h1 className="font-bold text-5xl text-slate-700">About</h1>
</div>

Save, then visit http://localhost:3000/about. Notice the home page lives at localhost:3000/, and the about page lives at localhost:3000/about — TanStack Start handled that routing automatically, purely based on the filename.

Adding a Products Page

Create src/routes/products.tsx the same way:

<div className="p-8">
  <h1 className="font-bold text-5xl text-slate-700">Products</h1>
</div>

Visit localhost:3000/products, and there's your new page. That's as simple as basic routing gets — there's plenty more you can do with nested and dynamic routes, which we'll cover as it becomes relevant.

What Is That `__root.tsx` File?

You've probably noticed a file called __root.tsx sitting in your routes folder. Here's the simplest way to think about it:

Picture any large website — Amazon, YouTube, anything. Every page has a header up top and often a footer at the bottom that never change, no matter what page you're on. But the content in the middle changes depending on where you navigated.

__root.tsx is the file that builds that "never changes" part. It's the frame around every page in your app. Every route you build — home, about, products — gets rendered inside this one file. Write it once, and every page automatically inherits it.

A word of caution: this file is central to how TanStack Router works under the hood. Avoid modifying it until you understand exactly what each piece does — we'll take a closer look at it in an upcoming post, exactly when it becomes relevant to what we're building.

Summary

In this part, we:

Installed and configured a new TanStack Start project
Ran it locally and confirmed Tailwind works out of the box
Learned file-based routing by building About and Products pages
Got introduced to __root.tsx, the file behind every page in the app

That wraps up our frontend setup. Next up, we'll start pulling real data from our Directus backend into this frontend — connecting everything we've built across this series.

Found this useful? Follow for more Directus and TanStack Start tutorials, or check out the video version above.

Why I Replaced Tailwind CSS With Vanilla CSS

Thu, 06 Aug 2026 12:39:32 +0000

I removed Tailwind CSS from this site and rewrote every style by hand in vanilla CSS. The reason is short: modern CSS now does natively what I was pulling Tailwind in to get. Cascade layers, custom properties, nesting, and :has() all ship in every current browser, and Tailwind v4 is built on those exact primitives. Once the browser speaks the language directly, a build step that generates it for you reads as overhead rather than leverage. When I rebuilt this site in December 2025 I reached for Tailwind v4 on instinct. This month I took it back out.

TL;DR

The features I used Tailwind for (design tokens, nesting, scoping, a consistent scale) are now native CSS or handled by Astro's scoped styles.
Tailwind v4 is itself built on native cascade layers, custom properties, and color-mix(), with Lightning CSS doing the build. I was shipping an engine to generate CSS the browser already understands.
The migration dropped three Tailwind packages, moved global styles into native @layers, and put every component's styles in Astro's scoped <style> blocks.
The site stayed Baseline Widely available the whole way.

Why replace Tailwind at all?

Because the job Tailwind did for me is now built into the platform. When I list what I actually reached for it to solve, every item has a native answer today:

What I used Tailwind for	The vanilla replacement	Baseline Widely since
Style layering and predictable overrides	`@layer` cascade layers	Sept 2024
Design tokens and theming	Custom properties (`--x`)	long-standing
Nesting without a preprocessor	Native CSS nesting (`&`)	June 2026
Parent and state selectors	`:has()`	June 2026
Component-scoped responsive rules	Container queries and Astro scoped styles	Aug 2025

The dates are the point. CSS nesting and :has() only crossed into Baseline Widely availability around June 2026, roughly two months before I did this. Cascade layers got there in September 2024, color-mix() in November 2025, size container queries in August 2025. The Chrome team's CSS Wrapped 2025 counted 22 new CSS features landing in Chrome in a single year. The gap Tailwind was filling closed while I wasn't looking, and 2026 is the year it actually finished closing.

None of this makes Tailwind bad. It makes it optional for what I'm doing here: a single-author content site where nobody but me touches the CSS.

Tailwind v4 already runs on the CSS I switched to

The thing that tipped me over was reading how Tailwind v4 works under the hood. Its January 2025 rewrite is explicit that it is built on modern CSS. The announcement lists "native cascade layers," "registered custom properties," "color-mix()," and logical properties as the foundation. The earlier post introducing its Oxide engine is blunter about the plumbing: the engine is "up to 10x faster," and "the only thing the new engine depends on is Lightning CSS."

Read that back with a migration in mind. Tailwind v4 generates native cascade layers, sets custom properties, and runs the output through Lightning CSS for prefixing and minification. That is the same stack I now write directly. I was running an engine whose job was to emit CSS features my target browsers already implement. For an app with dozens of engineers and a shared design system, that engine buys you consistency and guardrails worth paying for. For this site, it was a generator sitting between me and CSS I could just write.

There is a small irony worth stating plainly. Tailwind v4 leans on registered custom properties (@property), which won't reach Baseline Widely availability until around January 2027, so Tailwind ships its own fallbacks for it. My hand-written CSS holds a stricter bar than the framework I removed.

What the migration actually looked like

The site is Astro, so it splits cleanly in two: global styles in src/styles, and per-component styles in each .astro file's scoped <style> block. I rewrote both.

Cascade layers replace the Tailwind import

The old entry point started with Tailwind's import, its typography plugin, and a @custom-variant line for every palette so theme selectors would compile:

@import "tailwindcss";
@plugin "@tailwindcss/typography";

@custom-variant tokyo-night (&:where([data-theme="tokyo-night"]));
@custom-variant dracula (&:where([data-theme="dracula"]));
/* ...thirteen more palettes... */
@custom-variant dark (&:where([data-mode="dark"], [data-mode="dark"] *));

Fifteen @custom-variant declarations, one per palette, plus one for dark mode, all to teach the framework about selectors the browser already understands. The replacement is one line of real CSS that declares the cascade order, then a plain file per layer:

@layer reset, tokens, base, primitives, prose, utilities;

Ordering the layers by hand turned out to be the feature I most underrated in Tailwind. Layers win by declaration order regardless of selector specificity, so the reset can be dead simple, tokens can sit under everything, and utilities win last without a single !important. I get the exact override behavior Tailwind gave me, spelled out in one readable statement.

Design tokens are just custom properties

Theming didn't really change, which is the tell. Under Tailwind the palettes were already CSS variables swapped by a data-theme attribute; the framework just wrapped them in @theme and @custom-variant. Stripping that wrapper left plain rules:

:root,
[data-theme="catppuccin-mocha"] {
  --bg: #11111b;
  --ink: #cdd6f4;
  --accent: #89b4fa;
  /* ...the rest of the reduced token set... */
}

Sixteen of those blocks, one per theme, in a tokens layer. The switcher sets data-theme on <html>, the variables cascade in, and syntax highlighting tracks them through more variables. No config object, no plugin API, just the custom properties that were doing the work all along.

Components: from class lists to scoped styles

This is where the day-to-day difference shows. Here is the card component before, as a Tailwind class list:

<article
  class:list={[
    "relative rounded border bg-card p-4 sm:p-6",
    "has-focus-visible:outline-2 has-focus-visible:outline-offset-2 has-focus-visible:outline-ring",
    className,
  ]}
  {...props}
>
  <slot />
</article>

And after, as scoped CSS in the same file:

<article class={className} {...props}>
  <slot />
</article>

<style>
  article {
    position: relative;
    border-radius: var(--radius);
    border-width: 1px;
    background-color: var(--bg-elevated);
    padding: 1rem;

    &:has(:focus-visible) {
      outline: 2px solid var(--accent);
      outline-offset: 2px;
    }
  }

  @media (width >= 40rem) {
    article {
      padding: 1.5rem;
    }
  }
</style>

The markup goes quiet and the intent moves into CSS that reads like CSS. Native nesting holds the :has() state rule next to the base rule, and a normal media query handles the responsive padding that sm:p-6 used to encode. Astro scopes these styles through a generated data-astro-cid attribute, so a bare article selector is enough and the element needs no class of its own. And because scoped styles compile unlayered, they beat the global layers without any specificity games. That last property is what made the migration safe to do component by component: a scoped rule always wins over a global primitive, so I could move one file at a time without the two systems fighting.

Lightning CSS does the vendor work

The reflex worry with dropping a framework is that you inherit its chores: prefixing, downleveling new syntax, minifying. I inherited none of them, because Lightning CSS was already in the pipeline. It's a Rust parser, transformer, and minifier by Devon Govett, and it is the same tool Tailwind v4's Oxide engine depends on. Astro's Rust compiler uses it too, so turning it on for my own CSS was one line:

vite: {
  css: { transformer: "lightningcss" },
  build: {
    cssTarget: ["chrome111", "edge111", "firefox114", "safari16.4", "ios16.4"],
  },
}

It adds the handful of -webkit- prefixes my target browsers still need, lowers nesting for the stragglers, and minifies, all against a Baseline target set. The package.json diff was the satisfying part: out went tailwindcss, @tailwindcss/vite, and @tailwindcss/typography; in went a single lightningcss dev dependency that was effectively already there. The long-form article styling followed the same instinct I wrote about in shadcn/typeset vs Tailwind Typography: own the file, delete the rules you don't want.

Did the site stay Baseline compliant?

Yes, and that was a hard constraint, not a nice-to-have. Every feature this site ships has to be Baseline Widely available, interoperable across the core browsers for at least 30 months. That's exactly why the timing worked: the two features I lean on hardest, native nesting and :has(), only reached Widely availability around June 2026. If I'd tried this a year earlier they'd have been Baseline Newly at best, and the card component above would have needed an @supports gate with a full fallback. Doing it now, they're safe to use unguarded. The one place I still gate behind @supports is the anchor-positioned reading indicator in the table of contents, which is genuinely still Newly available.

Do you still need Tailwind in 2026?

Only if someone other than you owns the CSS. That is the honest split, and it decides whether replacing Tailwind with vanilla CSS is worth it for you:

A team with a shared design system: probably keep Tailwind. The constraints that feel like overhead on a solo site are the whole point when twenty people style the same product. Consistency you don't have to enforce by review is worth a build step.
A solo project or a content site: the trade-off has flipped. You get design tokens from custom properties, override control from cascade layers, nesting and state selectors natively, and scoping from your framework's components. The framework's value is real but no longer necessary.

I'm not claiming Tailwind lost. Kevin Powell has spent years arguing that learning CSS itself pays off, and the platform finally caught up to make that cheap. Tailwind v4 is a genuinely good piece of engineering, built on the same modern CSS that made me comfortable leaving it. For this site, hand-written CSS wired to theme variables is less code, one fewer dependency, and output I can read top to bottom. That's the same own-the-source call I keep making here, and this time the browser did most of the work for me.

Tailwind CSS for Beginners: From Zero to Your First Component

Tue, 21 Jul 2026 05:00:00 +0000

Introduction

The first time I saw a Tailwind CSS class list — something like flex items-center justify-between p-4 bg-slate-800 rounded-lg shadow-md — I genuinely thought it looked messy. Why not just write regular CSS?

Then I actually used it on a real project, and within a week I understood why so many developers (myself included now) switched permanently. You stop context-switching between HTML and a separate CSS file, you stop naming classes like .card-wrapper-inner-2, and you build UI noticeably faster.

This is the guide I wish I had when I started.

What Tailwind CSS Actually Is

Tailwind is a utility-first CSS framework. Instead of writing custom CSS classes, you compose your design directly in your HTML using small, single-purpose utility classes.

Regular CSS:

.button {
  padding: 8px 16px;
  background-color: #3b82f6;
  border-radius: 8px;
  color: white;
}

Tailwind:

<button class="px-4 py-2 bg-blue-500 rounded-lg text-white">
  Click Me
</button>

Same result. No separate CSS file needed for this button.

Setting It Up (React + Vite)

npm create vite@latest my-app -- --template react
cd my-app
npm install tailwindcss @tailwindcss/vite

In vite.config.js:

import tailwindcss from '@tailwindcss/vite'

export default {
  plugins: [tailwindcss()],
}

In your main CSS file:

@import "tailwindcss";

That's it — no separate config file required for modern Tailwind setups. Restart your dev server and you're ready to use utility classes anywhere.

Core Concepts You Need to Know

1. Spacing

p-4 = padding on all sides, px-4 = horizontal padding only, py-4 = vertical only, m-4 = margin. The number is a spacing scale (4 = 1rem = 16px).

2. Flexbox & Grid utilities

flex, items-center, justify-between, grid, grid-cols-3, gap-4 — everything from the Flexbox/Grid article, just as classes.

3. Responsive Design

Prefix any class with a breakpoint: md:flex-row means "apply this on medium screens and up."

<div class="flex flex-col md:flex-row gap-4">

This stacks items vertically on mobile, then switches to a row on tablets and larger.

4. Hover & State Variants

<button class="bg-blue-500 hover:bg-blue-600 transition">

hover: applies only on hover. Same pattern works for focus:, active:, disabled:.

Building Your First Component: A Pricing Card

<div class="max-w-sm mx-auto bg-slate-800 rounded-2xl p-6 shadow-lg">
  <h3 class="text-xl font-bold text-white mb-2">Starter Plan</h3>
  <p class="text-slate-400 mb-4">Perfect for small projects</p>
  <p class="text-3xl font-bold text-white mb-6">$9<span class="text-base font-normal text-slate-400">/mo</span></p>
  <button class="w-full py-2 bg-blue-500 hover:bg-blue-600 rounded-lg text-white font-medium transition">
    Get Started
  </button>
</div>

Notice what's happening: max-w-sm mx-auto centers and constrains the card width, rounded-2xl and shadow-lg give it depth, and everything is readable directly from the class names — no jumping to a separate file to understand the styling.

Common Beginner Mistakes

Fighting the spacing scale. Don't reach for custom pixel values
immediately — Tailwind's default scale (4, 8, 12, 16...) covers 95%
of real use cases.
Not using @apply for repeated patterns. If you're copy-pasting the
same 8 classes everywhere, extract them into a component instead of
a CSS class — that's the React way to do it, not @apply.
Ignoring the official docs. Tailwind's docs (tailwindcss.com) are
genuinely excellent — searchable, example-driven, and the fastest
way to find the exact class you need.

Final Thoughts

Tailwind feels weird for about a week, then it feels like the only sane way to write CSS. The speed difference is real — I build UI noticeably faster now than when I wrote custom CSS files for every component.

Start small: rebuild one existing component using Tailwind instead of your old CSS, and see how it feels.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

shadcn/typeset vs Tailwind Typography for Markdown

Sat, 18 Jul 2026 16:44:34 +0000

You render some markdown, get back a pile of unstyled HTML, and then you style it. Headings, paragraphs, lists, tables, code. You do it for the blog. Then you do it again for the docs. Then a third time for the chat UI that streams model output token by token. Every context, the same elements, slightly different rules.

shadcn shipped a take on this on July 10, 2026, called shadcn/typeset. It's worth a look even if you don't use the rest of shadcn/ui, because it isn't a component and it isn't a CLI install. It's one CSS file you copy into your project and own outright.

What is shadcn/typeset?

Typeset is a styling system for rendered HTML and markdown, delivered as a single CSS file. You wrap your content in a .typeset container and everything inside it gets styled: headings, paragraphs, lists, tables, code, blockquotes, links, footnotes, even MathML and <details>.

<div className="typeset typeset-docs">
  <YourMarkdownRenderer>{content}</YourMarkdownRenderer>
</div>

.typeset turns the styles on. .typeset-docs is a preset, a small class you layer on top to tune the look for a specific context. You can define as many presets as you have contexts: one for the blog, one for the docs, one for chat.

The thing to internalize up front: there's no npm package and no config layer. As the changelog puts it, "the file lives in your project," nothing to update, nothing to work around. If a heading annoys you, you open the file and change the rule. That's the whole distribution model.

This is a different thing from shadcn/ui's Typography component, which gives you styled React heading and paragraph components to author by hand. Typeset styles HTML you didn't write, the output of a markdown renderer.

How do you install shadcn/typeset?

You don't run a CLI. As of this release there's no npx shadcn@latest add typeset, and expecting one will send you looking for a command that doesn't exist.

Instead you build the file in the interactive builder, pick your sizes and fonts, and copy the generated typeset.css into your project. Then you import it after Tailwind:

@import "tailwindcss";
@import "./typeset.css";

Import order matters, and I'll come back to why in a moment. Once it's in, the wrapper from the first snippet is all you need.

Size, leading, and flow

Typeset condenses typographic tuning into three CSS variables it calls "rhythm," and everything else derives from them:

.typeset {
  --typeset-size: 1em;      /* base font size */
  --typeset-leading: 1.75;  /* line-height */
  --typeset-flow: 1.25em;   /* vertical space between blocks */
}

A preset is just those three variables set to different values under a class name:

.typeset-chat {
  --typeset-flow: 1em;
  --typeset-leading: 1.6;
}
.typeset-docs {
  --typeset-size: 15px;
  --typeset-flow: 1.5em;
}

Because it's all CSS custom properties, you can override a single value inline without touching the file:

<article className="typeset [--typeset-flow:1.75em]">{content}</article>

The sizing is container-relative rather than a fixed rem scale. Below 48rem the base size gets a 1.125x bump and then settles back to the raw value on larger screens, so text reads comfortably on a phone without a separate small-screen variant. Colors and borders pull from your app's theme tokens (--color-foreground, --color-muted-foreground, --color-border, --radius) with sensible fallbacks, so dark mode just works when your tokens flip. There's no second inverted palette to maintain.

One deliberate omission: Typeset doesn't set a max-width. Your layout owns the measure. The builder's Measure control adds a max-width to the wrapper if you want it, but the stylesheet itself stays out of your layout's business.

Why your Tailwind utilities win without !important

Here's the detail I liked most. Typeset lives in the CSS @components layer and uses zero-specificity :where() selectors for every element rule:

@layer components {
  .typeset {
    & :where(h1) { font-size: 1.75em; /* ... */ }
    & :where(p)  { margin-block-start: var(--typeset-flow); }
  }
}

The override comes from cascade layers, not specificity. Typeset's rules live in the @components layer, and Tailwind's utilities live in the @utilities layer, which is declared after it. When rules in two different layers conflict, the later layer wins outright, no matter how specific either selector is. So a utility beats a Typeset rule with no !important and no special modifier syntax. Slap .text-3xl on a heading and it just wins.

:where() does a related but separate job: it holds every element rule at zero specificity, so an override that isn't already shielded by a later layer, like plain CSS you write yourself or a rule in the same layer, can still win without a specificity fight. That's also why import order matters. Importing Tailwind first establishes its layer order, which puts @utilities after Typeset's @components.

If you want to pull a whole subtree out, there's an escape hatch: .not-typeset (or the data-not-typeset attribute), which cascades to descendants including any nested .typeset container.

<Card className="not-typeset">Untouched component.</Card>

shadcn is candid that both of these ideas, the :where() guard and the opt-out class, are borrowed from @tailwindcss/typography, which has a .not-prose of its own. Which brings us to the comparison you actually clicked for.

shadcn/typeset vs Tailwind Typography

The Tailwind CSS Typography plugin, and the .prose class it hands you, has been the default answer for styling rendered markdown for years, and it's still excellent at what it was built for. Typeset isn't a drop-in replacement or a wrapper around it. It's a different set of trade-offs. The docs lay them out directly:

	Tailwind Typography (`.prose`)	Typeset
Sizing	Fixed `rem` scale, `.prose-sm` to `.prose-2xl`	Relative to the container, any size
Dark mode	`.prose-invert`, a second palette	Your tokens flip, nothing to add
Overrides	`prose-a:`, `prose-headings:` modifier API	Plain utilities and CSS win
Streaming	No append-stability contract	Designed for stable appends
Distribution	npm plugin, generated CSS	One CSS file you own

The way I'd frame it: .prose is a well-designed dependency you configure, and Typeset is a starting point you edit. If you like the modifier API and want a maintained plugin tracking Tailwind releases, .prose is still a great pick. If you'd rather own the file and delete the rules you don't want, Typeset fits that instinct better. It's the same philosophy as the rest of shadcn/ui: copy the code in, make it yours.

What makes it streaming-safe?

This is the part that made Typeset feel designed for 2026 rather than 2020. If you've built a chat UI that renders an LLM's markdown as it streams, you've watched the layout twitch as each token lands. Typeset treats that as a first-class constraint.

The rule is that there are no forward-looking selectors in the layout. :last-child, :has(), and :empty are deliberately kept out of spacing rules, because what they match changes as content appends, which restyles blocks that were already on screen. Spacing flows in one direction only, using margin-block-start and never margin-block-end:

& :where(p) {
  margin-block-start: var(--typeset-flow);
  margin-block-end: 0;
}

The same discipline shows up in tables: the row separators sit on the cells rather than on tr:last-child, so appending a row never re-runs a :last-child match and shifts the borders above it. When you add a new block to a Typeset container, nothing before it moves. That's a genuinely hard property to get right by hand, and it's baked into the stylesheet.

What it costs you

Two things are worth knowing before you commit.

First, the stylesheet leans on modern CSS, though most of it is safe by now: color-mix() and oklch() colors have been widely supported since 2023, and logical properties like margin-block-start work everywhere. The real outlier is margin-trim, which as of 2026 still ships only in Safari and other WebKit browsers (16.4 and up). There's no fallback for it, so in Chrome and Firefox that rule quietly does nothing. Worth knowing before you count on the margin trimming it's meant to handle.

Second, wide tables wrap to fit by default. Horizontal scroll is opt-in through a .typeset-scroll wrapper you have to add in your renderer's table component or a small rehype plugin. It won't happen automatically.

Should you use it?

If you're already in the shadcn/ui world and you're styling rendered markdown, especially anything that streams, Typeset is an easy yes: it's free, it's one file, and the streaming stability alone justifies it. If you're outside that ecosystem and happy with .prose, there's no migration to rush. It's an alternative with a clearer answer to a couple of specific problems, not an upgrade you're missing out on.

What I appreciate is the framing. shadcn keeps betting that the right unit of distribution for UI is source you own rather than a dependency you configure, and Typeset applies that bet to typography. I made a similar call rebuilding this site: the long-form styling here is hand-written Tailwind wired to theme variables rather than a plugin, for exactly the reason Typeset exists. The same instinct runs through generating OG images with Satori: own the design, skip the abstraction. Owning the CSS means when something looks off, you fix the rule instead of fighting the abstraction. Go build one in the builder and read the file it hands you. It's short, and reading it teaches you more about typographic CSS than the docs do.

SaaS Starter Architecture with Next.js 2026

Thu, 16 Jul 2026 05:16:29 +0000

You've got the idea. You're pumped. You open your terminal, run npx create-next-app, and then... you stare at a blank page.tsx wondering — where do I even begin?

This is the silent killer of SaaS projects. Not the idea. Not the tech. The architecture. Most developers start hacking features together and three weeks in, the codebase is a mess of spaghetti — auth logic mixed with UI, API calls scattered everywhere, no clear structure. It's painful to extend and even more painful to hand off.

The good news? A solid SaaS architecture isn't complicated. It's just a set of decisions made upfront — decisions about folders, responsibilities, and boundaries. Get those right and building features becomes fast, predictable, and even enjoyable.

By the end of this guide, you'll have a clear, production-ready SaaS folder structure with authentication, billing, protected routes, and a dashboard layout — all wired together with Next.js App Router, TypeScript, Tailwind CSS, and React Compiler.

Why Most SaaS Projects Fall Apart Early

Here's the honest truth: most developers (even experienced ones) start with a feature-first mindset. They add auth, then billing, then a dashboard — each piece bolted on without a plan. It works for a while. Then it doesn't.

The problems that show up:

You can't tell where business logic lives (is it in the component? the API route? a hook?)
Protected and public pages share the same layout, causing weird rendering bugs
Adding a new feature means touching five different files across three folders
Onboarding a new developer takes days just to explain the structure

The fix isn't a framework or a library. It's deliberate architecture — deciding upfront how your app is organized and what each layer is responsible for.

What We're Building

A scalable SaaS starter with:

✅ App Router (Next.js latest)
✅ React Compiler (automatic optimization — no manual useMemo / useCallback)
✅ TypeScript (strict mode)
✅ Tailwind CSS
✅ Authentication-ready structure (works with Clerk, Auth0, NextAuth, etc.)
✅ Billing-ready structure (works with Stripe)
✅ Separate layouts for marketing, auth, and dashboard
✅ Proxy-based route protection

Prerequisites

Before we start, make sure you have:

Node.js 20+ installed
Basic familiarity with Next.js App Router
A fresh Next.js project (we'll scaffold one below)

Step 1: Scaffold the Project

Let's create a fresh Next.js app with all the defaults we need.

Run the following command:

npx create-next-app@latest saas-starter

Choose options according to your preferences.

Recommended setup:

TypeScript
Tailwind CSS
App Router
React Compiler
src/ directory

React Compiler

React Compiler automatically optimizes your components — it's like having a senior dev go through your entire codebase and add useMemo and useCallback everywhere they're needed. You get that for free.

⚠️ Common Mistake: Don't manually add useMemo or useCallback when React Compiler is enabled. It'll do it better than you. Adding them manually can actually interfere with the compiler's optimizations.

Step 2: Plan the Folder Structure

This is the most important step. A well-thought-out folder structure acts like a map — anyone who opens the project immediately knows where everything lives.

Here's the structure we're going for:

saas-starter/
├── src/
│   ├── app/
│   │   ├── (marketing)/          # Public-facing pages (landing, pricing, about)
│   │   │   ├── page.tsx          # Homepage
│   │   │   ├── pricing/
│   │   │   │   └── page.tsx
│   │   │   └── layout.tsx        # Marketing layout (navbar, footer)
│   │   │
│   │   ├── (auth)/               # Auth pages (login, signup, forgot password)
│   │   │   ├── login/
│   │   │   │   └── page.tsx
│   │   │   ├── signup/
│   │   │   │   └── page.tsx
│   │   │   └── layout.tsx        # Minimal auth layout (just centered card)
│   │   │
│   │   ├── (dashboard)/          # Protected app pages (only logged-in users)
│   │   │   ├── dashboard/
│   │   │   │   └── page.tsx
│   │   │   ├── settings/
│   │   │   │   └── page.tsx
│   │   │   └── layout.tsx        # Dashboard layout (sidebar, topbar)
│   │   │
│   │   ├── api/                  # API routes (backend endpoints)
│   │   │   ├── webhooks/
│   │   │   │   └── stripe/
│   │   │   │       └── route.ts
│   │   │   └── user/
│   │   │       └── route.ts
│   │   │
│   │   ├── layout.tsx            # Root layout (fonts, global providers)
│   │   └── globals.css
│   │
│   ├── components/
│   │   ├── ui/                   # Reusable UI primitives (Button, Input, Modal)
│   │   ├── marketing/            # Components only used on marketing pages
│   │   ├── dashboard/            # Components only used in the dashboard
│   │   └── shared/               # Components used everywhere (Avatar, Logo)
│   │
│   ├── lib/
│   │   ├── auth.ts               # Auth helper functions
│   │   ├── stripe.ts             # Stripe client setup
│   │   ├── db.ts                 # Database client setup
│   │   └── utils.ts              # General utility functions
│   │
│   ├── hooks/                    # Custom React hooks
│   ├── types/                    # TypeScript type definitions
│   └── proxy.ts                  # Route protection logic
└── .env.local                    # Environment variables (never commit this!)

Let's break down the key decisions here:

Route Groups (marketing), (auth), (dashboard) — The parentheses are a Next.js feature. They let you group routes without affecting the URL. So app/(marketing)/pricing/page.tsx lives at /pricing, not /marketing/pricing. The real power is that each group gets its own layout.tsx — meaning your dashboard gets a sidebar, your auth pages get a clean centered layout, and your marketing pages get a navbar. No mixing.

lib/ folder — This is where your "glue code" lives. Auth helpers, database clients, Stripe setup. These are not components, not hooks — they're plain functions and configurations that any part of the app can import.

types/ folder — All your TypeScript interfaces and types live here. This prevents the chaos of defining type User = {...} in five different files.

Important: In Next.js 16, Middleware has been renamed to Proxy. In older versions, you'll see middleware.ts used instead.

Step 3: Set Up Route Groups & Layouts

Let's create the three layout files that power the different sections of the app.

Root Layout

The root layout wraps everything. It's the right place for global providers (auth context, theme, etc.) and fonts.

// app/layout.tsx
import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: {
    template: "%s | YourSaaS",
    default: "YourSaaS — The tagline goes here",
  },
  description: "Your SaaS description here.",
};

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body className={inter.className}>
        {/* Global providers go here (auth, theme, etc.) */}
        {children}
      </body>
    </html>
  );
}

Marketing Layout

// app/(marketing)/layout.tsx
import { Navbar } from "@/components/marketing/Navbar";
import { Footer } from "@/components/marketing/Footer";

export default function MarketingLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex min-h-screen flex-col">
      <Navbar />
      <main className="flex-1">{children}</main>
      <Footer />
    </div>
  );
}

Auth Layout

// app/(auth)/layout.tsx
export default function AuthLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex min-h-screen items-center justify-center bg-gray-50">
      <div className="w-full max-w-md px-4">{children}</div>
    </div>
  );
}

Dashboard Layout

// app/(dashboard)/layout.tsx
import { Sidebar } from "@/components/dashboard/Sidebar";
import { Topbar } from "@/components/dashboard/Topbar";

export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex h-screen overflow-hidden bg-gray-100">
      <Sidebar />
      <div className="flex flex-1 flex-col overflow-hidden">
        <Topbar />
        <main className="flex-1 overflow-y-auto p-6">{children}</main>
      </div>
    </div>
  );
}

💡 Why separate layouts matter: Without this, you'd need conditional logic inside a single layout to decide whether to show the sidebar. That gets messy fast. Route groups keep things clean — each section of your app has its own look, independently.

Step 4: Protect Routes with Proxy

Proxy — think of it as a security guard that stands at the entrance of your app. Every request passes through it before hitting a page. This is the perfect place to check: "Is this user logged in? If not, redirect them to /login."

// proxy.ts  (lives at the ROOT of your project, not inside /app)
import { NextRequest, NextResponse } from "next/server";

// These are the routes that require the user to be logged in
const protectedRoutes = ["/dashboard", "/settings", "/billing"];

// These are routes that logged-in users shouldn't see (e.g. login page)
const authRoutes = ["/login", "/signup"];

export function proxy(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Check for your auth token/session cookie
  // Replace "auth_token" with whatever your auth provider uses
  const isAuthenticated = request.cookies.has("auth_token");

  // If the user is trying to access a protected route but isn't logged in
  if (protectedRoutes.some((route) => pathname.startsWith(route))) {
    if (!isAuthenticated) {
      return NextResponse.redirect(new URL("/login", request.url));
    }
  }

  // If the user is already logged in and tries to visit /login or /signup
  if (authRoutes.includes(pathname) && isAuthenticated) {
    return NextResponse.redirect(new URL("/dashboard", request.url));
  }

  return NextResponse.next();
}

// Tell Next.js which paths this proxy should run on
export const config = {
  matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
};

What's happening here, line by line:

protectedRoutes — the list of URL paths only logged-in users can visit
authRoutes — pages that make no sense for logged-in users (you're already in!)
request.cookies.has("auth_token") — checks if the auth cookie exists. Your auth provider (Clerk, NextAuth, etc.) will set this automatically
NextResponse.redirect(...) — sends the user to a different URL
matcher — tells proxy to skip static files and images (no need to auth-check a .png)

⚠️ Common Mistake: Forgetting the matcher config. Without it, proxy runs on every single request — including CSS files, images, and fonts. That's unnecessary overhead and can cause weird issues.

Step 5: Set Up the Types Folder

Define your core types once, use them everywhere. This prevents TypeScript errors and keeps your data shapes consistent.

// types/index.ts
export type User = {
  id: string;
  email: string;
  name: string;
  avatarUrl?: string;
  plan: "free" | "pro" | "enterprise";
  createdAt: Date;
};

export type Subscription = {
  id: string;
  userId: string;
  status: "active" | "cancelled" | "past_due" | "trialing";
  plan: "pro" | "enterprise";
  currentPeriodEnd: Date;
};

export type ApiResponse<T> = {
  data: T | null;
  error: string | null;
};

💡 Why a central types/ folder? If you define User in five files, changing one field means updating five places. One file, one source of truth.

Step 6: Set Up Core Lib Files

The lib/ folder holds your setup code — the stuff that's not a component but needs to exist before anything works.

Database (example with Supabase)

// lib/db.ts
import { createClient } from "@supabase/supabase-js";

// process.env is how you access environment variables in Next.js
// These are secret keys stored in your .env.local file — never hardcode them!
const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL!;
const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!;

export const db = createClient(supabaseUrl, supabaseKey);

Stripe Client

// lib/stripe.ts
import Stripe from "stripe";

// The "!" tells TypeScript "trust me, this value exists"
export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: "latest supported version",
  typescript: true,
});

Utility Functions

// lib/utils.ts

// Combines Tailwind class names without conflicts
// Install clsx and tailwind-merge first: npm install clsx tailwind-merge
import { clsx, type ClassValue } from "clsx";
import { twMerge } from "tailwind-merge";

export function cn(...inputs: ClassValue[]): string {
  return twMerge(clsx(inputs));
}

// Format a date to a readable string
export function formatDate(date: Date): string {
  return new Intl.DateTimeFormat("en-US", {
    month: "long",
    day: "numeric",
    year: "numeric",
  }).format(date);
}

💡 The cn() function is one of the most used utilities in any Tailwind project. It lets you merge class names conditionally without worrying about conflicting Tailwind classes. Almost every component will use it.

Step 7: Environment Variables

Environment variables are secret keys and configuration values that your app needs but should never be publicly visible. Things like your database password, Stripe secret key, or auth secret.

Create a .env.local file at the root of your project:

# .env.local

# Authentication (example with Clerk)
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_...
CLERK_SECRET_KEY=sk_test_...

# Database (example with Supabase)
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

# Stripe
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_...
STRIPE_SECRET_KEY=sk_test_...
STRIPE_WEBHOOK_SECRET=whsec_...

# App
NEXT_PUBLIC_APP_URL=http://localhost:3000

⚠️ Critical: Add .env.local to your .gitignore immediately. If you push secret keys to GitHub, bad actors can find them and abuse your accounts. This is not hypothetical — it happens all the time.

Variables starting with NEXT_PUBLIC_ are exposed to the browser. Everything else is server-only. Never put secret keys in NEXT_PUBLIC_ variables.

Frequently Asked Questions

Can I use this structure with the Pages Router instead of App Router?

You can, but the route groups (marketing), (auth), and (dashboard) are an App Router feature — they won't work in Pages Router. With Pages Router you'd achieve similar separation using custom _app.tsx logic and manual layout wrappers, but it's messier. App Router is the recommended approach going forward.

Do I have to use Clerk or Supabase specifically?

Not at all. The architecture is auth-provider agnostic. Whether you use Clerk, NextAuth, Auth0, or Supabase Auth — the folder structure stays the same. You just swap out the cookie name in proxy.ts and the client setup in lib/auth.ts.

What if my app grows and the structure doesn't scale?

This structure handles the vast majority of SaaS apps well. If you hit a point where a single components/dashboard/ folder gets too crowded, break it into feature folders — e.g. components/dashboard/billing/, components/dashboard/team/. The core principle stays the same: group by where things are used.

Is React Compiler production-ready?

Yes. As of 2025, React Compiler is stable and recommended for new projects. It's been battle-tested by the Meta team on large-scale apps. Just remember — once it's on, stop writing manual useMemo and useCallback. Let the compiler do its job.

Where should I put shared API logic that multiple routes use?

Put it in lib/. For example, a lib/user.ts file with a getUserById(id) function that your API routes and server components can both import. This avoids duplicating database queries across files.

The Final Picture

Here's what you've got now:

Layer	What lives here
`app/(marketing)`	Landing page, pricing, about — with navbar & footer
`app/(auth)`	Login, signup — minimal centered layout
`app/(dashboard)`	Protected app pages — sidebar + topbar
`proxy.ts`	Route protection — redirects unauthenticated users
`lib/`	DB client, Stripe setup, utility functions
`types/`	Shared TypeScript types — User, Subscription, etc.
`components/`	UI organized by where it's used

This architecture scales. Whether you're building alone or with a team of five, adding a new feature means you know exactly which folder it belongs in. There's no guessing, no hunting through files, no spaghetti.

From here, the next steps are wiring in your auth provider of choice, setting up your Stripe webhook handler in app/api/webhooks/stripe/route.ts, and building out your dashboard pages. Each of those is its own focused task — and now you have a solid foundation to do them on.

Happy building. 🚀

Next Steps

Useful Resources

15 Free Frontend Tools Every Developer Should Know in 2026

Tue, 14 Jul 2026 06:38:30 +0000

Introduction

When I started learning frontend development, I thought I needed expensive software to build things that looked "professional." Turns out, that's completely false.

Some of the best frontend tools out there are free — and a lot of developers, even experienced ones, don't know half of them exist. Whether you're picking colors, generating CSS animations, testing responsiveness, or just trying to find the right icon, there's a free tool for almost everything.

In this post, I'm sharing 15 tools I personally use (or have used) while building real projects — from client websites to personal portfolios. No fluff, no "100 tools you'll never open" lists. Just the ones that actually save time.

Let's get into it.

1. Design & Color Tools

Good design starts with good colors and layout inspiration. These tools take the guesswork out of it.

Coolors

Coolors is the fastest way to generate a color palette. Hit the spacebar and it keeps generating combinations until you find one you like. You can lock colors you love and regenerate the rest.

Why beginners love it: No design theory needed — just pick what looks good.
🔗 coolors.co

Adobe Color

More advanced than Coolors, this lets you build palettes based on color theory rules (complementary, triadic, monochromatic, etc.) and even extract a palette from an image.

Why it's useful: Great when you want a palette that matches a client's brand photo or logo.
🔗 color.adobe.com

2. CSS Generators (Stop Writing Gradients by Hand)

CSS Gradient

Pick colors, choose the direction, and copy the ready-made CSS. Simple, fast, and works for linear and radial gradients.
🔗 cssgradient.io

Neumorphism.io

If you want that soft, "pressed-in" neumorphic UI style, this generator gives you the exact box-shadow code — adjustable by distance, blur, and intensity, with light/dark background support.
🔗 neumorphism.io

Clippy

Need a custom shape (hexagon, arrow, triangle) using clip-path? Clippy lets you drag points visually and copies the CSS for you. No more guessing polygon coordinates.
🔗 bennettfeely.com/clippy

Pro tip: These generators are amazing for learning too — generate the code, then read it and understand why it works. That's how I actually learned box-shadow and clip-path properties.

3. Icons That Don't Look Generic

Lucide Icons

A clean, consistent icon set that works beautifully with React and Tailwind CSS. Lightweight, tree-shakable, and has an official React package (lucide-react).
🔗 lucide.dev

Heroicons

Made by the Tailwind CSS team, so naturally it pairs perfectly with Tailwind projects. Comes in outline and solid styles.
🔗 heroicons.com

Font Awesome (Free Tier)

The classic. Massive icon library, and the free tier alone covers most needs — social icons, UI icons, brand logos.
🔗 fontawesome.com

My pick for React + Tailwind projects: Lucide. It's the one I use across my own builds because it's lightweight and easy to customize with Tailwind classes.

4. Fonts & Typography

Google Fonts

The obvious one, but don't just grab the first font you see. Google Fonts also shows you popularity, styles, and lets you preview your own text before choosing.
🔗 fonts.google.com

Fontjoy

Struggling to pair a heading font with a body font? Fontjoy uses AI to suggest font combinations that actually work together — and you can lock one font and regenerate the other.
🔗 fontjoy.com

5. Online Code Playgrounds

CodePen

Great for quick CSS/JS experiments, sharing snippets, and browsing what other developers are building. Perfect for testing an animation idea before adding it to a real project.
🔗 codepen.io

StackBlitz

A full online IDE that runs actual React, Vue, or Node projects in your browser — no local setup needed. I use this a lot when testing a quick React component idea.
🔗 stackblitz.com

CodeSandbox

Similar to StackBlitz, with strong support for sharing full working React apps and instant deployment previews. Great for collaborating or showing a client a live demo without deploying anywhere.
🔗 codesandbox.io

6. Image Optimization Tools

Heavy images kill website speed — and speed affects both user experience and SEO rankings.

Squoosh

Made by Google. Drag in an image, compare compression formats (WebP, AVIF, JPEG) side by side, and download the optimized version — all in your browser, nothing uploaded to a server.
🔗 squoosh.app

TinyPNG

Bulk compress PNG and JPEG images with barely noticeable quality loss. I run every client project's images through this before deployment.
🔗 tinypng.com

7. Responsive & Accessibility Testing

Responsively App

A free desktop app that shows your website on multiple device sizes at once, side by side, and syncs scrolling and clicks across all of them. Saves so much time compared to resizing your browser manually.
🔗 responsively.app

Chrome DevTools (Lighthouse)

Built right into Chrome. Open DevTools → Lighthouse tab → run an audit. It scores your site on performance, accessibility, best practices, and SEO, and tells you exactly what to fix.

Why this matters for freelancers: Clients love seeing a 90+ Lighthouse score. It's an easy way to prove your work is solid.

WAVE

A free accessibility checker. Paste your URL and it visually flags missing alt text, low contrast, and other accessibility issues directly on the page.
🔗 wave.webaim.org

8. Reference & Learning

MDN Web Docs

The single most reliable source for HTML, CSS, and JavaScript documentation. When in doubt, check MDN before trusting a random blog post (including this one).
🔗 developer.mozilla.org

Can I Use

Before using a newer CSS or JS feature, check browser support here. Saves you from shipping something that breaks in Safari or older browsers.
🔗 caniuse.com

Final Thoughts

You don't need a paid design subscription or premium plugin to build clean, professional websites. The tools above cover almost every stage of frontend work — design, coding, testing, and optimization — and they're all free.

My honest advice as someone who's been learning and building for the past couple of years: don't try to learn all 15 tools at once. Pick 2–3 that solve a problem you're facing right now, use them in your next project, and the rest will come naturally as you build more.

If you found this useful, save it — you'll probably come back to this list more than once.

Written by Muhammad Farhan — Frontend Developer specializing in React.js & Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev
GitHub: github.com/muhammad-farhan-dev

shadcn/typeset vs Tailwind Typography: Styling Markdown

Sat, 11 Jul 2026 08:23:11 +0000

What is shadcn/typeset?

<div className="typeset typeset-docs">
  <YourMarkdownRenderer>{content}</YourMarkdownRenderer>
</div>

The thing to internalize up front: there's no npm package and no config layer. The changelog puts it plainly: "one CSS file that styles everything inside a typeset container. The file lives in your project, so you can change it directly when you need to." If a heading annoys you, you open the file and change the rule. That's the whole distribution model.

How do you install shadcn/typeset?

You don't run a CLI. As of this release there's no npx shadcn@latest add typeset, and expecting one will send you looking for a command that doesn't exist.

Instead you build the file in the interactive builder, pick your sizes and fonts, and copy the generated typeset.css into your project. Then you import it after Tailwind:

@import "tailwindcss";
@import "./typeset.css";

Import order matters, and I'll come back to why in a moment. Once it's in, the wrapper from the first snippet is all you need.

Size, leading, and flow

Typeset condenses typographic tuning into three CSS variables it calls "rhythm," and everything else derives from them:

.typeset {
  --typeset-size: 1em;      /* base font size */
  --typeset-leading: 1.75;  /* line-height */
  --typeset-flow: 1.25em;   /* vertical space between blocks */
}

A preset is just those three variables set to different values under a class name:

.typeset-chat {
  --typeset-flow: 1em;
  --typeset-leading: 1.6;
}
.typeset-docs {
  --typeset-size: 15px;
  --typeset-flow: 1.5em;
}

Because it's all CSS custom properties, you can override a single value inline without touching the file:

<article className="typeset [--typeset-flow:1.75em]">{content}</article>

Why your Tailwind utilities win without !important

Here's the detail I liked most. Typeset lives in the CSS @components layer and uses zero-specificity :where() selectors for every element rule:

@layer components {
  .typeset {
    & :where(h1) { font-size: 1.75em; /* ... */ }
    & :where(p)  { margin-block-start: var(--typeset-flow); }
  }
}

If you want to pull a whole subtree out, there's an escape hatch: .not-typeset (or the data-not-typeset attribute), which cascades to descendants including any nested .typeset container.

<Card className="not-typeset">Untouched component.</Card>

shadcn/typeset vs Tailwind Typography

	Tailwind Typography (`.prose`)	Typeset
Sizing	Fixed `rem` scale, `.prose-sm` to `.prose-2xl`	Relative to the container, any size
Dark mode	`.prose-invert`, a second palette	Your tokens flip, nothing to add
Overrides	`prose-a:`, `prose-headings:` modifier API	Plain utilities and CSS win
Streaming	No append-stability contract	Designed for stable appends
Distribution	npm plugin, generated CSS	One CSS file you own

What makes it streaming-safe?

& :where(p) {
  margin-block-start: var(--typeset-flow);
  margin-block-end: 0;
}

What it costs you

Two things are worth knowing before you commit.

Should you use it?

What I appreciate is the framing. shadcn keeps betting that the right unit of distribution for UI is source you own rather than a dependency you configure, and Typeset applies that bet to typography. I made a similar call rebuilding this site: the long-form styling here is hand-written Tailwind wired to theme variables rather than a plugin, for exactly the reason Typeset exists. Owning the CSS means when something looks off, you fix the rule instead of fighting the abstraction. Go build one in the builder and read the file it hands you. It's short, and reading it teaches you more about typographic CSS than the docs do.

Tailwind CSS on Large, Long-Lived Projects How Do You Keep It Manageable?

Sun, 05 Jul 2026 20:09:18 +0000

I've been using Tailwind CSS for a while now, and I genuinely enjoy it; it's fast to prototype with, the developer experience is smooth, and I rarely have to context-switch between files to style a component.

But the more I use it, the more a question keeps coming back to me.
On large projects that live and evolve for a long time, does Tailwind start becoming a pain to maintain? Between utility classes scattered across every single template, design systems that change over time, and teams where everyone has slightly different habits, I wonder if things can get messy fast.

Before Tailwind, I was heavy on SCSS. Variables, mixins, partials, a clear folder structure. It felt organized and easy to evolve. But it also came with its own overhead.
I'd love to hear from people with real experience on this:

Are you using Tailwind on large, long-lived applications?
Do you combine it with SCSS, CSS Modules, or something else?
Have you put conventions or rules in place to keep things from going off the rails over time?

What's worked, what hasn't? I'm genuinely curious about the good and the bad. 👇

Gridzzly: Build CSS Grid Layouts Visually - No Code Required

Sun, 14 Jun 2026 17:29:19 +0000

CSS Grid is one of the most powerful layout systems ever created. But let's be honest - remembering grid-template-columns, grid-area, and all those line numbers can be a headache, especially when you're just trying to prototype an idea.

That's why I built Gridzzly - a visual playground where you click and drag to create grid items, edit track sizes in real time, and export production‑ready HTML/CSS with one click.

Live Demo: https://gridzzly.vercel.app
GitHub Repo: github.com/byllzz/gridzzly

What Makes Gridzzly Different?

Visual Drawing - Click and drag across the grid. Release to create a new grid item. No writing grid-row or grid-column manually.
Live Track Editing - Edit column/row sizes directly in inputs above the grid. Use 1fr, auto, 200px, minmax() - anything CSS Grid supports.
Instant Code Export - Switch between CSS and HTML tabs, copy the code, and paste it into your project.
Built‑in Templates & Random Generator - Stuck? Load a preset or hit "Random Pattern" for instant inspiration.
Overlapping Items - Place items on top of each other (great for magazine‑style layouts).
Dark Theme - Easy on the eyes for long coding sessions.

How It Works (Under the Hood)

The entire app is built with React and Tailwind CSS. The core logic lives inside a custom hook: useGridGenerator.js.

1. Grid State

We store:

Number of columns/rows
Gap values (in pixels)
Column/row size strings (e.g., ['1fr', '2fr', '1fr'])
Placed items: each item is an object { id, rStart, cStart, rEnd, cEnd }

2. Drawing Mechanism

When the user mouses down on a cell, we start tracking the starting row/column. On mouse move, we calculate the rectangle between the start and current cell, highlight all cells, and show a live badge (3 cols × 2 rows). On mouse up, we create a new item and reset the selection.

// Simplified from useGridGenerator.js
const startDrawing = (row, col) => {
  setIsDrawing(true);
  setStartCell({ row, col });
  setHighlightedCells([{ row, col }]);
};

const updateDrawing = (row, col) => {
  if (!isDrawing || !startCell) return;
  const rMin = Math.min(startCell.row, row);
  const rMax = Math.max(startCell.row, row);
  const cMin = Math.min(startCell.col, col);
  const cMax = Math.max(startCell.col, col);
  // highlight all cells from rMin..rMax, cMin..cMax
};

3. Code Generation

Every time the grid or items change, we generate fresh CSS + HTML. We even compress consecutive identical track sizes into repeat():

css

/* Instead of: */
grid-template-columns: 1fr 1fr 1fr 1fr;
/* We output: */
grid-template-columns: repeat(4, 1fr);

The generated HTML uses simple div elements with classes like .div1, .div2, and a .parent container.

Quick Usage Guide

Create a grid item: Click and drag across empty cells → release
Delete an item: Hover the item → click the × Resize a track: Click
the input above the grid (e.g., 1fr) → type a new value Change grid
Scroll through "Grid Patterns" → click any preview Random layout:
Click Random Grid Pattern Export code: Click Please May I have Some
Code → copy CSS or HTML

Why I Built This

I've taught CSS Grid to many developers, and the hardest part is always the mental model of grid lines and spanning. I wanted a tool that gives immediate visual feedback while generating real, copy‑pastable code – no vendor lock‑in, no weird abstractions. Just vanilla CSS Grid.

Whether you're:

Learning CSS Grid for the first time,
Prototyping a dashboard layout,
Or building a complex magazine‑style design,

Gridzzly helps you see what you're building and export it instantly.

Contributions Welcome

Found a bug? Have an idea for a feature? Open an issue or a pull request. The project is MIT licensed, so feel free to fork and build your own version.

Let's Connect

GitHub: @byllzz
Twitter: @bilalmlkdev

If you found this useful, please ❤️ the post and share it with your network.

Happy Gridding! 🎉

An open-source CSS animation library with a live preview grid, creator suite, and community submissions

Sat, 13 Jun 2026 05:01:45 +0000

CSSFrames: GPU-Accelerated Motion Without the Runtime Weight:
JavaScript animation libraries like GSAP, Framer Motion, and anime.js are powerful tools - but they come with a cost. Bundle weight, parsing overhead, potential layout thrashing, and the complexity of managing animations at runtime.

What if there was a better way?
CSSFrames is a curated library of production-ready motion presets built entirely on pure CSS keyframes. Browse, preview, customize, and export — all without touching JavaScript. No runtime overhead. No layout shifts. No dropped frames.

Try it live
View on GitHub (MIT licensed)

The Problem With JavaScript Animations
Every animation library comes with a runtime cost. The browser must:

Parse and execute JavaScript
Calculate animated values in real-time
Trigger layout recalculations (reflow)
Repaint affected DOM nodes

For simple, repeatable animations, this is overkill. CSS keyframes, by contrast, are declarative, precomputed, and offloaded directly to the GPU.

The Solution: Pure CSS, Pure Performance
CSSFrames runs every animation on just two GPU-composited properties: transform and opacity. This means:

✓ Zero layout shifts - no reflow or repaint
✓ GPU acceleration - animations render on the compositor thread
✓ Drop-in ready - one class, instant animation
✓ Framework agnostic - works in React, Vue, plain HTML, anywhere

Just add a class. The animation handles the rest.

What CSSFrames Includes:
1. Live Preview Grid
Every preset previews in real-time on authentic UI elements: buttons, cards, loaders, icons, and text. Switch to Theater Mode to focus on a single animation full-screen. Understand what each preset does before you export.

2. Creator Suite
Built on Monaco Editor, the Creator Suite lets you author custom keyframes without leaving the browser. Set duration, tweak easing curves, preview live, and export instantly. Perfect for building brand-specific motion systems.

3. One-Click Export
Every animation exports in multiple formats:

Raw CSS — @keyframes definition + class
Tailwind Config — Ready-to-paste keyframes and animation blocks
Metadata — Duration and easing values for documentation

4. Community Grid
Developers can submit custom presets that persist via a REST API (powered by Railway). Browse and use animations created by the community. Every submission is live for all users — no build step required.

What's Included
Seven animation categories:
Buttons · Loaders · Entrances · Text · Cards · Icons · Shapes

Preset types:
Shimmer sweeps, typewriter effects, morphing blobs, staggered reveals, glitch systems, pulse rings, stroke-draw animations — all GPU-composited, all pure CSS.

The Stack

Frontend: React + Vite
Styling: Tailwind CSS
Code Editor: Monaco Editor
Syntax Highlighting: Prism.js
Backend API: Express.js
Hosting: Vercel (frontend) · Railway (API)

Get Started
Clone the repository and run locally:

bashgit clone https://github.com/byllzz/cssframes.git
cd cssframes
npm install
npm run dev

To run the community API server:

bashcd server
npm install
npm start
Then add this to your .env:
VITE_API_URL=http://localhost:3001

Why This Matters
CSSFrames solves a real problem: developers often reach for heavy animation libraries when CSS alone can deliver the same results - faster, lighter, and more reliably.

If CSSFrames helped you build smoother, more performant UI without bloating your bundle, a ⭐ on GitHub would mean a lot.

What's your favorite preset? Drop it in the comments below

The Executive Interface: Translating AI Telemetry into C-Level Decisions

Sun, 17 May 2026 07:27:53 +0000

The most highly engineered artificial intelligence backend fails to secure financial viability if upper management lacks the mechanism to visualize its direct impact on profitability. Applied Operations Engineering does not terminate inherently within a relational database architecture; the structural cycle invariably concludes on the decision-maker’s screen.

The asynchronous orchestration model implemented in previous segments (CrewAI piloting an LLM securely against deterministic SQL Supabase arrays) yields robust operational execution. This concluding segment reinforces the deployment by exposing the mathematical core toward a managerial interface deliberately calibrated exclusively to communicate Return on Investment (ROI) calculations and industrial downtime mitigation.

The Standardized Data Contract: Formulating the Analytical API

In order to rigorously decouple the cognitive analysis load originating from the underlying agent engines, balancing execution layers evenly across the network, we introduce a simulated Read-Replica structure atop the FastAPI environment (dashboard_api.py).

This REST terminal strictly exposes mathematical telemetry archived implicitly by our evaluating Agent resolving inbound PDNs:

@app.get("/api/v1/dashboard/risk-metrics")
def get_risk_metrics():
    # Enforces a static JSON contract for Frontend ingestion
    return {
        "total_risk_eur": 15450.00,
        "active_alerts": 2,
        "affected_skus": [
            {
                "sku": "DRONE-X1",
                "margin_at_risk": 12500.00,
                "status": "CRITICAL LTB REQUIRED",
                "trigger_mpn": "TI-CAP-10U-50"
            }
            # ...
        ],
        "agent_logs": [
            "[18:31:02] [Webhook] Inbound email parsed.",
            "[18:31:05] [CrewAI] Parsing semantic text. MPN extracted: TI-CAP-10U-50.",
            "[18:31:07] [CrewAI] P&L calculated. Retained Margin at Risk: 12,500.00 EUR."
        ]
    }

The absolute numerical aggregate indexed directly as total_risk_eur unifies the financial exposure stemming from synchronous alert computations, guaranteeing clear C-Level synthesis.

The Frontend Engineering Paradigm: Minimalist Fundamentals

The modern software landscape predominantly cultivates vast dependencies enveloping Node.js-based heavy frameworks (such as React or Angular), frequently extending these burdens even toward purely unidirectional Read-Only telemetry boards.

Contrasting this convention, a functional operational factory monitor (Andon boarding mechanics) strictly dictates absolute instantaneous availability, zero massive transient module repositories, and static instantaneous rendering boundaries. Employing rigid Dogfooding and adherence to strict First Principles methodologies, we outline a standard static index.html directly provisioned via CDN utilities.

The underlying stack distills precisely toward standard native Web API functionalities mapping the unadorned Fetch() standard enclosed inside strict Vanilla JavaScript bound dynamically by atomic atomic styling via Tailwind CSS.

fetch("http://localhost:8001/api/v1/dashboard/risk-metrics")
    .then(response => response.json())
    .then(data => {
        // Enforcing Macro-Econometric bindings
        document.getElementById('totalRisk').innerText =
            new Intl.NumberFormat('en-US', { style: 'currency', currency: 'EUR' }).format(data.total_risk_eur);
       
        // Channeling active event telemetry loops
        const consoleDiv = document.getElementById('telemetryConsole');
        data.agent_logs.forEach(log => {
            const line = document.createElement('div');
            line.innerText = `> ${log}`;
            consoleDiv.appendChild(line);
        });
    });

Visual Engineering for Critical Operations: Industrial UX

To aggressively preempt “Analysis Paralysis” constraints across executive viewers, structural interface segregation clusters data exclusively within three core categorical axes:

The Critical Analysis Threshold (Macro KPI): Disclosing the consolidated risk metric bound heavily inside an unmissable perimeter. Direct and literal exposure communicating the 15,450.00 EUR justifying the technological expenditure securing AI frameworks within the board room.
Constraint Tabulation (Blacklist Registers): A starkly structured matrix elevating purely the top-tier commercial product identifier base (DRONE-X1), deliberately isolating the complex inner web of microscopic resistors below. The target centers entirely upon final operational line constraints.
The Live Core (Active Telemetry Processing): Real-time monitoring console mapped visually to broadcast the raw cognitive iterations driven by the internal CrewAI process. Reassuring operational directors visually confirming the endless, uninterrupted analytic progression actively shielding logistics lines without manual prompting.

Series Culmination: A Blue Ocean Extracted in Logistics

This specific deployment sequence concludes our intensive technical trajectory mapped consistently to operational engineering, advancing drastically past speculative archaic forecasting techniques relying broadly on weak statistical projections.

We acknowledged material component obsolescence strictly as systematic margin erosion outlined prominently across IEC 62402 requirements. We encoded intricate supply interdependencies mapping vectors within rigorous recursive Graph databases. We algorithmically neutralized chaotic raw ingestion inconsistencies integrating Pandas filters; allocated heavily restrained advanced Language Agents dynamically converting abstract linguistic payloads autonomously into structured data matrices, and decisively scaled robust event-driven operations persistently spanning active Background FastAPI nodes.

Physical logistics obsolescence fundamentally resigns its classification as an uncontrollable, unpredictable Black Swan occurrence. Converted exclusively into a precisely measurable, purely mitigated domestic phenomenon, we have ultimately established a definitive and asymmetric tactical advantage securing systemic industrial resilience.

Underwind - The Wordpress Starter Theme That Let the Wind Change Direction

Fri, 24 Apr 2026 07:34:08 +0000

Once upon a commit in the vast kingdom of WordPress, there lived a humble theme called Underscores — a barebones starter with just enough HTML5 templates and clean PHP to make even seasoned developers smile. It didn’t hold much style, but it laid the foundation for dreams to grow.

For many moons, artisans grafted frameworks like Understrap upon this sturdy root — binding Underscores’ lean code with Bootstrap’s responsive might, crafting an engine that saved hours in every quest.

But developers began to whisper of a new wind…

️ The Call of a New Breeze

Legend whispers that on a morning drenched in dew and VS Code tabs, a band of explorers at Melasistema gazed upon Understrap and sighed. They loved Bootstrap’s lattice and grid, but their hearts beat in utility-first classes and blazing dev environments. Thus, in a stroke of inspiration, they took the rock-solid foundation of Underscores and let the wind change direction — welcoming Tailwind CSS into the fold.

And they named this creation… Underwind.

What Makes Underwind Magical

In the enchanted lands of theme development, Underwind blends tradition and modern craft. From its README scroll:

✨ A Modern Dev Environment — Powered by Vite with Hot Module Replacement (HMR), changes appear like magic in the blink of an eye.

✨ Utility-First Styling — Tailwind CSS lets builders compose UIs directly in markup without wrestling weights of custom classes.

✨ Alpine.js Ready — For small interactive components that feel alive with almost no overhead.

✨ Lean & Solid Foundation — Lean Underscores templates keep the bones strong, ready for any bespoke theme you imagine.

✨ WooCommerce-Friendly — A boon for merchants who venture into online marketplaces.

✨ Integrated Code Quality Tools — With ESLint, Prettier, and PHP_CodeSniffer, even the fiercest code standards never go astray.

This was not just another starter — it was a canvas with wings, inviting creators to craft faster and more joyfully than ever before.

Getting Started: The Hero’s Quest

To begin your journey with Underwind:

Clone the repository into your WordPress themes folder.
Install the dependencies with npm install and composer install.
Run npm run dev to watch your creations come alive with instant reloads.
Build for production with npm run build.

Suddenly, what once was a blank slate becomes an artisan’s delight — with Tailwind classes flowing like wind through sails.

Why Underwind Matters

In the kingdom of WordPress themes, many paths exist: from the bare essence of Underscores to Bootstrap-laden frameworks like Understrap. Yet few combined modern tooling, utility-first styling, and a refined developer experience into a single starter ready for today’s workflows.

Underwind doesn’t just give you a foundation — it gives you momentum. It’s the theme that whispers to you:

“Design with joy. Develop with speed. Let the wind carry you forward.”

Epilogue

And so, as the sun set on legacy workflows and the first rays of Tailwind dawned on WordPress development, Underwind stood tall — a new standard for ambitious theme creators.

May your commits be meaningful,
and your Tailwind classes ever abundant.

✨ A New Stack — Introducing Redis Nuxt Blog: A Sci-Fi Blog Boilerplate from a Galaxy Not So Far Away

Thu, 23 Apr 2026 16:49:31 +0000

“A long time ago, in a server rack far, far away, a lone developer sought a faster way to publish their thoughts across the galaxy…”

If you’re a developer roaming the cosmic void in search of the perfect blogging platform — one fast enough to outrun hyperspace lag, simple enough to configure from a single holocron file, and powered by the mighty Force of Redis — your quest ends here.

Welcome to Redis Nuxt Blog, a futuristic, high-performance boilerplate forged with Nuxt 3, Redis Stack, and a containerized fleet of Docker Star Destroyers.
Inspired by the legendary Salvatore “antirez” Sanfilippo, creator of Redis and intergalactic craftsman of absurdly fast data structures, this project aims to honor that sci-fi spirit — equal parts elegance, speed, and space-wizardry.

Grab your lightsabers, devs. We’re jumping to lightspeed. ⚡

Why Another Blog Boilerplate?

Because most blog starters are like broken droids — sluggish, uncustomizable, and likely to beep something rude at you when you change a font.

Redis Nuxt Blog is built for developers who want:

A fast, SSR-friendly, SEO-happy front-end
A database engine so quick it would embarrass a pod-racer
A deeply configurable UI without fiddling with 27 separate config files
A ready-to-launch Docker setup
A CLI so efficient it feels like talking to R2-D2 (but without the panic screams)
A theming system powered by Tailwind CSS, customizable from one file
Markdown-powered post content
Dynamic excerpts and content width control

✨ Core Features (Translated from Wookiee)

Nuxt.js 3 Frontend

Modern. Fast. SSR-powered.
Perfect for blogs, portals, and broadcasting your galactic manifestos.

⚡ Redis Stack as the Primary Database

Forget SQL. Forget slow disks.
We harness the Quantum Hyperdrive (a.k.a RedisJSON + Redis Sorted Sets) to store posts with blazing speed.

Salvatore Sanfilippo didn’t intend Redis to be a sci-fi artifact… but let’s be honest, it might as well have been forged from midichlorians.

One Config File to Rule Them All (Now With Full Tailwind Integration)

Every visual setting — fonts, weights, palette, spacing, even content width — comes from:

config/blog.config.ts

This single file now controls:

Typography per heading level
Full Tailwind color palette generation
Global content max-width
Header title & tagline
Layout constraints

Balance to the styling Force, at last.

✂️ Post Excerpts (New!)

Enable post previews on the homepage with:

postExcerpt.enabled
postExcerpt.maxLength

Perfect for teasing your readers like a Holonet trailer.

Navigate between posts like browsing encrypted Jedi archives.

Markdown Support

Posts are fully Markdown-powered — headings, lists, code blocks, even multi-line input via CLI.

Write your galactic knowledge in pure Markdown. No HTML acrobatics needed.

Dockerized Everything

Spin up Nuxt + Redis with one command:

docker compose up -d --build

Your dev environment becomes as consistent as Stormtrooper aim (but… good).

Content CLI (Upgraded!)

Create, list, delete posts with simple commands:

npm run new-post npm run post:list npm run post:delete

The CLI now supports:

Multi-line Markdown input
Automatically generated slugs
Default author fallback

You are now the administrator of your own Holocron Library.

️ Tech Stack: What Our Starship Is Made Of

Nuxt 3 — the elegant lightsaber
Redis Stack w/ RedisJSON — the hyperdrive core
Tailwind CSS — the robe of a modern Jedi developer
Google Fonts module — for typographic wizardry
Docker Compose — the Imperial Fleet
TypeScript + tsx runtime — because even smugglers need types

️ The Holocron of Configuration (Updated!)

Everything — fonts, colors, layout, excerpts, pagination — lives in:

config/blog.config.ts

New additions include:

headerTitle
headerTagline
Dynamic Tailwind theme generation
contentMaxWidth
Post excerpts config

Want your blog to have an imperial blue palette?
Done.

Want H1 in Englebert and H2 in Roboto Slab?
Absolutely.

Want your content width to feel like the inside of a Star Destroyer corridor?
Just set a new max-width.

API Endpoints (For the Droids Among Us)

Endpoint	Method	Description
`/api/posts`	GET	Retrieve posts. Supports `?page=N`
`/api/posts/:slug`	GET	Fetch single post + neighbors
`/api/tags`	GET	Retrieve all tags

Perfect for custom frontends, mobile apps, or your own droid companion.

Why Developers Love This

Because simplicity + power = developer bliss.

Because Redis is a piece of sci-fi technology disguised as a database.

Because Nuxt 3 is smooth as sliding through hyperspace.

Because Tailwind lets you customize everything without rewriting CSS.

Because Markdown posts feel like writing Jedi scrolls.

And because every post stored in Redis Sorted Sets is basically organized by the Force.

Author & Origin Story

Built by Luca Visciola — drummer, developer, and happy dad.

Inspired by Salvatore “antirez” Sanfilippo, whose creation Redis is widely believed to be running not on silicon… but on compressed fragments of a neutron star.

Final Transmission

If you're searching for a fast, flexible, sci-fi-friendly blog engine that handles posts faster than the Millennium Falcon outruns TIE Fighters, this boilerplate may be the one you’re looking for.

Clone it.
Customize it.
Seed it.
Deploy it.

GitHub Repository:
https://github.com/melasistema/redis-blog

And may the Force of Redis be with you. ❤️‍

Open-Source Spin-the-Wheel Website–No Ads, No Trackers

Sun, 19 Apr 2026 05:19:14 +0000

Picksy is a simple, open-source spin-the-wheel app for choosing a random name from a list without ads, trackers, or unnecessary clutter.

I originally built this project about four years ago, then forgot about it. After rediscovering the repository, I decided to revisit it, finish what I started, and finally share it.

I first created it during the pandemic, when spin-the-wheel tools became popular for online team-building, virtual game nights with friends and family, and similar activities. Most of the available options were cluttered with ads and trackers, so I built a simpler alternative without either.

After refreshing the UI and updating the dependencies, the project is now complete.

You can try it here: Picksy

If you want to see the code or contribute, the project is available on GitHub: joiellantero/picksy

This release also gave me a chance to revisit an older idea and clean it up into something I would actually use today: lightweight, straightforward, and easy to share.

If you prefer working in the terminal, I also made a Python-based version here: name-roulette.

Recreating History: Building a Windows 98 Disk Defrag Simulator with Modern Web Tech

Tue, 17 Mar 2026 13:54:18 +0000

Hey fellow devs! I'm Dennis Morello, a Senior Frontend Engineer with a passion for both cutting-edge web technologies and retro computing. I'm excited to share my latest project that combines these interests: a faithful recreation of the Windows 98 Disk Defragmenter, built entirely for the web.

Check it out: defrag98.com

Update 19 Jul 2024: We're on Product Hunt!

Great news, everyone! The Windows 98 Disk Defragmenter Simulator is now live on Product Hunt. This is an exciting milestone for the project, and I'm thrilled to share it with a wider audience of tech enthusiasts and nostalgia lovers.

Update 14 Jul 2024: Featured on The Verge and Hacker News!

The project has been featured on Hacker News and The Verge! Thank you to everyone who has tried it out and shared their love for this blast from the past.

The Tech Stack

For this project, I leveraged some of the most powerful tools in modern web development:

React: For building the UI components
Next.js: To optimize performance and SEO
Zustand: To manage the state of the app
TailwindCSS: To style the app, along with 98.css for bringing in the Windows 98 aesthetic
Radix UI Primitives: For accessible interactive components like sliders and modals
Vercel: The hosting platform for the app

Challenges and Solutions

1. Recreating the Defragmentation Algorithm

One of the biggest challenges was implementing a defragmentation algorithm that felt authentic. I created a custom algorithm that:

Randomly selects clusters to process
Simulates file movements across the disk
Adjusts processing speed based on the selected virtual drive

2. Pixel-Perfect UI Recreation

Achieving the exact look and feel of Windows 98 required meticulous attention to detail. I used a combination of 98.css and TailwindCSS to:

Match colors precisely
Recreate the characteristic 'chunky' borders
Implement the classic Windows 98 typography

3. Simulating Hard Drive Sounds

To add an extra layer of nostalgia, I implemented realistic hard drive sounds. This involved:

Recording and editing authentic HDD sounds
Leveraging the Web Audio API for precise playback control
Synchronizing sound effects with the visual defragmentation process
Adapting the HDD sounds to the chosen drive speed

What I Learned

This project was a fantastic opportunity to:

Deep dive into the intricacies of writing a custom defrag algorithm, and find a balance between performance and simulation accuracy
Explore the challenges of accurately simulating legacy software
Push the boundaries of what's possible in browser-based applications

What's Next?

This is a project I started just for fun, but I'm excited to see where it goes. I'm looking forward to continuing to improve the app, and adding more features as feedbacks from users come in.

I'd love to hear your thoughts, suggestions, or questions about this project. Have you worked on similar retro tech simulations? What challenges did you face?

From Zero to Hero: Create a Cyberpunk Snake Game with Real-Time Ranking using Supabase and Vanilla J

Tue, 17 Mar 2026 06:55:03 +0000

Do you remember the classic Snake from the old Nokias? Now imagine it with neon lights, synthesized music, explosive particles, and most importantly: connected to the cloud.

Web game development has experienced a renaissance thanks to the power of HTML5 Canvas and Serverless tools. In the past, if you wanted to save your players' scores to create a global leaderboard, you needed to set up a server, configure a REST API, manage databases, and pay for hosting. Today, thanks to Backend-as-a-Service (BaaS), we can do it in minutes.

In this tutorial, we are going to build "Neon Snake", an aesthetic and functional web arcade game that uses Supabase (an Open Source alternative to Firebase) to persist data in PostgreSQL.

️ The Tech Stack

We're going to keep it simple but powerful. No heavy frameworks, just the purity of the web:

Frontend: HTML5 Canvas + Vanilla JavaScript (ES6+).
Styles: Tailwind CSS (via CDN) for the user interface.
Backend: Supabase (PostgreSQL + Realtime).
Audio: Web Audio API for code-generated sound effects.

Step 1: Setting up the Backend with Supabase

Before writing a single line of JavaScript, we need our brain in the cloud. Supabase offers us a real PostgreSQL database with an automatically generated API.

Create a free account at supabase.com.
Create a new project called NeonSnake.
Go to the Table Editor section and create a new table called snake_scores.

The Magic of SQL

To streamline the process, Supabase allows you to execute SQL commands directly. Go to the SQL Editor and paste the following code. This will create the table structure and configure the security policies (RLS - Row Level Security) so your game can read and write data publicly.

-- 1. Create the scores table
create table snake_scores (
  id bigint generated by default as identity primary key,
  username text not null,
  score integer not null,
  created_at timestamp with time zone default timezone('utc'::text, now()) not null
);

-- 2. Enable Row Level Security (RLS)
alter table snake_scores enable row level security;

-- 3. Policy to allow anyone to view the ranking (Public Read)
create policy "Ver ranking publico"
on snake_scores for select
using ( true );

-- 4. Policy to allow anyone to save their record (Public Write)
create policy "Guardar puntuacion"
on snake_scores for insert
with check ( true );

Security Note: In a commercial game, we would use full user authentication. For this arcade-style demo, we allow public (anonymous) access to reduce friction so anyone can play and log their record instantly.

Finally, go to Settings > API and copy your Project URL and your anon public key. You will need them shortly.

Step 2: The Cyberpunk Frontend (HTML5 + Canvas)

Our game will live in a single index.html file. We will use Tailwind CSS for the floating menus (Game Over, Start Screen) and the <canvas> element to render the game at 60 FPS.

The basic structure is as follows:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Neon Snake 2077</title>
    <script src="[https://cdn.tailwindcss.com](https://cdn.tailwindcss.com)"></script>
    <style>
        @import url('[https://fonts.googleapis.com/css2?family=Orbitron:wght@400;700&display=swap](https://fonts.googleapis.com/css2?family=Orbitron:wght@400;700&display=swap)');
        body { font-family: 'Orbitron', sans-serif; background-color: #050505; }
        /* Neon glow effect for the canvas */
        canvas { box-shadow: 0 0 20px #0ff; border: 2px solid #0ff; }
    </style>
</head>
<body class="h-screen w-full flex items-center justify-center overflow-hidden bg-gray-900">

    <div class="relative">
        <canvas id="gameCanvas" width="400" height="400"></canvas>
        
        <div id="gameOverMenu" class="hidden absolute inset-0 bg-black/90 flex flex-col items-center justify-center z-10">
            <h2 class="text-4xl text-red-500 font-bold mb-4 drop-shadow-[0_0_10px_rgba(239,68,68,0.8)]">SYSTEM FAILURE</h2>
            <input type="text" id="usernameInput" placeholder="Enter ID..." class="bg-gray-800 text-cyan-400 p-2 rounded border border-cyan-500 mb-4 text-center outline-none">
            <button id="saveBtn" class="bg-cyan-600 hover:bg-cyan-500 text-white font-bold py-2 px-4 rounded shadow-[0_0_15px_#06b6d4] transition-all">
                UPLOAD DATA
            </button>
            
            <div id="leaderboard" class="mt-6 text-sm text-gray-300 w-64 text-left h-40 overflow-y-auto custom-scrollbar"></div>
        </div>
    </div>

    <script type="module">
        import { createClient } from '[https://cdn.jsdelivr.net/npm/@supabase/supabase-js/+esm](https://cdn.jsdelivr.net/npm/@supabase/supabase-js/+esm)'
        
        // ... Game Logic here (See step 3) ...
    </script>
</body>
</html>

Game Logic: Beyond Eating Apples

To give it that "Pro" touch and differentiate it from a basic tutorial, we implement several key mechanics in JavaScript:

Animation Loop: Using requestAnimationFrame to maintain fluidity at 60 FPS.
Particle System: An array of objects that spawn at the "food" coordinates when eaten and fade gradually, simulating a data explosion.
Dynamic Firewalls: From level 5 onwards, we generate static obstacles that the player must dodge, progressively increasing the difficulty.
Hybrid Controls:
- PC: We listen for keydown events for directional arrows.
- Mobile: We capture touchstart and touchend to calculate the gesture direction (swipe) and move the snake.

Step 3: Connecting the Dots (Integration with Supabase)

Here is where the Backend-as-a-Service magic happens. We are going to connect our Canvas to the PostgreSQL database. Inside our <script type="module"> tag:

1. Client Initialization

const supabaseUrl = 'YOUR_SUPABASE_PROJECT_URL';
const supabaseKey = 'YOUR_SUPABASE_ANON_KEY';
const supabase = createClient(supabaseUrl, supabaseKey);

2. The "Game Over" Flow

When the player loses and hits "UPLOAD DATA", we need to ensure the data is saved before showing the leaderboard. We will use async/await to control this asynchronous flow.

async function saveScore(username, score) {
    // 1. Save the score
    const { error } = await supabase
        .from('snake_scores')
        .insert([{ username: username, score: score }]);

    if (error) {
        console.error('Error uploading data:', error);
        alert('Connection error with the central server.');
        return;
    }
    
    // 2. Immediately after, update the leaderboard visually
    fetchLeaderboard();
}

3. Fetching the Ranking (Select)

We retrieve the Top 20 sorted by score in descending order to show who rules the server.

async function fetchLeaderboard() {
    const { data: scores, error } = await supabase
        .from('snake_scores')
        .select('username, score')
        .order('score', { ascending: false }) // Descending order
        .limit(20);                           // Only the top 20

    if (error) console.error('Error fetching leaderboard:', error);
    
    // Render in the DOM
    const list = document.getElementById('leaderboard');
    list.innerHTML = '<h3 class="text-cyan-400 border-b border-cyan-500 mb-2 font-bold">TOP HACKERS</h3>';
    
    scores.forEach((entry, index) => {
        // Highlight top 3 with different colors if you want
        const colorClass = index < 3 ? 'text-yellow-400' : 'text-gray-300';
        
        list.innerHTML += `
            <div class="flex justify-between py-1 border-b border-gray-800">
                <span class="${colorClass}">#${index + 1} ${entry.username}</span>
                <span class="text-cyan-300 font-mono">${entry.score}</span>
            </div>`;
    });
}

Bonus: Realtime ⚡

Do you want the ranking to update on everyone's screen if someone breaks the record at that precise moment? Supabase makes this trivial with its subscriptions:

// Subscribe to changes in the 'snake_scores' table
supabase
  .channel('public:snake_scores')
  .on('postgres_changes', 
      { event: 'INSERT', schema: 'public', table: 'snake_scores' }, 
      (payload) => {
        console.log('New record detected on the network!', payload);
        fetchLeaderboard(); // Automatically refresh the list for everyone
      }
  )
  .subscribe();

The Final Result

By putting it all together, you get a fluid and highly competitive user experience:

The user plays frantically dodging neon "Firewalls".
Upon crashing, the game stops with a visual "glitch" effect.
They enter their name (e.g., "Neo").
Upon clicking send, in milliseconds, their name appears on the leaderboard.
If their friend is playing on another mobile at the same time, they will see "Neo's" name appear on their screen without reloading the page.

And once created... all that remains is to enjoy and play

Datalaria Snake Game

Conclusion

We have moved from a simple static canvas to a Fullstack application in real-time without touching a traditional backend server (Node.js, PHP, Python) or managing infrastructure. The combination of creativity in game development with the power of BaaS tools like Supabase opens a world of possibilities for frontend developers.

The next step? I invite you to clone the project and improve it: add GitHub authentication to avoid duplicate names, create snake skins that unlock with high scores, or implement a multiplayer mode using Supabase presence channels.

The code is yours!

Did you like this tutorial? Share it on your networks with your High Scores and don't forget to check the official Supabase documentation to dive deeper.

I spent a year chasing AI hype and buying courses. Here is why I went back to Vue.

Thu, 29 Jan 2026 23:35:34 +0000

I’ll be honest: I got lost.

For the past year, I abandoned my comfort zone. As a veteran Vue 2 developer, I felt the "Fear Of Missing Out" (FOMO) hitting me hard. Everywhere I looked, people were shouting:

"AI will replace you!" > "Learn LLMs or become obsolete!" > "Make passive income with AI-generated videos!"

I have two kids to feed. The anxiety was real.

So, I did what many terrified developers did. I stopped writing code and started chasing the wind. I bought the expensive courses on "AI App Development". I tried to become a "Content Creator" using AI tools to churn out soulless videos. I tried to force myself to love the React ecosystem just because "it has more AI libraries."

I became a "Leek" (a term we use in China for people who get harvested by hype).

After a year of burning cash and time, I looked at my portfolio. I had zero real users, a bunch of "Hello World" AI demos, and a lingering feeling of emptiness. The AI tools improved my efficiency, sure, but they didn't solve the core problem: I wasn't building anything valuable.

The Return to Reality

I had a reality check one late night. I realized that while everyone is trying to build the next ChatGPT wrapper, regular people still struggle with basic things.

I create content, and I work with images daily. I realized that simple tasks like bulk resizing, converting formats, or compressing images without uploading them to a shady server (privacy matters!) are still annoying.

Photoshop is too expensive and heavy for quick tasks.
Most online tools are ad-ridden nightmares that steal your data.

So, I made a decision. Stop chasing the hype. Start shipping utility.

From Vue 2 to Nuxt 4

I went back to my roots, but I leveled up. I skipped the legacy Vue 2 patterns I was used to and dove straight into Vue 3 (Composition API) and Nuxt.

It was refreshing. No more fighting with Python environments or prompt engineering. Just pure, clean JavaScript/TypeScript.

I built BulkPicTools.

It’s not an "AI-powered, Blockchain-backed, Metaverse-ready" platform. It’s a boring, useful tool.

⚡️ Client-side only: It runs entirely in your browser using WebAssembly and modern JS APIs.
Privacy-first: Your photos never leave your device. No server uploads.
Solves a real problem: Bulk processing for creators who value their time.

I’m writing this for any other developer who feels inadequate because they aren't an "AI Expert" yet.

You don't need to ride every wave. Your engineering skills—whether it's Vue, Rails, or PHP—are still valuable if you use them to solve real problems.

I’m still learning the ropes with the latest Nuxt features, and the journey from "Corporate Employee" to "Indie Hacker" is terrifying. But at least now, I'm building something real again.

If you have feedback on the tool or the Nuxt implementation, I’d love to hear it!

Thanks for reading.

Tailwind CSS: Build Modern UIs Faster Without Writing Custom CSS

Mon, 19 Jan 2026 07:58:07 +0000

Tailwind CSS is a utility-first CSS framework that completely changes the way developers build user interfaces.

Instead of writing long custom CSS files, Tailwind allows you to style elements directly in your HTML or JSX using pre-defined utility classes.

Why Developers Love Tailwind CSS:

⚡ Super fast development – no context switching

Consistent design system – spacing, colors & typography stay aligned

Highly customizable – extend themes easily

Responsive by default – mobile-first utilities

♻ Clean & scalable UI – perfect for React, Next.js & Vue

Whether you're building a startup landing page, dashboard, or full-scale SaaS product, Tailwind CSS helps you move faster without sacrificing design quality.

Once you try Tailwind, going back to traditional CSS feels slow.

Tailwind’s hidden trade-off

Sat, 10 Jan 2026 12:23:14 +0000

If you hang around modern frontend discourse (or pretty much any React codebase), Tailwind feels like the default.

It’s fast. It’s polished. It has great docs. It makes UIs look decent by accident.

And yet… I don’t use it.

This post is my attempt to explain that without turning it into a holy war. I’m not here to dunk on Tailwind, and I’m definitely not here to cosplay as the last defender of “real CSS”. Tailwind is an impressive piece of work.

But for the way I build things, it’s not my tool.

Tailwind’s actual superpower

Most arguments around Tailwind get stuck at the surface:

“Class soup is ugly”
“It’s basically inline styles”
“No, it’s faster”
“No, it destroys semantics”
“No, BEM is worse”

That debate is endless.

The real Tailwind pitch is simpler: constraints + speed.

Tailwind turns styling into selecting from a predefined design system (spacing scale, font scale, colors, shadows, radii). That’s why it feels so productive. You’re not inventing a new margin value every 5 minutes , you’re picking from a menu. Tailwind’s own docs explicitly frame it as “designing with constraints”, and pair that with variants for hover, focus, and responsive behaviour.

When Tailwind works, it feels like this:

You have a component in your head
You type the HTML
You sprinkle utilities until it looks right
You move on with your life

No naming. No context switching between files. No “where is this class defined”. No cascade surprises.

And if you’re working in a team (or inheriting a codebase), the consistency is a big deal. You can open any component and recognise the spacing and typography patterns instantly, because everyone is pulling from the same scale.

That’s a real benefit.

“Isn’t it just inline styles?” Not really.

This is worth addressing because it’s the most common misunderstanding.

Inline styles are limited. No pseudo-classes, no pseudo-elements, no media queries, no selector relationships, no tooling. Utility classes live in real stylesheets, so they can do everything CSS can do (including complex selectors, responsive behaviour, caching, processing, etc.).

So no, Tailwind is not style="".

It’s more like: “write your CSS once, pre-slice it into Lego bricks, then build UIs by snapping bricks together.”

The moment Tailwind clicks (and why people love it)

I’ve worked on Tailwind projects. I get the appeal.

There are three moments where Tailwind feels undeniably good:

1) You stop naming things

Naming is hard. Naming CSS classes is its own little tax.

Tailwind sidesteps that by making your “naming” be the composition itself. You don’t create .pricingCardFeatured and then hunt for it later. You just describe the styles right where they apply.

Even if you disagree with the conclusion, the problem is real: CSS and HTML are coupled whether you like it or not.

2) It makes boring layout work fast

Spacing, flex, grid, alignment, typography: Tailwind is extremely optimized for the 80 percent case.

It’s especially good at “dashboard UI” work: cards, nav bars, modals, forms, tables, list items, and all the slightly boring stuff every product needs.

3) It gives you a default design system

This is the underrated part.

People don’t just like Tailwind because it’s utilities. They like it because the defaults are tasteful and cohesive. You can move quickly without designing a spacing scale from scratch.

That “design tokens out of the box” feeling is the gateway drug.

The main trade-off Tailwind makes

Tailwind’s trade-off is not “long class attributes”.

That’s annoying, but it’s manageable.

The real trade-off is: you move a big chunk of your styling layer into your markup layer.

Sometimes that’s exactly what you want.

But it changes how the codebase feels.

And that’s where I start to drift away from Tailwind, because for me HTML readability is not optional. It’s where I think about:

structure
accessibility
content hierarchy
interactive states
layout relationships

When every element is carrying 15 to 40 styling decisions, the document stops reading like a document.

Yes, components help. Yes, you can extract patterns. Yes, you can use @apply (we’ll talk about that). But the default mode is still “style lives in the markup”.

Some people love that. I don’t.

Another trade-off

There’s one more Tailwind trade-off that doesn’t show up:

you’re not just adopting a set of utilities, you’re adopting a whole ecosystem.

Tailwind works because it’s a tightly designed package: a Domain-Specific Language, a compiler pipeline, a config-driven design system, a documentation culture, and a bunch of editor tooling that makes it pleasant.

That’s great… until it isn’t.

This week, a GitHub discussion around Tailwind’s documentation (about adding an llms.txt endpoint for LLM-friendly docs) unexpectedly highlighted the fragility of that setup. In that thread, Tailwind’s creator described docs traffic being down significantly since early 2023, revenue being down sharply even while the framework remains popular, and a major reduction in engineering headcount. (c.f. https://github.com/tailwindlabs/tailwindcss.com/pull/2388)

I’m not bringing this up to predict doom. Tailwind is widely used and not “going away tomorrow.”

I’m bringing it up because it clarifies the risk profile of adopting a framework-level styling layer:

If Tailwind’s development slows, you can’t just “swap it out”.
Your markup is full of Tailwind’s vocabulary.
And if you leaned into @apply, even your CSS is now Tailwind-dependent.

So the exit cost isn’t “rewrite some styles”. It’s rewrite markup, retrain habits, rebuild constraints, and reestablish a design system.

With native CSS, you can still make bad architecture choices , but at least you’re building on the platform’s most stable contract. If tomorrow you change approaches, your code doesn’t stop compiling because a tooling layer changed shape.

The practical pain points (from actually using it)

Here’s what bothered me in real projects, beyond vibes.

1) “Content gets buried”

When class lists get long, the actual content becomes harder to scan. This is a real maintenance cost: editing copy, reviewing diffs, reading templates, doing quick refactors.

If your workflow depends on “fold all classes” plugins, that’s a signal. Not necessarily a deal breaker, but a signal.

2) You start needing tooling to keep it readable

Tailwind is amazing with good tooling:

class autocomplete
sorting
linting
folding
component extraction patterns

Without that, it can feel like typing encrypted abbreviations.

Again: not fatal, just friction.

3) It nudges you toward breakpoint-heavy design

This one is subtle, and it depends on how you write CSS.

A really common Tailwind style is: sm:, md:, lg: everywhere.

That works, but it can also push you into “design at breakpoints” instead of building layouts that are fluid by default.

To be clear: Tailwind can do fluid layouts. But the path of least resistance often becomes breakpoint choreography.

4) The “escape hatch” problem

Tailwind is great until you hit something that doesn’t map nicely to utilities.

At that point you either:

write custom CSS anyway
use arbitrary values
create weird utility combos
reach for plugins
or accept something “close enough”

I don’t even mind mixing. The web is messy. But if I’m going to write CSS anyway, I start asking: why am I also maintaining a second styling language?

“But you can just use @apply”

A lot of Tailwind discussions end with:

“Just extract components.” or “Just use @apply.”

And you can. The issue is what you’re extracting into.

@apply is not CSS. It’s Tailwind syntax that requires Tailwind in your build pipeline. If you remove Tailwind, those styles break.

This is where Tailwind starts to feel less like “CSS helpers” and more like adopting a framework.

That’s fine. Frameworks are normal. I just prefer when my styling layer stays as close as possible to the platform.

My honest reason: I like CSS as a language

This is the part that gets misread as elitism, so let me say it plainly:

I don’t avoid Tailwind because I think Tailwind users are wrong.
I avoid Tailwind because I enjoy writing CSS, and modern CSS has become extremely capable.

I like:

custom properties as real design tokens
cascade layers to keep priorities predictable
container queries for component-level responsiveness
newer selectors and pseudo-classes
small utilities that I control
debugging styles in DevTools as actual CSS rules, not a long list of class mappings

Tailwind can coexist with modern CSS, but it’s still an abstraction layer. And when you already know the base language well, abstractions have to earn their place.

The part people really want: “Okay, what do you do instead?”

I try to steal Tailwind’s best idea (constraints) without adopting Tailwind’s whole approach.

Here’s the pattern:

1) Design tokens in CSS, not JS

Instead of a Tailwind config defining spacing and colors, I define tokens using custom properties:

:root {
  /* spacing scale */
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-3: 0.75rem;
  --space-4: 1rem;
  --space-6: 1.5rem;
  --space-8: 2rem;

  /* colors */
  --bg: #f6f0e8;
  --text: #111;
  --accent: #1f6b55;
}

This gets me the “designing with constraints” benefit, but it stays native.

2) A tiny set of utilities that I actually use

I’m not against utilities. I’m against importing 10,000 of them by default.

So I’ll define a few:

.stack {
  display: grid;
  gap: var(--space-4);
}

.card {
  border: 2px solid var(--text);
  border-radius: 12px;
  padding: var(--space-6);
  background: var(--bg);
}

Now my HTML is readable again:

<section class="stack">
  <article class="card">
    <h2>Title</h2>
    <p>Text</p>
  </article>
  ....
</section>

3) Use CSS for the relationships Tailwind struggles with

Tailwind is great at styling an element. CSS is great at styling relationships.

Parent state, sibling relationships, component structure, “if this exists then style that”, fluid layouts, container-driven behaviour.

This is why I keep coming back to CSS. The language keeps getting better at exactly the kinds of things that used to be Tailwind’s sweet spot.

When Tailwind absolutely makes sense
If you read this as “Tailwind bad”, you missed the point.

Tailwind is a great choice when:

you have a product team and need consistent UI fast
you want onboarding to be easy (many devs know Tailwind now)
you want a default design system with strong guardrails
you build mostly inside component frameworks where markup readability matters less than component boundaries
you don’t want to spend time building and maintaining a CSS architecture

It can also be a solid bridge for devs who feel lost in CSS, because its docs + constraints teach styling patterns indirectly.

Why I still don’t use it
If I had to summarise my position in one sentence:
I want Tailwind’s constraints, but I want them in native CSS, with readable HTML, and without adopting a second styling Domain-Specific Language.

That’s it.

Tailwind solves real problems. It just solves them in a way that makes my code feel less like the web platform and more like a framework language.

If that trade-off is worth it for you, use it. Seriously.

If you’re on the fence, my suggestion is boring but honest: try both approaches on a real project, then pick the one that makes you move faster without hating your codebase three months later.

Support My Work

Feel free to leave your comments or questions.
If you found this article helpful, please share it with your peers.

If you want more content from me, you can go directly on my blog.
I also created a 7-day email course to learn more about modern CSS.

Happy coding!

Diagonal Background Pattern with TailwindCSS

Mon, 20 Oct 2025 09:08:35 +0000

Background patterns are a recent trend in web design, and most can be replicated with only CSS. In this article, I will teach you how to replicate the diagonal background pattern on the Tailwind CSS website using only Tailwind CSS.

What we will be building

We will build this simple card component using the background pattern on the card header. The card is a custom shadcn card with extended styles. I will only focus on the background pattern on the card header, and not the card layout or content.

Tailwind CSS

globals.css

:root {
  --border: oklch(0.9219 0 0);
}

.diagonal-bg {
  @apply bg-[image:repeating-linear-gradient(315deg,var(--border)_0,var(--border)_1px,transparent_1px,transparent_50%) bg-[size:8px_8px];
}

Card Component

/** Card.tsx */

function Card() {

  return (
    <Card>
      <CardHeader className="py-4 diagonal-bg">
        <CardTitle>User Details</CardTitle>
      </CardHeader>
      <CardContent>
       {/** card content */}
      </CardContent>
    </Card>
  );
}

Explanation

Gradient

315° points top-left. Using repeating-linear-gradient(315deg, …) lays stripes along that diagonal.
The pattern then repeats infinitely along the gradient axis for a subtle diagonal texture.

Colored stripe (var(--border))

In this example, I am using a --border variable.
var(--border) 0 starts the colored stop at the very beginning of the pattern.
var(--border) 1px holds that color until 1px, creating a crisp 1px line.
var(--border) is a CSS variable for colour.

Transparent gap

transparent 1px turns the colour off right after the 1px line.
transparent 50% keeps it transparent until halfway through the repeat segment, so each unit is “1px line + clear space.”

Tile size & repeat

background-size: 8px 8px sets each repeating tile to 8×8px.
With a 1px line in each tile, the repeats intersect to form a fine diagonal grid/checker texture.

Conclusion

One thing to note is that more often than not, background patterns in Tailwind CSS can be very verbose. I encourage you to move the CSS code to an @apply Tailwind block in an external file, or, as we will see in other examples in this series, you can keep the code within the component, depending on your preferred React pattern.

What other background pattern do you want me to cover?

Space vs. Gap — Tailwind CSS Explained

Sat, 04 Oct 2025 07:32:09 +0000

Tailwind is an awesome resource when styling web applications. It’s fast, lightweight, and easy to use once you get used to the class-first syntax. But what do you use when you need to add some spacing between items — gap or space?
Let’s get into it.

What do I use?

To tackle this question, let’s create a scenario. We’ll be using three boxes represented by divs in an HTML document.

<section>
  <div class="w-48 h-48 bg-slate-300">Box 1</div>
  <div class="w-48 h-48 bg-slate-400">Box 2</div>
  <div class="w-48 h-48 bg-slate-500">Box 3</div>
</section>

In this example, there are three boxes we need to add some spacing to. Normally, the way to go about this would be to:

Use a flex layout on the section parent element and add a gap value to create space.
Use a margin on each box.

But what happens when there’s no need to use a flex layout or margin? What do we use?

That’s where the space Tailwind class comes in. Picture it as what gap is capable of in a grid or flex layout, but without the flex/grid. So let's see a side-by-side comparison.

<!-- with tailwind space -->
<section class="space-5">
  <div class="w-48 h-48 bg-slate-300">Box 1</div>
  <div class="w-48 h-48 bg-slate-400">Box 2</div>
  <div class="w-48 h-48 bg-slate-500">Box 3</div>
</section>

<!-- with tailwind gap -->
<section class="flex gap-5">
  <div class="w-48 h-48 bg-slate-300">Box 1</div>
  <div class="w-48 h-48 bg-slate-400">Box 2</div>
  <div class="w-48 h-48 bg-slate-500">Box 3</div>
</section>

In the first code block, using Tailwind spacecreates spacing between the items in the section element. The main difference is that when using gap, a flex or grid layout is required, whereas when using space, it's not.

This is something I discovered earlier when exploring more of what Tailwind CSS can do in my projects.

Hopefully, this article has helped to simplify the gap vs. space concept in Tailwind. For more detailed documentation, please visit the official Tailwind docs: Tailwind gap vs. Tailwind space.

Thanks for reading, and have a great day.
Ciao

Why My First React App Was Ugly (and What I Did to Fix It)

Mon, 14 Jul 2025 11:01:12 +0000

When I built my first React app, I didn’t expect to be embarrassed by it.

I had the logic working. Components rendered. Data flowed. But when I stepped back and looked at the whole thing… it just felt off. No one had to tell me I knew it was ugly.

Looking back now, I realize that this “ugly” version was one of the best things that could have happened. It forced me to think deeply about design, user flow, and what I was really trying to build.

The App: A Minimal Portfolio
You can check it out here: modello-oro-jb.netlify.app

It’s still minimalistic and could definitely use more polish. But I’m proud of it not because it’s perfect, but because it shows progress. Every section is a reminder of the small (but crucial) lessons I picked up while learning React and frontend design at the same time.

Where I Went Wrong
Here are a few things I didn’t get right at first:

1. Design Without Spacing Logic
I underestimated the power of padding and margins. Everything felt crammed or too spaced out. I learned quickly that design isn’t just about color and fonts it’s also about breathing room and visual hierarchy.

2. Responsiveness? What’s That?
I focused so much on getting it to look good on desktop that I forgot people would visit on mobile too. The first time I opened it on my phone, I was horrified. Buttons overflowed, text broke, layouts collapsed.

3. State Management Overkill
In one section, I used useState and useEffect when a simple conditional would’ve done the job. I was so eager to use React tools that I forgot about clarity and simplicity.

4. Animations Were… Missing
I didn’t think much about transitions or feedback animations. So every interaction felt a bit lifeless. Later on, I discovered how even subtle motion can change the user’s perception of quality.

What I Fixed (and Still Improving)
Switched to a component-first approach to keep code dry and reusable

Adopted Tailwind CSS for more consistent styling and responsive utility classes

Focused more on typography and spacing to guide the eye better

Added some subtle transitions and hover effects for interactivity

Started thinking of mobile-first instead of retrofitting for small screens later

What I Learned
Here’s what I’d tell my past self (or anyone just starting out with React and frontend):

Ugly is part of the process and it’s a great teacher.

Don’t obsess over frameworks; obsess over the user experience.

Write your code like someone else has to read it because one day, that someone will be you.

Design and development aren’t separate they go hand in hand, especially for solo devs.

Final Thoughts
The app still isn’t perfect, but I see it as a snapshot of my learning curve and that’s something to be proud of.

If you're building your first project and it feels a bit ugly, don’t give up. Instead, ask why, fix what you can, and learn from the rest.

I’d love to hear from others who’ve gone through the same phase drop your link or story below

LockedIn: Visualize Your Life in Weeks and Plan for Success

Sun, 03 Nov 2024 21:30:23 +0000

It was just another lazy evening. I was mindlessly scrolling through Instagram,
And then, one reel stopped me in my tracks.

It was a sarcastic but brutally honest saying,

“Yes, you're going to become a billionaire, trillionaire... by scrolling all day. Someone out there is keeping their head down, working tirelessly. And that's definitely not you.”

I seriously Uninstalled Instagram and started thinking this scrolling would not reach me where I wanted and even it would never make me reach if I continued doing so.

Rewiring My Mindset

Uninstalling Instagram wasn’t enough. I still had to figure out how to keep myself focused, disciplined, and working towards my bigger vision.

It wasn't just about getting rid of distractions; it was about setting my mind to operate in emergency mode—to treat time like the precious commodity it is.

But how?

How to make my mind in Emergency mode,

People around the globe are developing tools to improve productivity, focus, and motivation.

That’s when something from the web world hit me—I realized I could build something of my own…

A tool that could remind me every single day of how important time is.

What is LockedIn?

LockedIn is more than just a productivity tool; it's a visual representation of your life in weeks.

It shows you, in the most straightforward way possible, how much time you’ve spent and how much time you have left to achieve your goals.

The Countdown Grid: You enter your birthdate and name, and LockedIn generates a grid where each block represents one week of your life.

Progress Bar: LockedIn includes a progress bar that tracks how much of your life you've lived and how much remains.

Turning Vision Into Action: The To-Do List

While LockedIn helps you visualize your life at a macro level, I knew that wouldn’t be enough.

The next step was to bridge the gap between the big picture and daily actions. That’s where the To-Do List feature came in.

Check off accomplishments as you make progress, feeling that rush of dopamine with each task you complete.

With this, Plan your daily tasks and make sure they align with your long-term goals.

Final Thoughts: Lock in Your Time, Build Your Legacy
Initially, LockedIn was something I built just for myself. I wanted a tool that would help me stay in “emergency mode” and never waste another week.

But then something interesting happened—it was a Tuesday, and I remembered Peerlist - a platform where people submit their projects to gain feedback and connect with like-minded peers.

I figured, “Why not?” I decided to share LockedIn with the world. I submitted my project, expecting maybe a few eyeballs, a couple of comments, and that would be it.

But the response blew me away.

Suddenly, LockedIn was getting attention. People were commenting, upvoting, and praising the idea.

Why I Need Your Support on Peerlist
Now, here I am, sharing this with you because today is the last day to upvote LockedIn on Peerlist. Your support means a lot.

If you've ever felt like time is slipping through your fingers, I invite you to upvote LockedIn on Peerlist and join this movement of people who are taking control of their lives, one week at a time.

Final Thoughts:

Lock in Your Time, Build Your Legacy
The day I uninstalled Instagram was the day I stopped letting my time be controlled by algorithms. I decided to lock in and take charge of how I spend my days.

LockedIn has transformed the way I approach time, turning it from an abstract concept into something I can see, plan, and act on.

And now, I want to share this with you.

Join me on this journey. Let’s make every week count.

Upvote LockedIn on Peerlist before time runs out!

I hope you loved this writing, I have used my creativity and AI to write this article.

Do not forget to Upvote. for the time being, visit my other Blogs.

Thanks for reading.

Coder Legion - Recent posts tagged tailwindcss

Your Flex Child Won't Shrink, and overflow: hidden Isn't the Fix (It's min-width: 0)"

The Layout That Breaks

Why It Happens

Why overflow: hidden Looks Like a Fix (Sometimes)

Fix 1: min-width: 0 on the Flex Child

Fix 2: Grid's 1fr Has the Same Trap

Fix 3: Truncating Text With an Ellipsis Inside Flex

Fix 4: Long Words Need the Right overflow-wrap

Which One When

The Rule

Build a Slide-In Mobile Menu in TanStack Start with Tailwind v4

Remove the old mobile menu

Always render the panel

Make it jump in and out

Add the backdrop

Make it slide

Hide the closed panel

Stop the page from scrolling

Respect reduced motion (optional)

Test it and wrap up

Good to know and what to try next

Responsive Navigation in TanStack Start: Hamburger Menu and Desktop Navbar

Write the links once

Think mobile first

A separate NavLinks component

The header

Closing the menu when you navigate

Active links

Accessibility basics

Use it in the layout

Try it

What's next

Why Your Tailwind Classes Work in Development and Silently Vanish in Production

The Code That Looks Completely Reasonable

Why This Happens: Tailwind Doesn't Actually Execute Your Code

Why This Specifically Survives Local Development

The Fix: Always Write Complete Class Names, Literally

The Rule That Generalizes Beyond This One Example

Setting Up Our Frontend with TanStack Start

What Is TanStack Start?

Creating the Project

Walking Through the Setup Prompts

Running the App

Editing the Home Page

File-Based Routing

Adding an About Page

Adding a Products Page

What Is That __root.tsx File?

Summary

Why I Replaced Tailwind CSS With Vanilla CSS

TL;DR

Why replace Tailwind at all?

Tailwind v4 already runs on the CSS I switched to

What the migration actually looked like

Cascade layers replace the Tailwind import

Design tokens are just custom properties

Components: from class lists to scoped styles

Lightning CSS does the vendor work

Did the site stay Baseline compliant?

Do you still need Tailwind in 2026?

Tailwind CSS for Beginners: From Zero to Your First Component

Introduction

What Tailwind CSS Actually Is

Setting It Up (React + Vite)

Core Concepts You Need to Know

1. Spacing

2. Flexbox & Grid utilities

3. Responsive Design

4. Hover & State Variants

Building Your First Component: A Pricing Card

Common Beginner Mistakes

Final Thoughts

shadcn/typeset vs Tailwind Typography for Markdown

What is shadcn/typeset?

How do you install shadcn/typeset?

Size, leading, and flow

Why your Tailwind utilities win without !important

shadcn/typeset vs Tailwind Typography

What makes it streaming-safe?

Why `overflow: hidden` Looks Like a Fix (Sometimes)

What Is That `__root.tsx` File?