Shopify acquires Tailwind

Tailwind's business model existed due to a massive inefficiency in the frontend industry not being able to come to terms with CSS or native components. They surfed the wave of JS frontends becoming ever more complicated. If it wasn't AI and just a human awakening to that fact, realizing that the complexity of modern frontends and Tailwind are not an absolute necessity, they'd have lost business just the same. There are dozens of different ways of writing frontends that have nothing to do with Tailwind.

Providing ready-made UI components and templates has never been a million-dollar business, nor should it be.

If you think about it, the site docs garnering traffic (beyond potential tailwind labs conversions) is more of an indicator of a code or design smell than anything. That’s just my 2 cents as a guy who used to look up their docs constantly to confirm a pattern I was implementing, as tailwind classes were never really as self-evident as tailwind labs liked to believe they were IMO.

Like it just doesn’t make total sense to me to compare library documentation traffic hits to traffic hits that happen in other industries here, or with other products or companies. They aren’t even a traditional SaaS company, not that there really Is one either. Their service or income flow is defined by things like offering Enterprise support or a component library at a premium — things that aren’t simply dictated by or shown through documentation traffic trends; things that were encroached upon by plenty of other things besides AI.

They used different technologies for different templates and some even use a 3rd party CMS service that I had no interest in using. Their JavaScript components were non-native, so if I wanted to use any of the interactivity I had to write from scratch.

I think they had an opportunity to grow with AI and with the amount of code that is now being written.

Compare that to shadcn, which had visible growing pains and yet reached rocketship fame. Shadcn is evidence that developers were hungry for yet another library, and it's also evidence that users were willing to tolerate rough code on the ride to maturity.

I don't believe Tailwind's component libraries deserved to win.

But I guess not.

Too bad, they seem like such good people. Not that they're dead or something but I don't think this was their ideal end state for Tailwind.

Being a bit silly with the analogy: it's like we've discovered gunpowder and now entire classes of fortification are deficient.

In lieu of everything else, I'd say that in circumstances like that it's time to adapt to the state of the world and be the jerks that advertise in CLI.

In other words, the documents for the latest versions are hidden behind a pay wall.

If you're building something where your unit of organization looks more like a "page" than super fine grained elements, Tailwind will just make things messy and a higher-level library or writing your own CSS would be a better approach.

I don't think this changes much with AI - right now most models are not terrific at maintaining a huge degree of context in larger projects, so I could absolutely see an agent implementing CSS that works well in isolation but breaks due to the cascade. Maybe that changes in the future, but right now if anything I think Tailwind is well suited to AI because it enforces a certain locality to the changes you're making (i.e. you can reasonably assume that a `text-red-500` class on an element isn't going to break things elsewhere and wll do what it says on the box).

1: https://www.zolkos.com/2025/12/03/vanilla-css-is-all-you-nee...

2: https://www.joshwcomeau.com/css/subgrid/

3: https://railsdesigner.com/custom-elements/ (more Rails specific)

If you are styling a site, there's no competition at all. But if you are styling a single interaction-heavy page, it's a lot less work to put all the formatting inline instead of thinking about a descriptive structure and write your CSS around it.

Apparently a lot of people design entire sites one page at a time.

I do think Tailwind is overused, but it obviously has some legitimate use case.

I am a big advocate of classes, not inline styles spaghetti.

The only contact I had with it was due to FE teams jumping into it, however every couple of months is something else anyway.

Tailwind is just conceptually bunch of css inline styles repackaged as classes for performance boost. It was always just shifting complexity around, but offered an immediate perception of productivity gain, because you could just make a quick edit here and there.

a) it helps you codify your design system in utility classes. It makes it easier to keeps things consistent.

b) LLMs understand it better than plain css or other css-in-js systems where you're constantly wrestling control back. I mean, you still wrestle, but less.

Were I work I have to deal with an 8-years old codebase and we've switch several times from plain css, css modules, styled components, radix and now tailwind. I would be mad if I still had to write all those classes manually, but it's not the case anymore thank God.

Styling radio buttons, working date inputs, forms that POST automatically, typeahead and server-side validation (eg username already taken.)

You spend all your time reinventing the wheel and then it's buggy and looks like a dog. To say nothing of the inevitable poly fills and Cross-Browser issues.

A major point of components is having a single place where you can change design and behavior across your entire codebase. With LLMs you can with very good accuracy tell them to change the look of "all buttons that are confirmation buttons in modals but not in the login modal". Doesn't matter if there are 10 such buttons or 1000, it'll take a few seconds for them to accomplish it.

I'm slowly forming the opinion that nowadays having copy-and-pasted "components", with their whole HTML just repeated over and over, is now a much less worrying thing in a codebase. Even a bloated CSS can be quickly fixed by a LLM.

And like you said: you eliminate the build phase entirely and frontend development ergonomics goes back to how it was in the early 2000s.

CSS is really good these days. Scope rules and the new selectors available mean you actually have to work hard to mess things up like you did in previous eras

(Abstractions are still very useful to LLMs)

With AI I guess you could skip it, but I like to understand the code.

I can't be the only one who has no idea what this means. Do you mean high-abstraction classes that are bound to the DOM arbitrarily, and are difficult to change later? We've had 25+ years to see how that doesn't scale.

Do you mean Tailwind-style functional CSS written by hand? What would be the point of that?

I think there's a lot of technologies that are in the category of categoric mistakes to use, but popular enough and inert enough that they don't get dropped. There might be lots of different explanations depending on the technology, a lot have a reason the moment they are released.

Many third party tech becomes de facto standard at some era, then those features get incorporated into more mainstream tooling like browser css, and at that point the third party tooling exists only because of inertia and adds little value, but increasing supply chain and complexity risk.

Another example on this category is Axios which was essentially a cleaner DX for XMLHTTPRequests in client side javascript before Fetch, and later a polyfill for it. Nowadays it's a blunder to include it, but it ended up in stackoverflow answers and training sets, so it's "safe" to include. Developers that are on the bleeding edge drop it, but those that are catching up and reading tutorials or classes from the previous era, or using llms, use the previous era cutting edge technique, because they aren't evaluating all the parameters of a choice, they are just going with whatever someone else is using, which causes a coalescing around certain central technologies like React, Kafka, Redis.

Regarding Redis, my understanding is that it was popular during one era where databases were used to store state because we didn't know any better and people were moving fast and breaking things, so it was developed as a sort of hack to move things from a database into memory. But nowadays people just use it wherever (because it really is the most blank microservice you can think of, you can slap it anywhere), and people implement it off the bat.

There's lots of more specific reasons why bad third party deps persist. In python there's a library called python-dotenv, which is a categorical mistake to include, but people do it because they come from Node where it is a standard practice. But there's the standard nuance that in Node, it is a built in, but in python it is a third party dependency from a random dev (no offense to the dep dev, only to the users of the dep). It literally is replaceable by calling Open(), write(), and close(), but there it is with a lot of downloads waiting for the day it is targetted and hacked to capture millions of .env files. Personally to me it would be strike 1 of 2 if someone imports it, but there you go.

Yes, there's no reason to import tailwind, it adds nothing, the idea of:

red-color { color: red}

big-text { font-size: 14px}

<p class="red-color big-text"></p>

Is as laughably low quality, the application of a technique in form but not substance, similar to Getters and setters in Java, effectively making every property of a class public, but formally implementing the private keyword and access through functions. 100% a categoric mistake to implement.

I've written elsewhere of a phenomenon where devs avoid lerning a base technology, and rather end up learning a tech on a higher abstraction that ends up being a 1-for-1 of the lower tech, but it gave them the hope that they could avoid doing that learning, and they only drop into that realization by piecemeal ala "we did it not because it was easy, but because we thought it would be easy", and the only cost is that they learned the non-portable version of that technology and now they are vendor-locked professionally into that technology so they will spread it to the next repo, company, job posting and so on.

There's analogues in biology of inert viruses or parasites that don't materially cause damages, but their lifecycle depends on the host. Although to some extent, by competing for resources they always cause SOME damage, but it is important to notice that not all viruses or damages are highly damaging, that's a rare situation of very extreme pathogens, it isn't very beneficial to kill or damage your host. In fact many may be commensal, but there is a tendency to harm.

In conclusion, I think tailwind and such pre-ai slop-deps are more popular because they are inert viral parasites rather than because they provide value.

That said, Tailwind is not as powerful as plain old CSS. It's a bit like training wheels for CSS—you gain some guardrails and prevent newbies from messing things up too badly, but you also give up the power modern CSS affords you.

E.g. I invite you to look at some of Ahmed Shadeed's (https://ishadeed.com) layout tutorials, or whatever you find on the CSS-Tricks/Masters.dev homepage today. It's bonkers what you can do with modern CSS!

Tailwind gives you access some of what's possible with CSS today, and they keep adding support for new features, but it's impossible to express everything CSS is capable of using only utility classes. At some point, you need to write some actual real CSS code.

So personally, it's a tradeoff for me. If I really want the full power of CSS, I use plain old CSS. If I'm willing to trade power for the convenience of Tailwind's built-in design tokens and guardrails, then I pick Tailwind.

Both approaches are good and valid. The right choice is context dependent. With And with LLMs in the mix, it's not that hard to port a Tailwind codebase to plain CSS, or vice versa, so picking the wrong thing doesn't have as high a cost as it used to.

We use Claude for design of document templates a lot, and whilst we've built a fantastic pipeline for doing that well, asking Claude to then design anything outside of our guardrails isn't effective.

So I could imagine folks prioritising high quality design of all kinds choosing templates that would guide Claude.

I look at a large number of startup websites and it's very clear which ones are using Claude the excessive CAPS headings alone give it away. They look OK but the Claude aesthetic does leave me wondering whether this is a real business or one person using Claude to build a LP.

Even the bossman admitted that AI fired his employees, not the boss.

I guess that’s why people talk so much about leadership this leadership that. I’m learning that leadership is when you are the captain of the ship and the ship goes down you man the lifeboat and mourn your sailors over what the Sea did to them.

And a recent video is about designing a dashboard with Ai, which is exactly what I been needing from him specifically.

I remember reading the book 6 years ago and I loved how easy it was to understand.

It's also where I first learned about dense UI and was amazed at a before/after example of one. You can clearly see that uncommon common sense he has about UI/UX.

Thanks for mentioning this.

That said, I prefer vanilla CSS. Modern CSS is great.

If you are using mostly agents and don't actually need to have it in your brain, then I'd probably go with strict TypeScript at the very least for verifiability purposes

https://xcancel.com/argyleink/status/2095253698431844607

It has for me at least.

I had a solo business for 10 years selling tech video courses (learning Flask, Docker, etc.). It was enough to pay the bills, but for the last few years it has nose dived. For 2026 YTD it has generated $20 / month in revenue but it costs almost triple that to host the courses so I've been losing hundreds of dollars a year, for years. All while watching LLMs cannibalize ~600 free in-depth blog posts and YouTube videos only to re-sell that information to anyone willing to pay.

It completely flipped my life upside down to where for 20 years I was able to sustain myself doing contract work + courses to having to take full time work. All of this started when AI became popular.

It's all related to a massive loss of traffic to my site which was the entry point to both contract work and the courses. Both sides of the business have been crushed.

You've got to wonder how long that model can continue if no new customers are allowed in.

They've even removed the Plus splash page so clicking Plus on the homepage or going to /plus takes you to a login page with no detail about what it was.

The only thing that remains to be seen is how these affect those tools going forward (and who's next)

You end up having to keep them synchronized anyway, messing with your HTML is frequently gonna break your CSS. Tailwind is infinitely more pleasant to write than a separate CSS file that has to be kept in sync with the HTML.

And even if they were a charity, the sponsors... well I don't think you would like them either.

They were 'captured' before Shopify bought them.

Money > Principles

100% every time

Years of people deploying web apps and using (My-)SQL without prepared statements provide a counterexample to this. One can argue about ORMs, but stating SQL would need no abstraction layer around it seems questionable to me :/

If you want to build a case against Tailwind that's actually compelling, you should start by understanding what it is first. Only then can you compare it to other frameworks and methodologies.

https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...