5 ms·

As someone who is skeptical about Tailwind because I've learnt to separate the structure from the presentation (the old school way). It reads like the advantag

by jraph 3y ago

As someone who is skeptical about Tailwind because I've learnt to separate the structure from the presentation (the old school way). It reads like the advantages listed in the article would apply if one used style="...." everywhere. Which does not sell it well to me. Then again the author says they needed to actually try Tailwind for it to "click". But then again, they are praising something without much long term insight, I'd be interested to have an opinion from someone who has maintained a project for one or two years, or more. Tailwind feels like Bootstrap to me: as someone who has written raw CSS for years, you need to learn a new vocabulary and map it to standard CSS. Which I don't feel the need for. I know CSS, and you kind of have to anyway even when using a CSS framework. With the extra disadvantage that you need to have a build pass so Tailwind can pick up the dynamic classes you used to build the corresponding CSS for you. But I really want to write this CSS myself and have meaningful class names, I feel like it helps me understand what's what when working on the structure. I can always inspect with the web developer tools if I want do understand what styles apply. I see the appeal of having some default design system applied to your thing and not having to write some style reset stuff when using a CSS framework like Bootstrap, but even for this I'm not sure about the benefit/drawback ratio. I work for a company whose product is somewhat trapped in an old version of bootstrap because it can be augmented with extensions, and not the old bootstrap version is part of the API, if you update it you break the API. I don't know.

mock-possum 3y ago
Man I am right there with you. It just feels like it’s giving up too much. It’s more enjoyable to write the CSS yourself.
IlPeach 3y ago
Same here. Have tried a few before moving my portfolio to Sveltekit last year, including Tailwind. And to be honest it does feel Bootstrappy as you said. The simplicity and flexibility you have in some of the functionality of CSS to really do whatever in terms of layouts is fantastic. The only thing I know for sure, as it's a current problem with the front-end development at work, is that majority of devs are not that experts in CSS and they have hardly spent any time working on raw CSS in their whole career. Which is where I can see the appeal of using Tailwind. Maybe.
btown 3y ago
My take on this is that meaningful class names are massively helpful for maintainability and any kind of development lifecycle. What is the name of the sub-widget you are currently building? Say you're building a card - if there is a row that has various icons for the features of the thing depicted in the card, alongside a subtitle, what is that row? It's not just an icon row, because of that subtitle. Should it be its own component? Or will you just give it a reasonable name, keep it defined inline in the larger card's component, but make it clear that you see it as a definable sub-layer? A class name is easier and less disruptive to type than creating an entire new React file for a subcomponent. What about code review and QA? Must the reviewer read a dense string of Tailwind class names just to try to intuit what is going on? And then, when someone doing QA says "we need to add some padding on the..." - can they go into dev tools and see a reasonable name for that subcomponent? Or would they need to refer to it as the thing around the X and Y and Z, because that's the only way they have to describe the thing? Not to mention userscripts and extensibility. For the same reasons that one might open-source parts of their stack, and for the same reason that app stores drive stickiness, allowing your users to hack on the visualization of your product can be highly synergistic. Using opaque class names takes this power away. We've all seen Figma files with unnamed Group 142 nested in Group 134 nested in... if they are grouped at all, that is! A tradeoff was made for design speed vs. maintainability/future component extraction. Often that's the right choice at the design stage. But if you work in a realm of text editors and textual code reviews, that may not be the right choice for you.
- kaba0 3y ago
  With all due respect, I think many of us has been massively burnt by that “meaningful classname”, that happened to be also a meaningful classname in a different part of the code, or was not specific enough, or an update to a CSS dependency broke the whole thing.
- DanielHB 3y ago
  Tailwind makes a lot more sense when used in conjunction with a component library.
- nailer 3y ago
  Unfortunately like “jQuery developers” a decade ago, we now have “react developers” that don’t understand CSS and add more divs until they get the result they want. A modal log in screen is five elements: a shade, a dialog, two labels, two inputs and a button. These are all very easy to name. Not 300 unnamed divs. The react developer adds divs and then considers it difficult to name them all.
inopinatus 3y ago
Here's a thought: HTML does not separate structure, or content, from presentation. I'm not sure where the myth of the web's separation of concerns first arose - possibly from some architecture astronaut who'd never written an element in their life, perhaps from someone who really knew better but needed to slip something past the mediocrity police - but irrespective of what any non-normative reference may say, HTML does in practice blend structure, semantics, content, and presentation. CSS and JS substantially augment the presentation and semantics, but fighting against the grain of what HTML fundamentally embodies, instead of leaning on the framework, is a prime recipe for technical debt, not to mention opening the door for an awful lot of NIH. Tailwind responds to that with an organising principle of styles refactored at the abstraction level of page components. It is not supplying an off-the-shelf design system for front-end novices a la bootstrap/material design. That is an excellent fit for a template-driven world, which is to say, most applications of scale. It is also an excellent fit for anyone (or any HTML generation language) that thinks of data as functional and anonymous. Naming things is hard, so the fewer things we're forced to name the better. My CSS has even improved from using Tailwind, not just thanks to the excellent docs but because it's been easy to experiment with alternative compositions. To your specific inquiry - I've been maintaining several Tailwind frontends for a few years now, and it's been more reusable, more composable, and more maintainable that any of the hand-crafted CSS I might've written in the past, no matter how polished and proud I was of it.
- po 3y ago
  I'm not sure where the myth of the web's separation of concerns first arose - possibly from some architecture astronaut who'd never written an element in their life, perhaps from someone who really knew better but needed to slip something past the mediocrity police I'm pretty sure it came from CSS Zen Garden (http://www.csszengarden.com http://www.csszengarden.com). The same HTML with dozens of different presentations all done exclusively with CSS changes. Don't get me wrong, I agree with you that for the most part the separation is a myth, but I personally remember before seeing CSS Zen Garden, the idea wasn't as common.
  - louzell 3y ago
pocketarc 3y ago
I think the appeal of Tailwind is in having the defaults preset (especially if you customise them to your own design needs). Padding numbers, font sizes, colours available, etc. You're not just randomly picking a px number in a style declaration, or trying to come up with a random variation of red. A new developer can come in and use the standard tailwind classes and they'll be productive right off the bat, regardless of your product's decisions around sizes/colours/etc. And it scales in a way that Bootstrap doesn't, because Bootstrap imposes a design. Unless you customise the living daylights out of it, it's going to look like Bootstrap. With Tailwind, you're building from scratch, and you can make it look like whatever you want, you don't lose any of the flexibility of CSS. I, too, had to try it before it clicked; I thought it looked ugly as all hell, tons of random classes sprinkled in. Went against all that we've all been taught in the past (remember when we all worried about semantic class names?). But it really is useful.
- epiccoleman 3y ago
  >having the defaults preset This was very much the appeal to me - it eliminated a ton of different little decisions I would have otherwise had to think hard about, and let me just get into the actual fun part of style. I also like that most Tailwind classes are named very similarly to the CSS directives that they apply, which meant (for me at least) that learning Tailwind has had a direct impact on my ability to write decent vanilla CSS. I used it to style my personal site / blog (epiccoleman.com) and was really happy with the results. Previous attempts at rolling my own design did not come out looking nearly as good, so there's definitely something to it.
kristiandupont 3y ago
I have used it for three years at this point. I would feel very disabled if not allowed to use it on the next project. You say that you want to write "meaningful class names", which is something that clicked for me: naming things is hard[1]! I remember having the feeling that every time I used inline styles, I was cheating in both senses of the word: doing something not allowed and getting away with something too easily. I get that second feeling when using Tailwind. [1] https://medium.com/p/9eab459633d2 https://medium.com/p/9eab459633d2
- nailer 3y ago
  How is naming things hard? I am looking at a comment, it contains two voting buttons, and some text. The elements should be : .comment, button.upvote, button.downvote, .text If you have more elements than that you’re either doing something extraordinary or you need to learn CSS better.
  - kaba0 3y ago
    Now do a card-widget. HTML is too barebones to operate without random helper divs, and those can’t be meaningfully named.
    - nailer 3y ago
      I do card widgets all the time without wrapper hacks. So do most competent from end developers. Challenge me on any design you want.
- danShumway 3y ago
  > naming things is hard This is an argument that would have held more weight for me before I started using BEM. Naming your CSS should be exactly as hard as naming your component, and no harder. Is your React/Vue/Svette component named "GenericButton"? Congrats, that's your class name. Got some markup under it that you need to style and you're worried about name intersections? Don't be; "GenericButton__whatever". You never need to worry about collisions again, they just don't happen. And you never need to worry about naming, you just use the same names that you're using in your Javascript/Typescript. ---- To me, I look at Tailwind, and it feels like taking a bunch of React components and saying "no, don't separate those out into hooks and helpers, inline all of it." People say that Tailwind is about locality of style, but I just don't see it. Locality of style, component-based CSS -- you do that by using components and by scoping your CSS to those components. You can do that with normal CSS. Heck, there are even libraries that will get rid of the cascade if it becomes a problem. I'm told that the reason Tailwind often ends up looking like spaghetti code is because you're supposed to be using more helpers with it and that you can make it reusable. Sure, I buy that. I buy that it can be made reusable and composable. But say that you make it reusable and composable -- part of that process is going to be naming things. It's going to be deciding what to name your helpers and your shared styles you want to use everywhere. So I don't know, maybe there's something I'm missing. I agreed with a lot of the criticisms of "semantic" CSS and I might have been really receptive to Tailwind at some point (I do think using element names in CSS is usually bad practice), but then BEM happened and I realized, "hey, you can just name CSS after the component you have it attached to, and then suddenly all of these problems go away and it becomes way easier to debug because you always know exactly what to search for in the codebase and where to look to adjust every class." And yeah it's more verbose and the double underscores look a little ugly, but come on, we're comparing it to Tailwind. Having your markup look a little bit ugly obviously isn't a dealbreaker. I'm trying not to be dismissive of Tailwind in part because a lot of people use it and like it, and I felt dismissive about BEM as well before I started using it. So I keep on using Tailwind when I run into it, I keep on waiting for it to click. It hasn't yet. Maybe I'm just not seeing it or not using it right but I'm never tempted to use it when I don't have to. ---- Edit: I will add to this, you want to talk about coupling CSS to Javascript then one of the cool things about BEM styling is that your generated output documents your Javascript/Typescript. When I look at an app that's using BEM, and I see part the HTML that I want to change, even if I've never looked at the codebase before in my life I know exactly what to grep to get to the HTML and exactly what file I need to change. If somebody wants something added to a footer, I know what filename to search for to get that footer, I know the full list of every component that's inside that footer just by looking at the HTML. I know how the Javascript code is organized just from the HTML. And that makes it so much easier to just think about individual components without having to worry about understanding an entire application. In comparison, every time I look at an app with Tailwind, I'm struck by how utterly useless the generated HTML is for doing any kind of debugging -- both debugging style and debugging the HTML/Javascript. Because it turns out that having every component name in code mirrored to your class list and tied to your styles makes it really easy to cross-reference everything.
Mikhail_Edoshin 3y ago
There is XSL-FO, less famous cousin of CSS, that formats documents for printing. It has no formatting classes; each element has to have the appropriate attributes. To make it manageable there are, of course, default values and inheritance, so you can set the main font once on the root element and then only use 'font' when you need another. And since these are XML documents and are mostly created via XSL, they can also use an alternative generic mechanism of setting attributes: XSL attribute sets. I’ve worked with XSL-FO (not as much as I would like to), and I would say that this is a pretty viable approach. First I tried to turn attribute sets into formatting classes (it is totally possible, plus these classes can also form a hierarchy with clear priority rules). This mapped very well to what I knew about CSS and to my experience in desktop publishing. But over time I became perfectly content with just setting attributes on an element directly and only resort to attribute sets when they came naturally as a time-saving technique. In old times people who wrote about UI emphasised “direct control”: users must feel they are in control of things that are happening on the computer, that they not just convince the computer to do something but can, for example, directly move a file from one place to another. This is an illusion, of course, but the one that gives the interface a very empowering quality. (Which becames more and more scarce nowadays.) As far as I understand Tailwind it gives the same feeling of direct control.
- moritzwarhier 3y ago
  Thank you, this was a good read and positively exhaustive. Especially the comparison with XSL-FO regarding the cascade: I never felt that tailwind abandoned the C in CSS entirely, it just encourages to limit its usage to a sane and transparent approach (as opposed to specificity wars)

by jraph 3y ago

mock-possum 3y ago

Man I am right there with you. It just feels like it’s giving up too much. It’s more enjoyable to write the CSS yourself.

IlPeach 3y ago

Same here. Have tried a few before moving my portfolio to Sveltekit last year, including Tailwind. And to be honest it does feel Bootstrappy as you said. The simplicity and flexibility you have in some of the functionality of CSS to really do whatever in terms of layouts is fantastic. The only thing I know for sure, as it's a current problem with the front-end development at work, is that majority of devs are not that experts in CSS and they have hardly spent any time working on raw CSS in their whole career. Which is where I can see the appeal of using Tailwind. Maybe.

btown 3y ago

My take on this is that meaningful class names are massively helpful for maintainability and any kind of development lifecycle. What is the name of the sub-widget you are currently building? Say you're building a card - if there is a row that has various icons for the features of the thing depicted in the card, alongside a subtitle, what is that row? It's not just an icon row, because of that subtitle. Should it be its own component? Or will you just give it a reasonable name, keep it defined inline in the larger card's component, but make it clear that you see it as a definable sub-layer? A class name is easier and less disruptive to type than creating an entire new React file for a subcomponent. What about code review and QA? Must the reviewer read a dense string of Tailwind class names just to try to intuit what is going on? And then, when someone doing QA says "we need to add some padding on the..." - can they go into dev tools and see a reasonable name for that subcomponent? Or would they need to refer to it as the thing around the X and Y and Z, because that's the only way they have to describe the thing? Not to mention userscripts and extensibility. For the same reasons that one might open-source parts of their stack, and for the same reason that app stores drive stickiness, allowing your users to hack on the visualization of your product can be highly synergistic. Using opaque class names takes this power away. We've all seen Figma files with unnamed Group 142 nested in Group 134 nested in... if they are grouped at all, that is! A tradeoff was made for design speed vs. maintainability/future component extraction. Often that's the right choice at the design stage. But if you work in a realm of text editors and textual code reviews, that may not be the right choice for you.

kaba0 3y ago
With all due respect, I think many of us has been massively burnt by that “meaningful classname”, that happened to be also a meaningful classname in a different part of the code, or was not specific enough, or an update to a CSS dependency broke the whole thing.
DanielHB 3y ago
Tailwind makes a lot more sense when used in conjunction with a component library.
nailer 3y ago
Unfortunately like “jQuery developers” a decade ago, we now have “react developers” that don’t understand CSS and add more divs until they get the result they want. A modal log in screen is five elements: a shade, a dialog, two labels, two inputs and a button. These are all very easy to name. Not 300 unnamed divs. The react developer adds divs and then considers it difficult to name them all.

inopinatus 3y ago

Here's a thought: HTML does not separate structure, or content, from presentation. I'm not sure where the myth of the web's separation of concerns first arose - possibly from some architecture astronaut who'd never written an element in their life, perhaps from someone who really knew better but needed to slip something past the mediocrity police - but irrespective of what any non-normative reference may say, HTML does in practice blend structure, semantics, content, and presentation. CSS and JS substantially augment the presentation and semantics, but fighting against the grain of what HTML fundamentally embodies, instead of leaning on the framework, is a prime recipe for technical debt, not to mention opening the door for an awful lot of NIH. Tailwind responds to that with an organising principle of styles refactored at the abstraction level of page components. It is not supplying an off-the-shelf design system for front-end novices a la bootstrap/material design. That is an excellent fit for a template-driven world, which is to say, most applications of scale. It is also an excellent fit for anyone (or any HTML generation language) that thinks of data as functional and anonymous. Naming things is hard, so the fewer things we're forced to name the better. My CSS has even improved from using Tailwind, not just thanks to the excellent docs but because it's been easy to experiment with alternative compositions. To your specific inquiry - I've been maintaining several Tailwind frontends for a few years now, and it's been more reusable, more composable, and more maintainable that any of the hand-crafted CSS I might've written in the past, no matter how polished and proud I was of it.

po 3y ago
I'm not sure where the myth of the web's separation of concerns first arose - possibly from some architecture astronaut who'd never written an element in their life, perhaps from someone who really knew better but needed to slip something past the mediocrity police I'm pretty sure it came from CSS Zen Garden (http://www.csszengarden.com http://www.csszengarden.com). The same HTML with dozens of different presentations all done exclusively with CSS changes. Don't get me wrong, I agree with you that for the most part the separation is a myth, but I personally remember before seeing CSS Zen Garden, the idea wasn't as common.
- louzell 3y ago

pocketarc 3y ago

I think the appeal of Tailwind is in having the defaults preset (especially if you customise them to your own design needs). Padding numbers, font sizes, colours available, etc. You're not just randomly picking a px number in a style declaration, or trying to come up with a random variation of red. A new developer can come in and use the standard tailwind classes and they'll be productive right off the bat, regardless of your product's decisions around sizes/colours/etc. And it scales in a way that Bootstrap doesn't, because Bootstrap imposes a design. Unless you customise the living daylights out of it, it's going to look like Bootstrap. With Tailwind, you're building from scratch, and you can make it look like whatever you want, you don't lose any of the flexibility of CSS. I, too, had to try it before it clicked; I thought it looked ugly as all hell, tons of random classes sprinkled in. Went against all that we've all been taught in the past (remember when we all worried about semantic class names?). But it really is useful.

epiccoleman 3y ago
>having the defaults preset This was very much the appeal to me - it eliminated a ton of different little decisions I would have otherwise had to think hard about, and let me just get into the actual fun part of style. I also like that most Tailwind classes are named very similarly to the CSS directives that they apply, which meant (for me at least) that learning Tailwind has had a direct impact on my ability to write decent vanilla CSS. I used it to style my personal site / blog (epiccoleman.com) and was really happy with the results. Previous attempts at rolling my own design did not come out looking nearly as good, so there's definitely something to it.

kristiandupont 3y ago

I have used it for three years at this point. I would feel very disabled if not allowed to use it on the next project. You say that you want to write "meaningful class names", which is something that clicked for me: naming things is hard[1]! I remember having the feeling that every time I used inline styles, I was cheating in both senses of the word: doing something not allowed and getting away with something too easily. I get that second feeling when using Tailwind. [1] https://medium.com/p/9eab459633d2 https://medium.com/p/9eab459633d2

nailer 3y ago
How is naming things hard? I am looking at a comment, it contains two voting buttons, and some text. The elements should be : .comment, button.upvote, button.downvote, .text If you have more elements than that you’re either doing something extraordinary or you need to learn CSS better.
- kaba0 3y ago
  Now do a card-widget. HTML is too barebones to operate without random helper divs, and those can’t be meaningfully named.
  - nailer 3y ago
    I do card widgets all the time without wrapper hacks. So do most competent from end developers. Challenge me on any design you want.
danShumway 3y ago
> naming things is hard This is an argument that would have held more weight for me before I started using BEM. Naming your CSS should be exactly as hard as naming your component, and no harder. Is your React/Vue/Svette component named "GenericButton"? Congrats, that's your class name. Got some markup under it that you need to style and you're worried about name intersections? Don't be; "GenericButton__whatever". You never need to worry about collisions again, they just don't happen. And you never need to worry about naming, you just use the same names that you're using in your Javascript/Typescript. ---- To me, I look at Tailwind, and it feels like taking a bunch of React components and saying "no, don't separate those out into hooks and helpers, inline all of it." People say that Tailwind is about locality of style, but I just don't see it. Locality of style, component-based CSS -- you do that by using components and by scoping your CSS to those components. You can do that with normal CSS. Heck, there are even libraries that will get rid of the cascade if it becomes a problem. I'm told that the reason Tailwind often ends up looking like spaghetti code is because you're supposed to be using more helpers with it and that you can make it reusable. Sure, I buy that. I buy that it can be made reusable and composable. But say that you make it reusable and composable -- part of that process is going to be naming things. It's going to be deciding what to name your helpers and your shared styles you want to use everywhere. So I don't know, maybe there's something I'm missing. I agreed with a lot of the criticisms of "semantic" CSS and I might have been really receptive to Tailwind at some point (I do think using element names in CSS is usually bad practice), but then BEM happened and I realized, "hey, you can just name CSS after the component you have it attached to, and then suddenly all of these problems go away and it becomes way easier to debug because you always know exactly what to search for in the codebase and where to look to adjust every class." And yeah it's more verbose and the double underscores look a little ugly, but come on, we're comparing it to Tailwind. Having your markup look a little bit ugly obviously isn't a dealbreaker. I'm trying not to be dismissive of Tailwind in part because a lot of people use it and like it, and I felt dismissive about BEM as well before I started using it. So I keep on using Tailwind when I run into it, I keep on waiting for it to click. It hasn't yet. Maybe I'm just not seeing it or not using it right but I'm never tempted to use it when I don't have to. ---- Edit: I will add to this, you want to talk about coupling CSS to Javascript then one of the cool things about BEM styling is that your generated output documents your Javascript/Typescript. When I look at an app that's using BEM, and I see part the HTML that I want to change, even if I've never looked at the codebase before in my life I know exactly what to grep to get to the HTML and exactly what file I need to change. If somebody wants something added to a footer, I know what filename to search for to get that footer, I know the full list of every component that's inside that footer just by looking at the HTML. I know how the Javascript code is organized just from the HTML. And that makes it so much easier to just think about individual components without having to worry about understanding an entire application. In comparison, every time I look at an app with Tailwind, I'm struck by how utterly useless the generated HTML is for doing any kind of debugging -- both debugging style and debugging the HTML/Javascript. Because it turns out that having every component name in code mirrored to your class list and tied to your styles makes it really easy to cross-reference everything.

Mikhail_Edoshin 3y ago

There is XSL-FO, less famous cousin of CSS, that formats documents for printing. It has no formatting classes; each element has to have the appropriate attributes. To make it manageable there are, of course, default values and inheritance, so you can set the main font once on the root element and then only use 'font' when you need another. And since these are XML documents and are mostly created via XSL, they can also use an alternative generic mechanism of setting attributes: XSL attribute sets. I’ve worked with XSL-FO (not as much as I would like to), and I would say that this is a pretty viable approach. First I tried to turn attribute sets into formatting classes (it is totally possible, plus these classes can also form a hierarchy with clear priority rules). This mapped very well to what I knew about CSS and to my experience in desktop publishing. But over time I became perfectly content with just setting attributes on an element directly and only resort to attribute sets when they came naturally as a time-saving technique. In old times people who wrote about UI emphasised “direct control”: users must feel they are in control of things that are happening on the computer, that they not just convince the computer to do something but can, for example, directly move a file from one place to another. This is an illusion, of course, but the one that gives the interface a very empowering quality. (Which becames more and more scarce nowadays.) As far as I understand Tailwind it gives the same feeling of direct control.

moritzwarhier 3y ago
Thank you, this was a good read and positively exhaustive. Especially the comparison with XSL-FO regarding the cascade: I never felt that tailwind abandoned the C in CSS entirely, it just encourages to limit its usage to a sane and transparent approach (as opposed to specificity wars)