Before Tailwind came along I very often found myself just wanting to put some inline styling in various places. It's so much easier to just add some CSS to an element than having to think of a class name, think of where the best place would be to put the class, etc.
Unlike the yet-another umpteenth bespoke `.card-header__buttons .card-header__button--secondary` that no one can remember and create an umpteenth+1
Tailwind works great when your site/app is a collection of components
So why bother with a DSL like Tailwind over Component CSS/SCSS for example?
Everywhere I've seen CSS-in-JS used, everywhere it's people busy writing bespoke styles in every file.
I may run into the same issues as the other CSS-in-JS solutions (I only encountered stitch once, and not for a long period of time)
Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style
The link literally has this:
``` export const className = style({ display: 'flex', flexDirection: 'column', selectors: { '&:nth-child(2n)': { background: 'aliceblue' } }, '@media': { 'screen and (min-width: 768px)': { flexDirection: 'row' } } }); ```
Which is indistinguishable from any other CSS-in-JS which has hundreds of these one-off things scattered everywhere. With a theme somewhere exposing another hundred or so variables of varing quality. And all these solutions basically converge on Tailwind (or other utility-first CSS approaches):
``` export const hero = style({ backgroundColor: vars.color.brandd, color: vars.color.white, padding: vars.space.large }); ```
is nothing more than `bg-brand color-white p-4`
But TypeScript support is definitely nice.
Re-typing/re-quoting:
--------
The link literally has this:
export const className = style({
display: 'flex',
flexDirection: 'column',
selectors: {
'&:nth-child(2n)': {
background: 'aliceblue'
}
},
'@media': {
'screen and (min-width: 768px)': {
flexDirection: 'row'
}
}
});
Which is indistinguishable from any other CSS-in-JS which has hundreds of these one-off things scattered everywhere. With a theme somewhere exposing another hundred or so variables of varing quality. And all these solutions basically converge on Tailwind (or other utility-first CSS approaches): export const hero = style({
backgroundColor: vars.color.brandd,
color: vars.color.white,
padding: vars.space.large
});
is nothing more than `bg-brand color-white p-4`But TypeScript support is definitely nice.
----
/// Define variants for a specific component, such as a button
export const button = recipe({
base: {
borderRadius: 6
},
variants: {
color: {
neutral: { background: 'whitesmoke' },
brand: { background: 'blueviolet' },
accent: { background: 'slateblue' }
},
size: {
small: { padding: 12 },
medium: { padding: 16 },
large: { padding: 24 }
},
rounded: {
true: { borderRadius: 999 }
}
},
// Applied when multiple variants are set at once
compoundVariants: [
{
variants: {
color: 'neutral',
size: 'large'
},
style: {
background: 'ghostwhite'
}
}
],
defaultVariants: {
color: 'accent',
size: 'medium'
}
});
/// Use in code
<button className={
button({
color: 'accent',
size: 'large',
rounded: true
})
}>
Hello world
</button>
Basically, unlike other CSS-in-JS libraries, you can encode your design system into something called variants, then you use them by calling the function `button()` to generate a class name.Notice how `button()` takes in certain properties and only those properties with their corresponding values (enforced by TypeScript). If you try to put in `button({ color2: 'testColor', ...})`, TS won't compile.
In this way, you can take the design team's ButtonSmall, ButtonLarge, NeutralButtonLarge etc and codify them into TypeScript such that you literally can't make a mistake. You simply can't do that in Tailwind, unless you use some outside plugin I assume.
(Note that VE also has a Tailwind-like atomic CSS API called Sprinkles, but since I don't like Tailwind I don't use this either).
I prefer a global set of styles and more specific selectors to override styles where needed. It may not work well on projects with many teams but for the projects I typically work on it's fine.
The thing with Tailwinf is that it already has a decent design syste encoded in its utility classes. It's very easy to slap a p-2 for a standardized padding than trying to remember what it was when you write the next component with `{ padding: 2 2 2 2 }`
> I prefer a global set of styles and more specific selectors to override styles where needed.
That's kinda what I mean. In all projects I've seen you have a global stylesheet with a bunch of classes that no one remembers, and hundreds of one-ofs in every component either reimplementing stuff from scratch or serving as an `!important` of sorts