6 ms·

It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup. That's

It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup. That's exactly what it is. But... you have to do that regardless of what you use for CSS layout. If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remember what you called them. Hopefully you're good at that and you can remember, else you'll duplicate things. Hopefully your entire team are aligned on the same naming conventions, or your project's styles will be a total mess. Maybe you'll use styled-components or another CSS-in-JS solution, which helps a bit by making your styles scoped to components so they don't interfere with things outside of where they should, but then you'll have to keep a set of constants to use across all of them anyway, which puts you back at the same problem as plain CSS - you need to remember what's been set, and not duplicate things. Ultimately, Tailwind is a really well designed abstraction of inline styles that means you don't have to worry about inconsistency and duplication of things any more. It's another thing to learn but because it's so similar to raw CSS it's not actually a lot of effort. It works well.

the_other 4y ago
> If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remember what you called them. This is true. But if we better taught the cascade and promoted the idea of global styles rather than pretending it's a problem then more people would be better at this and the problems would gently recede. We (the high-end front-end dev community) have fallen into the habit of using class names where we really wanted IDs and using components when we really wanted global styles. I feel we have been pushed in this direction by developers who didn't understand the technology properly. The Tailwind author clearly understands it, so I'm not targeting them... but they are supporting the people who don't see why the cascade is useful. We have megabytes of code to create the impression of global consistency (components, style libraries, CSS-modules...) shipped to millions of users every hour. Browsers do that for us already. Embrace the simplicity of button { border: foo; color: bar; } .callout button { color: aux; } It's so clear, so elegant. The obsession with modularising everything, and then applying a DSL to get between the modules, makes the language's inherent convenience, elegance and clarity so much harder to work with that it boggles my mind.
- andiareso 4y ago
  But this isn't much different than: <Button class=`border text-gray ${override}`/> <CalloutButton /> extends <Button override="text-blue" /> I'd argue you have less markup to write overall if you are modularizing component logic/styling
  - deleted 4y ago
    [deleted]
  - LouisSayers 4y ago
    And what about your :hover, ::before etc, where do you put those? (genuinely curious)
    - timdorr 4y ago
      Those have utility classes: https://tailwindcss.com/docs/hover-focus-and-other-states https://tailwindcss.com/docs/hover-focus-and-other-states
    - seek 4y ago
      Tailwind supports those https://tailwindcss.com/docs/hover-focus-and-other-states#hover-focus-and-active https://tailwindcss.com/docs/hover-focus-and-other-states#ho... https://tailwindcss.com/docs/hover-focus-and-other-states#before-and-after https://tailwindcss.com/docs/hover-focus-and-other-states#be...
  - meowtimemania 4y ago
    One gripe I have with tailwind, is overriding styles is difficult. The .text-blue style will only override .text-gray if it is declared later in the css document. for example if the corresponding css file is this: .text-blue { color: blue; } .text-gray { color: gray; } Then in your above example, both Button and CalloutButton will have gray text because .test-gray has higher specificity than .text-blue
  - xigoi 4y ago
    The difference is that your website will be much larger and won't work without JavaScript.
blain_the_train 4y ago
> you're going to end up creating classes using the raw CSS A program can read what looks like inline css and produce class names for youand put those in class files. When developing your see "height 20px" In your app its compiled to "h-20" with a css file "h-20: height 20" This is better because you don't have to learn another way to express the same logic.
- pythonaut_16 4y ago
  So Tailwind with more steps
- xigoi 4y ago
  Why not use actual inline CSS instead of that?
dangerface 4y ago
It seems like the main advantage of tailwind is that you don't have to learn how CSS cascading and specificity works, which is a fair advantage as most frontend developers I talk to don't even realise that specificity is a thing. I don't see the advantage over inline style tho. I see abbreviations as a disadvantage as its just as fast to type background as it is bg but background is clearly more intelligible. How do you deal with side effects for example I think bg-red is the brand red but some one has modified that class so it now has a border. You could prevent this with convention but then you have the same issues as using css with specificity and people not understanding the conventions around it. I think its easier for every one to just force your frontend developers to just learn CSS and use it.
- tomtheelder 4y ago
  Tailwind is actually a lot like inline styles in certain ways. Whether that's a good thing or not depends on your use case. If you are using a component based framework it ends up, IMO, being way better and less complicated to use the abstraction you already have, your components, as your styling abstraction rather than trying to layer a second abstraction (the cascade approach) on top of it. The biggest advantage over inline styles is that you are constrained. The idea is that you set up the primitives for your application's styling system: which colors are in use, which font weights, all the way to things like which border radii are valid. Your devs can then only use those. You are correct that theoretically you can modify them to do anything, but in practice I find that people are extremely unlikely to violate the scheme (in ways like you described, adding a border to bg-red). As for abbreviations? I think that's probably just eye of the beholder. Since you tend to add a lot of these to your HTML it helps it not get too ridiculously out of hand. I spent years working with more traditional CSS schemes (including my all time least favorite, BEM), and it was pretty consistently a nightmare within the context of component driven applications. For a while now I've worked with tailwind and it feels like a massive step in the right direction. I think it's one of those things that really doesn't make sense until you try it and feel the difference for yourself.
- teen 4y ago
  Tailwind has a lot of advantages if you read the documentation rather than conjecture about what you think it might do.
calvinmorrison 4y ago
> That's exactly what it is. Which is why this is basically reinventing inline styles. With some shorthand. How did we go from removing <u> and <b> to calling it <div class="bold" an improvement?
- tomtheelder 4y ago
  It's a lot like inline styles. The big advantage is that you create a design language with the helper classes, and then your devs are constrained to use it. No one can add a border radius of 11 if you only have utility classes for 8 and 16, or whatever. Historically you couldn't do that if you were using inline styles. You could do it with a cascading approach, but if you're building a component based application (this is what Tailwind is really for) then you already have an abstraction for re-usability. Trying to layer another one on top usually results in a really difficult to reason about mess of interlacing components and style classes. In short it's a way to use an inline-type styling approach, which is suitable for component based apps, without giving up the ability to constrain developers to a limited design language. There are a TON of other benefits for utility classes over inline, but I think what I described is the biggest one (media queries, pseudo selectors, stylesheet caching for reduced page load, etc.) > How did we go from removing <u> and <b> to calling it <div class="bold" an improvement? You can still use <u> and <b> if you want to. Adding a utility bold class also works fine.
azangru 4y ago
> Hopefully you're good at that and you can remember, else you'll duplicate things. Hopefully your entire team are aligned on the same naming conventions, or your project's styles will be a total mess. - CSS classes can be named on a per-component basis, according to one of the well-established naming conventions (BEM, SMACSS, or whatever). This does not require remembering the names of other classes. - With the arrival of web components, styles can be scoped within the shadow DOM; and the name collision becomes a non-issue; as well as keeping track of _all_ the CSS that's written in the project. If CSS classes don't leak, you can focus your attention only on a given component and ignore the rest. - Instead of CSS-in-JS, one could use CSS modules, which are just regular CSS with a build step. The relevant project-level (site-level, page-level) constants can be defined as CSS constants on the root element.
- holler 4y ago
  my thought exactly, sometimes I wonder when reading about tailwind... naming css classes has been a problem exactly 0 times in recent memory...

the_other 4y ago

> If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remember what you called them. This is true. But if we better taught the cascade and promoted the idea of global styles rather than pretending it's a problem then more people would be better at this and the problems would gently recede. We (the high-end front-end dev community) have fallen into the habit of using class names where we really wanted IDs and using components when we really wanted global styles. I feel we have been pushed in this direction by developers who didn't understand the technology properly. The Tailwind author clearly understands it, so I'm not targeting them... but they are supporting the people who don't see why the cascade is useful. We have megabytes of code to create the impression of global consistency (components, style libraries, CSS-modules...) shipped to millions of users every hour. Browsers do that for us already. Embrace the simplicity of button { border: foo; color: bar; } .callout button { color: aux; } It's so clear, so elegant. The obsession with modularising everything, and then applying a DSL to get between the modules, makes the language's inherent convenience, elegance and clarity so much harder to work with that it boggles my mind.

andiareso 4y ago
But this isn't much different than: <Button class=`border text-gray ${override}`/> <CalloutButton /> extends <Button override="text-blue" /> I'd argue you have less markup to write overall if you are modularizing component logic/styling
- deleted 4y ago
  [deleted]
- LouisSayers 4y ago
  And what about your :hover, ::before etc, where do you put those? (genuinely curious)
  - timdorr 4y ago
    Those have utility classes: https://tailwindcss.com/docs/hover-focus-and-other-states https://tailwindcss.com/docs/hover-focus-and-other-states
  - seek 4y ago
    Tailwind supports those https://tailwindcss.com/docs/hover-focus-and-other-states#hover-focus-and-active https://tailwindcss.com/docs/hover-focus-and-other-states#ho... https://tailwindcss.com/docs/hover-focus-and-other-states#before-and-after https://tailwindcss.com/docs/hover-focus-and-other-states#be...
- meowtimemania 4y ago
  One gripe I have with tailwind, is overriding styles is difficult. The .text-blue style will only override .text-gray if it is declared later in the css document. for example if the corresponding css file is this: .text-blue { color: blue; } .text-gray { color: gray; } Then in your above example, both Button and CalloutButton will have gray text because .test-gray has higher specificity than .text-blue
- xigoi 4y ago
  The difference is that your website will be much larger and won't work without JavaScript.

blain_the_train 4y ago

> you're going to end up creating classes using the raw CSS A program can read what looks like inline css and produce class names for youand put those in class files. When developing your see "height 20px" In your app its compiled to "h-20" with a css file "h-20: height 20" This is better because you don't have to learn another way to express the same logic.

pythonaut_16 4y ago
So Tailwind with more steps
xigoi 4y ago
Why not use actual inline CSS instead of that?

dangerface 4y ago

It seems like the main advantage of tailwind is that you don't have to learn how CSS cascading and specificity works, which is a fair advantage as most frontend developers I talk to don't even realise that specificity is a thing. I don't see the advantage over inline style tho. I see abbreviations as a disadvantage as its just as fast to type background as it is bg but background is clearly more intelligible. How do you deal with side effects for example I think bg-red is the brand red but some one has modified that class so it now has a border. You could prevent this with convention but then you have the same issues as using css with specificity and people not understanding the conventions around it. I think its easier for every one to just force your frontend developers to just learn CSS and use it.

tomtheelder 4y ago
Tailwind is actually a lot like inline styles in certain ways. Whether that's a good thing or not depends on your use case. If you are using a component based framework it ends up, IMO, being way better and less complicated to use the abstraction you already have, your components, as your styling abstraction rather than trying to layer a second abstraction (the cascade approach) on top of it. The biggest advantage over inline styles is that you are constrained. The idea is that you set up the primitives for your application's styling system: which colors are in use, which font weights, all the way to things like which border radii are valid. Your devs can then only use those. You are correct that theoretically you can modify them to do anything, but in practice I find that people are extremely unlikely to violate the scheme (in ways like you described, adding a border to bg-red). As for abbreviations? I think that's probably just eye of the beholder. Since you tend to add a lot of these to your HTML it helps it not get too ridiculously out of hand. I spent years working with more traditional CSS schemes (including my all time least favorite, BEM), and it was pretty consistently a nightmare within the context of component driven applications. For a while now I've worked with tailwind and it feels like a massive step in the right direction. I think it's one of those things that really doesn't make sense until you try it and feel the difference for yourself.
teen 4y ago
Tailwind has a lot of advantages if you read the documentation rather than conjecture about what you think it might do.

calvinmorrison 4y ago

> That's exactly what it is. Which is why this is basically reinventing inline styles. With some shorthand. How did we go from removing <u> and <b> to calling it <div class="bold" an improvement?

tomtheelder 4y ago
It's a lot like inline styles. The big advantage is that you create a design language with the helper classes, and then your devs are constrained to use it. No one can add a border radius of 11 if you only have utility classes for 8 and 16, or whatever. Historically you couldn't do that if you were using inline styles. You could do it with a cascading approach, but if you're building a component based application (this is what Tailwind is really for) then you already have an abstraction for re-usability. Trying to layer another one on top usually results in a really difficult to reason about mess of interlacing components and style classes. In short it's a way to use an inline-type styling approach, which is suitable for component based apps, without giving up the ability to constrain developers to a limited design language. There are a TON of other benefits for utility classes over inline, but I think what I described is the biggest one (media queries, pseudo selectors, stylesheet caching for reduced page load, etc.) > How did we go from removing <u> and <b> to calling it <div class="bold" an improvement? You can still use <u> and <b> if you want to. Adding a utility bold class also works fine.

azangru 4y ago

> Hopefully you're good at that and you can remember, else you'll duplicate things. Hopefully your entire team are aligned on the same naming conventions, or your project's styles will be a total mess. - CSS classes can be named on a per-component basis, according to one of the well-established naming conventions (BEM, SMACSS, or whatever). This does not require remembering the names of other classes. - With the arrival of web components, styles can be scoped within the shadow DOM; and the name collision becomes a non-issue; as well as keeping track of _all_ the CSS that's written in the project. If CSS classes don't leak, you can focus your attention only on a given component and ignore the rest. - Instead of CSS-in-JS, one could use CSS modules, which are just regular CSS with a build step. The relevant project-level (site-level, page-level) constants can be defined as CSS constants on the root element.

holler 4y ago
my thought exactly, sometimes I wonder when reading about tailwind... naming css classes has been a problem exactly 0 times in recent memory...