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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
The announcement post<\/a> is short and worth reading in full rather than through my summary. The parts that matter for anyone with Tailwind in production:<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Here is my honest read after a few days of sitting with it.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Every client project I’ve touched since about 2019 has had a file called something like Then in the markup:<\/p>\n 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 The v4.3 release post<\/a> added first-party utilities for The hidden-scrollbar variant is The part I care about most is that the colours are now theme tokens. When the client changes their brand blue, What you don’t get: the If you still need the pixel-level control, you can keep a tiny That’s six lines instead of 41, and none of them contain a colour.<\/p>\n 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.<\/p>\n The dedicated webpack loader is the one with a real number attached. The team measured 932ms with The logical property utilities matter if you ship anything with Arabic or Hebrew content, which for me, working out of Dubai, is most projects. 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.<\/p>\n And If you’re on a Tailwind project right now, three things, in order of how long they take.<\/p>\n Run Grep your CSS for What it changes for client work (less than the headline suggests)<\/h2>\n
The 41 lines I deleted: scrollbar styling before v4.3<\/h2>\n
scrollbars.css<\/code>. It looks like this, more or less, and I’d bet you have one too:<\/p>\n\/* scrollbars.css - copied between projects since forever *\/\n.nice-scroll {\n scrollbar-width: thin;\n scrollbar-color: #0369a1 #e0f2fe;\n}\n\n.nice-scroll::-webkit-scrollbar {\n width: 8px;\n height: 8px;\n}\n\n.nice-scroll::-webkit-scrollbar-track {\n background: #e0f2fe;\n}\n\n.nice-scroll::-webkit-scrollbar-thumb {\n background-color: #0369a1;\n border-radius: 4px;\n}\n\n.nice-scroll::-webkit-scrollbar-thumb:hover {\n background-color: #075985;\n}\n\n.hide-scroll {\n scrollbar-width: none;\n -ms-overflow-style: none;\n}\n\n.hide-scroll::-webkit-scrollbar {\n display: none;\n}\n\n.stable-gutter {\n scrollbar-gutter: stable;\n}\n<\/code><\/pre>\n<div class="nice-scroll stable-gutter overflow-auto max-h-96">\n <!-- long list -->\n<\/div>\n<\/code><\/pre>\n::-webkit-scrollbar<\/code> pseudo-elements and the standard scrollbar-color<\/code> 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.<\/p>\nThe same thing in Tailwind v4.3<\/h2>\n
scrollbar-width<\/code>, scrollbar-color<\/code>, and scrollbar-gutter<\/code>. Here’s the same component with the CSS file deleted:<\/p>\n<div class="scrollbar-thin scrollbar-thumb-sky-700 scrollbar-track-sky-100\n scrollbar-gutter-stable overflow-auto max-h-96">\n <!-- long list -->\n<\/div>\n<\/code><\/pre>\nscrollbar-none<\/code>. The gutter utilities are scrollbar-gutter-auto<\/code>, scrollbar-gutter-stable<\/code>, and scrollbar-gutter-both<\/code>. The colour utilities take the normal opacity modifier, so scrollbar-thumb-slate-900\/60<\/code> works the way you’d expect.<\/p>\nsky-700<\/code> gets swapped in @theme<\/code> once and the scrollbars follow. That’s the bug I’d fixed three times, gone.<\/p>\n::-webkit-scrollbar<\/code> 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<\/code> 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.<\/p>\n@utility<\/code> in your CSS and layer it on top:<\/p>\n@utility scrollbar-rounded {\n &::-webkit-scrollbar {\n width: 8px;\n height: 8px;\n }\n &::-webkit-scrollbar-thumb {\n border-radius: 4px;\n }\n}\n<\/code><\/pre>\nThe v4.2 bits I’d missed<\/h2>\n
@tailwindcss\/postcss<\/code> versus 429ms with @tailwindcss\/webpack<\/code> 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<\/a> recently, and this loader stacks on top of that because Turbopack runs webpack loaders through its compatibility layer.<\/p>\nmbs-6<\/code> and pbe-8<\/code> for block-start and block-end spacing, inset-s-0<\/code> and inset-e-4<\/code> for logical positioning. The old start-*<\/code> and end-*<\/code> utilities still work but are deprecated in favour of inset-s-*<\/code> and inset-e-*<\/code>. I have a find-and-replace queued for that.<\/p>\nfont-features-[\"tnum\"]<\/code> for OpenType features that don’t have their own utility. You should still use tabular-nums<\/code> for the common case, but the escape hatch is nice for stylistic sets.<\/p>\nWhat I’d actually do this week<\/h2>\n
npm install tailwindcss@latest<\/code> 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.<\/p>\n::-webkit-scrollbar<\/code>. Every hit is a candidate for deletion. Decide per component whether you need the pixel radius or whether scrollbar-thin<\/code> is good enough, and don’t keep the file out of sentiment.<\/p>\n