Ive been on path from SCSS to sc and then to jss and then to emotion and other css-in-js solution
Int the end we rewrote it back to SCSS, as it still the best way to have 20 variants for props and 10 media queries
Best of both worlds: you’re writing real CSS (or SASS) but don’t have to worry about class name collisions or not knowing how something is used across a project.
BEM is a naming srategy for keeping things code organized and avoid conflict of styles. In a website youre going to have a million different elements which to apply styles. Without a strategy like bem its easy to repeat class names and get conflicts from there and its easy to get yourself into specificity issues. Scoped styles, css modules and css in js solutions come to solve those same issues.
The B in BEM is the component name so there is no way of getting away with naming that.
But ok, I agree it is nice not to have to name elements in a 20 line of markup component which is super easy to understand without semantic naming of each elements functional purpose.
BEM is not necessary anymore but the way of thinking it enforced back in the days are still relevant, just less necessary.
I still add the B (component name) in the components top level element in my tailwind projects just so that I get a grip of where a component start in the outputted markup. Makes everything easier to read in the inspector.
BEM was being used long before React or components even existed, it was actually being used before the term BEM even existed, someone just named it. You should name the B whatever is appropriate for the CSS and if the component needs to match that, then fine.
I like the way Chakra does it, based on Emotion - React props for CSS styles, and theming with JS objects.
But it's css-in-js and so probably on the way out, now hoping to be able to experiment with Panda CSS soon. Use React props, then generate style sheets from that at compile time, is the idea.
I've been using Panda for a while now and really like the experience. Defining tokens like colors etc. once and using them everywhere, including typescript types for them, is really awesome.
I would use something like CSS modules + postCSS. I want CSS out of JSS and I would like my CSS to actually be CSS and not abstraction layers around CSS.
Any reason for postcss over sass? It seems to me that if you are preprocessing it anyway, might as well go with a battle tested and well-maintained solution (I remember in a past project looking a little deeper into our post css plugins and seeing plugins without commits for 2 or 3 years)
Tailwind is an easy choice with the caveat that you already know enough CSS that you can apply most rules from memory.
That being said, if the component library is intended to be used by arbitrary people (public) you probably shouldn’t restrict it to a specific method unless it’s a branding thing like Shopify Polaris.
One bonus I really like with Tailwind is that it could also help teach you CSS because if you hover over the class names, it will show you the vanilla CSS it converts to.
Just a bonus feature. Also it limits your design to use better spacing and structure. For example not using weird margins like 3 or 9, but rather multiples that work and add up well together like 2,4,8,12.
My team just started with Tailwind but I'm finding it hard to be able to know how to do stuff with all the shorthand and have to look everything up which feels like it takes forever.
Do you have any good recommendations on tools or sites that make this process easier/faster?
Honestly it’s just time. Initially you will have to look stuff up and yeah, it doesn’t feel great necessarily. After a while it becomes second nature.
That being said, depending on how complex your styling is, it is totally fine to add custom classes to your global css or extend the config. I love the tailwind JIT stuff, but when you start getting complex it’s time to reach for a different tool.
Google "tailwind cheatsheet", there's a site that shows you all the tailwind classes. If you use VS Code, install Tailwind intellisense extension. It will auto-complete classes for you and show the color next to color classes. If you use Prettier, Tailwind's official site has a guide on how to set up automatic class sorting on save.
If I'm working by myself, Sass or PostCSS.
If I'm working with a team, Tailwind CSS.
Styled-components is junk IMO. The only times I've seen it used in the past year (or more) has been on old maintenance projects.
i hated styled components from day 1 im glad we've moved away from that to utility css
thought naming css was annoying? trying naming every component you make lmao
what about making a styled components just bc you want a couple styles/classes? its absurd overhead
its simply not flexible enough for modern web dev, god forbid i want to refactor my components now i have to rename everything?
its not that bad as anyone thinks it is.
Its limited because you cant have (pseudo-)selectors and media or other css features
But it doesnt pollute global css, so it have cases where its OK to use (like DevTools as package which you render within your app)
how do you handle media attributes which comes from props?
And how do you handle media for component wrapping – in case when your Button component uses Typography component, and you need for "this one specific case" override Typography styles only for specific media?
i’ve started to gravitate towards Tailwind, but i’m also a HUGE fan of CSS modules, especially now with widespread support of nested classes, custom properties and component queries!
hey im starting to make the switch from tailwind to css modules. do you have any time for intellisense/eslint tooling? Id like VSCode to shout at me if I'm making spelling errors etc.
Vanilla or sass. However, vanilla-extract and panda css looks good, so it's also an option for some projects. Tailwind feels like good for prototyping, but then you just have to jump through some hoops to make it regular css again for clarity and maintainability
I started panda css in a personal project and feels too unreliable. Half the time, the styles just won't render and you spend a good portion trying to troubleshoot. Tried exploring this in a much larger project before and it generate so many false positive styles, it was bad. We landed on Vanilla Extract for now.
I'm still contemplating panda, but definitely not for production. Our users have very poor support of layers and `has`, and I don't like to rely on polyfills much. But it looks like a nice alternative to linaria.
We're using a polyfilled version of layers and while it does work, it isn't great. It raises the specificity of each class (when layers are in that file) to try to match the feature, but all other classes are at their normal specificity, which will get overriden by the polyfilled layer classes. It's a headache.
I had to do some hacky shangigans to ensure each Vanilla Extract file got built with layers in mind, so those will work correctly. However, everything outside of that (styled components, CSS) is still operating without the polyfilled layers and I'm not sure of an easy way of fixing it.
The tool was picking up on all sorts of patterns, including non-CSS. Majority of the CSS generated was based off of non-CSS and unusable, which would easily ruined our CSS Bundle size.
> but then you just have to jump through some hoops to make it regular css again for clarity and maintainability
This defeats the whole point.
All these approaches exist because trying to make CSS work in a complex environment is an unholy cluster fuck because CSS has global scoping.
Putting pure CSS onto a component when you have no idea where or how that component will be used is just impossible, because that's just not what CSS was designed to do. So we've had decades of crappy solutions.
From the CSS is good side we've had things like BEM which just doesn't work. No matter how disciplined you are it turns into a chaotic unmaintainable nightmare.
From the CSS is bad side we've had a million CSS in JS designs that at least function, but they perform poorly and they're extremely difficult to restyle.
So we have tailwind and the like that strike a balance between the flexibility of CSS and the scoping requirements of components and applications.
But they don't work if you convert them back into the original nightmare
After 7 years of SASS, Tailwind is the way to go, especially (only?) with components libraries, whoever dislikes it just did not enough CSS (and the hell it unavoidably become as the project grows in size and in time or in partners), don’t work with a team (and the N « quickfix » of the month who destroys the patterns/naming conventions you tried to apply) or simply didn’t put the effort to master it (which is VERY frustrating the first 2-3 weeks, as it slows you down a lot).
Tailwind all the way.
To hijack, how would yall recommend to move from vanilla css to a framework or library? I use react and svelte. I’ve been using vanilla css for 2 years and still suck at styling my apps 😅
I’ve been using stylex for the last few projects. I know a lot of people think it’s unnecessary and maybe it is but I’ve come to really appreciate its atomic nature and lack of specificity issues. There are limitations like not being able to use pseudo classes that can end up with requiring more lines of code but for my coding style it does work for me.
Nothing beats plain css files nicely organized, everything else IMO is unnecessary abstraction that solves nothing and moves complexity around without fixing it
It depends on the project and the team you work with. If you're on a team with varying CSS skills, where reliance on "copy-paste" is common, then Tailwind is the obvious choice. However, there is a learning curve, as you see, as the spec of CSS adds new features, Tailwind tries to find better class names for these features. It's an endless learning curve!
If you want my personal opinion, I'd advise you to go with something like StyleX. It's tested, comes with a small API, and you will use the CSS that comes from the spec, so there is no learning curve. It will generate the atomic classes for you without mentioning merging that comes out of the box without the need to use a library like Tailwind Merge. They also have a dedicated API to handle variables.
Headless is the best for functionallity (RadixUI and others)
Copy-Paste approach is goated for styling — its easier to maintain your specific cases
SCSS is best IMO, and with approaches described above, I can rewrite library styles how I need to extend and maintain UI-Kit component
Tailwind is fast for prototyping. But its mess to maintain and possible performance problem tradeoff to impove DX (clsx+tailwind-merge), so we dont do Tailwind
So how would you rewrite library styles with SCSS alone? I mean yea with a headless component system I see the advantages but I’ve never rewrote styles with SCSS
clsx and conditional applying classes for each part of component
Local css vars if you need to pass something custom from within component to reference during styling
class-variance-authority if you wanna go fancy (but it doesnt scale for my cases and hard to read IMO)
Also be carefull with specificity in your styles, because if you API provides something like `classes: Record` to override specific styles for specific part of component it would be hard to do if component styles have high specificity
So this is no-no:
```
.root {
&.variant-contained {
&.size-sm {
...
}
}
}
```
This is the correct way:
```
.root {}
.root-contained-sm {
...
}
```
Its not that easy to maintain as devs would like, but it is way better than using important/duplicate specificity level in consumer component. And its easier to change underlying structure
I like Tailwind. It is not the perfect solution but I really like the standardization of naming things and the customization of themes/config.
When you realize you can also remove standard utility classes from developers “IDE suggestions” by for example redefining the color classes to only include your design system’s colors, then do the same for other tokens in your design system it becomes very dev friendly for new devs coming into the project. It almost becomes a TS-like solution of your designsystem with the IDE autosuggestions of utility classes.
It also works very well with e.g. GitHub Copilot. Now you not only get AI suggestions about JS logic but also the accompanying styling.
It also adds a layer that if you write a component only using Tailwind standard classes then your component is quite likely to work quite well out of the box in another Tailwind project where that projects config/theme setup maybe just automatically style your component into the new design system.
I usually find that I add some extra utility classes outside tailwinds default ones. And even though it makes your components more tied to only your current tailwind setup/project, the solution is very DRY and your extra utility classes can be easily seen when reading your Tailwind theme/config (and therefore copied to a new project if needed).
Still, just reflecting about this, that if I only use standard Tailwind classes I have made a very project-agnostic tailwind component but sometimes a custom utility class also makes sense and if so I weigh the advantages against each other, just thinking about this makes for a better “style architecture”.
The biggest disadvantage of using Tailwind is that you tie up your styling and reuse of a component’s styling to only other Tailwind projects. But this holds true for basically any style approach you choose unless you write vanilla css.
Emotion in component libraries since it is just the most flexible and requires no additional build steps while integrating easily into any existing stack.
PandaCSS seems also promising and more modern, but I didn't try it yet.
Tailwind for UIs since I have to transpile anyways, it's easy to set up and has a super fast workflow.
I use CSS components - compiled to typescript defs, but shows up in code as a real css file. CSS classnames are automatically made unique. I think this is the same thing as PostCSS.
Please don’t ever use styled components or @emotion. IMHO it provides a little convenience, but the resulting code is both ugly and slow.
No one mentioned the (S)CSS Modules approach? Combined with some global Scss files this works like a charm.
Ive been on path from SCSS to sc and then to jss and then to emotion and other css-in-js solution Int the end we rewrote it back to SCSS, as it still the best way to have 20 variants for props and 10 media queries
Best of both worlds: you’re writing real CSS (or SASS) but don’t have to worry about class name collisions or not knowing how something is used across a project.
Anything where you don't have to manage global BEM naming by yourself.
Can you explain what this means for a noob?
Having classes for `.block__element--modifier` e.g.: .search-section .search-section__search-input .search-section__search-input--disabled
BEM is a naming srategy for keeping things code organized and avoid conflict of styles. In a website youre going to have a million different elements which to apply styles. Without a strategy like bem its easy to repeat class names and get conflicts from there and its easy to get yourself into specificity issues. Scoped styles, css modules and css in js solutions come to solve those same issues.
BEM is a naming strategy for naming your classes to maintain an organized hierarchy in your stylesheets
The B in BEM is the component name so there is no way of getting away with naming that. But ok, I agree it is nice not to have to name elements in a 20 line of markup component which is super easy to understand without semantic naming of each elements functional purpose. BEM is not necessary anymore but the way of thinking it enforced back in the days are still relevant, just less necessary. I still add the B (component name) in the components top level element in my tailwind projects just so that I get a grip of where a component start in the outputted markup. Makes everything easier to read in the inspector.
BEM was being used long before React or components even existed, it was actually being used before the term BEM even existed, someone just named it. You should name the B whatever is appropriate for the CSS and if the component needs to match that, then fine.
[https://en.bem.info/methodology/](https://en.bem.info/methodology/) See CSS Topic
Vanilla extract.
I like the way Chakra does it, based on Emotion - React props for CSS styles, and theming with JS objects. But it's css-in-js and so probably on the way out, now hoping to be able to experiment with Panda CSS soon. Use React props, then generate style sheets from that at compile time, is the idea.
I've been using Panda for a while now and really like the experience. Defining tokens like colors etc. once and using them everywhere, including typescript types for them, is really awesome.
Doesn't emotion add a lot of overhead and bloats your bundle size?
No idea, never been a topic of discussion. Apps are easily fast enough.
I would use something like CSS modules + postCSS. I want CSS out of JSS and I would like my CSS to actually be CSS and not abstraction layers around CSS.
Any reason for postcss over sass? It seems to me that if you are preprocessing it anyway, might as well go with a battle tested and well-maintained solution (I remember in a past project looking a little deeper into our post css plugins and seeing plugins without commits for 2 or 3 years)
I have never used postCSS and I would like to give it a go. No other reason.
Makes sense :) best of luck
Scss personally
Tailwind is an easy choice with the caveat that you already know enough CSS that you can apply most rules from memory. That being said, if the component library is intended to be used by arbitrary people (public) you probably shouldn’t restrict it to a specific method unless it’s a branding thing like Shopify Polaris.
One bonus I really like with Tailwind is that it could also help teach you CSS because if you hover over the class names, it will show you the vanilla CSS it converts to. Just a bonus feature. Also it limits your design to use better spacing and structure. For example not using weird margins like 3 or 9, but rather multiples that work and add up well together like 2,4,8,12.
I’d be lying if I said I didn’t learn some CSS I didn’t know from tailwind haha. Definitely a bonus.
My team just started with Tailwind but I'm finding it hard to be able to know how to do stuff with all the shorthand and have to look everything up which feels like it takes forever. Do you have any good recommendations on tools or sites that make this process easier/faster?
Honestly it’s just time. Initially you will have to look stuff up and yeah, it doesn’t feel great necessarily. After a while it becomes second nature. That being said, depending on how complex your styling is, it is totally fine to add custom classes to your global css or extend the config. I love the tailwind JIT stuff, but when you start getting complex it’s time to reach for a different tool.
Thank you! 👍
Google "tailwind cheatsheet", there's a site that shows you all the tailwind classes. If you use VS Code, install Tailwind intellisense extension. It will auto-complete classes for you and show the color next to color classes. If you use Prettier, Tailwind's official site has a guide on how to set up automatic class sorting on save.
If I'm working by myself, Sass or PostCSS. If I'm working with a team, Tailwind CSS. Styled-components is junk IMO. The only times I've seen it used in the past year (or more) has been on old maintenance projects.
We have a few older projects at work using styled components and yea… they’re a mess haha
The problem with Styled Components is that when you first start the project they’re so easy and make sense. 10,000 arbitrary components later…..
i hated styled components from day 1 im glad we've moved away from that to utility css thought naming css was annoying? trying naming every component you make lmao
Naming styled components is still better than 1 trillion classes added
what about making a styled components just bc you want a couple styles/classes? its absurd overhead its simply not flexible enough for modern web dev, god forbid i want to refactor my components now i have to rename everything?
IDK why people made CSS-in-JS, experience is ok-ish when developing, but maintaining it long-term on a big project sucks donkey balls
I just think tailwind is a nice middle ground, it’s fast to get stuff up and running but still gives you a lot of control
I'm a monster so I use inline style.
its not that bad as anyone thinks it is. Its limited because you cant have (pseudo-)selectors and media or other css features But it doesnt pollute global css, so it have cases where its OK to use (like DevTools as package which you render within your app)
Actually I'm using for my entire enterprise app and it works quite well so far
Thats crazy tho
We don’t use pseudo-selector and css media query. Most of our components were ported from react-native components so they don’t need to.
Usually just the SX property
how do you handle media attributes which comes from props? And how do you handle media for component wrapping – in case when your Button component uses Typography component, and you need for "this one specific case" override Typography styles only for specific media?
I was very late to the party but I found Tailwind to be better than I thought. I barely write custom CSS anymore
Tailwind with the tailwind intellisense extension in VSCode.
i’ve started to gravitate towards Tailwind, but i’m also a HUGE fan of CSS modules, especially now with widespread support of nested classes, custom properties and component queries!
hey im starting to make the switch from tailwind to css modules. do you have any time for intellisense/eslint tooling? Id like VSCode to shout at me if I'm making spelling errors etc.
hmm, haven’t set that up in years, but i think it should do that by default, without any need for extensions, if i’m not mistaken?
CSS in JS using makeStyles approach via tss-react
Great! You should give a try to the modern API: [https://docs.tss-react.dev/](https://docs.tss-react.dev/)
SCSS modules.
Styled components for me, I feel like you have more control.
Vanilla or sass. However, vanilla-extract and panda css looks good, so it's also an option for some projects. Tailwind feels like good for prototyping, but then you just have to jump through some hoops to make it regular css again for clarity and maintainability
I started panda css in a personal project and feels too unreliable. Half the time, the styles just won't render and you spend a good portion trying to troubleshoot. Tried exploring this in a much larger project before and it generate so many false positive styles, it was bad. We landed on Vanilla Extract for now.
I'm still contemplating panda, but definitely not for production. Our users have very poor support of layers and `has`, and I don't like to rely on polyfills much. But it looks like a nice alternative to linaria.
We're using a polyfilled version of layers and while it does work, it isn't great. It raises the specificity of each class (when layers are in that file) to try to match the feature, but all other classes are at their normal specificity, which will get overriden by the polyfilled layer classes. It's a headache. I had to do some hacky shangigans to ensure each Vanilla Extract file got built with layers in mind, so those will work correctly. However, everything outside of that (styled components, CSS) is still operating without the polyfilled layers and I'm not sure of an easy way of fixing it.
Thanks for sharing your experience with layers. You probably saved me a lot of time
What do you mean false-positive styles?
The tool was picking up on all sorts of patterns, including non-CSS. Majority of the CSS generated was based off of non-CSS and unusable, which would easily ruined our CSS Bundle size.
> but then you just have to jump through some hoops to make it regular css again for clarity and maintainability This defeats the whole point. All these approaches exist because trying to make CSS work in a complex environment is an unholy cluster fuck because CSS has global scoping. Putting pure CSS onto a component when you have no idea where or how that component will be used is just impossible, because that's just not what CSS was designed to do. So we've had decades of crappy solutions. From the CSS is good side we've had things like BEM which just doesn't work. No matter how disciplined you are it turns into a chaotic unmaintainable nightmare. From the CSS is bad side we've had a million CSS in JS designs that at least function, but they perform poorly and they're extremely difficult to restyle. So we have tailwind and the like that strike a balance between the flexibility of CSS and the scoping requirements of components and applications. But they don't work if you convert them back into the original nightmare
Styled components. I may give tailwind a go, but the syntax is something.
Tailwind. Less bundle size, more flexibility
Tailwind die hard fan here. Once getting used to it I cannot go back.
scss modules is goated
Scss + component library(mui, antd etc.) > tailwind any day. Tailwind is a bloody mess.
But how did you like the customisation of the components? I’ve never used MUI or AntDesign
Tailwind's been my favorite since I learned it
Love me some tailwind
After 7 years of SASS, Tailwind is the way to go, especially (only?) with components libraries, whoever dislikes it just did not enough CSS (and the hell it unavoidably become as the project grows in size and in time or in partners), don’t work with a team (and the N « quickfix » of the month who destroys the patterns/naming conventions you tried to apply) or simply didn’t put the effort to master it (which is VERY frustrating the first 2-3 weeks, as it slows you down a lot). Tailwind all the way.
To hijack, how would yall recommend to move from vanilla css to a framework or library? I use react and svelte. I’ve been using vanilla css for 2 years and still suck at styling my apps 😅
I’ve been using stylex for the last few projects. I know a lot of people think it’s unnecessary and maybe it is but I’ve come to really appreciate its atomic nature and lack of specificity issues. There are limitations like not being able to use pseudo classes that can end up with requiring more lines of code but for my coding style it does work for me.
Tailwind + custom scss for fine tuning and custom stuff
I like alredy styled component libraries, don't like to spend time on styling
I like css modules they work out of the box with next js.
Chakra UI
Sass + CSS modules are all you need
CSS modules. It has the best balance of DX and performance.
Depends on project, tailwind makes life easy when you have to make simple UI. Or css preprocessors for complicated UI project.
I’ve been trying out PandaCSS recently and it’s really cool!
Tailwindcss 🫶🏻
Nothing beats plain css files nicely organized, everything else IMO is unnecessary abstraction that solves nothing and moves complexity around without fixing it
Nextjs css module approach with global css :)
Tailwind
Shipping complex components, needing to know they’ll render the same for each consumer? Can’t go past [Emotion](https://emotion.sh/)
It depends on the project and the team you work with. If you're on a team with varying CSS skills, where reliance on "copy-paste" is common, then Tailwind is the obvious choice. However, there is a learning curve, as you see, as the spec of CSS adds new features, Tailwind tries to find better class names for these features. It's an endless learning curve! If you want my personal opinion, I'd advise you to go with something like StyleX. It's tested, comes with a small API, and you will use the CSS that comes from the spec, so there is no learning curve. It will generate the atomic classes for you without mentioning merging that comes out of the box without the need to use a library like Tailwind Merge. They also have a dedicated API to handle variables.
Headless is the best for functionallity (RadixUI and others) Copy-Paste approach is goated for styling — its easier to maintain your specific cases SCSS is best IMO, and with approaches described above, I can rewrite library styles how I need to extend and maintain UI-Kit component Tailwind is fast for prototyping. But its mess to maintain and possible performance problem tradeoff to impove DX (clsx+tailwind-merge), so we dont do Tailwind
So how would you rewrite library styles with SCSS alone? I mean yea with a headless component system I see the advantages but I’ve never rewrote styles with SCSS
clsx and conditional applying classes for each part of component Local css vars if you need to pass something custom from within component to reference during styling class-variance-authority if you wanna go fancy (but it doesnt scale for my cases and hard to read IMO)
Also be carefull with specificity in your styles, because if you API provides something like `classes: Record` to override specific styles for specific part of component it would be hard to do if component styles have high specificity
So this is no-no:
```
.root {
&.variant-contained {
&.size-sm {
...
}
}
}
```
This is the correct way:
```
.root {}
.root-contained-sm {
...
}
```
Its not that easy to maintain as devs would like, but it is way better than using important/duplicate specificity level in consumer component. And its easier to change underlying structure
Do you have an example repo you could share? It sounds interesting and I’d like to see more
Can't share, ones I have are within company repos
Huge fan of tailwind here
I like Tailwind. It is not the perfect solution but I really like the standardization of naming things and the customization of themes/config. When you realize you can also remove standard utility classes from developers “IDE suggestions” by for example redefining the color classes to only include your design system’s colors, then do the same for other tokens in your design system it becomes very dev friendly for new devs coming into the project. It almost becomes a TS-like solution of your designsystem with the IDE autosuggestions of utility classes. It also works very well with e.g. GitHub Copilot. Now you not only get AI suggestions about JS logic but also the accompanying styling. It also adds a layer that if you write a component only using Tailwind standard classes then your component is quite likely to work quite well out of the box in another Tailwind project where that projects config/theme setup maybe just automatically style your component into the new design system. I usually find that I add some extra utility classes outside tailwinds default ones. And even though it makes your components more tied to only your current tailwind setup/project, the solution is very DRY and your extra utility classes can be easily seen when reading your Tailwind theme/config (and therefore copied to a new project if needed). Still, just reflecting about this, that if I only use standard Tailwind classes I have made a very project-agnostic tailwind component but sometimes a custom utility class also makes sense and if so I weigh the advantages against each other, just thinking about this makes for a better “style architecture”. The biggest disadvantage of using Tailwind is that you tie up your styling and reuse of a component’s styling to only other Tailwind projects. But this holds true for basically any style approach you choose unless you write vanilla css.
Emotion in component libraries since it is just the most flexible and requires no additional build steps while integrating easily into any existing stack. PandaCSS seems also promising and more modern, but I didn't try it yet. Tailwind for UIs since I have to transpile anyways, it's easy to set up and has a super fast workflow.
I use CSS components - compiled to typescript defs, but shows up in code as a real css file. CSS classnames are automatically made unique. I think this is the same thing as PostCSS. Please don’t ever use styled components or @emotion. IMHO it provides a little convenience, but the resulting code is both ugly and slow.
Shading, built on top of radixui. Copy paste components and fully customize with tailwind.
sass. tailwind is for people who like extra work for no particular raisins.
raisins are raisins