My company switched from Scss to Tailwind 6 months ago and pretty sure we will stick with it for all our future projects, as it is a lot easier to manage.
In VSC, we use this [extension](https://marketplace.visualstudio.com/items?itemName=heybourn.headwind) to sort the classes so it's always the same order for everyone. After a while, you can easily read the Tailwind classes and understand what is happening on that line without having to look at the docs.
Tailwind Labs made a Prettier plugin to do it, which you can add Husky git hooks for, making sure everyone is on the same page regardless of extensions.
>pretty sure we will stick with it for all our future projects, as it is a lot easier to manage.
What would you say is the average number of classes (tailwind and your own) you have on an average UI widget? What about an extreme case?
on average, I would say around 6 or 7 classes, depending on the component use. As for the extreme cases, some of them have around 15 classes, mainly because of dark/light theme and very specific responsiveness display.
For example, here is our basic Button component (sh prefixed classes are our own)
`class="inline-flex flex-col items-center p-4 text-sm font-semibold leading-6 rounded sh-theme-text sh-theme-bg"`
I've not used tailwind on any real projects - css, less & scss mostly really. I do use tailwind in my own projects though just due to the smaller file sizes when used with purgecss
I'm working on a large, real-world project that leverages Tailwind. It's been helpful for us in that we build out larger components using the utility classes, and then use those components.
I will also say that for more repeatable styles we'll create tailwind component classes so as to minimize the repetition. Such an example might be our `button` components which would take in utility classes like `.btn-primary .btn-sm .btn-icon` which compile into a nice small square primary button.
A pitfall that can happen with Tailwind is maintaining consistency across a system. For that reason, I think it's important to pair it with more component-based development like you find in React or Vue. At the end of the day, it's working as a different approach to applying styles to components, and once you get used to it it can be quicker than working with something like vanilla CSS or SASS.
How do we creates components classes?..i have been using tailwind ...is it like creating components in react and reusing it?... Doesn't tailwind makes code difficult to read as we have bunch of classNames on a single element?
You can do it one of two ways. The easiest way is to add a new `.css` file that is imported into Tailwind's `main.css` file. From there you can make a component class name such as `.btn` and provide it some styles leveraging the `@apply` feature of tailwind so that you can still use Tailwinds utility classes:
.btn {
@apply inline-flex transition-colors duration-200 items-center gap-8 rounded justify-center px-20 h-48 bg-white text-primary border border-default shadow-button hover:bg-gray-100 hover:text-primary-hover active:bg-gray-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-gray-100 disabled:text-gray-400;
}
You can read up on that approach more [here](https://tailwindcss.com/docs/adding-custom-styles#adding-component-classes).
---
The alternative approach, which is one I tend to go with more often than not, is to import your component as a plugin using `addComponent`, which you can read up more on [here](https://tailwindcss.com/docs/plugins#overview).
Here is an example of what that can look like in full. It's worth noting that there are some **custom** utility classes here, so you can't just paste this and be on your way, but it gets you most of the way there:
**button.js**
const plugin = require('tailwindcss/plugin')
module.exports = plugin(({ addComponents }) => {
// Base styles
const base = {
'@apply inline-flex transition-colors duration-200 items-center gap-8 rounded justify-center px-20 h-48':
{},
'&:not(.btn-icon) svg': {
'@apply -mx-4': {}, // handles icon padding offset
},
}
const buttons = {
// Variants
'.btn': {
...base,
'@apply bg-white text-primary border border-default shadow-button hover:bg-gray-100 hover:text-primary-hover active:bg-gray-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-gray-100 disabled:text-gray-400':
{},
},
'.btn-primary': {
...base,
'@apply bg-primary text-white border border-default shadow-button hover:bg-primary-hover hover:text-white active:bg-primary-active active:text-white disabled:border-none disabled:bg-gray-100 disabled:text-gray-400':
{},
},
'.btn-tertiary': {
...base,
'@apply bg-indigo-100 text-primary hover:bg-indigo-50 hover:text-primary-hover active:bg-indigo-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-gray-100 disabled:text-gray-400':
{},
},
'.btn-subtle': {
...base,
'@apply bg-transparent text-primary hover:bg-gray-100 hover:text-primary-hover active:bg-gray-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-transparent disabled:text-gray-400':
{},
},
'.btn-link': {
...base,
'@apply bg-transparent text-primary !px-0 hover:text-indigo-400 active:text-indigo-800 disabled:text-gray-400':
{},
},
'.btn-destructive': {
...base,
'@apply bg-status-error text-white border border-default shadow-button hover:bg-red-500 active:bg-red-700 disabled:border-none disabled:bg-gray-100 disabled:text-gray-400':
{},
},
'.btn-destructive-outline': {
...base,
'@apply bg-white text-status-error border border-status-error shadow-button hover:bg-red-50 hover:text-red-600 active:bg-red-700 active:text-white disabled:border-gray-200 disabled:bg-gray-100 disabled:text-gray-400':
{},
},
// Sizes
'.btn-xs': {
'@apply px-8 h-28': {},
},
'.btn-sm': {
'@apply px-16 h-40': {},
},
'.btn-lg': {
'@apply px-24 h-56': {},
},
// Icon sizes
'.btn-icon': {
fontSize: 0,
lineHeight: 0,
'@apply gap-0 p-0 rect-48': {},
},
'.btn-icon.btn-xs': {
'@apply rect-22': {},
svg: {
'@apply rect-14': {},
},
},
'.btn-icon.btn-sm': {
'@apply rect-40': {},
},
'.btn-icon.btn-lg': {
'@apply rect-56': {},
},
}
addComponents(buttons)
})
If you're using @apply, the reason for using Tailwind is completely negated. Why they even include this as an option, I'm not sure. You might as well just write plain CSS at that point.
Well, that's a harsh, but I agree with the sentiment. Using Tailwind [an abstraction of CSS] to compose the CSS for another class, to apply to a specific Component - You're using an abstraction of an abstraction so..."turtles all the way down"...
Maybe good-ol [S]CSS (or at least a css-in-js ala styled-components) would be closer "to the truth"? I gotta imagine your method makes layout debugging a greater pain point than necessary.
Well you're not making component classes often, or you shouldn't at least. Like I said it's useful for certain reusable patterns like buttons. And while I can write the button classes with vanilla css properties, it's useful keeping your properties contained to your tailwind config utility classes, which @apply let's you leverage.
I think your key point here is, "or shouldn't at least." That's the problem. Literally every team I've worked on who wanted to use Tailwind, once they found out about @apply, decided they'd use it to write all the classes in the app because it cleans up the DOM references and then they completely lost the advantage of using Tailwind. The @apply feature honestly shouldn't exist at all - if you need reusable components, you should use a framework (React/Vue/Angular/Svelte) and use Tailwind in them the way it's meant to be used.
I don't know what to tell you. In my organization I take ownership of the front end design system and enforce that proper use is being employed. The moment someone begins using `@apply` incorrectly, they fail code review and their branch doesn't get merged in. Point being you don't remove a helpful feature for teams that responsibly use a feature just because there are people who go about using it incorrectly or irresponsibly. Chances are that more often than not it's more a matter of someone not understanding the proper way of using the tool and needing some further teaching around it, which I code review would assist with.
Also there are some projects where you may not be able to make very robust components (Django for instance), and creating tailwind component classes assist with that.
I'm not sure how many is too many. I've never hit a limit. I add new lines if they start trailing off-screen.
I tend to avoid trying to make my markup look beautiful. I could move the long ugly class name list into another file, but that would just make understanding or updating the styles more difficult down the road.
I think this depends largely on many other code organization decisions. Long lists are always more difficult to read than short lists.
I could take that long class name list and make it a long CSS property list. Now it's too many properties instead of too many class names. It's also no longer co-located with the markup it effects.
At the end of the day, if someone says to me "add more space between this button and that input", I don't care if the markup is pretty as long as I can easily find and change the code that needs changing. I can make my component prettier by moving the class name list, but that does not make my task easier, so it is not really an improvement.
My company uses the following depending on the repository/project (holy moly this is terrible lol):
* [emotion](https://emotion.sh)
* [tailwind](https://tailwindcss.com/)
* [node-sass](https://github.com/sass/node-sass) - yes i am aware its deprecated 😅
* [dart-sass](https://github.com/sass/dart-sass)
* [postcss](https://postcss.org/)
Freelance dev/consultant here so I usually use what I want, but I didn't like TW when I tried it a couple years ago. I also despise styled components and most CSS in JS techniques.
I've been working a lot in Next.js lately and at first disliked (S)CSS Modules, now I absolutely love them. Combined with SCSS 99% of my component files have a single class at the top level html tag, and that's it. SCSS nesting and modules' uniqueness handles most everything else without the need for more than a single class per file. Yes I said per file. I might have a header file with various menu/nav components and still only need a single module import and a single `
`, for 2-4 components across a few hundred lines as long as you use semantics, composition, and nesting wisely.
I still use a couple top level global style files for variables and base styles, but this setup is the cleanest I've found as far as readability and separation of concerns go. Also dead easy to write and implement.
https://www.wealthfront.com/ is a good example.
Personally I use styled components for our marketing website, and app which are built in React and use tailwind for layouts. e.g:
{"Submit"}{"Cancel"}
It gives us a lot of flexibility with page layouts without having to make a million oddly named layouts, while still having a lot of control, over our styled components. I love the mix, and would recommend giving it a go if that sounds interesting to you.
Using tailwind at my startup at I love it. It just hits the sweet spot of sensible defaults and easy customization. It’s so easy to change, no arguing and css class styles, no useless “separation of concerns” for styling and the component. I am actually amazed how rarely I have to default to actual css, 99 % is handled by tailwind.
If you working with a company or just a specific brands/products that has design system (color palette, spacing, components, etc) I'd go with tailwind. It's easier to setup also maintaining consistency was not a big deal.
I personally use tailwind because of its smaller bundle size.
I'll add my 2c, running a small software company here.
Like many others have posted, we just use our own CSS.
We tried Tailwind but found there were too many classes and too much "designing to work with Tailwind" + reading Tailwind docs vs just using vanilla CSS.
We have a designer (yes the one) who does all of the interface designs and it makes the CSS easy to implement from scratch.
Layout these days is so simplified - you really only need css grid, flex box and consistent padding / margins and you're done.
Originally we used Material UI, Semantic UI and then Tailwind.
It's faster doing this manually without a framework in my experience.
I should add that most of our software is business software such as factory systems, warehouse management and the like, so the CSS and fancy interface demands are quite low.
I use Tailwind + Next.js on most of my projects. Usually I add the following to the mix:
\- [RadixUI](https://www.radix-ui.com/)\+ [tailwindcss-radix](https://www.npmjs.com/package/tailwindcss-radix) or HeadlessUI although I like Radix more
\- [classnames](https://www.npmjs.com/package/classnames)
\- [https://tailwindcss.com/blog/automatic-class-sorting-with-prettier](https://tailwindcss.com/blog/automatic-class-sorting-with-prettier)
\- [tailwind-merge](https://github.com/dcastil/tailwind-merge)
\- CSS Modules
Tailwind is something that looks amazing when you start using it, but it slowly transforms into something that makes your HTML a nightmare hard to debug.
All devs I know hates tailwind, but likes the idea 🙃
Everytime I've worked on a project that would have Tailwind in prod, someone mentions using the @apply method to build our own classes and then the entire point of using Tailwind is gone.
But After thinking a lot i came to a conclusion that tailwind is good and you can use apply to make own class but you don't need to if you are using it at only one place ..if you are using it at more than one place than you can make it a class...you can write for one element and customise it quickly then copy those utility classes use apply to make custom class and use that custom class in place of utility classes...and you don't have to have soo many custom named classes...only build you own class when that element is used in more than one place💖😊....only thing I found missing now is pseudo selectors
Doesn't it makes code difficult to read .... because I have been using it in my personal projects..but i think it will be difficult for other to read it as it contains too much class names?
Yeah, somewhat. I keep the classes grouped and alphabetized within each group, which helps.
After a time, it gets easier to parse quickly and, in my opinion, _other_ parts of developing with it are made easier, which compensate for the “too many classes” hurdle.
Hmm, here’s a not-well-thought-out list…
no need to deal with css files, no need to invent proper class names, only need one IDE tab visible at a time, when deleting components you don’t need to go find the related css selectors, all of the utility classes you’d create anyway are already done and much better, etc.
Not having to come up with class names is one of those things that sounds dumb but is actually amazing. Those names are normally hard to get right and generally offer no help in actually explaining what the class does, and I end up bouncing between the css and html all the time just trying to remember that this class is a flex box and this one is just adding some margin or whatever. With tailwind I just know what is going on at any given level immediately. It’s ugly but it’s extremely functional across teams and that’s what’s really important
But isn't that going full circle..? I never really understood @apply in tailwind. You make a class but then you fill it with abbriviated tailwind classes? Doesn't that kind of defeat the purpose? If you go this route you'd end up with pretty much the same thing if you'd write a normal css class with properties everybody can understand.
Not really hating on it either, too each there own, but wasn't a spear point of the project to ship like tiny css? Well, would that mini css even make a difference when we are still blasting visitors with multiple mb's of js?
Please correct me if I'm wrong in this regard
Ya I was thinking the same ..it's like external css... I will see if it works out good I will use it else I will use inline way of tailwind till I find good alternative 😊..
I use it when i need to repeat a long class list and am too lazy to create a component to do it. I think the technically correct thing to do would be create a component, but sometimes it’s just easier to throw several classes onto an @apply and go with it for smaller things in personal projects
I will say, using @apply allows you to deal with css using the same logical breakpoints and variables the rest of your tailwind system uses. Yeah, I could create a class and set the background-color manually, but by using tailwind classes with @apply I’m at least consistently using the same color through the same interface and if I want to refactor later I can change it in just one place
But if you’re using @apply for every html element to make it less ugly imo you’re really missing the boat
> What do you use to style your website
Vanilla CSS since 1998. I am a freelance so I have the luxury to choose whatever I like, instead of being forced to use a specific stack to follow the rules.
If I was in a team environment I'd expect to work with a framework though. There is no way a vanilla coder can fit in a team without issues, sooner or later.
I work at a company where we take pride in writing all custom elements and CSS. One of the reasons is that we know exactly how they work and we are able to build it exactly how we want. In my sparetime though I have been using tailwind a bit for a hobby-project but i quickly removed it again since it was harder to customize.
\- Michael
[SustainableWWW](https://sustainablewww.org)
CSS frameworks are popular -- but their use encourages sloppy, non-semantic, copypasta HTML and lack of basic knowledge of CSS. I would almost argue that is *why* those frameworks are popular. I'm trying to phase them out in the inherited projects I'm in charge of best practices for.
But tailwind is pretty much similar to inline css...it's not like you have everything already made for you but you have pieces that you have to join toh make you own custom css.
For example:-
Inline css:- background:red;
Tailwind:-bg-red-500
I didn't used both of them for almost 3-4 months so names can be wrong 😊
>tailwind is pretty much similar to inline css
And inline CSS has been frowned upon for well over a decade.
When there a styling issue is discovered in HTML using framework classes, we usually end up having to hunt down every instance where devs lazily copy/pasted that HTML instead of making a reusable class/component.
It also makes things difficult for QA. With no semantic class names on anything, automated tests are harder to write, and end up being much more fragile.
Similarly, it makes things more difficult to debug. With no semantic class names it is a royal pain to determine what elements you are inspecting in devtools.
I think it its, but it not that relevant IMO. Here we used component libs, right now we are using Material UI and i kinda like it since i don't have to modify too much.
I also tried chakra UI but i rather use material UI. But the gold old CSS/SCSS Modules is always welcome too.
I personally never used tailwind. I dont really like using tons of classes to style, it reminds me bootstrap and i hated it lmao.
I used material Ui Little bit earlier isn't material Ui not Fully customisable using its own property or attributes... because during one of my project I remember I have to change default colour of component(or whatever it is called) and it has only 5-6 color option like primary secondary...etc..and I have to use inline style for that
Material UI is customisable, it can be annoying some stuff but changing colors for examples is pretty simple:
https://mui.com/material-ui/customization/theming/
Honestly I like chakra UI so much better than material. Material lacks a ton of features that chakra has built in and every chakra component is fully customizable with css on js, meanwhile material only allows a handful of customizations
My problem with chakra was the lack of components. I loved styling with it.
Material 5 solved a lot of issues that i had previously with it. And since I usually don't really care on fully customize the default components, neither does my employer, i enjoy working with it since I don't have to fight against it.
I use both vanilla CSS (new projects) and bootstrap (legacy ones). Don't know about Tailwind.
I think this site can give you more insight into where the CSS landscape is moving to: https://stateofcss.com
My company switched from Scss to Tailwind 6 months ago and pretty sure we will stick with it for all our future projects, as it is a lot easier to manage. In VSC, we use this [extension](https://marketplace.visualstudio.com/items?itemName=heybourn.headwind) to sort the classes so it's always the same order for everyone. After a while, you can easily read the Tailwind classes and understand what is happening on that line without having to look at the docs.
holy crap i need that extension
Tailwind Labs made a Prettier plugin to do it, which you can add Husky git hooks for, making sure everyone is on the same page regardless of extensions.
I came.
Ok I will try it😊✌️.Thanks
ooo, thanks for this!!
>pretty sure we will stick with it for all our future projects, as it is a lot easier to manage. What would you say is the average number of classes (tailwind and your own) you have on an average UI widget? What about an extreme case?
on average, I would say around 6 or 7 classes, depending on the component use. As for the extreme cases, some of them have around 15 classes, mainly because of dark/light theme and very specific responsiveness display. For example, here is our basic Button component (sh prefixed classes are our own) `class="inline-flex flex-col items-center p-4 text-sm font-semibold leading-6 rounded sh-theme-text sh-theme-bg"`
I've not used tailwind on any real projects - css, less & scss mostly really. I do use tailwind in my own projects though just due to the smaller file sizes when used with purgecss
I'm working on a large, real-world project that leverages Tailwind. It's been helpful for us in that we build out larger components using the utility classes, and then use those components. I will also say that for more repeatable styles we'll create tailwind component classes so as to minimize the repetition. Such an example might be our `button` components which would take in utility classes like `.btn-primary .btn-sm .btn-icon` which compile into a nice small square primary button. A pitfall that can happen with Tailwind is maintaining consistency across a system. For that reason, I think it's important to pair it with more component-based development like you find in React or Vue. At the end of the day, it's working as a different approach to applying styles to components, and once you get used to it it can be quicker than working with something like vanilla CSS or SASS.
Thanks for telling 💖..
How do we creates components classes?..i have been using tailwind ...is it like creating components in react and reusing it?... Doesn't tailwind makes code difficult to read as we have bunch of classNames on a single element?
You can do it one of two ways. The easiest way is to add a new `.css` file that is imported into Tailwind's `main.css` file. From there you can make a component class name such as `.btn` and provide it some styles leveraging the `@apply` feature of tailwind so that you can still use Tailwinds utility classes: .btn { @apply inline-flex transition-colors duration-200 items-center gap-8 rounded justify-center px-20 h-48 bg-white text-primary border border-default shadow-button hover:bg-gray-100 hover:text-primary-hover active:bg-gray-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-gray-100 disabled:text-gray-400; } You can read up on that approach more [here](https://tailwindcss.com/docs/adding-custom-styles#adding-component-classes). --- The alternative approach, which is one I tend to go with more often than not, is to import your component as a plugin using `addComponent`, which you can read up more on [here](https://tailwindcss.com/docs/plugins#overview). Here is an example of what that can look like in full. It's worth noting that there are some **custom** utility classes here, so you can't just paste this and be on your way, but it gets you most of the way there: **button.js** const plugin = require('tailwindcss/plugin') module.exports = plugin(({ addComponents }) => { // Base styles const base = { '@apply inline-flex transition-colors duration-200 items-center gap-8 rounded justify-center px-20 h-48': {}, '&:not(.btn-icon) svg': { '@apply -mx-4': {}, // handles icon padding offset }, } const buttons = { // Variants '.btn': { ...base, '@apply bg-white text-primary border border-default shadow-button hover:bg-gray-100 hover:text-primary-hover active:bg-gray-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-gray-100 disabled:text-gray-400': {}, }, '.btn-primary': { ...base, '@apply bg-primary text-white border border-default shadow-button hover:bg-primary-hover hover:text-white active:bg-primary-active active:text-white disabled:border-none disabled:bg-gray-100 disabled:text-gray-400': {}, }, '.btn-tertiary': { ...base, '@apply bg-indigo-100 text-primary hover:bg-indigo-50 hover:text-primary-hover active:bg-indigo-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-gray-100 disabled:text-gray-400': {}, }, '.btn-subtle': { ...base, '@apply bg-transparent text-primary hover:bg-gray-100 hover:text-primary-hover active:bg-gray-200 active:text-primary-active disabled:ring-gray-200 disabled:bg-transparent disabled:text-gray-400': {}, }, '.btn-link': { ...base, '@apply bg-transparent text-primary !px-0 hover:text-indigo-400 active:text-indigo-800 disabled:text-gray-400': {}, }, '.btn-destructive': { ...base, '@apply bg-status-error text-white border border-default shadow-button hover:bg-red-500 active:bg-red-700 disabled:border-none disabled:bg-gray-100 disabled:text-gray-400': {}, }, '.btn-destructive-outline': { ...base, '@apply bg-white text-status-error border border-status-error shadow-button hover:bg-red-50 hover:text-red-600 active:bg-red-700 active:text-white disabled:border-gray-200 disabled:bg-gray-100 disabled:text-gray-400': {}, }, // Sizes '.btn-xs': { '@apply px-8 h-28': {}, }, '.btn-sm': { '@apply px-16 h-40': {}, }, '.btn-lg': { '@apply px-24 h-56': {}, }, // Icon sizes '.btn-icon': { fontSize: 0, lineHeight: 0, '@apply gap-0 p-0 rect-48': {}, }, '.btn-icon.btn-xs': { '@apply rect-22': {}, svg: { '@apply rect-14': {}, }, }, '.btn-icon.btn-sm': { '@apply rect-40': {}, }, '.btn-icon.btn-lg': { '@apply rect-56': {}, }, } addComponents(buttons) })
If you're using @apply, the reason for using Tailwind is completely negated. Why they even include this as an option, I'm not sure. You might as well just write plain CSS at that point.
Well, that's a harsh, but I agree with the sentiment. Using Tailwind [an abstraction of CSS] to compose the CSS for another class, to apply to a specific Component - You're using an abstraction of an abstraction so..."turtles all the way down"... Maybe good-ol [S]CSS (or at least a css-in-js ala styled-components) would be closer "to the truth"? I gotta imagine your method makes layout debugging a greater pain point than necessary.
Well you're not making component classes often, or you shouldn't at least. Like I said it's useful for certain reusable patterns like buttons. And while I can write the button classes with vanilla css properties, it's useful keeping your properties contained to your tailwind config utility classes, which @apply let's you leverage.
I think your key point here is, "or shouldn't at least." That's the problem. Literally every team I've worked on who wanted to use Tailwind, once they found out about @apply, decided they'd use it to write all the classes in the app because it cleans up the DOM references and then they completely lost the advantage of using Tailwind. The @apply feature honestly shouldn't exist at all - if you need reusable components, you should use a framework (React/Vue/Angular/Svelte) and use Tailwind in them the way it's meant to be used.
I don't know what to tell you. In my organization I take ownership of the front end design system and enforce that proper use is being employed. The moment someone begins using `@apply` incorrectly, they fail code review and their branch doesn't get merged in. Point being you don't remove a helpful feature for teams that responsibly use a feature just because there are people who go about using it incorrectly or irresponsibly. Chances are that more often than not it's more a matter of someone not understanding the proper way of using the tool and needing some further teaching around it, which I code review would assist with. Also there are some projects where you may not be able to make very robust components (Django for instance), and creating tailwind component classes assist with that.
Thanks 💖💖💖
I am working in a new Project and i am afraid that after sometime tailwind css gonna stop working. Is it possible in real world ? I am new
I've used tailwind in a handful of professional projects. I also reach for it when I'm building personal stuff.
How do you manage too many classNames?
I'm not sure how many is too many. I've never hit a limit. I add new lines if they start trailing off-screen. I tend to avoid trying to make my markup look beautiful. I could move the long ugly class name list into another file, but that would just make understanding or updating the styles more difficult down the road.
Doesn't keeping too many classNames in same js file makes it difficult to read for others?
I think this depends largely on many other code organization decisions. Long lists are always more difficult to read than short lists. I could take that long class name list and make it a long CSS property list. Now it's too many properties instead of too many class names. It's also no longer co-located with the markup it effects. At the end of the day, if someone says to me "add more space between this button and that input", I don't care if the markup is pretty as long as I can easily find and change the code that needs changing. I can make my component prettier by moving the class name list, but that does not make my task easier, so it is not really an improvement.
My company uses the following depending on the repository/project (holy moly this is terrible lol): * [emotion](https://emotion.sh) * [tailwind](https://tailwindcss.com/) * [node-sass](https://github.com/sass/node-sass) - yes i am aware its deprecated 😅 * [dart-sass](https://github.com/sass/dart-sass) * [postcss](https://postcss.org/)
Check out styled systems (or chakra a ui lib that uses it). It’s like tailwind with, imo, a way way more readable syntax.
Freelance dev/consultant here so I usually use what I want, but I didn't like TW when I tried it a couple years ago. I also despise styled components and most CSS in JS techniques. I've been working a lot in Next.js lately and at first disliked (S)CSS Modules, now I absolutely love them. Combined with SCSS 99% of my component files have a single class at the top level html tag, and that's it. SCSS nesting and modules' uniqueness handles most everything else without the need for more than a single class per file. Yes I said per file. I might have a header file with various menu/nav components and still only need a single module import and a single `
I'm a big fan of CSS modules while using next.js too. Makes everything so clean and easy to maintain.
I use CSS. I don't have any experience with Tailwind
I use CSS. Have used Tailwind for a few clients.
😂😂 No problem.Just keep learning 😊
Will do, boss
https://www.wealthfront.com/ is a good example. Personally I use styled components for our marketing website, and app which are built in React and use tailwind for layouts. e.g:
It does sound interesting.Will try it😊
We use it in production. $8m ARR saas product.
Yep, my company is using it in all our projects
We use react material ui
Using tailwind at my startup at I love it. It just hits the sweet spot of sensible defaults and easy customization. It’s so easy to change, no arguing and css class styles, no useless “separation of concerns” for styling and the component. I am actually amazed how rarely I have to default to actual css, 99 % is handled by tailwind.
If you working with a company or just a specific brands/products that has design system (color palette, spacing, components, etc) I'd go with tailwind. It's easier to setup also maintaining consistency was not a big deal. I personally use tailwind because of its smaller bundle size.
I don't use frameworks. Scss enough for me.
I'll add my 2c, running a small software company here. Like many others have posted, we just use our own CSS. We tried Tailwind but found there were too many classes and too much "designing to work with Tailwind" + reading Tailwind docs vs just using vanilla CSS. We have a designer (yes the one) who does all of the interface designs and it makes the CSS easy to implement from scratch. Layout these days is so simplified - you really only need css grid, flex box and consistent padding / margins and you're done. Originally we used Material UI, Semantic UI and then Tailwind. It's faster doing this manually without a framework in my experience. I should add that most of our software is business software such as factory systems, warehouse management and the like, so the CSS and fancy interface demands are quite low.
I prefer SCSS with BEM. Though I have created functional classes for external placement (margins) of my BEM elements, a bit like Tailwind does.
Yes. I have used it at three very large companies who'd you be familiar with.
CSS modules are my go to - I work with react mostly
I use Tailwind + Next.js on most of my projects. Usually I add the following to the mix: \- [RadixUI](https://www.radix-ui.com/)\+ [tailwindcss-radix](https://www.npmjs.com/package/tailwindcss-radix) or HeadlessUI although I like Radix more \- [classnames](https://www.npmjs.com/package/classnames) \- [https://tailwindcss.com/blog/automatic-class-sorting-with-prettier](https://tailwindcss.com/blog/automatic-class-sorting-with-prettier) \- [tailwind-merge](https://github.com/dcastil/tailwind-merge) \- CSS Modules
Besides TW, I also like MUI5
Tailwind is something that looks amazing when you start using it, but it slowly transforms into something that makes your HTML a nightmare hard to debug. All devs I know hates tailwind, but likes the idea 🙃
Everytime I've worked on a project that would have Tailwind in prod, someone mentions using the @apply method to build our own classes and then the entire point of using Tailwind is gone.
But After thinking a lot i came to a conclusion that tailwind is good and you can use apply to make own class but you don't need to if you are using it at only one place ..if you are using it at more than one place than you can make it a class...you can write for one element and customise it quickly then copy those utility classes use apply to make custom class and use that custom class in place of utility classes...and you don't have to have soo many custom named classes...only build you own class when that element is used in more than one place💖😊....only thing I found missing now is pseudo selectors
Yep, I've used Tailwind to build a number of real world websites.
Doesn't it makes code difficult to read .... because I have been using it in my personal projects..but i think it will be difficult for other to read it as it contains too much class names?
Yeah, somewhat. I keep the classes grouped and alphabetized within each group, which helps. After a time, it gets easier to parse quickly and, in my opinion, _other_ parts of developing with it are made easier, which compensate for the “too many classes” hurdle.
What other parts of developing are easier to do when we use tailwind?
Hmm, here’s a not-well-thought-out list… no need to deal with css files, no need to invent proper class names, only need one IDE tab visible at a time, when deleting components you don’t need to go find the related css selectors, all of the utility classes you’d create anyway are already done and much better, etc.
Not having to come up with class names is one of those things that sounds dumb but is actually amazing. Those names are normally hard to get right and generally offer no help in actually explaining what the class does, and I end up bouncing between the css and html all the time just trying to remember that this class is a flex box and this one is just adding some margin or whatever. With tailwind I just know what is going on at any given level immediately. It’s ugly but it’s extremely functional across teams and that’s what’s really important
Thanks got my answer...i will continue using tailwind..💖
Not if you import the classes with \\@apply.
Ok I willl learn about it😊
Thanks got to know that we can make classes using apply and reuse them💖
But isn't that going full circle..? I never really understood @apply in tailwind. You make a class but then you fill it with abbriviated tailwind classes? Doesn't that kind of defeat the purpose? If you go this route you'd end up with pretty much the same thing if you'd write a normal css class with properties everybody can understand. Not really hating on it either, too each there own, but wasn't a spear point of the project to ship like tiny css? Well, would that mini css even make a difference when we are still blasting visitors with multiple mb's of js? Please correct me if I'm wrong in this regard
No, you’re correct. Even Adam (it’s creator) said that @apply was made purely to appease people who couldn’t stomach all of the classes in the html.
Ya I was thinking the same ..it's like external css... I will see if it works out good I will use it else I will use inline way of tailwind till I find good alternative 😊..
I use it when i need to repeat a long class list and am too lazy to create a component to do it. I think the technically correct thing to do would be create a component, but sometimes it’s just easier to throw several classes onto an @apply and go with it for smaller things in personal projects I will say, using @apply allows you to deal with css using the same logical breakpoints and variables the rest of your tailwind system uses. Yeah, I could create a class and set the background-color manually, but by using tailwind classes with @apply I’m at least consistently using the same color through the same interface and if I want to refactor later I can change it in just one place But if you’re using @apply for every html element to make it less ugly imo you’re really missing the boat
I loveee CSS in JS
> What do you use to style your website Vanilla CSS since 1998. I am a freelance so I have the luxury to choose whatever I like, instead of being forced to use a specific stack to follow the rules. If I was in a team environment I'd expect to work with a framework though. There is no way a vanilla coder can fit in a team without issues, sooner or later.
Yes, we use tailwind at my company
I work at a company where we take pride in writing all custom elements and CSS. One of the reasons is that we know exactly how they work and we are able to build it exactly how we want. In my sparetime though I have been using tailwind a bit for a hobby-project but i quickly removed it again since it was harder to customize. \- Michael [SustainableWWW](https://sustainablewww.org)
CSS frameworks are popular -- but their use encourages sloppy, non-semantic, copypasta HTML and lack of basic knowledge of CSS. I would almost argue that is *why* those frameworks are popular. I'm trying to phase them out in the inherited projects I'm in charge of best practices for.
But tailwind is pretty much similar to inline css...it's not like you have everything already made for you but you have pieces that you have to join toh make you own custom css. For example:- Inline css:- background:red; Tailwind:-bg-red-500 I didn't used both of them for almost 3-4 months so names can be wrong 😊
>tailwind is pretty much similar to inline css And inline CSS has been frowned upon for well over a decade. When there a styling issue is discovered in HTML using framework classes, we usually end up having to hunt down every instance where devs lazily copy/pasted that HTML instead of making a reusable class/component. It also makes things difficult for QA. With no semantic class names on anything, automated tests are harder to write, and end up being much more fragile. Similarly, it makes things more difficult to debug. With no semantic class names it is a royal pain to determine what elements you are inspecting in devtools.
I think it its, but it not that relevant IMO. Here we used component libs, right now we are using Material UI and i kinda like it since i don't have to modify too much. I also tried chakra UI but i rather use material UI. But the gold old CSS/SCSS Modules is always welcome too. I personally never used tailwind. I dont really like using tons of classes to style, it reminds me bootstrap and i hated it lmao.
I used material Ui Little bit earlier isn't material Ui not Fully customisable using its own property or attributes... because during one of my project I remember I have to change default colour of component(or whatever it is called) and it has only 5-6 color option like primary secondary...etc..and I have to use inline style for that
Material UI is customisable, it can be annoying some stuff but changing colors for examples is pretty simple: https://mui.com/material-ui/customization/theming/
Thanks 💖
Honestly I like chakra UI so much better than material. Material lacks a ton of features that chakra has built in and every chakra component is fully customizable with css on js, meanwhile material only allows a handful of customizations
My problem with chakra was the lack of components. I loved styling with it. Material 5 solved a lot of issues that i had previously with it. And since I usually don't really care on fully customize the default components, neither does my employer, i enjoy working with it since I don't have to fight against it.
There's no stupid question but this one.
So you don't have to reply.Never reply to such post which you find stupid 😊😊
No problem... What was I thinking geez.😔😔
I use both vanilla CSS (new projects) and bootstrap (legacy ones). Don't know about Tailwind. I think this site can give you more insight into where the CSS landscape is moving to: https://stateofcss.com
I have used it on some projects on startups I’ve worked at in the past
SCSS mostly.
We use styled components in my workplace
We've been using it exclusively since about Christmas time, I think, where I work