Short version for the impatient: Tailwind CSS is not going anywhere, the v4.3 scrollbar utilities let you delete a file you've been copy-pasting between projects for years, and if you were about to buy Tailwind Plus for a client build, that door closed on September 9th. If you want the details, read on.
I found out about the Shopify news the same way I find out about most things, which is a client forwarding me a headline with the message "should we be worried?" This particular client has three storefront-adjacent marketing sites on Tailwind, and I built all of them. So I had a vested interest in the answer being no. I spent a chunk of Wednesday evening reading the announcement, then the v4.3 changelog I had somehow skipped in May, and then I did the thing I always end up doing, which is opening one of those client repos and looking for stuff I could delete.
I deleted 41 lines. This post is about those 41 lines, and about what the acquisition does and doesn't change for people like me who ship Tailwind to paying clients.
What Adam Wathan actually said
The announcement post is short and worth reading in full rather than through my summary. The parts that matter for anyone with Tailwind in production:
The framework stays MIT-licensed. Wathan's wording is that nothing changes with Tailwind CSS or any of the other open source projects, and that the team continues to lead them with Shopify's support. Headless UI and Heroicons fall under that same umbrella.
The commercial side is being wound down. Existing Tailwind Plus and ui.sh customers keep access. New sign-ups are closed. That last line is the one that actually affects freelancers, and I'll come back to it.
The stated reason is that Wathan wanted the framework developed in service of a real product rather than a template business. You can be cynical about acquisition posts (I usually am), but this one lines up with something he's been saying in podcasts for years, so I'm inclined to take it at face value.
Shopify's own stake is not small either. The post says Tailwind is used to style ChatGPT, X, Cloudflare, Reddit, and Shopify itself, and that the package is installed over 110 million times a week. A company that depends on a library that heavily has an obvious incentive to keep it maintained. That's a different situation from an acquirer buying a project it doesn't use.
What it changes for client work (less than the headline suggests)
Here is my honest read after a few days of sitting with it.
For the framework itself, nothing changes this year. The npm package, the Vite plugin, the PostCSS plugin, the new webpack loader, all still there, all still MIT. I'm not adding a line to any client contract about this.
For Tailwind Plus, it changes a lot, and quietly. I've used Plus as a shortcut on at least a dozen client projects. Buying a license and adapting a marketing block is faster than designing one from scratch, and clients don't care where the starting point came from. With sign-ups closed, that shortcut is gone for anyone who didn't already have a license. If you have one, keep the account alive. If you don't, you're back to designing sections yourself or paying for a different component library, and most of the alternatives are either React-only or noticeably worse.
For the ecosystem, the thing I'm actually watching is the release cadence. The v4.2 improvements came out of the Partners Program with Netflix and Vercel. Under Shopify, the pressure will come from Shopify's storefront and admin teams instead. That's fine, and arguably better, because those teams build the kind of dense, data-heavy UI that stresses a utility framework more than a marketing site does. But it does mean the roadmap will lean toward what Shopify needs. I'm not sure yet whether that's good or bad for the average agency build. I'll know in a year.
And for the "is Tailwind dead" question my client was really asking: no. A project that ships 110 million weekly installs and just got a corporate maintainer is closer to the opposite of dead. The thing that died is the template business, and most people who search that phrase weren't paying for templates anyway.
The 41 lines I deleted: scrollbar styling before v4.3
Every client project I've touched since about 2019 has had a file called something like scrollbars.css. It looks like this, more or less, and I'd bet you have one too:
/* scrollbars.css - copied between projects since forever */
.nice-scroll {
scrollbar-width: thin;
scrollbar-color: #0369a1 #e0f2fe;
}
.nice-scroll::-webkit-scrollbar {
width: 8px;
height: 8px;
}
.nice-scroll::-webkit-scrollbar-track {
background: #e0f2fe;
}
.nice-scroll::-webkit-scrollbar-thumb {
background-color: #0369a1;
border-radius: 4px;
}
.nice-scroll::-webkit-scrollbar-thumb:hover {
background-color: #075985;
}
.hide-scroll {
scrollbar-width: none;
-ms-overflow-style: none;
}
.hide-scroll::-webkit-scrollbar {
display: none;
}
.stable-gutter {
scrollbar-gutter: stable;
}
Then in the markup:
<div class="nice-scroll stable-gutter overflow-auto max-h-96">
<!-- long list -->
</div>
Two problems with this. First, the colours are hardcoded hex values that drift out of sync with the Tailwind theme the moment a client asks for a palette change. I've fixed exactly that bug three separate times. Second, the ::-webkit-scrollbar pseudo-elements and the standard scrollbar-color property fight each other in some Chromium versions, and the way they resolve that fight changed around Chrome 121. I got a bug report once where the thumb was the right colour but the track was white, and it took me an embarrassing amount of time to work out that both rule sets were applying.
The same thing in Tailwind v4.3
The v4.3 release post added first-party utilities for scrollbar-width, scrollbar-color, and scrollbar-gutter. Here's the same component with the CSS file deleted:
<div class="scrollbar-thin scrollbar-thumb-sky-700 scrollbar-track-sky-100
scrollbar-gutter-stable overflow-auto max-h-96">
<!-- long list -->
</div>
The hidden-scrollbar variant is scrollbar-none. The gutter utilities are scrollbar-gutter-auto, scrollbar-gutter-stable, and scrollbar-gutter-both. The colour utilities take the normal opacity modifier, so scrollbar-thumb-slate-900/60 works the way you'd expect.
The part I care about most is that the colours are now theme tokens. When the client changes their brand blue, sky-700 gets swapped in @theme once and the scrollbars follow. That's the bug I'd fixed three times, gone.
What you don't get: the ::-webkit-scrollbar pseudo-elements. Tailwind is only emitting the standard properties. That means you lose the ability to set an explicit pixel width or a thumb border-radius. scrollbar-width: thin is whatever the browser thinks thin is. On my Mac with overlay scrollbars it barely matters; on a Windows laptop with a mouse it's a visible difference from the 8px rounded thumb my old CSS produced. I kept the old file on one project because the design spec called for a specific radius and the client would notice. On the other two I deleted it and nobody has said a word.
If you still need the pixel-level control, you can keep a tiny @utility in your CSS and layer it on top:
@utility scrollbar-rounded {
&::-webkit-scrollbar {
width: 8px;
height: 8px;
}
&::-webkit-scrollbar-thumb {
border-radius: 4px;
}
}
That's six lines instead of 41, and none of them contain a colour.
The v4.2 bits I'd missed
Because the v4.3 post is, by the team's own admission, also the v4.2 post they forgot to write, I caught up on a few other things at the same time.
The dedicated webpack loader is the one with a real number attached. The team measured 932ms with @tailwindcss/postcss versus 429ms with @tailwindcss/webpack on their own docs site under Next.js and Turbopack. That's the compile step only, and your project won't be their docs site, but if you're on Next.js it's a one-line dependency swap. I wrote about the Turbopack chunking changes in Next.js 16.3 recently, and this loader stacks on top of that because Turbopack runs webpack loaders through its compatibility layer.
The logical property utilities matter if you ship anything with Arabic or Hebrew content, which for me, working out of Dubai, is most projects. mbs-6 and pbe-8 for block-start and block-end spacing, inset-s-0 and inset-e-4 for logical positioning. The old start-* and end-* utilities still work but are deprecated in favour of inset-s-* and inset-e-*. I have a find-and-replace queued for that.
Four new neutral palettes: mauve, olive, mist, taupe. I've used mist once already. It's slightly cooler than slate without going full blue, and it made a dashboard look less like every other dashboard.
And font-features-["tnum"] for OpenType features that don't have their own utility. You should still use tabular-nums for the common case, but the escape hatch is nice for stylistic sets.
What I'd actually do this week
If you're on a Tailwind project right now, three things, in order of how long they take.
Run npm install tailwindcss@latest and check what version you land on. If you were on 4.1 you've skipped two releases and you'll want to read the changelog before the upgrade rather than after.
Grep your CSS for ::-webkit-scrollbar. Every hit is a candidate for deletion. Decide per component whether you need the pixel radius or whether scrollbar-thin is good enough, and don't keep the file out of sentiment.
If you have a Tailwind Plus account, log in and confirm it's still active. If you don't, and you were relying on it as a starting point for client sections, start looking at alternatives now rather than mid-project. I've been comparing a few for my own agency work and I'll write that up once I've shipped something with one of them.
The acquisition is a good outcome for a project that a lot of us depend on. It's a slightly worse outcome for people who liked buying templates. I'm in both groups, and on balance I'll take it.
Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.
