4 ms·

I'm talking about the design aesthetics included in Tailwind as default. Keep the values and the names if you want. Like this, for example: "blue-500" becomes

I'm talking about the design aesthetics included in Tailwind as default. Keep the values and the names if you want. Like this, for example: "blue-500" becomes --blue-500. That's it. This is a far cry from using Tailwind as a whole while keeping the good-looking aesthetics.

troupo 3y ago
> "blue-500" becomes --blue-500. That's it. Of course it's not "it". Now in every class that needs it, you also need to add { ... other styles... background-color: var(--blue-500); } And then you need to apply that class
- emmacharp 3y ago
  How is that different than writing "bg-color-blue-500" in every component that needs it? As for the class, it's the name of the component, the same name you give to the component file. Does it really add that much work? Correct me if I'm wrong but as I see it, that's literally a couple of seconds of "work".
ethanbond 3y ago
Sure now do the same for: whitespace (margins and padding), border radiuses, shadows, opacities, font sizes, font weights, and continue playing whack-a-mole as you run into new cases. Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set of classes that took you zero hours of initial setup and will cost you zero hours of maintenance outside of your own use/application until the end of time. And it has a name so when a new engineer joins your team, you can say "we use Tailwind, go to tailwindcss.com" and they are fully read into your setup in about 15 seconds.
- emmacharp 3y ago
  mt-100 vs. margin-top: var(--100); And the IDE will help you autocomplete it all. The same is true for all the other properties you enumerated. If it's a Tailwind design token, it can be a pure CSS design token. No "whack-a-mole" needed here. Still, you're right about having documentation. And there has been a loooot of these kinds of doc (BEM, SMACSS, ITCSS, etc.) in the last 15 years. Nonetheless, a more modern-oriented one is indeed needed. And that's why I'm working on something like this. As for the "15 seconds", I mean, really? If so, I beg to disagree. There is a lot to take in. And that is why numerous colleagues still have to open the Tailwind docs to know how to write a class that's not 1:1 CSS. And lucky you if you haven't had any update and dependency issues in the medium to long term. But I know we had. > Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set "of CSS features". The sentence above is every bit as true as yours. Add a beautiful design language and you are in business.

troupo 3y ago

> "blue-500" becomes --blue-500. That's it. Of course it's not "it". Now in every class that needs it, you also need to add { ... other styles... background-color: var(--blue-500); } And then you need to apply that class

emmacharp 3y ago
How is that different than writing "bg-color-blue-500" in every component that needs it? As for the class, it's the name of the component, the same name you give to the component file. Does it really add that much work? Correct me if I'm wrong but as I see it, that's literally a couple of seconds of "work".

ethanbond 3y ago

Sure now do the same for: whitespace (margins and padding), border radiuses, shadows, opacities, font sizes, font weights, and continue playing whack-a-mole as you run into new cases. Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set of classes that took you zero hours of initial setup and will cost you zero hours of maintenance outside of your own use/application until the end of time. And it has a name so when a new engineer joins your team, you can say "we use Tailwind, go to tailwindcss.com" and they are fully read into your setup in about 15 seconds.

emmacharp 3y ago
mt-100 vs. margin-top: var(--100); And the IDE will help you autocomplete it all. The same is true for all the other properties you enumerated. If it's a Tailwind design token, it can be a pure CSS design token. No "whack-a-mole" needed here. Still, you're right about having documentation. And there has been a loooot of these kinds of doc (BEM, SMACSS, ITCSS, etc.) in the last 15 years. Nonetheless, a more modern-oriented one is indeed needed. And that's why I'm working on something like this. As for the "15 seconds", I mean, really? If so, I beg to disagree. There is a lot to take in. And that is why numerous colleagues still have to open the Tailwind docs to know how to write a class that's not 1:1 CSS. And lucky you if you haven't had any update and dependency issues in the medium to long term. But I know we had. > Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set "of CSS features". The sentence above is every bit as true as yours. Add a beautiful design language and you are in business.