People still complain about the tailwind build process and I agree and would not use it bc of that except.. Tailwind has had a stand alone executable builder available for a long time. (Including at the writing of this article)You can just drop the exe and either add it to your path or run it directly. No node or npm/npx needed.
Sure but I've seen people complaining not that there is any build step but that they think it requires the whole node/npm ecosystem to be installed for it to work.
At this point I don't think anyone doing anything beyond a landing page is working without some sort of build process anymore.
I feel like these are two very, very different tools. Pico (or something similar) is great for a Just-Works framework where things look simply and nice. For a lot of things, this is good enough.
But Tailwind is for building... anything. It's better to think of it as inline styles with syntactical sugar. Yes, this has historically been something to avoid. But as components become more common, it moves the DRY to the HTML level (rather than CSS classes).
It's not for everyone or everything, but I've loved it. There's a joke that the hardest part of CS is naming things, and this removes having to map classes and IDs across two different files.
That's exactly how I feel. I didn't realize how much of a productivity-stopper class naming was until I stopped doing it. It's amazing how much faster you move.
I entirely agree. They get compared a lot but to me they seem to solving different problems. Pico if you want something asap, and you are ok with sticking with it's opinionated styles. Tailwind if you want control - now, or if not now then later, i.e., you see your application evolving.
Personally for me, the opinionated pico styles don't work because I'm usually building high density interfaces and pico has stuff that I'd consider good for marketing kind of sites, e.g., buttons with large text (I think you can override/add styles but if it comes to that you should reconsider this choice anyway).
Another advantage for tailwind is that I can use to style components from other frameworks to my liking, e.g., skeletonUI or bits-UI.
A common complaint with tailwind is the long class names. While true I think it's unavoidable due to the flexibility it provides. But that's not why it doesn't bother me: the names make sense (like you say) and they're composable, i.e., you can put together or parse these class names piecewise.
PS: I should add that this article is fair in the sense that it doesn't prescribe over another, just shows which is best for what.
It’s an artfully constrained design system that reduces mental burden.
The main benefit is what you aren’t doing: jumping between css files and html, naming class’s, trying to debug layers of cascading, wondering what other unrelated components will be impacted by a css rule change…
Colors aren’t a great example because those should be set as css variables (dark mode right?). Think about padding: how many layers of margin/padding on parent wrappers is making things look strange?
And even for colors, the benefit is the consistent color scale. You've only got 10 shades of red, which are all visually distinct. You won't find slightly different RGB values all over your code base each time someone wanted red.
The drawback is that you end up with an incomprehensible soup of classes on too many html elements, often redefining and redefining rules.
If you work in a highly componentized scenario that’s probably convenient. You don’t have to name things as you would if you were to keep a separate css ruleset and then tie it to the html elements via naming.
Very noisy compared to a disciplined, structured css though. But who has time for that.
Have to disagree it's a design system - it's basically a theme. Consistent colors, fonts, borders, spacing is handy for sure - but Tailwind is not a great option if you expect to drop it in and have building block components, etc without a lot of work.
CSS as a language is different from the style attributes that you can insert into `style=`, mainly because it's a lot more powerful. You can do things like set a background colour on hover, or apply a style only to the first child element of a parent. None of that is possible with the style attribute.
This is also the key difference between conventional CSS classes and Tailwind - it acts less like a set of predetermined classes, and more like a DSL for directly writing CSS inline in the "class" attribute. The result is arguably less reasonable than directly writing CSS, but on the other hand, it's a lot less boilerplate.
In my experience, it really clicks if you write a lot of components, in which case you've already got a way to reuse your code, and so tailwind fits in really nicely with that. If you're mainly writing whole-page styling, then Tailwind usually results in a lot of repetition and doesn't produce much better results than writing everything in CSS in the first place.
If you change the base css variables, you can configure that default spacing and the corresponding ratios stay reasonable. This is how I use picocss for my high density UIs.
I think people should still think of TW as classes, because they are, and it doesn't need to be more complex than that.
Thinking of TW as inline styles is harmful imo, the specificity works differently and there are a number of things that TW offers that isn't possible inline. Plus inline just carries a stigma which helps people dunk unfairly on TW.
The selling point of TW is that it is, effectively, styles. That's what distinguishes it from what I could call just normal CSS. It has value over inline styles -- otherwise it wouldn't exist -- but it's still the same principle.
I maintain OneJS which provides tailwind support for Unity (the game engine). Whenever I need to show people some code examples in Discord, I always use TW instead of, say, raw css, emotion, etc. This is because TW makes it possible to have everything in one file. And the utility classes are so short, it just make more sense to use them to save screen estate.
CSS is global, so I'd highly recommend against using two separate CSS systems. Even Tailwind introduces several global styles via its own reset. Years ago, I worked on a team that used both Bootstrap and Foundation, and even over the course of 5 years was unable to disentangle them.
I've been using one of these semantic classless CSS systems for an application I've been developing for the past ~6 months with a team of ~3. It's working great so far. We didn't even install it from a package manager. Just copy and paste the file straight into source control. (attributions intact, don't worry licensing enthusiasts) Customizations go right into the original file.
I don't think these are the same, but as a non-web-developer who likes building web side-projects, I love pico.css. It's fantastic for forms and the light grid/container stuff.
My stack these days is Flask + HTMX + Alpin.js + Pico.css and I write almost nothing but Python and HTML.
I use the same principle as pico but from scratch with tailwind. It does too much magic and it’s far too complex and undocumented to be able to modify a piece of it you need to change. In my global stylesheet I style inputs all one way and target aria and state selectors for more specific styling. I still use inline styles for more unique cases.
They are two different techniques that can work together well. If I’d make any comparison, it’d be between pico and tailwind’s typography plugin specifically.
The workflow I'm trending towards is a design system (e.g. Radix UI) for the bulk of the styling, inline styles for most customizations (shouldn't be too many), and then plain CSS with classes on occasion (e.g. I have an override I need to use in multiple places or an animation). The little CSS you do need can be isolated if you're using a framework like Remix.
Tailwind requires you to learn CSS. It's not a framework, it just gives you access to the raw CSS primitives in a better way (IMO) than writing classes.
It does not. Tailwind requires you to learn tailwind which uses multiple different terms than what is in CSS (most of the times at least similar, but it is not the same). And it creates its own language to use more complex CSS features like [&_[not:(button)]]:bg-blue, this isn't CSS.
Tailwind is more about removing "cascade" from CSS, making it harder to make CSS "spaghetti". Unlike CSS frameworks e.g. Bootstrap that abstract away CSS primitives
Does anyone have a good guide / article on how to think in CSS?
I do mostly backend work, but have spent plenty of time fixing frontend stuff. I can usually make it work but I can't build CSS from the ground up in the way I would with a backend / database application.
50 comments
[ 1.7 ms ] story [ 112 ms ] threadhttps://tailwindcss.com/blog/standalone-cli
[0] https://tailwindcss.com/docs/installation/play-cdn
At this point I don't think anyone doing anything beyond a landing page is working without some sort of build process anymore.
But Tailwind is for building... anything. It's better to think of it as inline styles with syntactical sugar. Yes, this has historically been something to avoid. But as components become more common, it moves the DRY to the HTML level (rather than CSS classes).
It's not for everyone or everything, but I've loved it. There's a joke that the hardest part of CS is naming things, and this removes having to map classes and IDs across two different files.
Personally for me, the opinionated pico styles don't work because I'm usually building high density interfaces and pico has stuff that I'd consider good for marketing kind of sites, e.g., buttons with large text (I think you can override/add styles but if it comes to that you should reconsider this choice anyway).
Another advantage for tailwind is that I can use to style components from other frameworks to my liking, e.g., skeletonUI or bits-UI.
A common complaint with tailwind is the long class names. While true I think it's unavoidable due to the flexibility it provides. But that's not why it doesn't bother me: the names make sense (like you say) and they're composable, i.e., you can put together or parse these class names piecewise.
PS: I should add that this article is fair in the sense that it doesn't prescribe over another, just shows which is best for what.
The main benefit is what you aren’t doing: jumping between css files and html, naming class’s, trying to debug layers of cascading, wondering what other unrelated components will be impacted by a css rule change…
Colors aren’t a great example because those should be set as css variables (dark mode right?). Think about padding: how many layers of margin/padding on parent wrappers is making things look strange?
The best argument is just to try it though.
If you work in a highly componentized scenario that’s probably convenient. You don’t have to name things as you would if you were to keep a separate css ruleset and then tie it to the html elements via naming.
Very noisy compared to a disciplined, structured css though. But who has time for that.
Have to disagree it's a design system - it's basically a theme. Consistent colors, fonts, borders, spacing is handy for sure - but Tailwind is not a great option if you expect to drop it in and have building block components, etc without a lot of work.
This is also the key difference between conventional CSS classes and Tailwind - it acts less like a set of predetermined classes, and more like a DSL for directly writing CSS inline in the "class" attribute. The result is arguably less reasonable than directly writing CSS, but on the other hand, it's a lot less boilerplate.
In my experience, it really clicks if you write a lot of components, in which case you've already got a way to reuse your code, and so tailwind fits in really nicely with that. If you're mainly writing whole-page styling, then Tailwind usually results in a lot of repetition and doesn't produce much better results than writing everything in CSS in the first place.
The docs are decent enough to configure this.
Thinking of TW as inline styles is harmful imo, the specificity works differently and there are a number of things that TW offers that isn't possible inline. Plus inline just carries a stigma which helps people dunk unfairly on TW.
Feels amazing.
t-shirt vs sweater car vs truck cat vs dog
My stack these days is Flask + HTMX + Alpin.js + Pico.css and I write almost nothing but Python and HTML.
- wonderful integration with pydantic for serialization - background tasks - autogenerated swagger docs - dependency injection per-route
"in-place" is a stretch, you will have to change code, but I found it to be a very speedy task to migrate a codebase from flask to fastapi.
They are two different techniques that can work together well. If I’d make any comparison, it’d be between pico and tailwind’s typography plugin specifically.
Also, most of the time all you need is flexbox https://css-tricks.com/snippets/css/a-guide-to-flexbox/
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Types
I do mostly backend work, but have spent plenty of time fixing frontend stuff. I can usually make it work but I can't build CSS from the ground up in the way I would with a backend / database application.
If you need a build no reason not to use tailwind imo.