> I used the JIT version recently on a new landing page

Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability.

Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with several `class="..."` strings across multiple files, possibly with class names in arbitrary order, possibly mixed with logic from other templating languages (be it from Django or JSX or whatever). So you can't just grep to achieve the objective of changing styles in one place to affect all instances of some semantic group.

Personally I think comparing Tailwind directly against traditional CSS as a whole is painting in too broad strokes. There's a lot of CSS methodologies and also a lot of bad practices (e.g. using SASS indentation as namespacing mechanism and then running into the old problem of specificity), and comparatively, there's a lot more than Tailwind in the atomic CSS space, and more broadly, in the compiled CSS space.

Utilities like Bootstrap (e.g. `class="btn btn-primary"`) for example share many benefits of both atomic CSS and "good" subsets of traditional CSS practices (namely, you get memorable short class names, which are also organizable along semantic lines). So there's definitely more shades of gray than just "atomic-css-is-the-best-thing-since-sliced-bread" vs "looks-like-lazy-style-attributes-lol".

The trick with CSS is to write semantic HTML and avoid div, span and css classes. You can of course inline css too (used mostly for optimization to prevent layout shift, but is also fine for elements/classes that are not repeated, such as the top menu, top banner/intro and header/footer)

We use Tailwind at my work and I personally find hopping into the template of a file I've never been in before super easy with it. With normal CSS I've usually got an HTML file and a CSS file side-by-side in my IDE, and I'm cross-referencing awkwardly-named classes in the template with a stylesheet. Sometimes these styles might be coming from a local, dedicated stylesheet, sometimes they might be coming from a global stylesheet that I might end up needing to grep through the project for in order to find where these styles are coming from.

With Tailwind, I see a <div>, and I see all the styles on it, right within the template. I don't need to follow class names, or cross-reference between files, it's just there, where I'm already looking.

I'm very surprised that people actually like tailwinds.

I wrote HTML in a time when you used inline HTML attributes for styling. Changing one bit of the style meant visiting every single page to update everything (then making sure to test because you definitely forgot at least one place).

CSS was an amazing idea for making just one place to put all your styling. You could now change one style and everything else would automatically update.

Tailwinds feels like it's just a trip right back to the old inline styling right down to searching bunches of pages if you're making a styling update.

Why not use both? twin.macro is an excellent library that compiles Tailwind (and adds additional, useful variants) in systems like Styled Components and Emotion, so you gain the benefits of quick component creation, but the same pleasant maintenance of colocating utilities and styles/classes/objects composed of these utilities with your components.

It's been an absolute dream in a decent-sized project so far, and even with some refactors.

Regardless, it's not everyone's cup of tea, but depending on the UI framework of choice and the flavor of CSS you use, YMMV when it comes to dev experience.

In Vue or Svelte, I wouldn't even use a CSS-in-JS solution because vanilla Tailwind to compose utilities into localized classes is a straightforward approach.

Tailwind works wonders in a component based system, but component styling ought to be very fine grained to ensure maintainability.

I have created React components with TW, where the components are complex and large.

However, breaking them down into tiny functional blocks, maintenance is easier.

I found exactly the same with my brief experience with Tailwind. Great fun to write, couldn't make head nor tail of it when I came back a few weeks later. Perhaps this changes if you use Tailwind day in day out though!

I've stuck with styled-components for now, though I confess that I've started to wonder if the the verbosity of creating a (styled) component for everything, passing props, etc. is a bit excessive since trying Tailwind.

The only thing I appreciate Tailwind for is that I started to dig deeper just to have even stronger hesitation against it, so I believe I've saved a lot of hours in my projects just by not using it. But it also got me stumbling upon solutions based on the CSS global variables and that's what I think is the CSS next big thing. They allow to stay with CSS within CSS layer so no leakage to HTML or JS.

we use tailwind along with a component system. works great.

Seems like you are basing your opinions on some misconceptions. Let me try to clear that for you.

"CSS modules still seem to solve every problem Tailwind solves, and better."

- Not necessarily true. Unlike css modules, tailwind removes the whole "think about a name for your class" mindset, reducing friction from the development process. It also unifies some base level design decisions like spacing and colors, which developers would have to rely on "best practices" otherwise, which don't necessarily get strictly enforced.

"I'm not sure how Tailwind works, but any CSS that's built at runtime and JS and inserted into the DOM dynamically should be avoided, and is an example of favoring developer experience over end user experience."

- You are right, looks like you are not sure how Tailwind works. Tailwind does not build anything at runtime, it all happens at build time. Tailwind will compile only the things you need (using the new JIT mode) into a css stylesheet which is sent to the frontend. Not much different from how sass or scss works.

"CSS modules let you use the full power and control of vanilla CSS, without having to worry about styles bleeding across components."

- Tailwind does not stop you from using vanilla css, but in most cases you do not need to. As per their website, you can think of it as an API to use parts of CSS, instead of CSS replacement. I think you are confusing Tailwind as a replacement for something like CSS Modules, but those two are completely unrelated. You can still use CSS Modules while using Tailwind. Think of it as an api to your design sytem just like you could think of an ORM as an API to your database.

Based on what you've said, you're right, you don't understand it...the things you're comparing it to don't really make sense. Bem doesn't make sense to compare and neither do css modules. Tailwind is a stylesheet with css classes that do atomic things like changing border radius. It gives you a set of classes that allow you to build just about anything you need with just classes. When you compile an app that uses tailwind, it takes just the styles you use and puts them into a single stylesheet. So all of the things you claim to be wrong with tailwind aren't true. Tailwind is very performant because you only use the styles you need. It uses css variables for theming so there's no need to implement it in userland. It also uses css variables to do transforms which is very important because transforms are not additive in css yet. Even if you don't end up liking tailwind, the thing is executed really really well from the ground up.

There's three things:

1. It removes a layer of abstraction that's redundant if you use a component-based UI framework.

2. It provides constraints that act as guardrails against introducing inconsistencies into a design.

3. Its tooling is not magic and does not have runtime impact.

More detail at https://vincenttunru.com/why-tailwind/

I think Tailwind is multiple very different ideas in one library. One thing that Tailwind is is a set of primitives and design tokens that’s just slightly higher level than CSS, but still lower level than a component library. I think it’s pretty good at this.

Another thing that Tailwind is is an opinionated delivery mechanism for your styles, in this case, as utility classes that can go straight into your HTML. This is probably a big cause of Tailwind’s popularity, not because any one person necessarily loves using classes, but because it makes it extremely easy for everyone to start using Tailwind in nearly any imaginable web project starting at plain static HTML files and going up from there. This aspect of Tailwind is something I’m not a huge fan of. To me it feels like a step back from a lot of higher-level CSS tools (like many CSS-in-JS libraries) to just go back to concatenating magic string literals into my UI code. All the official Tailwind tooling (AFAIK) either just watches your codebase looking for these magic string and generating the appropriate raw CSS, or doing it in real-time with their new JIT compiler (which I admittedly haven’t investigated yet).

> CSS modules still seem to solve every problem Tailwind solves, and better.

I agree with most of what you're writing, but in arguing this out with people who seem to be enthusiasts, what I think I've discovered is that while there are existing (hell, longstanding) unbundled technical solutions fully capable of solving the problems Tailwind does... they don't solve the practical problems of channeling a group into a good-enough design system, and in fact many people who've been doing CSS have never actually really used a design system (especially if their experience is solely recent, and definitely if their experience is only incidental in the sense that they're application devs first). And many organizations don't have roles where someone can focus on solving this problem.

Just-add-Tailwind may hit an interesting pit-of-success spot for a lot of people in this position, where TW provides the atoms of the design system to scatter in a just-in-time manner. Sure, not elegantly, but practically.

Personally, I'd prefer to work with people/orgs that don't see this is an optimum, but I might accept it as a situational local optimum.

Tailwind is global utility classes too. There’s no runtime aspect. It’s literally just css classes. The nicest thing is that all your variations exist, so you can do things like hover:font-bold. So you can see the rules immediately like with inline styles, but they’re more flexible.

I'm in the same boat. Started using Vanilla Extract (https://vanilla-extract.style) earlier this year and it's the best CSS setup I've ever worked with.

> CSS modules still seem to solve every problem Tailwind solves, and better.

I don't understand Tailwind either; but I find myself struggling with CSS modules when I need to override a CSS rule of a child from a parent. Like, say, my button should always be green, except in this context I want it to be purple, its font-size larger and its padding a bit different. With CSS modules, the parent component is unaware of the class name of the child component; so it cannot target that. Perhaps this should all be done with CSS variables; but then hell, how many CSS variables should my components expose? and besides, I am not even sure even they will completely solve this.

I build tailwind exactly once and it gives me a static css file with utility classes. I get local scoping from scope classes ala Svelte.

I don't personally care for Tailwind, but I get the reasoning why people gravitate towards it: just as modern JS moved away from inheritance to composition, so is CSS.

There's a fundamental argument that inheritance is a mirage and things in large projects become much simpler with composition-based approaches. You don't really need to grok the inheritance chain with Tailwind in the same way you do typical CSS.

For my personal projects I'd continue writing my own CSS... but for teams, I'd go to Tailwind without a second thought.

> Doing everything with utility classes and OOCSS / BEM are things we stopped doing literally decades ago.

I don't understand what you mean by this. Literally decades ago would take us back to at least 2001. OOCSS, BEM, etc. were all created after that year. Wouldn't it be correct to say "Doing everything with utility classes and OOCSS / BEM are things we hadn't even started doing literally decades ago."?

The difference is you type that lingo inline into the HTML instead of in separate files and you don't have to come up with any class names.

    <el style="display:flex;justify-content: start;">...

?

The beauty of it comes when you're working in a team of say 5 other front end devs of varying skill levels. There tends to be a large amount of duplication & overlap, people have different ways of doing things and achieving certain looks. If everyone agrees to use tailwind, you stop people from writing custom code which is ultimately a good thing because custom code requires custom comments and custom documentation etc which let's face it - nobody does or wants to do and even if they do, it's not maintained to the sort of standard tailwind docs are.

> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo.

This is the only problem of tailwind, it relies on its own lingo, as all the OOCSS/BEM projects. When you involve semantics, you will always bring these kind of problems.

I covered this problem and I solved it with this approach http://minid.net/2019/04/07/the-css-utilitarian-methodology/

Consider using this handy Tailwind cheat sheet: https://nerdcave.com/tailwind-cheat-sheet

I have it open in a browser tab almost constantly.

Spot on. Whenever you add a DSL like this, you need to carefully weigh costs and benefits. A hidden downside is that every new person who views your code base (And you in the future!) has to become proficient with the DSL. The base tech it wraps (HTML + CSS) is more fundamental; less overhead.

Another way of saying this, is that Tailwind adds cognitive overhead.

In my experience it's because any web app with complicated styling rules tends towards this anyways, except all the CSS names are custom, undocumented, and duplicated. The main tradeoff is that the CSS names are not domain specific, but honestly that's worked fine for me.

I hear you. I don't understand the reasoning behind frameworks propensity to abbreviate things, especially at "atomic"/utility levels. I think it partially stems from wanting to prevent ignorant knee-jerk reactions like "hurr durr why not just write inline styles".

I wish framework devs would just hyphenate (or even colon-ize) the CSS property names fully like "display-flex justify-content-start". I think Bootstrap does their own pattern like "d-flex", but all that does is require one to visit the docs to view some less common properties. Autocompletion pretty much makes typing these a breeze, and having less opinionated patterns for property names will make it less painful transitioning between frameworks.

> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo.

Autocompletion in your IDE makes this easy (the class names are similar to the CSS attributes, even in your examples, so you can usually guess them) and you use the same classes over and over again so you learn them quick. I barely spent 10 minutes in the Tailwind documentation the first few days because of the VSCode extension.

Try using an IDE extension for autocompleting Tailwind's utilities based on your tailwind.config.js.

Twin Macro is a great wrapper library for Tailwind-in-JS with strong IDE support and it autocompletes all my utilities. I barely have to type anything to style everything in my project.

I can even hover over utilities to peek at its raw CSS.

https://marketplace.visualstudio.com/items?itemName=lightyen...

I don't do frontend except when I have to and "flex justify-start" is way easier for me to learn and explore with than "display:flex; justify-content: start"

And the keywords all seem to make sense to me? It's "n-dimensional properties" but the dimensions are pretty consistent...

You have to learn the more verbose CSS properties in the first place, and the vast majority of tailwind's class names include the unique keywords of those anyway.

Yeah that's my issue as well and so much divitis and unnecessary nesting...

>This works okay in extremely componentized web apps. It's a nightmare if your UI isn't highly componentized. I've seen projects where you make a button by copy pasting this ~80 character string of tailwind classes all over the place, and then changing the color names if you need to. Good luck fixing that when the designer decides that we don't want any buttons to have rounded corners anymore.

That app is done wrong. If you are using the same styles to represent a button you should use postcss and do

.myButtonClass { @extend: (80 tailwind classes here) }

    function Button = ({ children }) => <button className={80 tailwind classes here}>{children}</button>

    <Button>Create</Button>
    <Button>Edit</Button> // Same style
    <Button>Delete</Button> // Same style

I agree. I used Tailwind for roughly six months on a few projects before I noticed that I was only using the basic utility classes. I didn't like all the screen sizes and state "bloat" classes so I decided to take the best parts (margins, padding, background, font, text alignment) and create a simple CSS framework.

For anyone interested, you can find it at: https://brixi.dev/

I can just add that WindiCss is worth testing. In my small trials it worked a lot better than Tailwind with jit. Windi with Vite gives me a really fast dev experience.

We'll see if UnoCss takes over.

If you're talking about Tailwind UI[1] — I use Tailwind extensively and have basically never looked at Tailwind UI. It's just useful snippets of HTML styled with Tailwind. It is by no means required to get value out of Tailwind.

I'm not sure what you mean by proprietary culture! Based on the fact that I've pretty much never seen anyone talk about it, I would guess (total guess, no real knowledge) that no more than 1% of Tailwind users have paid for Tailwind UI.

[1] https://tailwindui.com/

It seems proprietary because there are ad links disguised as documentation links. You can't click "Components" anywhere on TailwindCSS.com or you'll end up on TailwindUI.com pricing page.

It's fine that they want to make money but it's very confusing for a new user. Ultimately, they might make more money by dropping the shady links if it's turning away enough new users.

  s/Components/Tailwind UI/g

across their site would be a big improvement.

Just started with tailwinds and similiar thoughts. A framework like this without components.

Try daisyui as a tailwinds plugin. It comes with the missing components. It also allows you to replace your 80 character style for buttons with btn btn-primary.

There is a dead sibling comment which I will repeat with a bit kinder words, and with a different caveat.

As a frontend developer I don’t like Tailwind for several reasons, it brings the styling into the structure. As a frontend developer Tailwind is at a forefront of what I would consider bad practice and encourages a code style which would be a nightmare for me to maintain.

That said. Tailwind seems to be loved be people who are not professional frontend developers. It seems to be just the right tool for people who are not necessarily proficient in CSS. And perhaps people like me (and the dead sibling) need to learn to let go and allow other people to have the tools which makes it easier for them to do the job which they are not experts at. For that reason I understand Tailwind, even though I don’t agree with it.