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?).
"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.
(Also not a Tailwind user) I guess the common response to this is that well chosen semantic names usually help later down the line after these kinds of changes happen, especially with devs coming in and out.
I've actually come across C code that had "#define ONE_THOUSAND_TWENTY_FOUR 4096" because that was the audio buffer size and later had to be increased to 4096 but the macro name was never changed. AUDIO_BUFFER_SIZE would probably have been a better name in the first place.
Most code is not that bad though, haha. But that is still my first reaction. What if instead of slightly changing the gray color, you now want them to be blue and underlined? Or take HN for example, the username, vote buttons, and timestamp are all #828282, but have different class names. Is keeping this in sync ever a problem in Tailwind? This is only my first time looking at Tailwind, but it seems it's not really meant for "complex" apps where you'd run into these problems often?
If I wanted to change all links from gray to blue/underlined, the best practice there would probably be to use a different utility class (text-blue-500 and underline) and update my templates/partials/whatever.
I think for your specific example, I would use the `@apply` directive to apply certain utilities to all links.
I've used Tailwind on large, complex apps with around 50 screens (so far), and using extracted components or partials hasn't been a problem at all with keeping things in sync.
```
a {
@apply text-gray-700;
}
// now becomes
a {
@apply text-blue-500 underline;
}
```
The documentation goes over this pretty well, I think.
What if I had two types of links, both of which were currently "text-blue-500 and underline" but I wanted to make one italics at some time in the future?
> 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?).
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.
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.
Sure, but the colors from Tailwind aren't determined through an algorithm like this. They are handpicked from a designer, which I feel like most design systems do as well.
RGB isn't even a good system to lighten or darken colors. CSS supports HSL which is certainly more intuitive. Then again, it's easier to use a good pre-processor with color functions to darken($color, 10%) and so on (quickly, can you tell me what is 10% lighter than 2222FF off the top of your head?).
Still, in the end it makes most sense to use tones from a good color palette then to mess around with hex values.
> 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.
This sounds like a boldRedText pattern to me [1]. I get the idea of adding utility classes that inherit the base classes, but altering the definition of the "gray" class to be some other color feels wrong.
gray-700 isn't really 70% gray though, it's a darker gray than gray-600 and a lighter gray than gray-800. It also contains a bit more blue in it, which is actually quite common to do with gray.
In reality I'm pretty sure that you wouldn't alter it directly either and that if you do, you would try to keep the 10 versions of it somewhat linear, or at least consistent with the use that you do of it. Theses colors are there for prototyping quickly yet still offering good looking result. Sure "color: gray" works, but look at the colors choices [1], it's much better than the default gray and offer more choice than lightgray, gray and darkgray without having to do math over #808080.
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.
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.
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".
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.
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.
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.
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.
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.)
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.
> 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?).