I just can't fathom how someone can look at this and think "yeahhhh thats some good clean code". How did tailwind get so popular? Learn plain CSS. It's really good now
Tailwind goes into crazy extreme so people can copy paste whole complex components and they work. That’s why you can dunk on these verbose examples.
This is not how custom functional css codebase looks. In custom projects you change the system/configuration to fit the project. You create your own utilities for example you wont have “text-lg sm:text-xl font-semibold tracking-tight” but will have class “font-heading-2”. Similarly you will create button/input classes that have you basic styles.
Generally you start with just simple utility classes inside html and go from there and where it make sense or its too complex you separate to more complex class. You end up with short css file that only has these special components and none of the basic stuff.
For most elemets it ends up like “flex justify-center gap-4”. In BEM i have to invent “nav-secondary__header” put it in correct place and hate myself when i need to change it to “flex justify-beween”.
Tailwind popularised functional css but is also aimed at masses/noobs. Somehow some of those concepts also resonated with some experienced users.
Code doesn't necessarily need to be clean. We've had, like, two decades of "do clean code" and a lot of the time that mentality is shit. Putting stuff in a separate file and introducing layers and layers of abstractions to keep things "clean" doesn't always make it so. Often, it makes the code more complex, and makes behavior difficult to reason about.
The big problem with Vanilla CSS is that's it's sort of like Perl. It's a read-only language in practice.
Yes, theoretically, you can have perfect semantic CSS classes and use those. In practice, not every button is the same and you'll need slightly different styling in different places.
Yes, we could go in and change the .button class. But who is using the .button class? Where is it used? Nobody knows, and you can't find out. So editing that class is EXTREMELY risky. I have seen many an entire application break because some dev decided to edit CSS. The bigger the application, the bigger the risk.
Where I work, we have 1500 devs. Does anyone know the complete set of usecases a CSS class would have? No. Even if I gave you a month to research it, you would not find out. So you cannot edit CSS classes, it's far too risky.
So, the result is that everyone just tacks on to the end of the CSS. And now, in your clean code world, you have 50 different button classes. Um... whoops.
If you want to compartmentalize, what you can do is use components, in whatever backend/frontend framework you have. You can have the component have their own state and allow users of the component to change parts of it. Then, it doesn't matter how "unclean" the tailwind is - because you'll almost never see it. But if you need to change it, you can, without destroying the entire application. No more 50 button classes, and no more read-only implementations.
Can I copy some random HTML+CSS snippet from the internet and be sure that it'll look exactly the same in my project and that no existing CSS is going to overwrite it?
I'm never gonna argue learning proper CSS wouldn't be better, but Tailwind is by far the path of least resistance for someone that has no interest in writing frontend for a living. It's like putting legos together, it requires very little thought to get from nothing to a decently looking website.
This is objectively good clean code when you develop it.
Because most of those classes are per component.
If you have a single card component defined with these classes, and then repeat it 20 times on the page, then of course the output will look like a giant mess.
> How did tailwind get so popular?
- quick to understand and get started with
- much cleaner for components than the variety of CSS-in-JS libs
- (mostly) do not require fighting CSS with BEM-style atrocities
- come with nice default styles and colors that can be easily changed and extended
> Learn plain CSS. It's really good now
CSS is okay now. We only just got nesting and scoping
I was a Tailwind skeptic for a long time but I've used it on a few projects now at my full discretion.
However I use it in a much more blended way than the authors probably prefer. I use it with Tailwind Variants and to quickly hack out components. However depending on the project, component, and etc I may also construct BEM-based CSS files to live along side the component.. I use "@apply" in the CSS files, something the author(s?) are on record saying they regret. However I'd counter them by saying if it weren't for "@apply" Tailwind wouldn't be where it is today..
I like how tailwind provides scoping automatically. But in projects already having a build system I use css modules. Writing pure CSS is so much nicer but please don't make me manage class names myself.
I have seen this sentiment on HN a lot recently. Any good resources for that? I was quite the accomplished web developer 15-20 years ago and want to catch up without having to learn a new library or framework every six months.
It is not the nicest but you will quickly get used to it and productive.
However maintaining huge websites with thousands of thousands of lines of custom CSS will never be easy. And especially if somebody else wrote it.
This takes away so many of the criticisms I see in this thread. The issue with Tailwind, and my only minor criticism, is just long, unreadable, not easy to deliminate lists of classes. This very easily takes care of that (and I use it for more complex class lists daily)
I do this to this day, when I’m writing manual vanilla CSS. I group spacings, fonts, texts, borders etc together so it is easier for me to debug without using too many tools.
Before Tailwind, every web designer I’ve ever worked with invented their own version of this.
Yes, CSS in theory is powerful and has everything necessary to avoid using Tailwind, but in practice CSS has a major flaw: You’re almost required to build a semantic model to get the full power. But this ignores that designers are working with mood and emotion just as much as document structure and information architecture. Capturing these more nebulous concepts as logical semantic rules is very difficult if not impossible. Tailwind just codified what everyone already did: Skip the semantic dance (“Making that text bold would be really cool, but what does it mean to be cool, as a general rule?”) and just create semantic rules like “bold” and “red”.
This is the complete opposite of what good CSS is supposed to be. The class name is supposed to tell you what it is not how it looks like. Anyone remember CSS Zen Garden?
Doesn't react with styles components (or CSS in js) avoid this? I define reusable components, drawing from a shared theme object. But the styles are still css
I have a feeling that Tailwind started with a good intention to be a utility classes CSS framework, akin to “Bourbon on Steroids”, but people began to accept and use their prototype/sample/example codes way better than they had intended, and they ran with it.
I stumbled on Tailwind in 2018 and introduced it to a team looking to revamp a pretty massive project. I remember that the initial proposal I made was to treat it like Bourbon[1] and write classes that build on Tailwind’s utilities. That way, you can still have `.button`, `.button-primary`, and `.button-primary__accent` etc without the cryptic classes in the HTML.
However, after reading Tailwind, the team found it much easier to write the pre-built classes and stack them as they progressed. And it worked; if I don’t care about how the code is written, things were consistent. It reminds me of “Pixel Perfection” before the responsive design era, when things looked as designed in Photoshop and printed for clients during presentations.
But at what cost? If it’s not a CSS builtin, it’s going to use JS - it may not be something you care about, but it will be there. There’s no other way.
We actually ended up adding the custom animation-specific data props to all dialog specific custom elements before the release, so the group-*/dialog is no longer necessary but I forgot to update the code in the post.
I think Tailwind became popular because React doesn't have a good way to combine CSS and JSX in a single file, unlike Vue/Svelte which support single-file components. With Tailwind utility classes you can just add them to your JSX template. React problem solved.
Tailwind tends to be smaller bundle-wise because it will only compile the styles you actually use in the final bundle. The old app I work on, the BEM classes are staggering in their size all combined, whereas the tailwind portions are tiny and importantly barely ever grow in size since the majority of code, old and new, will be using the same "building block" classes like flex p-4 or whatever.
Some people (I suspect a lot of young and motivated developers) think that UI development should be easy and elegant.
But consider that a UI is 100% state management and side effects (so fundamentally imperative and asynchronous). On top of that it takes about three revisions for any tool to require bespoke display of something (everybody has an opinion). They also bring a layout engine which is best expressed in constraints.
And somehow we are trying to shoehorn all this into a functional paradigm.
Looks like it's done using standards-based web components[0]. The page says these components don't require any existing JavaScript framework; because web component support is built-in to the browser.
We use web components at the hook for my company's advertising code but I've found them pretty thoroughly disappointing, personally. They make it simple to trigger code execution but their API isn't really that good
The whole point is to make it simple to trigger code and to be interoperable. Then you write whatever code you want to implement the component.
Web components are not analogous to frameworks because frameworks tightly couple the component interface and lifecycle hooks with the component implementations. Those are properly decoupled in web components and you bring whatever rendering layer you prefer.
This has been soooooooo long in the making, i remember playing with webcomponents for personal stuff years ago when i didn't care about compat. Good to see mainstream libraries finally picking it up
12 years I’ve been saying this… 12, damn, years. React graduates look at me crazy. Angular devs say it’s not needed anyway. Svelte bros say get bent. I’m so happy that someone is paying attention.
You don’t need a shadow dom, you don’t need rerendering of everything when a simple value changes. You simply need web components and scoped js/ts with vite or whatever rollup you use.
I remember toying with Polymer circa 2014, for some reason the word "transclusion" jumps into my mind, I remember being excited about it at the time. I barely remember what it means today though.
Polymer still haunts me to this day. It never made sense. It was literally designed to be deprecated. It's a big nasty polyfill for web components and it had/has a huge perf overhead. Not to mention it's ergonomics are just bad.
The world would be a significantly better place if someone could throw a small mountain of money at the Tailwind folks so that they can stop worrying about money and simply make the full tailwind experience freely available. There are so many lost opportunities for deep integration with other projects.
Kind of like how Jeff Bezos threw a bunch of money at 37signals at some insane valuation, which helped them completely avoid the VC trap.
Worried about money? They are already rich beyond their wildest dreams. They are, reasonably, excited about growing and expanding and building a company that does much more, but that is not driven by a need for money, it is driven by their ambition.
edit: I can’t speak for Adam etc., this is just my impression. My impression is that they want to build a business of which tailwind (the open source project) is one part. I think that regardless of money in the bank they would want to have revenue generating projects. Laravel is a good comparable.
interesting, i had just watched Primeagens Standup with Adam and got the impression they don't do well for money, but a quick google came up with a bunch of posts from Adam himself disclosing some fairly impressive numbers.
No idea if he still does ok from it, but he certainly did at one stage.
Fwiw I feel like their components are something I'd be less likely to want to pay for now that you can generate tailwind components so easily with ai. I guess now that I think of it I actually paid for them back when it was called Tailwind UI, but instead of using them I'm just telling claude to generate a UI for me, which has the advantage that there's no licensing issues. It'll be interesting to see how their business does going forward
How has shipping high quality products using AI generated tailwind components actually been working for you? I think the problem that I and many others have/had, is that it can certainly build a few components that look good in isolation, but it doesn’t do a good job at maintaining a cohesive theme/idea across many different page sections/components etc. I built blendful [0] to solve this, and sort of lost interest when LLMs became increasingly capable. However, seeing them not making any gains, really, on visual cohesion between sections and components provoked enough excitement to continue working on it this year.
We will see how long it takes for LLMs to make headway in this area specifically.
The “full Tailwind experience” is already freely available. What “lost opportunities for deep integration” is a frontend CSS framework missing?
Tailwind Plus (the commercial product) is like buying an off-the-shelf template. It’s just a collection of themes and pre-built components — useful for devs who want to get started quickly on a project, but it’s cookie-cutter and can easily be replicated by anyone with Tailwind itself.
There are devs who think the currently available HTML elements are all we needed. But there are many more that believe we are missing primitives that Tailwind (and others) is attempting to solve for.
> It’s just a collection of themes and pre-built components
All reusable web components could be described as an optionally themed pre-built component. That's kind of the point.
I no longer see value in prebuilt templates since LLMs can put things together sufficiently well for prototyping. Even when using templates before you still needed to customise them. Feels like we are going through a transition period.
I think you are confused? Tailwind is already free and open source? These are just components they sale that are pre-made to save you time. It doesn’t take away much at all from the full experience?
This is great. Last time I looked into this UI component world I was surprised the popular UI libraries weren't all 'headless' at their base. Web components have been around a long time now. What was stopping this approach?
There are so many framework specific libraries like shadcn, and the community set about building half finished conversions for different frameworks like Vue, which are always several iterations behind and don't really work properly. They have their own version of the docs and it all relies on a specific version of Vue and a specific version of Tailwind and whatever else. It's an abomination.
Start with headless UI as a base and then build wrappers for specific frameworks if you really feel the need. But the wrappers should be syntax sugar only and linked directly to the base library.
I'm sure it's all more complicated than that but a man can dream.
Put simply: if you’re using something like React, Vue, Svelte, whatever, then Web Components are strict overhead in terms of bundle size and runtime overhead. And when there’s impedance mismatch between the two worlds, which I hear is particularly common in React (can’t attest it personally, I don’t use React), you have to compromise on functionality or ergonomics, or else do fancier bindings, at which point why even bother with Web Components?
It will also commonly not play nicely with some more advanced aspects of the frameworks, like server-side rendering will probably suffer (depending on how exactly things are done).
In a world where React is dominant and you’re wanting to use React yourself, targeting Web Components just doesn’t make sense.
Then “headless” makes it worse. The more comprehensive implementations have a lot of overhead.
With so many frameworks out there it's infeasible to build custom wrappers for them all. With web components they can build once, and work everywhere. It's only up to the frameworks to make sure they have great web components support (which just means great HTML support).
Vue has great web component support. Even React 19 (finally!) does.
Web components are a mess but this is a great application of them: shipping reusable components that work in all frameworks. It's the one and only killer application of web components.
Frankly I'm surprised they're marketing this as "for vanilla javascript" and not as a "now supports all frameworks" type positioning.
That’s not really the point. Tailwind UI depends on Headless UI. Headless UI had both Vue and React packages. The Vue package was abandoned. Many are in the process of finding workarounds for the issues or moving to another library. This new shiny thing can be used in Vue, sure. I know better now to not build anything on top of it though.
At this point, the new crop of AI enhanced design tools are basically skipping vector based design and jumping right to code. A lot of them are using ShadCN/UI which is styled using Tailwind, so it's more like designers are somewhat unknowingly getting onto the same page as Tailwind.
This is a exciting use-case for custom elements, and probably how tailwind should have been implemented from the start, but it’s hilariously a paid feature?! (https://tailwindcss.com/plus#pricing) Intuitively, I’d expect the custom elements to be free and the framework integrations to cost money.
Thanks! It's a paid feature because we just spent around $250,000 developing the library. Couldn't have built it if we were just going to give it away and maintain it forever for free, our engineers are talented people and deservingly well-paid.
It's funny because they're unintuitive to their end users. However, that is deliberate - they are looking for a decision point that comes after, but not too long after, devs have heavily invested in the product.
Yeah this seems like an odd thing to paywall. In the web dev world where everything is free, it's a pretty crazy ask to ask people to tie themselves to a UI framework where I guess you're forever paying a subscription just to continue using the framework?
It's like putting if postgres expected you to pay them a monthly fee.
edit: I see now their pricing is one-time perpetual access. Still, I'm genuinely curious how well this model works.
This is the only feature I genuinely want available for tailwind free users too. Sounds really interesting and I can't even try this? That's a shame.
But I understand that funding open source is never easy & I still appreciate tailwind from the bottom of my heart simply because some might hate it for what it is, but I appreciate that I have options to being with (daisy,tailwind etc.)
If anyone who has ever contributed to open source is reading this. Thanks. I am a real frugal person but one day, I want to earn enough money that I can donate to you guys without hesitation and be an open source contributor too.
Readit News
<div class="group card">
</div>This sort of thing is objectively ugly and takes a minute to learn. The advantages of this approach I found is two-fold
1. You can be more confident that the changes you are making apply to only the elements you are interested in changing
You are modifying an element directly. Contrast with modifying some class that could be on any number of elements
2. You can change things around quite quickly
Once you're well familiar with your toolset, you know what to reach for to quickly reach a desired end state
This is not how custom functional css codebase looks. In custom projects you change the system/configuration to fit the project. You create your own utilities for example you wont have “text-lg sm:text-xl font-semibold tracking-tight” but will have class “font-heading-2”. Similarly you will create button/input classes that have you basic styles.
Generally you start with just simple utility classes inside html and go from there and where it make sense or its too complex you separate to more complex class. You end up with short css file that only has these special components and none of the basic stuff.
For most elemets it ends up like “flex justify-center gap-4”. In BEM i have to invent “nav-secondary__header” put it in correct place and hate myself when i need to change it to “flex justify-beween”.
Tailwind popularised functional css but is also aimed at masses/noobs. Somehow some of those concepts also resonated with some experienced users.
The big problem with Vanilla CSS is that's it's sort of like Perl. It's a read-only language in practice.
Yes, theoretically, you can have perfect semantic CSS classes and use those. In practice, not every button is the same and you'll need slightly different styling in different places.
Yes, we could go in and change the .button class. But who is using the .button class? Where is it used? Nobody knows, and you can't find out. So editing that class is EXTREMELY risky. I have seen many an entire application break because some dev decided to edit CSS. The bigger the application, the bigger the risk.
Where I work, we have 1500 devs. Does anyone know the complete set of usecases a CSS class would have? No. Even if I gave you a month to research it, you would not find out. So you cannot edit CSS classes, it's far too risky.
So, the result is that everyone just tacks on to the end of the CSS. And now, in your clean code world, you have 50 different button classes. Um... whoops.
If you want to compartmentalize, what you can do is use components, in whatever backend/frontend framework you have. You can have the component have their own state and allow users of the component to change parts of it. Then, it doesn't matter how "unclean" the tailwind is - because you'll almost never see it. But if you need to change it, you can, without destroying the entire application. No more 50 button classes, and no more read-only implementations.
I'm never gonna argue learning proper CSS wouldn't be better, but Tailwind is by far the path of least resistance for someone that has no interest in writing frontend for a living. It's like putting legos together, it requires very little thought to get from nothing to a decently looking website.
Because most of those classes are per component.
If you have a single card component defined with these classes, and then repeat it 20 times on the page, then of course the output will look like a giant mess.
> How did tailwind get so popular?
- quick to understand and get started with
- much cleaner for components than the variety of CSS-in-JS libs
- (mostly) do not require fighting CSS with BEM-style atrocities
- come with nice default styles and colors that can be easily changed and extended
> Learn plain CSS. It's really good now
CSS is okay now. We only just got nesting and scoping
However I use it in a much more blended way than the authors probably prefer. I use it with Tailwind Variants and to quickly hack out components. However depending on the project, component, and etc I may also construct BEM-based CSS files to live along side the component.. I use "@apply" in the CSS files, something the author(s?) are on record saying they regret. However I'd counter them by saying if it weren't for "@apply" Tailwind wouldn't be where it is today..
If I do something myself, I keep using bootstrap, as it is good compromise for those of us not honoured with CSS mastery.
Ironically I have no issues making great looking UIs with native toolkit.
In 5 years the tailwind craziness will be replaced by the next shiny CSS of the month.
Yes, CSS in theory is powerful and has everything necessary to avoid using Tailwind, but in practice CSS has a major flaw: You’re almost required to build a semantic model to get the full power. But this ignores that designers are working with mood and emotion just as much as document structure and information architecture. Capturing these more nebulous concepts as logical semantic rules is very difficult if not impossible. Tailwind just codified what everyone already did: Skip the semantic dance (“Making that text bold would be really cool, but what does it mean to be cool, as a general rule?”) and just create semantic rules like “bold” and “red”.
Nothing semantic about .bg-white.
I stumbled on Tailwind in 2018 and introduced it to a team looking to revamp a pretty massive project. I remember that the initial proposal I made was to treat it like Bourbon[1] and write classes that build on Tailwind’s utilities. That way, you can still have `.button`, `.button-primary`, and `.button-primary__accent` etc without the cryptic classes in the HTML.
However, after reading Tailwind, the team found it much easier to write the pre-built classes and stack them as they progressed. And it worked; if I don’t care about how the code is written, things were consistent. It reminds me of “Pixel Perfection” before the responsive design era, when things looked as designed in Photoshop and printed for clients during presentations.
1. https://www.bourbon.io
It is also pretty good configurable utility framework but that is secondary and new version 4 is worse at customisation.
So people are moving to https://unocss.dev/ with tailwind naming conventions.
1. https://tachyons.io/
Deleted Comment
I doubt that changes your mind, though.
But consider that a UI is 100% state management and side effects (so fundamentally imperative and asynchronous). On top of that it takes about three revisions for any tool to require bespoke display of something (everybody has an opinion). They also bring a layout engine which is best expressed in constraints.
And somehow we are trying to shoehorn all this into a functional paradigm.
Nice to see devs picking up web components.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
Web components are not analogous to frameworks because frameworks tightly couple the component interface and lifecycle hooks with the component implementations. Those are properly decoupled in web components and you bring whatever rendering layer you prefer.
You don’t need a shadow dom, you don’t need rerendering of everything when a simple value changes. You simply need web components and scoped js/ts with vite or whatever rollup you use.
Kind of like how Jeff Bezos threw a bunch of money at 37signals at some insane valuation, which helped them completely avoid the VC trap.
edit: I can’t speak for Adam etc., this is just my impression. My impression is that they want to build a business of which tailwind (the open source project) is one part. I think that regardless of money in the bank they would want to have revenue generating projects. Laravel is a good comparable.
No idea if he still does ok from it, but he certainly did at one stage.
We will see how long it takes for LLMs to make headway in this area specifically.
[0]: https://www.blendful.com
Honestly, I kinda feel like 37Signals would have been better off with the founders having someone to report to...
Tailwind Plus (the commercial product) is like buying an off-the-shelf template. It’s just a collection of themes and pre-built components — useful for devs who want to get started quickly on a project, but it’s cookie-cutter and can easily be replicated by anyone with Tailwind itself.
> It’s just a collection of themes and pre-built components
All reusable web components could be described as an optionally themed pre-built component. That's kind of the point.
What kind of integrations are you thinking of?
> To pull this off, we built @tailwindplus/elements — a library we're releasing exclusively for Tailwind Plus customers.
This means if you want to use the Tailwind UI components without a Javascript framework, you have to build them all yourself, or pay.
There are so many framework specific libraries like shadcn, and the community set about building half finished conversions for different frameworks like Vue, which are always several iterations behind and don't really work properly. They have their own version of the docs and it all relies on a specific version of Vue and a specific version of Tailwind and whatever else. It's an abomination.
Start with headless UI as a base and then build wrappers for specific frameworks if you really feel the need. But the wrappers should be syntax sugar only and linked directly to the base library.
I'm sure it's all more complicated than that but a man can dream.
It will also commonly not play nicely with some more advanced aspects of the frameworks, like server-side rendering will probably suffer (depending on how exactly things are done).
In a world where React is dominant and you’re wanting to use React yourself, targeting Web Components just doesn’t make sense.
Then “headless” makes it worse. The more comprehensive implementations have a lot of overhead.
Just a reminder that jQuery was once dominant, too.
We've got some UI components built with html, CSS and JavaScript. They use web standards.
We want to add them into web frameworks that are built in JavaScript. They are built for html, CSS and JavaScript.
No need to overcomplicate things.
And for a universal component library I'll happily accept 7kb extra overhead in my 4mb React slop website
With so many frameworks out there it's infeasible to build custom wrappers for them all. With web components they can build once, and work everywhere. It's only up to the frameworks to make sure they have great web components support (which just means great HTML support).
Web components are a mess but this is a great application of them: shipping reusable components that work in all frameworks. It's the one and only killer application of web components.
Frankly I'm surprised they're marketing this as "for vanilla javascript" and not as a "now supports all frameworks" type positioning.
TailwindCSS itself is meant to be nothing more than a styling tool, like Bootstrap...
It's funny because they're unintuitive to their end users. However, that is deliberate - they are looking for a decision point that comes after, but not too long after, devs have heavily invested in the product.
It's like putting if postgres expected you to pay them a monthly fee.
edit: I see now their pricing is one-time perpetual access. Still, I'm genuinely curious how well this model works.
It's a one-time fee for unlimited use and lifetime updates, not a subscription.
Deleted Comment
edit:
Confirmed, they removed alpine from their copy/pastable code. Now you see:
<!-- Include this script tag or install `@tailwindplus/elements` via npm: -->
<!-- <script src="https://cdn.jsdelivr.net/npm/@tailwindplus/elements@1" type="module"></script> -->
This sucks because I have been using alpine and now I can't copy paste the examples ~_~
But I understand that funding open source is never easy & I still appreciate tailwind from the bottom of my heart simply because some might hate it for what it is, but I appreciate that I have options to being with (daisy,tailwind etc.)
If anyone who has ever contributed to open source is reading this. Thanks. I am a real frugal person but one day, I want to earn enough money that I can donate to you guys without hesitation and be an open source contributor too.