7 ms·

Tailwind has been great and I've been looking forward to this for months. I fought Tailwind as a concept pretty hard at first, but after hearing Adam and a few

Tailwind has been great and I've been looking forward to this for months. I fought Tailwind as a concept pretty hard at first, but after hearing Adam and a few others raving about it I gave it a shot. It takes some getting used to at first but I can't imagine developing without it anymore. To me, the biggest benefit of Tailwind and utility classes in general is that it removes the cognitive overheard of having to think of class names while designing a new page. For example, if I'm working on a card and I want some text below the main text to have a smaller, gray font size. What do I name that class? "card-sub-text", "card-sub-title"? No - don't even worry about it - "text-sm text-gray-700" and move on. Later on, if I end up repeating that combination in a number of places, I have more context of what that class name really should be, and I can extract the utility classes to a specific class name. Really powerful stuff that has helped to increase my velocity quite a bit.

arcatek 7y ago
Disclaimer: I haven't used Tailwind. Maybe I'm missing something. > For example, if I'm working on a card and I want some text below the main text to have a smaller, gray font size. What do I name that class? "card-sub-text", "card-sub-title"? No - don't even worry about it - "text-sm text-gray-700" and move on. What's the difference with "color: gray; font-weight: 700"? In this case I really don't have to care about the property order, whereas in your case I would guess you still have the cognitive overhead requiring you to know that "gray" comes before "700" (unless it's expected to be preprocessed away? what if I use text-700-gray?).
- mike1o1 7y ago
  "text-sm" is just font-size and text-gray is a color code, so the order of the classes doesn't matter either. The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration. It takes some getting used to of the rules, but after a day or two I don't even need to think about what the class names are.
  - blattimwind 7y ago
    > The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration. But gray-700 says it's a 70 % gray. Changing it to something else is akin to changing "color: #666" to "color: #444" through redefinition (JS?).
    - mike1o1 7y ago
      No, "gray-700" doesn't mean it's 70% gray. The term "700" is just referring to a color on a scale. I don't even need to name it "700", I can name it "dark" or whatever I want (which is what previous versions of Tailwind used). i.e. "text-gray-dark", or "text-gray-700", would have a class with a single css property: color: #4A5568; By default Tailwind comes with a default color palette with hand picked colors. They were hand picked by a designer, not determined through an algorithm. https://tailwindcss.com/docs/customizing-colors#default-color-palette https://tailwindcss.com/docs/customizing-colors#default-colo...
      - deleted 7y ago
        [deleted]
      - stanmancan 7y ago
        The numbering name system makes it really easy to make incremental changes too. I can’t manually edit a hex to my liking, but I can easily change text-blue-500 to text-blue-600 if I want it a bit darker.
        6510 7y ago
        #000000 is black #FFFFFF is white They are 3 sets of 2 hex numbers. #FF0000 is red #00FF00 is green #0000FF is blue (you hear of RGB, Red Green Blue, in that order) Now if you want a darker color (closer to black) you lower FF to a lower value. A darker blue would for example be #0000AA if you want a lighter color you increase the other 2 color values. A lighter blue would be #2222FF If you don't like hex there is rgb(0,0,255) which does exactly the same. There is also rgba(0,0,255,0-1) with an alpha channel. You can also put any part of that in a css variable and use it where you like. body{--foo: 0,0,255,0.5; bar:0,0,100 } p {background: rgba(var(--foo)) } div {background: rgba(var(--bar), 0.8) }
- rymate1234 7y ago
  the 700 is a shade of gray not a font weight
- jaf656s 7y ago
  I have been using tailwind on a new project and I only see 3 real benefits over using inline css styles: 1) Sizes are standardized in a predetermined set of discrete size classes. So you start to think about sizes, padding, margins, etc in terms of steps instead of values. You can change the steps in one place and they apply globally. It's a little easier to standardize a rough style guide compared to starting from scratch. 2) Colors are standardized in a similar way. You just need to configure your app's core colors and then you can just think in terms of steps instead of color values. 3) You have a smaller set of "best practice" means to achieve most outcomes compared to all that's available with css. You don't need to know the best way to do what you want, you can just browse the documentation to find what you want. Outside of that, you still have to use @apply to collapse utility classes into more semantic classes if you want style changes to cascade (tailwind recommends using components or view partials to achieve this instead of via css classes, though this would work equally well with inline styles) The styles are very verbose, just like with inline styles. They are only slightly shorter than inline styles since they are basically abbreviated forms of inline styles. You can still do everything tailwind does for you by using your own style guide and building out css classes, but tailwind gives you a head start. It feels like it makes you more productive in the beginning because you get a toolset with a lot of decisions already made for you, but I suspect it will make things a bit slower as the app gets more complicated.
  - stefanfisk 7y ago
    I big benefit is that Tailwind supports media queries, while inline styles can't help you at all there.
    - jaf656s 7y ago
      oh yeah, I forgot about media queries. Which is impossible inline, but also adds to the verbosity
- dwild 7y ago
  Someone else mentioned this and as I'm not a Tailwind user either, it made me understood a bit more the principle. text-gray-700 is not a font-weight, it's a color predetermined by the framework. They aren't generated, they are hand picked by a designer. Each addition of 100 is a bit darker. https://tailwindcss.com/docs/customizing-colors/#default-color-palette https://tailwindcss.com/docs/customizing-colors/#default-col... So essentially, what's the difference between style="color: gray;" and class="text-gray-500" is mostly that you get a more beautiful gray (they add a bit of blue in it). I guess "text-sm" is also similar, with an hand picked size which appear nice on every device and can be considered "small text".
  - ChristianBundy 7y ago
    In that case, isn't that basically style="color: var(--gray-500);" with extra steps? I love to see people experiment for the sake of experimentation, but I'd be hesitant to adopt Tailwind as an engineer unless I understood why they weren't just CSS variables.
    - whelming_wave 7y ago
      For plain old `text-gray-500`, they're pretty similar. One advantage that Tailwind has is screen sizes - you might write `flex items-center justify-between mobile:flex-col` for a row that turns into a column on smaller screens where the UI becomes awkward, for example.
    - mike1o1 7y ago
      They are variables in that they're specified in your Tailwind configuration file, which is what generates the utility classes that are generated. If you really wanted to you, you can extract it out as a variable if you wanted to use that color elsewhere, such as part of a box-shadow or background color or something like that. .custom-bg-color { background-color: theme('colors.gray.500'); }
    - dwild 7y ago
      CSS variables are still relatively new though, unsupported until about March 2018 in all browsers, yet the first commit over TailwindCSS is from Jul 20, 2017, nearly a year before browsers even supported the feature. Even today it seems like 11% of users doesn't have support for variables. Could make sense to add support for variables now, but for the sake of backward compatibility, it does make sense to keep it with classnames too. I love though that as an engineer you would be hesitant to use Tailwind, but you are not aware of how new variables are. I think Tailwind seems to make sense for any prototypes works and probably even an MVP for a company that still doesn't have a shared CSS that represent the style of the company.
- zupa-hu 7y ago
  I think the key difference is that you can't use conditionals in style attributes. For example responsive variants, hover, focus, etc. `text-sm lg:text-lg` is something you simply can't do in style attributes. `text-gray-700` or `color: var(--mycolor-gray);` is indeed not _that_ much different. (I'm using CSS variables here to achieve the same as Tailwind variables.)
- cageface 7y ago
  Tailwind also gives you responsive prefixes so if you need different padding on mobile vs desktop it's easy to just use a lg:p-4, for example. You can't do this inline styles.
tomc1985 7y ago
How is that any different from setting CSS in the style attribute of your tag? What happens when you need to update all the "text-sm text-gray-700" to something else? Seems like a step backwards at worst and identical to Bootstrap/Foundation at best. Everyone provides class primitives like that What you're describing offends separation-of-concerns
- mike1o1 7y ago
  Typically the "text-sm text-gray-700" would be a one-off styling while I'm developing a page or a component, not necessarily something that will be repeated a hundred times. If it turns out that later down the line I realize that "every card should have that size and color for the card title", then I'll pull it out to a separate class or part of a partial or something like that. The idea being at that point then I have more context around when and how that particular section of a component should be displayed, so I have more context about what I should name the class (i.e. "card-subtitle"). I feel like the documentation explains it fairly well if you're interested in reading more about it: https://tailwindcss.com/docs/extracting-components#extracting-css-components-with-apply https://tailwindcss.com/docs/extracting-components#extractin...
  - pests 7y ago
    My question is why you cant just name the card and then use selectors to style the title or any other internal styling? This removes the need to name at all. It can just be .card > h2 or whatever and there you would do your font-weight and color.
    - mike1o1 7y ago
      Because I don't want that cognitive overhead of even thinking about what the selector should be. Then what if I have another sub-sub text? Do I make that an h3? An h4? I don't want to have to think about that. I just make it "text-xs" and move on. I don't even need to move over to my css file at all - I stay within my template and stay within my flow. It seems crazy and counter-intuitive at first, but I find that it makes me a lot more productive.
aschismatic 7y ago
I first took a look at Tailwind CSS a year ago and liked it. However, when I started using its flexbox classes I noticed it was missing one for align-content: space-between (or space-evenly, I can't recall precisely). Thankfully it looks as though those utility classes have since been added [0], however, at the time it made me hesitant to adopt Tailwind because it made me wonder how many other basic property-value pairs were not yet implemented as classes. Maybe that's a stupid reason to have given up on it, but it's just how I felt at that point in time. Do you feel Tailwind has mostly improved with since you started using it? [0] https://tailwindcss.com/docs/align-content https://tailwindcss.com/docs/align-content

arcatek 7y ago

Disclaimer: I haven't used Tailwind. Maybe I'm missing something. > For example, if I'm working on a card and I want some text below the main text to have a smaller, gray font size. What do I name that class? "card-sub-text", "card-sub-title"? No - don't even worry about it - "text-sm text-gray-700" and move on. What's the difference with "color: gray; font-weight: 700"? In this case I really don't have to care about the property order, whereas in your case I would guess you still have the cognitive overhead requiring you to know that "gray" comes before "700" (unless it's expected to be preprocessed away? what if I use text-700-gray?).

mike1o1 7y ago
"text-sm" is just font-size and text-gray is a color code, so the order of the classes doesn't matter either. The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration. It takes some getting used to of the rules, but after a day or two I don't even need to think about what the class names are.
- blattimwind 7y ago
  > The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration. But gray-700 says it's a 70 % gray. Changing it to something else is akin to changing "color: #666" to "color: #444" through redefinition (JS?).
  - mike1o1 7y ago
    No, "gray-700" doesn't mean it's 70% gray. The term "700" is just referring to a color on a scale. I don't even need to name it "700", I can name it "dark" or whatever I want (which is what previous versions of Tailwind used). i.e. "text-gray-dark", or "text-gray-700", would have a class with a single css property: color: #4A5568; By default Tailwind comes with a default color palette with hand picked colors. They were hand picked by a designer, not determined through an algorithm. https://tailwindcss.com/docs/customizing-colors#default-color-palette https://tailwindcss.com/docs/customizing-colors#default-colo...
    - deleted 7y ago
      [deleted]
    - stanmancan 7y ago
      The numbering name system makes it really easy to make incremental changes too. I can’t manually edit a hex to my liking, but I can easily change text-blue-500 to text-blue-600 if I want it a bit darker.
      - 6510 7y ago
        #000000 is black #FFFFFF is white They are 3 sets of 2 hex numbers. #FF0000 is red #00FF00 is green #0000FF is blue (you hear of RGB, Red Green Blue, in that order) Now if you want a darker color (closer to black) you lower FF to a lower value. A darker blue would for example be #0000AA if you want a lighter color you increase the other 2 color values. A lighter blue would be #2222FF If you don't like hex there is rgb(0,0,255) which does exactly the same. There is also rgba(0,0,255,0-1) with an alpha channel. You can also put any part of that in a css variable and use it where you like. body{--foo: 0,0,255,0.5; bar:0,0,100 } p {background: rgba(var(--foo)) } div {background: rgba(var(--bar), 0.8) }
rymate1234 7y ago
the 700 is a shade of gray not a font weight
jaf656s 7y ago
I have been using tailwind on a new project and I only see 3 real benefits over using inline css styles: 1) Sizes are standardized in a predetermined set of discrete size classes. So you start to think about sizes, padding, margins, etc in terms of steps instead of values. You can change the steps in one place and they apply globally. It's a little easier to standardize a rough style guide compared to starting from scratch. 2) Colors are standardized in a similar way. You just need to configure your app's core colors and then you can just think in terms of steps instead of color values. 3) You have a smaller set of "best practice" means to achieve most outcomes compared to all that's available with css. You don't need to know the best way to do what you want, you can just browse the documentation to find what you want. Outside of that, you still have to use @apply to collapse utility classes into more semantic classes if you want style changes to cascade (tailwind recommends using components or view partials to achieve this instead of via css classes, though this would work equally well with inline styles) The styles are very verbose, just like with inline styles. They are only slightly shorter than inline styles since they are basically abbreviated forms of inline styles. You can still do everything tailwind does for you by using your own style guide and building out css classes, but tailwind gives you a head start. It feels like it makes you more productive in the beginning because you get a toolset with a lot of decisions already made for you, but I suspect it will make things a bit slower as the app gets more complicated.
- stefanfisk 7y ago
  I big benefit is that Tailwind supports media queries, while inline styles can't help you at all there.
  - jaf656s 7y ago
    oh yeah, I forgot about media queries. Which is impossible inline, but also adds to the verbosity
dwild 7y ago
Someone else mentioned this and as I'm not a Tailwind user either, it made me understood a bit more the principle. text-gray-700 is not a font-weight, it's a color predetermined by the framework. They aren't generated, they are hand picked by a designer. Each addition of 100 is a bit darker. https://tailwindcss.com/docs/customizing-colors/#default-color-palette https://tailwindcss.com/docs/customizing-colors/#default-col... So essentially, what's the difference between style="color: gray;" and class="text-gray-500" is mostly that you get a more beautiful gray (they add a bit of blue in it). I guess "text-sm" is also similar, with an hand picked size which appear nice on every device and can be considered "small text".
- ChristianBundy 7y ago
  In that case, isn't that basically style="color: var(--gray-500);" with extra steps? I love to see people experiment for the sake of experimentation, but I'd be hesitant to adopt Tailwind as an engineer unless I understood why they weren't just CSS variables.
  - whelming_wave 7y ago
    For plain old `text-gray-500`, they're pretty similar. One advantage that Tailwind has is screen sizes - you might write `flex items-center justify-between mobile:flex-col` for a row that turns into a column on smaller screens where the UI becomes awkward, for example.
  - mike1o1 7y ago
    They are variables in that they're specified in your Tailwind configuration file, which is what generates the utility classes that are generated. If you really wanted to you, you can extract it out as a variable if you wanted to use that color elsewhere, such as part of a box-shadow or background color or something like that. .custom-bg-color { background-color: theme('colors.gray.500'); }
  - dwild 7y ago
    CSS variables are still relatively new though, unsupported until about March 2018 in all browsers, yet the first commit over TailwindCSS is from Jul 20, 2017, nearly a year before browsers even supported the feature. Even today it seems like 11% of users doesn't have support for variables. Could make sense to add support for variables now, but for the sake of backward compatibility, it does make sense to keep it with classnames too. I love though that as an engineer you would be hesitant to use Tailwind, but you are not aware of how new variables are. I think Tailwind seems to make sense for any prototypes works and probably even an MVP for a company that still doesn't have a shared CSS that represent the style of the company.
zupa-hu 7y ago
I think the key difference is that you can't use conditionals in style attributes. For example responsive variants, hover, focus, etc. `text-sm lg:text-lg` is something you simply can't do in style attributes. `text-gray-700` or `color: var(--mycolor-gray);` is indeed not _that_ much different. (I'm using CSS variables here to achieve the same as Tailwind variables.)
cageface 7y ago
Tailwind also gives you responsive prefixes so if you need different padding on mobile vs desktop it's easy to just use a lg:p-4, for example. You can't do this inline styles.

tomc1985 7y ago

How is that any different from setting CSS in the style attribute of your tag? What happens when you need to update all the "text-sm text-gray-700" to something else? Seems like a step backwards at worst and identical to Bootstrap/Foundation at best. Everyone provides class primitives like that What you're describing offends separation-of-concerns

mike1o1 7y ago
Typically the "text-sm text-gray-700" would be a one-off styling while I'm developing a page or a component, not necessarily something that will be repeated a hundred times. If it turns out that later down the line I realize that "every card should have that size and color for the card title", then I'll pull it out to a separate class or part of a partial or something like that. The idea being at that point then I have more context around when and how that particular section of a component should be displayed, so I have more context about what I should name the class (i.e. "card-subtitle"). I feel like the documentation explains it fairly well if you're interested in reading more about it: https://tailwindcss.com/docs/extracting-components#extracting-css-components-with-apply https://tailwindcss.com/docs/extracting-components#extractin...
- pests 7y ago
  My question is why you cant just name the card and then use selectors to style the title or any other internal styling? This removes the need to name at all. It can just be .card > h2 or whatever and there you would do your font-weight and color.
  - mike1o1 7y ago
    Because I don't want that cognitive overhead of even thinking about what the selector should be. Then what if I have another sub-sub text? Do I make that an h3? An h4? I don't want to have to think about that. I just make it "text-xs" and move on. I don't even need to move over to my css file at all - I stay within my template and stay within my flow. It seems crazy and counter-intuitive at first, but I find that it makes me a lot more productive.

aschismatic 7y ago

I first took a look at Tailwind CSS a year ago and liked it. However, when I started using its flexbox classes I noticed it was missing one for align-content: space-between (or space-evenly, I can't recall precisely). Thankfully it looks as though those utility classes have since been added [0], however, at the time it made me hesitant to adopt Tailwind because it made me wonder how many other basic property-value pairs were not yet implemented as classes. Maybe that's a stupid reason to have given up on it, but it's just how I felt at that point in time. Do you feel Tailwind has mostly improved with since you started using it? [0] https://tailwindcss.com/docs/align-content https://tailwindcss.com/docs/align-content