9 ms·

I really was hoping that tailwind was a fad which died but like everything JavaScript it's here to stay sadly I recently found myself staring at a button eleme

I really was hoping that tailwind was a fad which died but like everything JavaScript it's here to stay sadly I recently found myself staring at a button element with more classes than I have ever seen like <button class="bg-blue-500 hover:bg-blue-600 text-white font-bold py-2 px-4 rounded-md shadow-md">Click me!</button>. It’s like the eccentric artist who insists on using every color in the palette. After been forced to use it for almost 2 years I still don't see the point. Your HTML files? Bloated. Your sanity? Questionable. And those cryptic class names? Why God did we have to do this.

llamaimperative 2y ago
The point is that it’s ridiculously fast to build and extremely easy to maintain. It’s also not hard to read after, idk, a week of working in it? The only people I’ve seen struggle beyond that are people who dug in their heels and dogmatically decided to struggle with it. FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element.
- jacobyoder 2y ago
  It's adequate for some folks who work in the same codebase, and define their own style of work. It's been a real pain for me who comes in to various codebases for short periods of time and have to read/digest/learn every single project's unique take on buttons. class="btn btn-primary" is also pretty easy to read. But in the last couple weeks I've have to deal with both class="bg-blue-500 hover:bg-blue-600 text-white font-bold py-2 px-4 rounded-md shadow-md" style buttons and <LinkButton4 /> and <LinkButton7 /> components, both of which still seemed to be affected by another wrapping container that decided to "text-xs" everything below it, but which wasn't obvious. Trying to simply add a 'button' that had the same styles around it was far more work than it should have been. No doubt, I'm somehow in a minority of switching between projects/codebases more often than other people. But this was much less of a problem with bootstrap and related definitions. > your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element. When you want, say, most things to share some common color/style definitions, you will still end up repeating a lot of stuff (same long string for buttons, and for headers, etc). The tailwind system gives you the option of @apply, but the tw docs are also relatively strongly against it, for ... I can't really understand the reason why. https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles > If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice. There's some reasons listed on that page justifying "don't use @apply!" but... they don't ring all that useful to me. They do say "well, you could do it for reusable things like buttons", but those are the very things that most tailwind examples use longhand examples for. > Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse. There's a balance between the 'ugly' (their words) and 'tons of custom css'. Everyone's balance is different, I get it, but I'm usually having to come in after someone who was jazzed about tailwind has moved on and left me the 'ugly' (their words) mess. If every link should have "text-dark font-bold font-xs"... @apply that with an understandable name. Or document your design decisions...? But that conflicts with "ridiculously fast to build". Documenting them in an '@apply' way would let me see how you want some styles grouped together without having to scan through dozens of your components looking for a pattern.
  - naught0 2y ago
    > without having to scan through dozens of your components looking for a pattern Wouldn't you have to scan disparately located CSS files anyway? How many projects have you seen with nonsensical or clobbered classnames or conflicting rules? Really for a lot of designs I think you can just eyeball it. If `px-4` looks about right, then use it. Otherwise you can find a similar component and hijack the exact padding if you want, or get it from the design. You probably think @apply makes more sense because you know and like traditional CSS. You want to apply tailwind classes and condense them into a single reusable one. Tailwind asks you to think in a different way. The classes are aptly named (mostly) and granular (one class per css directive), so my knowledge of CSS felt very transferable. <LinkButton4 /> Imo should be <LinkButton variant={"homepage"} /> Leveraging something like Class Variance Authority or more simply: <LinkButton className="text-xl other-override-here" /> Using tailwind-merge I have found tailwind to be indispensable, and it pairs particularly well with React.
    - jacobyoder 2y ago
      Again, at least part of the core issues I have is coming in to other projects where each person thinks in a 'different way'. And almost all of them are simply copy/pasting loads of tailwind extended strings of stuff, then semi randomly tweaking until something looks 'ok', then moving on. > scan disparately located CSS files anyway usually, I encounter CSS in one of two ways: 1. a main base css file or set of files (from a framework, maybe), and then an override css file. Single override file can get hairy to look through, admittedly, but it's typically in one spot. I rarely come across projects with dozens of standalone css files. 2. 'style-in-components' - primarily in vue, because vue sfc encourages scoped styling - structure, code, style in a single file. Whether that's bootstrap styling ('btn btn-primary', etc) or tailwind doesn't make too much of a difference. Where I've hit more maintenance issues is coming in to projects with tailwind in say, react or vue - with the 'style in components' - is that "text-xs px-1 rounded-sm bg-gray-200 inline-block text-gray-600 mb-1" repeated across multiple components, is harder to find when I want to replicate something vs just "class='tooltip'" Of course, we're all doing it wrong, and if we all just 'think different' all the time, and spend loads of time rewriting "wrong" stuff from other people - things will be just fine. But the world I live in, and the world I see a lot of people in - is not greenfield, but brownfield, and we have to live with the decisions others made. Tailwind does not make my life any easier that way, and generally introduces more cognitive overhead earlier in a project when it comes to visual stuff.
- orangepanda 2y ago
  I strongly disagree on the maintainability. Mistakes are easy to make and have been made when comparing a list of 20 class names across a dozen elements. Its only "maintainable" if you ignore the class list when reading. I review my local evangelists' tailwind code and from their mistakes its clear they're not reading the class list. It reminds me of how some people claim they're great at multitasking and can text & drive with no issues - meanwhile not even being aware of what they're missing. Tailwind has its uses, but it should not be the default choice.
  - datavirtue 2y ago
    All this talk reminded me of the extensions I installed to deal with these issues.
  - lobsterthief 2y ago
    I’ve experienced the exact same thing. Most TW evangelists I know are admittedly not that great at CSS. Those who are generally prefer a library like MUI instead, which offers the same maintainability benefits, a far more consistent UI, but with a higher learning curve.
    - dabber 2y ago
      I'd love to love MUI, but in my experience: MUI + React + Typescript just moves the toil of doing anything away from the style concerns and makes it a purely Typescript puzzle.
    - nightski 2y ago
      As an end user (not developer) I'd take just about any design system over MUI. It's so clunky/heavy, has an abundance of useless white space, and just feels really outdated.
    - 0x457 2y ago
      > a far more consistent UI That's what I like about tailwindcss - unlike MUI and co, it lets you follow sane design rules laid by tailwind and yet make the website look different from the rest. Consistency of UI entirely depends on the user of tailwind.
- lawn 2y ago
  > FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element. And pray you never have to tweak or debug that element. Hiding away bad code where you don't have to look at it doesn't stop it from being bad.
  - progx 2y ago
    Open the browser tools, select the element, view the styles and look what class cause the problem. Nothing else would you do, if you had a problem in styles css file.
  - llamaimperative 2y ago
    If you can’t follow a DOM tree through some custom components to debug uhhhh… maybe practice more.
    - lawn 2y ago
      The point was, obviously, that the styling string doesn't go away if you hide it inside an element.
      - llamaimperative 2y ago
        Then I’m failing to see why it’s “bad” other than the verbosity/visual noise, which does in fact go away if you hide it (this is the point of abstraction in general, of course)
- pupppet 2y ago
  You lost me at ‘maintain’. It’s definitely not easier than just updating a single .button class, and I’m not going to create reusable components out of everything in my project, the <Button /> approach doesn’t work for everything.
  - compootr 2y ago
    Yes, it is easier to maintain (assuming no css-in-js) Your styles are bound to the component, not some global in your app. States and their representations are controlled in the component themselves With normal css files and class names, you must jump between files. With tailwind, I see what's going on with a component right in my jawascript
    - pupppet 2y ago
      You’re assuming I’m going to create a component out of any element on the page that needs styling. In my project I could just have a small handful of these scattered across hundreds of files: <table class=“datatable”> If I used tailwind utility classes, how do I update my data table styling without having to search and replace across all of my files? Assuming you could even search and replace, the utility classes could be in a different order. Not saying it’s not doable, but it seems like a real pain in the ass. What am I missing?
  - llamaimperative 2y ago
    The things it doesn't work for are the things that .button doesn't work for either.
- danielvaughn 2y ago
  After writing Tailwind for a few years, I've kinda shifted position on the maintainability of it. It's definitely easier than any alternative, but it's also painful to read through a giant list of classes. There's no getting around that. I think a better way to put it is that Tailwind optimizes for writes vs reads. It sacrifices the readability of HTML for the writability of CSS. I still think that's a worthwhile tradeoff, but it's definitely a tradeoff.
- azangru 2y ago
  > FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element. Sure thing. What I don't understand though is why not put a Button.css file next to the Button element file, and describe all the button styles in there. What's so hard about building or maintaining that?
  - danenania 2y ago
    1 - It’s easy for style bugs to get introduced when someone updates the html and forgets the css. 2 - It’s simpler to have styles that depend on js vars/parameters when components handle their own styling. Encapsulation, in other words.
  - 0x457 2y ago
    Soon after, you're going to need slightly adjust that button, you will add some helper classes. Then there will be a case when base style of that button doesn't work with new button style, and now you have 2 bases for a button. You might have semantically named those buttons, but 3 months later that no longer makes sense, and now you're afraid to rename it. Tailwind lets you style elements in the same file as the element, you don't have to switch between `button.<whatever you use>` and `button.css` to know what is going on. nah, I love tailwindcss.
    - azangru 2y ago
      > Soon after, you're going to need slightly adjust that button The proper thing to do, in my mind, is to gradually set up a collection of such buttons (and other components), and document their properties. A design system, if you will. You shouldn't have that many button variations. This should also help with the "3 months later" case. Once you've catalogued your buttons, you can reason about them, update their styles, rename them as you please, and so on, while maintaining consistency of buttons across your site.
NeutralForest 2y ago
I have used tailwind on and off and I still find this pretty easy to read tbf.
iamsaitam 2y ago
Ever heard of CSS files? No one forces you to bloat your html.
blorenz 2y ago
Every time something with tailwind is posted there is always a rehash of this response. I believe most of this frustration comes from using tailwind in the raw. There are a few essential libraries available that amplify the power of tailwind by magnitudes: tailwind-merge for last-specified wins, and class-variance-authority to reduce your class declarations in coherent reusable variants. Tailwind empowers the expressiveness of styling. I steadfastly counter that the statement that it is the eccentric artist who insists on using every color in the palette. By design, tailwind implements constraints on what can be utilized by it's configuration file. Sure, you can absolutely break out with arbitrary classes but the spirit is akin to a Crayola box of 64 crayons and you have to work with what you have in front of you. The largest benefit is that I can read my JSX/HTML and understand the presentation of the elements. Nothing is cryptic. I don't have to dive into another file where I can lose cognitive load. DX is enhanced. Critically stated: tailwind has been nothing but a massive boon for web dev since its inception.
- ramon156 2y ago
  Your last argument is a perfect reason why tailwind isn't a fad. Its a standard where, if you've worked with it, you know exactly what these classes will do. Saying "the classlist becomes long" is not an argument to avoid using tailwind, especially if you already have a component based framework. I'd rather read a tailwind classlist than having to spend time setting up my own half-arsed class list.
- hu3 2y ago
  Interesting response. I'm in this war against build steps. Is there a way to 80/20 Tailwind without the build steps? I mean, get 80% of the benefits with 20% of the work.
  - dimava 2y ago
    You may use CDN build of UnoCSS (16k GH stars) https://unocss.dev/integrations/runtime https://unocss.dev/integrations/runtime which generates styles on the fly for 80% of benefits with 0% build steps (even with regular HTML) It does have quirks compared to build variant, so if you use a framework, using it in a build step may be better, it'll still be much lighter then tailwind
simonbarker87 2y ago
So that’s a mid blue button that gets slightly darker on hover, with bold white text, it’s got a little more horizontal padding than vertical padding and has slight corner rounding and a slight drop shadow. And I can see all of that in context where the button is declared rather than having to go look at another file and see what everything is. Oh and I know that none of those TW classes conflict or over write any properties, unlike two in house styles.
- nprateem 2y ago
  Good luck changing the style site-wide.
  - vile_wretch 2y ago
    If you need to change a style site-wide you shouldn't be using individual tw classes. Don't blame the tool for shoddy workmanship, etc.
    - nprateem 2y ago
      It's called iteration
  - hennell 2y ago
    Go into the button component change the style.
    - nprateem 2y ago
      I'm sorry, I'm not creating a component per HTML tag with all the possible attributes just for my design system. What a complete waste of time. Anyway the GP said he could see everything without extra files. Which is it?
    - xigoi 2y ago
      Can’t do that when creating a user stylesheet.
  - 2y ago
klabb3 2y ago
> And those cryptic class names? They’re as cryptic as ls, cat, pwd. They have well defined semantics, sensible default, and tooling that can warn if your properties are conflicting. In fact, with regular css you need to target elements by coming up with arbitrary class names, like .banner-main-content. Those are more cryptic imo, and completely arbitrary. (Naming things is problem #2, remember) Do I wish there was a better way than space-separated attrs inside the human hostile xml-like format that is html? Yes. Do I want to go back to having to write custom selectors? No. 80-95% of the time utility classes is a better fit, especially with component based frameworks.
- lobsterthief 2y ago
  Have you used MUI before? No need for utility classes, no need for writing custom selectors, everything ties back to the theme, and everything is consistent. I don’t believe that “80-95% of the time utility classes are better” when super popular alternatives like MUI exist. Tailwind introduces some solutions while introducing other problems. It has its place when used correctly, but I’ve never seen a single TW codebase implemented properly. I’ve been writing CSS for 25 years and have gone through just about everything at this point—inline/attribute styles, CSS, SCSS/SASS, LESS, stylus, Bourbon, Tailwind, Bootstrap, Ant, Semantic UI, MUI, etc. And tbh, MUI is the closest I think we’ve gotten towards rapid iteration while solving specificity issues, the problem of selector generation, proper a11y and state styling (e.g. button focus styling), and inconsistency issues, but again—only when architectured correctly.
  - klabb3 2y ago
    > Have you used MUI before? No, React-specific? Keep in mind Tailwind is not bound to a specific component engine and works fantastic in e.g. Svelte which I'm using. That said, it looks good I guess? But I fail to see what's so unique. Tailwind is just a lower level preprocessor that can be used with unstyled components (which is definitely not unique - there's lots of traction outside the React ecosystem as well..) From what I can see, it looks like MUI also has a utility class type of approach, or is it baseUI? In either case, my point is that plain CSS with class selectors is not great, and that very often it makes more sense to bundle markup and styles. Well-thought-out interactions between the component- and style/theming systems is also an important part, and Tailwind clearly plays well with different component systems in the ecosystem. Other than that I don't have any interest in dying on some Tailwind-specific hill. I'm happy to see it improve or be superseded, should that be necessary. > Tailwind [...] has its place when used correctly, but I’ve never seen a single TW codebase implemented properly. Yes but ironically that's not necessarily a bad thing. That's the expected result of tech that is flexible enough to let you do what you need, including painting yourself into a corner. The most common mistake in framework design I've seen is "one to rule them all" - where you have to play according to restrictive rules within, or suffer greatly to break out. Tailwind is a la carte, incremental, and plays nice with other paradigms, which isn't to be underestimated.
smatija 2y ago
Agreed, I find tailwind defaults sensible, but it tends to make templates quite unreadable. My compromise with it is just using @apply in css files: styles.css: .button { @apply px-2 py-1 rounded-sm shadow-md hover:shadow-lg font-bold cursor-pointer block; height: 32px; } .button.create { @apply bg-green-700 text-white; } template.html: <button class="button create">...</button>
- nprateem 2y ago
  Ah the dream. Only now it takes my django project 45s to rebuild the tailwind any time I change those styles (and I only have about 30).
  - smatija 2y ago
    For me it's just a few seconds, but my css needs are rather compact. Luckily I don't have to change styles daily though.
progx 2y ago
Some time ago i thought the same, but using it a while change my mind. You can create and edit quick things, especially if some elements should have another styling. I don't miss the times when you specify every elements styling, especially nested components where you have to be carefull. Whether web-app or website, nobody create them in 2024 from scratch without any tools. And these tools can render your HTML with minimal classnames and optimize you css-file with needed tailwind styles. Primary i use it in web-app, and i don't care about dozens of classnames. The tools optimize it.
mattbrewsbytes 2y ago
Having just dipped my toes into tailwind and getting back up to speed on CSS, its shortcut syntax to base CSS. Putting all of that right on the element makes it easy for anyone to understand what is going on. After seeing web tech come and go over the years, I have a distaste for most tech that transpiles or similar things. In my experience, transpiling increases the likelihood of painting yourself into a corner eventually. It complicates the tech stack by adding more dependencies and it appears a goal with a lot of frameworks is to avoid actually writing HTML and CSS. Sure the goal of using techniques so you don't have to repeat code is there too but how many abstractions are actually necessary to achieve that?
liampulles 2y ago
Different strokes I guess. I would say I have basic skills (and interest frankly) in web dev, and I find all the HTML and CSS to look pretty messy anyway. At least with Tailwind I can have the mess in one place and try and understand it there, rather than needing to track down and interpret which CSS class is causing what and how to modify it without breaking something else.
azangru 2y ago
> I really was hoping that tailwind was a fad which died but like everything JavaScript it's here to stay sadly I feel with Tailwind it's worse somehow. At least heavy javascript frameworks are commonly ridiculed by back-end or full-stack developers here on HackerNews; but with Tailwind, they embraced it just as firmly as front-end developers have. It is common to hear from back-end or full-stack dev that all they need is just jQuery or plain vanilla; but far more rare to hear same sentiment expressed about plain old (or rather plain new) CSS.

llamaimperative 2y ago

The point is that it’s ridiculously fast to build and extremely easy to maintain. It’s also not hard to read after, idk, a week of working in it? The only people I’ve seen struggle beyond that are people who dug in their heels and dogmatically decided to struggle with it. FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element.

jacobyoder 2y ago
It's adequate for some folks who work in the same codebase, and define their own style of work. It's been a real pain for me who comes in to various codebases for short periods of time and have to read/digest/learn every single project's unique take on buttons. class="btn btn-primary" is also pretty easy to read. But in the last couple weeks I've have to deal with both class="bg-blue-500 hover:bg-blue-600 text-white font-bold py-2 px-4 rounded-md shadow-md" style buttons and <LinkButton4 /> and <LinkButton7 /> components, both of which still seemed to be affected by another wrapping container that decided to "text-xs" everything below it, but which wasn't obvious. Trying to simply add a 'button' that had the same styles around it was far more work than it should have been. No doubt, I'm somehow in a minority of switching between projects/codebases more often than other people. But this was much less of a problem with bootstrap and related definitions. > your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element. When you want, say, most things to share some common color/style definitions, you will still end up repeating a lot of stuff (same long string for buttons, and for headers, etc). The tailwind system gives you the option of @apply, but the tw docs are also relatively strongly against it, for ... I can't really understand the reason why. https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles > If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice. There's some reasons listed on that page justifying "don't use @apply!" but... they don't ring all that useful to me. They do say "well, you could do it for reusable things like buttons", but those are the very things that most tailwind examples use longhand examples for. > Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse. There's a balance between the 'ugly' (their words) and 'tons of custom css'. Everyone's balance is different, I get it, but I'm usually having to come in after someone who was jazzed about tailwind has moved on and left me the 'ugly' (their words) mess. If every link should have "text-dark font-bold font-xs"... @apply that with an understandable name. Or document your design decisions...? But that conflicts with "ridiculously fast to build". Documenting them in an '@apply' way would let me see how you want some styles grouped together without having to scan through dozens of your components looking for a pattern.
- naught0 2y ago
  > without having to scan through dozens of your components looking for a pattern Wouldn't you have to scan disparately located CSS files anyway? How many projects have you seen with nonsensical or clobbered classnames or conflicting rules? Really for a lot of designs I think you can just eyeball it. If `px-4` looks about right, then use it. Otherwise you can find a similar component and hijack the exact padding if you want, or get it from the design. You probably think @apply makes more sense because you know and like traditional CSS. You want to apply tailwind classes and condense them into a single reusable one. Tailwind asks you to think in a different way. The classes are aptly named (mostly) and granular (one class per css directive), so my knowledge of CSS felt very transferable. <LinkButton4 /> Imo should be <LinkButton variant={"homepage"} /> Leveraging something like Class Variance Authority or more simply: <LinkButton className="text-xl other-override-here" /> Using tailwind-merge I have found tailwind to be indispensable, and it pairs particularly well with React.
  - jacobyoder 2y ago
    Again, at least part of the core issues I have is coming in to other projects where each person thinks in a 'different way'. And almost all of them are simply copy/pasting loads of tailwind extended strings of stuff, then semi randomly tweaking until something looks 'ok', then moving on. > scan disparately located CSS files anyway usually, I encounter CSS in one of two ways: 1. a main base css file or set of files (from a framework, maybe), and then an override css file. Single override file can get hairy to look through, admittedly, but it's typically in one spot. I rarely come across projects with dozens of standalone css files. 2. 'style-in-components' - primarily in vue, because vue sfc encourages scoped styling - structure, code, style in a single file. Whether that's bootstrap styling ('btn btn-primary', etc) or tailwind doesn't make too much of a difference. Where I've hit more maintenance issues is coming in to projects with tailwind in say, react or vue - with the 'style in components' - is that "text-xs px-1 rounded-sm bg-gray-200 inline-block text-gray-600 mb-1" repeated across multiple components, is harder to find when I want to replicate something vs just "class='tooltip'" Of course, we're all doing it wrong, and if we all just 'think different' all the time, and spend loads of time rewriting "wrong" stuff from other people - things will be just fine. But the world I live in, and the world I see a lot of people in - is not greenfield, but brownfield, and we have to live with the decisions others made. Tailwind does not make my life any easier that way, and generally introduces more cognitive overhead earlier in a project when it comes to visual stuff.
orangepanda 2y ago
I strongly disagree on the maintainability. Mistakes are easy to make and have been made when comparing a list of 20 class names across a dozen elements. Its only "maintainable" if you ignore the class list when reading. I review my local evangelists' tailwind code and from their mistakes its clear they're not reading the class list. It reminds me of how some people claim they're great at multitasking and can text & drive with no issues - meanwhile not even being aware of what they're missing. Tailwind has its uses, but it should not be the default choice.
- datavirtue 2y ago
  All this talk reminded me of the extensions I installed to deal with these issues.
- lobsterthief 2y ago
  I’ve experienced the exact same thing. Most TW evangelists I know are admittedly not that great at CSS. Those who are generally prefer a library like MUI instead, which offers the same maintainability benefits, a far more consistent UI, but with a higher learning curve.
  - dabber 2y ago
    I'd love to love MUI, but in my experience: MUI + React + Typescript just moves the toil of doing anything away from the style concerns and makes it a purely Typescript puzzle.
  - nightski 2y ago
    As an end user (not developer) I'd take just about any design system over MUI. It's so clunky/heavy, has an abundance of useless white space, and just feels really outdated.
  - 0x457 2y ago
    > a far more consistent UI That's what I like about tailwindcss - unlike MUI and co, it lets you follow sane design rules laid by tailwind and yet make the website look different from the rest. Consistency of UI entirely depends on the user of tailwind.
lawn 2y ago
> FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element. And pray you never have to tweak or debug that element. Hiding away bad code where you don't have to look at it doesn't stop it from being bad.
- progx 2y ago
  Open the browser tools, select the element, view the styles and look what class cause the problem. Nothing else would you do, if you had a problem in styles css file.
- llamaimperative 2y ago
  If you can’t follow a DOM tree through some custom components to debug uhhhh… maybe practice more.
  - lawn 2y ago
    The point was, obviously, that the styling string doesn't go away if you hide it inside an element.
    - llamaimperative 2y ago
      Then I’m failing to see why it’s “bad” other than the verbosity/visual noise, which does in fact go away if you hide it (this is the point of abstraction in general, of course)
pupppet 2y ago
You lost me at ‘maintain’. It’s definitely not easier than just updating a single .button class, and I’m not going to create reusable components out of everything in my project, the <Button /> approach doesn’t work for everything.
- compootr 2y ago
  Yes, it is easier to maintain (assuming no css-in-js) Your styles are bound to the component, not some global in your app. States and their representations are controlled in the component themselves With normal css files and class names, you must jump between files. With tailwind, I see what's going on with a component right in my jawascript
  - pupppet 2y ago
    You’re assuming I’m going to create a component out of any element on the page that needs styling. In my project I could just have a small handful of these scattered across hundreds of files: <table class=“datatable”> If I used tailwind utility classes, how do I update my data table styling without having to search and replace across all of my files? Assuming you could even search and replace, the utility classes could be in a different order. Not saying it’s not doable, but it seems like a real pain in the ass. What am I missing?
- llamaimperative 2y ago
  The things it doesn't work for are the things that .button doesn't work for either.
danielvaughn 2y ago
After writing Tailwind for a few years, I've kinda shifted position on the maintainability of it. It's definitely easier than any alternative, but it's also painful to read through a giant list of classes. There's no getting around that. I think a better way to put it is that Tailwind optimizes for writes vs reads. It sacrifices the readability of HTML for the writability of CSS. I still think that's a worthwhile tradeoff, but it's definitely a tradeoff.
azangru 2y ago
> FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element. Sure thing. What I don't understand though is why not put a Button.css file next to the Button element file, and describe all the button styles in there. What's so hard about building or maintaining that?
- danenania 2y ago
  1 - It’s easy for style bugs to get introduced when someone updates the html and forgets the css. 2 - It’s simpler to have styles that depend on js vars/parameters when components handle their own styling. Encapsulation, in other words.
- 0x457 2y ago
  Soon after, you're going to need slightly adjust that button, you will add some helper classes. Then there will be a case when base style of that button doesn't work with new button style, and now you have 2 bases for a button. You might have semantically named those buttons, but 3 months later that no longer makes sense, and now you're afraid to rename it. Tailwind lets you style elements in the same file as the element, you don't have to switch between `button.<whatever you use>` and `button.css` to know what is going on. nah, I love tailwindcss.
  - azangru 2y ago
    > Soon after, you're going to need slightly adjust that button The proper thing to do, in my mind, is to gradually set up a collection of such buttons (and other components), and document their properties. A design system, if you will. You shouldn't have that many button variations. This should also help with the "3 months later" case. Once you've catalogued your buttons, you can reason about them, update their styles, rename them as you please, and so on, while maintaining consistency of buttons across your site.

NeutralForest 2y ago

I have used tailwind on and off and I still find this pretty easy to read tbf.

iamsaitam 2y ago

Ever heard of CSS files? No one forces you to bloat your html.

blorenz 2y ago

Every time something with tailwind is posted there is always a rehash of this response. I believe most of this frustration comes from using tailwind in the raw. There are a few essential libraries available that amplify the power of tailwind by magnitudes: tailwind-merge for last-specified wins, and class-variance-authority to reduce your class declarations in coherent reusable variants. Tailwind empowers the expressiveness of styling. I steadfastly counter that the statement that it is the eccentric artist who insists on using every color in the palette. By design, tailwind implements constraints on what can be utilized by it's configuration file. Sure, you can absolutely break out with arbitrary classes but the spirit is akin to a Crayola box of 64 crayons and you have to work with what you have in front of you. The largest benefit is that I can read my JSX/HTML and understand the presentation of the elements. Nothing is cryptic. I don't have to dive into another file where I can lose cognitive load. DX is enhanced. Critically stated: tailwind has been nothing but a massive boon for web dev since its inception.

ramon156 2y ago
Your last argument is a perfect reason why tailwind isn't a fad. Its a standard where, if you've worked with it, you know exactly what these classes will do. Saying "the classlist becomes long" is not an argument to avoid using tailwind, especially if you already have a component based framework. I'd rather read a tailwind classlist than having to spend time setting up my own half-arsed class list.
hu3 2y ago
Interesting response. I'm in this war against build steps. Is there a way to 80/20 Tailwind without the build steps? I mean, get 80% of the benefits with 20% of the work.
- dimava 2y ago
  You may use CDN build of UnoCSS (16k GH stars) https://unocss.dev/integrations/runtime https://unocss.dev/integrations/runtime which generates styles on the fly for 80% of benefits with 0% build steps (even with regular HTML) It does have quirks compared to build variant, so if you use a framework, using it in a build step may be better, it'll still be much lighter then tailwind

simonbarker87 2y ago

So that’s a mid blue button that gets slightly darker on hover, with bold white text, it’s got a little more horizontal padding than vertical padding and has slight corner rounding and a slight drop shadow. And I can see all of that in context where the button is declared rather than having to go look at another file and see what everything is. Oh and I know that none of those TW classes conflict or over write any properties, unlike two in house styles.

nprateem 2y ago
Good luck changing the style site-wide.
- vile_wretch 2y ago
  If you need to change a style site-wide you shouldn't be using individual tw classes. Don't blame the tool for shoddy workmanship, etc.
  - nprateem 2y ago
    It's called iteration
- hennell 2y ago
  Go into the button component change the style.
  - nprateem 2y ago
    I'm sorry, I'm not creating a component per HTML tag with all the possible attributes just for my design system. What a complete waste of time. Anyway the GP said he could see everything without extra files. Which is it?
  - xigoi 2y ago
    Can’t do that when creating a user stylesheet.
- 2y ago

klabb3 2y ago

> And those cryptic class names? They’re as cryptic as ls, cat, pwd. They have well defined semantics, sensible default, and tooling that can warn if your properties are conflicting. In fact, with regular css you need to target elements by coming up with arbitrary class names, like .banner-main-content. Those are more cryptic imo, and completely arbitrary. (Naming things is problem #2, remember) Do I wish there was a better way than space-separated attrs inside the human hostile xml-like format that is html? Yes. Do I want to go back to having to write custom selectors? No. 80-95% of the time utility classes is a better fit, especially with component based frameworks.

lobsterthief 2y ago
Have you used MUI before? No need for utility classes, no need for writing custom selectors, everything ties back to the theme, and everything is consistent. I don’t believe that “80-95% of the time utility classes are better” when super popular alternatives like MUI exist. Tailwind introduces some solutions while introducing other problems. It has its place when used correctly, but I’ve never seen a single TW codebase implemented properly. I’ve been writing CSS for 25 years and have gone through just about everything at this point—inline/attribute styles, CSS, SCSS/SASS, LESS, stylus, Bourbon, Tailwind, Bootstrap, Ant, Semantic UI, MUI, etc. And tbh, MUI is the closest I think we’ve gotten towards rapid iteration while solving specificity issues, the problem of selector generation, proper a11y and state styling (e.g. button focus styling), and inconsistency issues, but again—only when architectured correctly.
- klabb3 2y ago
  > Have you used MUI before? No, React-specific? Keep in mind Tailwind is not bound to a specific component engine and works fantastic in e.g. Svelte which I'm using. That said, it looks good I guess? But I fail to see what's so unique. Tailwind is just a lower level preprocessor that can be used with unstyled components (which is definitely not unique - there's lots of traction outside the React ecosystem as well..) From what I can see, it looks like MUI also has a utility class type of approach, or is it baseUI? In either case, my point is that plain CSS with class selectors is not great, and that very often it makes more sense to bundle markup and styles. Well-thought-out interactions between the component- and style/theming systems is also an important part, and Tailwind clearly plays well with different component systems in the ecosystem. Other than that I don't have any interest in dying on some Tailwind-specific hill. I'm happy to see it improve or be superseded, should that be necessary. > Tailwind [...] has its place when used correctly, but I’ve never seen a single TW codebase implemented properly. Yes but ironically that's not necessarily a bad thing. That's the expected result of tech that is flexible enough to let you do what you need, including painting yourself into a corner. The most common mistake in framework design I've seen is "one to rule them all" - where you have to play according to restrictive rules within, or suffer greatly to break out. Tailwind is a la carte, incremental, and plays nice with other paradigms, which isn't to be underestimated.

smatija 2y ago

Agreed, I find tailwind defaults sensible, but it tends to make templates quite unreadable. My compromise with it is just using @apply in css files: styles.css: .button { @apply px-2 py-1 rounded-sm shadow-md hover:shadow-lg font-bold cursor-pointer block; height: 32px; } .button.create { @apply bg-green-700 text-white; } template.html: <button class="button create">...</button>

nprateem 2y ago
Ah the dream. Only now it takes my django project 45s to rebuild the tailwind any time I change those styles (and I only have about 30).
- smatija 2y ago
  For me it's just a few seconds, but my css needs are rather compact. Luckily I don't have to change styles daily though.

progx 2y ago

Some time ago i thought the same, but using it a while change my mind. You can create and edit quick things, especially if some elements should have another styling. I don't miss the times when you specify every elements styling, especially nested components where you have to be carefull. Whether web-app or website, nobody create them in 2024 from scratch without any tools. And these tools can render your HTML with minimal classnames and optimize you css-file with needed tailwind styles. Primary i use it in web-app, and i don't care about dozens of classnames. The tools optimize it.

mattbrewsbytes 2y ago

Having just dipped my toes into tailwind and getting back up to speed on CSS, its shortcut syntax to base CSS. Putting all of that right on the element makes it easy for anyone to understand what is going on. After seeing web tech come and go over the years, I have a distaste for most tech that transpiles or similar things. In my experience, transpiling increases the likelihood of painting yourself into a corner eventually. It complicates the tech stack by adding more dependencies and it appears a goal with a lot of frameworks is to avoid actually writing HTML and CSS. Sure the goal of using techniques so you don't have to repeat code is there too but how many abstractions are actually necessary to achieve that?

liampulles 2y ago

Different strokes I guess. I would say I have basic skills (and interest frankly) in web dev, and I find all the HTML and CSS to look pretty messy anyway. At least with Tailwind I can have the mess in one place and try and understand it there, rather than needing to track down and interpret which CSS class is causing what and how to modify it without breaking something else.

azangru 2y ago

> I really was hoping that tailwind was a fad which died but like everything JavaScript it's here to stay sadly I feel with Tailwind it's worse somehow. At least heavy javascript frameworks are commonly ridiculed by back-end or full-stack developers here on HackerNews; but with Tailwind, they embraced it just as firmly as front-end developers have. It is common to hear from back-end or full-stack dev that all they need is just jQuery or plain vanilla; but far more rare to hear same sentiment expressed about plain old (or rather plain new) CSS.