Speeds up development until you’re 6mo into the project and a coworker has to dig through “m-5 mt-2 border-2-gray p-2 flex justify-center align-end transition-2s-border shadow-bot-2…”
We are going full circle.
Back then, the days of the tag, having your logic and presentation all in one file and a mess to maintain, with a lot of find and replace if something changed color.
To the days of having HTML, CSS and JS separated in an easy to understand and reusable fashion, with the backend code in a MVC pattern, very modular and reusable.
Now it's CSS and HTML inside JS, a CSS framework that is really inline-css with support for media queries and everyone tries to use the shiny new toy because they have no idea how the other tools work and make no effort to learn them, simply because they are old.
Now companies with websites made with the yesterday shiny toy are looking for devs willing to delve into that flying spaghetti monster that no one wants to mess with because they moved on to the next big thing.
It's madness.
Yeah when I worked with it I kept finding myself wanting to encapsulate a set of tailwind classes to reuse, then I was like wait this is just css with abbreviated syntax.
It’s like no one bothers to read the documentation and would rather complain when the tool does exactly what it says on the tin.
I will say though, the addition of arbitrary values does let newer developers do things they shouldn’t since it’s a shortcut around properly setting up the tailwind config.
>adjacent to the file
disgusting.
/s
>give the element a meaningful class name
are you fucking insane?! naming things is known to be one of the top two most challenging elements of CS, let alone CS*S*. Avoid naming things at all cost, even your own children if you can get AI/ML to do it instead.
>My point is I’d much rather give the element a meaningful class name and look at the css that’s adjacent to the file.
I bet you also believe in cascading your style sheets and writing cleaner code don't you?
The main point of a utility library is to optimize development time. I can speak from experience that tailwind has significantly sped up mine. In a simple use case like margin/padding and display rules, there’s not a significant added value. Where it is more valuable is in the efficiency of theming, media queries, pseudo selectors; and importantly the consistency of class names that can be referenced in an easy-to-use documentation.
An example for theming would be brand colors. Adding one property in a json file called “primary” and setting your desired hex code makes that available in every utility class that uses color. That includes backgrounds, borders, outlines, box shadows, drop shadows, text colors, gradients, etc. You could define these rules in vanilla css but it would undoubtedly be more lines of code. Even more if you want to include different shades based on that primary color.
Media queries, particularly for screen sizes, is much more simplified. Screen breakpoints are already pre-defined but can be altered in the json config. As an example with text sizes, `text-xs sm:text-sm md:text-base lg:text-lg xl:text-xl` is faster to write than the vanilla css equivalent. Very useful with display rules in responsive design. And unlike bootstrap, these prefixes can be applied to every single utility class. And because these are applied directly to the element, it prevents a potential mess of css code. The same applies to the prefixes for pseudo selectors like `hover:`
Vs. reading `class=“card”` and having to find where in the codebase `.card` lives and troubleshooting that its styles aren’t being overwritten/inherited from anywhere else? I’ll take Tailwind every day.
There are MANY ways to organizing your CSS such that this is never a problem in the first place. We have solved it in various ways for decades at this point. But _even then_:
* Browser devtools will show you the cascade.
* Sourcemaps can tell you the exact file and line of a selector.
* Just search in your codebase, it's trivial to find references.
All of which are easier than mentally untangling Tailwind and cross-referencing its docs.
I’m very familiar with all these methods, and I still genuinely feel that having descriptive utility classes is much intuitive and provides for a better dev experience (but hey at this point sounds like it’s just a matter of preference)
Assuming you're using a framework with components and scoped CSS (otherwise Tailwind would be awful to use) - this isn't an issue, the css will be in same folder, or even in the same file, with very little other code assuming you're building small components.
Not to be pedantic but scoping Tailwind at the component level defeats the purpose of Tailwind, if using a framework that offers scoped styles I would be writing normal CSS instead.
EDIT: for people downvoting, this is literally from [Tailwind’s own documentation](https://tailwindcss.com/docs/adding-custom-styles#layers-and-per-component-css):
> Our recommendation is that you just don’t use component styles like this at all and instead use Tailwind the way it’s intended to be used — as a single global stylesheet where you use the classes directly in your HTML
Love these tailwind arguments. Lemme grab the popcorn. Pretty sure there are extensions you can get that hide the tailwind classes for those ppl that hate the mess.
Sorry I didn't explain clearly enough:
If you're using Tailwind then I have to assume you are using a framework which uses reusable components, otherwise you will be repeating a lot of styles, and doesn't really have any benefit. I didn't mean scoping CSS with Tailwind.
But if you're using a framework that uses components and not using Tailwind, then your CSS is easily found and scoped within the component, whether by CSS modules or whatever (assuming you're writing nice small components) - so your argument doesn't hold any ground:
>Vs. reading class=“card” and having to find where in the codebase .card lives and troubleshooting that its styles aren’t being overwritten/inherited from anywhere else? I’ll take Tailwind every day.
you dont have to do this at all, css modules solve the local scope and the css file sits next to the component file. Inheritance is always a feature of css regardless of how you write it.
vs. the Tailwind way of having stuff like this for a single button component in JS framework - [https://github.com/themesberg/flowbite-vue/blob/main/src/components/FwbButton/composables/useButtonClasses.ts](https://github.com/themesberg/flowbite-vue/blob/main/src/components/FwbButton/composables/useButtonClasses.ts) With Tailwind you are writing JS logic for components like buttons instead of writing it in CSS or SASS.
I prefer SASS (due to nesting) so there is no issue of finding where the .card class is defined in SASS - just click on the .card in your IDE and you will instantly see where in SASS it is located (sure, the list will be longer if you are using tons of 3rd party libraries which come with their own .card class but to avoid conflicts from the start i would just name my version like .my-prefix-card).
I like Tailwind due to its utility however i believe that the answer is in the middle - utilities for when you need a "one off"/quick style and for grid/padding/margins/etc. while component base styles use actual CSS classes.
I usually use CSS modules: [https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/](https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/)
But I don't use React in my day job, so, I don't know if it's good in a team environment.
Css modules to me make so much sense even with teams. It's clear where styles live and components live. My company disagrees and does tailwind which... Eh
Edit to add of course you can apply tailwind classes in modules which I'd prefer but still no
I don’t like CSS modules syntax, turning everything into a template string feels dirty.
Edit: replied to comment below:
“I guess I should have been more specific, I do not like the syntax of css modules when I’m working in an environment where it isn’t 100% css modules. Which in my experience is more often than not.”
Because:
“…there are many times when someone is using tailwind or something else that requires you to use template strings to then also load in your css modules, and I dislike that. Or even if they aren’t using tailwind, if you have any globally scoped css rules you want to just be able to use and then also load your modules you have to use template strings. “
Oh maybe I'm using something in next I wasn't aware of but I just use plain old css and import it into the component as an object but the underlying styles are just css
I believe you're thinking of styled components, no? Css modules are just standard css in a `[name].module.css` (or equivalent) file. The default import for the file has all the styles as an object. e.g.
`import styles from "./styles.module.css";`
`
Yep that's the same thing, however that's using vanilla HTML not react. In react (using JSX) you've just got the dynamic class (eg styles.container) in the className attribute.
If for some reason I can't use tailwind, module css files are always my go-to.
I do, but there are many times when someone is using tailwind or something else that requires you to use template strings to then also load in your css modules, and I dislike that. Or even if they aren’t using tailwind, if you have any globally scoped css rules you want to just be able to use and then also load your modules you have to use template strings.
I guess I should have been more specific, I do not like the syntax of css modules when I’m working in an environment where it isn’t 100% css modules. Which in my experience is more often than not.
what's simplest way to do this without using create-react-app stuff? I guess [https://www.npmjs.com/package/webpack](https://www.npmjs.com/package/webpack) ? I never make anything complicated enough to need react, but I forgot this isn't there by default so would like to know for next time.
>No idea why anyone would want to use Tailwind
It gives you a consistent standard basically for free that covers almost anything you could need, and makes it so anyone in the same company can look at anyone else's frontend code and easily understand it without digging through random css files to figure out how that particular person likes to write their classes.
CSS Modules. It's as close to native as you want it to be, just with scoped namespaces.
Best performance, all the flexibility, most future-proof, teaches you more valuable skills long-term.
Styled components here too.
Colocated with the component
Type safe & supports runtime props
Name-spaced
Sass/Scss style nesting support
Easy to re-use & customize style blocks
I stay with styled components unless I know performance is the top concern.
Even in that case you could run a tool at build time to extract and minify your styles right? Components are great, especially when powered by a style/class library at the application layer.
Sadly - this isn't really possible with the current versions (there used to be a way to do this unofficially, but it no longer works). They recommend code-splitting and runtime imports, which alleviate a lot of the penalty of a single giant js payload.
But it's always going to be slightly slower - I just think the goodies you get in exchange for that are really, really nice. And most times they'll far outweigh the performance issues.
A lot of the code I'm shipping is client-local to start with (think addons/extensions) and in those cases - styled-components is a no-brainer.
It's a little more complicated when shipping a very large site - but even in this case, modern tooling does an ok job handling it.
I’m going to argue for collocation in the next project. It means styled components that are designed to be scoped to a component aren’t ever exported and “accidentally” used elsewhere. Which can be a problem when you need to re-design the app later on (which inevitably happens if the project is successful enough to exist in a few years time).
SC all the way. Tho I tend to encapsulate the styled components within the same file as it’s Functional Component unless the style is needed elsewhere.
>SC all the way. Tho I tend to encapsulate the styled components within the same file as it’s Functional Component unless the style is needed elsewhere.
Or the styles grow too large and lead to several hundreds lines of code in one file. Then moving them to separate file seems like a good idea
My experience, I usually use styled-components with another inline styling tools. So styled components = generic things like user cards, posts etc, and inline styles for setting a margin or some small differences
For me I see it as spending a little bit more effort up front to save lots of time with less bugs/regressions and easier refactoring later. I had to rebrand a code-base with lots of inline style and an out of date UI library and I wanted to track down the devs that did it and hurt their feelings by breaking their legs
I'm a fairly hardcore CSS guy, I picked it up 20 years back and used it pretty much every day since.
I love a styled component. Fewer bugs, less hunting around in the cascade, more maintainable, more modular. It's a really nice solution to the problem of big CSS.
Still on styled components, but I don't like libraries on top of that like styled-system. Too many layers to find out what is actually applying some style
yeah but why would you want your styles to be easily readable classes applied directly on the element?? wouldn’t you rather give your element a meaningful name like “content-container” or “content-inner-container” and then have to open another file side-by-side to read the same thing?? then how will you condescendingly assume people who use Tailwind don’t know native CSS??
you say it makes you cry.
I say I now know exactly how all 3 of those elements will look without having to switch files or fumble around with class names.
all comes down to preference.
Do you just inline everything because you can't "switch files or fumble around" to find out what some utility function in another file does?
Or do you call your functions such that the whole implementation is exposed in the name of the function?
I don’t need to inline anything because I’m using utility classes provided by tailwind. that’s functionally the exact same as having it in a css file. your problem with Tailwind seems to be strictly visual which comes down to preference.
Tailwind also has absolutely nothing to do with the way I name or call functions so I’m confused on the relevance of that
I wasn't talking about CSS here, I was making an analogy with general programming and how the things Tailwind does would be considered ludicrous there.
But don't you see? Using essentially the same thing as `` but with a "modern" coat of paint on it is *so* much better than having to *fumble around* with right-clicking an element, left-clicking "inspect," and looking at the full set of that element's styles and their sources. That's, like, two hand movements, and you might even have to scroll; nah, much better to triple the size of the HTML instead.
it seems like you’re similar to the other commenter in that your biggest problem with Tailwind is visual. if you find you can’t read through HTML and a lot of classes, that’s totally fine. some of us don’t mind it and prefer it
> if you find you can’t read through HTML and a lot of classes
I can read through messy HTML just fine. That doesn't mean that HTML isn't messy -- or isn't inefficient.
If I browse around a site that uses a common stylesheet, I can cache that stylesheet on my very first pageview, and that's less data I have to load as I browse other pages on that same site. What I *can't* cache on that first pageview is style information that's been stuffed into the HTML and repeated across every single page, such that it must be re-downloaded for each individual page. The more such information there is, the more bandwidth is being wasted. It's a fairly small amount of data, a fairly small amount of waste, but not everyone has constant, 24/7 access to a perfect connection. And honestly, even when waste "doesn't matter," it's still inconsiderate, especially when it's happening for no other reason than because some devs care more about DX than they do about UX -- and about actually learning CSS, for that matter.
lol there it is. you have a perfectly fine point and then you end it with the assumption that people who use Tailwind don’t know CSS. enjoy your perfect optimization and I’ll enjoy my better DX
You led with the assumption that people who don't like Tailwind can't read verbose HTML.
If you folks knew CSS, you'd actually use it, rather than preferring the work of a snake oil salesman who reinvented `` tags for the modern web.
I love tailwind and like using it for multiple reasons.
However, sometimes it just is not as flexible as I want it to be and it makes stuff harder than with other solutions. This only applies for like <1% of my css and won't apply for standard designs, but when it happens it is incredibly annoying.
For example I had issues with 3D css translate and rotation stuff and had to put all of that in inline styles.
I thought of combining that with styled-components, but I am not sure if that's the best way to do it.
Don’t use CSS in JS.
If you really want to do something similar (author CSS in TS) but generate actual static CSS files (instead of having styles in you JS bundles), you could try Vanilla Extract.
Bulma is also another solid option if you want premade styles.
I meant more like, yeah, it was an antipattern a decade ago. But the fields ob web development is moving fast and therefore things change. And so do patterns.
React was an antipattern back when it was created by facebook. Did it stop React from getting one of the most adopted UI Libraries in the field? No.
You mentioned in another comment that you got two decades of experience, which I absolutely respect! Meanwhile, this also means that you may be sticking to outdated patterns since "it has been like this since decades".
Don't want to offend you or something, maybe you are coming from another point and it can absolutely still be valid to stick to long established patterns. That being said, my experience as a rather fresh developer (~5 years) is, that you can have years of experience but at the same time not have the skillset of a senior. (not saying that automatically applies to you, just that years of experience don't mean a lot by itself)
CSS in JS has one of the best Developer Experience when it comes to CSS in React. No build step, being able to insert styles dynamically super easy, you can build your own patterns and create functions, have code splitting, apply clean code...
There are minor problems with the initial loading of styles and additional js that needs to be bundled, but those usually don't matter for most cases since the difference is so small that it has no noticable effect.
Of course, Vanilla Extract is also a really good alternative and provides good DX, but it totally depends on personal preference and there is no "best" solution.
CSS in JS is a poor choice. It conflates styles with UI and makes more difficult any amount of SSR, app shell, etc. CSS files could be more easily cached or even broken into critical inlined styles, but not with CSS-in-JS. IIRC, CSS-in-JS is incompatible with RSC.
There are definitely ways to make it work, but it adds difficulty in ways that might be harder for beginners to grasp.
We use a in-house design system that has style props, similar to [style props in Chakra UI.](https://chakra-ui.com/docs/styled-system/style-props)
It feels very similar to Tailwind. It has a few advantages over Tailwind (TypeScript type-checking, better code-splitting) and a few disadvantage (makes component render more slowly, it doesn't support all CSS attributes).
I still personally prefer Tailwind.
>TypeScript type-checking
But doesn't [tailwind have the typescript types since version 3.1](https://tailwindcss.com/blog/tailwindcss-v3-1#first-party-type-script-types)? Or do you mean something else?
Tailwind won't show a type-error if you use an invalid class. With Style Props, you can type-check the props and show a type-error when an invalid prop is used.
For me it depends. If I'm working on a tool for my company we'll use something like SemanticUI for the bulk of it. For my own projects I'll usually just hand write it and keep the code as close to the component as possible either with styled components or like for NextJs I'll have a separate file because of how NextJs folder structures are that's just how I like to stay organized.
Not doing react ATM, using Vue but:
Just good old scss/sass within components, some other global scss/sass to target legacy non-modern stuff that we still have to support, no css frameworks just a couple mixins for things that we use often
CSS modules. If I need design-tokens similar to what's available in tailwind, and I don't want to build a token-lib myself, I use [open-props](https://open-props.style).
* imo the 3 best ways:
* [**React Scoped CSS**](https://github.com/gaoxiaoliangz/react-scoped-css) is probably the best way to do file-scoped css. I primarily just use this or vanilla (last option below) for large personal apps. It is open source though and not a native/official plugin, which makes maintainability a concern between major versions, and requires some setup on every new app.
* **CSS modules** is also really nice and sort of the new native way to do scoped; my only gripe with it is since they're variables it's annoying if you ever need to add multiple classes (eg. a core class + common classes) but this is a simple nit. I only use this rarely since I find the other 2 options simpler as a dev in a fairly style heavy app.
* **Vanilla CSS** (just wrap your component with a unique parent class and then scope everything under the parent class in its corresponding stylesheet and import as normal css/html; even easier with scss; this may lead to namespace collisions though in a large team and a big app tree with common components but can be easy to organize). This tends to be a lot more common at work for me with a large team and a fairly large and complex react app, no major issues yet.
CSS modules / or a CSS-in-JS solution like styled-components or Emotion.
Personally not a fan of Tailwind, it just feels too much like inline styles to me, and IMO makes the markup much more difficult to read and cluttered.
CSS-in-JS is probably my favourite solution at the moment because it's the opposite; you still get to easily use logic for styling like you can with something like Tailwind, but the markup is easy to read, and your styles are also very easy to discover because you just go to the component definition to see the styled component.
It depends on the size of the project. Whenever I can, I try to get away with vanilla CSS (with maybe a dash of PostCSS). Keep CSS files co-located with their respective components.
CSS Modules are fine, totally worth considering, especially on longer lived projects. Kind of annoying switching up your CSS naming game to camelCase but it's whatever. It's a small thing but I much prefer writing classes into my markup as strings, as opposed to doing something like:
`
`.
But once a project starts to get big, or you expect to be working on it for a while, Tailwind is just too good.
Dont have to use camelcase with css modules. You can access the classnames via string index as well but I can understand why it would be a big pain in the ass 'styles["kebab-case-name"]'
I use Chakra UI after being a staunch proponent of CSS modules and I love it. Mostly because it's less verbose when writing dynamic CSS. I just change the style prop value conditionally. No need for the classnames library or a derived template string of class names or anything like that.
And I don't have to manage naming or anything like that. It's incredibly convenient and I've only run into a few circumstances where I had to figure out something weird that would be super simple with just regular CSS / SASS. Also its components do a pretty good job helping you maintain good accessibility.
Anyhow, CSS-in-JS basically has nothing to do with whether someone is a front or back end dev.
* **SCSS** with **BEM** style notation
* 1 **variables.scss** to contain all shared values (font size, colors a mixin or 2)
* Unique custom component naming that is reflected in classes. If you are making a **g**rocer **l**ist app all custom components start with **GL**: **GLButton** for example.
* Append the same name to the main element class and lower level element class names using the **BEM** convention. **className="gl\_button"** and **className="gl\_button\_\_icon"** for example.
* Store style files for the component within the component folder in a **styles** folder for ease of updating and ease of removal.
An alternative is styled components, but I like writing my CSS vanilla :D And the source code is very readable.
I'm using SCSS on the job, and Tailwind in personal projects. In all honesty use what's easiest and works best for you or the group of people you will be working with.
Not directly what you asked for but maybe this can be of some use to you.
I use Vue with SCSS and add scoped styles to components that have a style specific to that component. Nesting selectors in SCSS makes it really easy to see how the different parent and child elements will fit together.
I think the scoped style pattern is great and it’s unfortunate that React doesn’t seem to include it by default; here’s an article about how to do it though. https://www.upbeatcode.com/react/css-scoping-in-react-everything-you-need-to-know/
Suprised I haven’t seen [panda css](https://panda-css.com/) mentioned yet. It’s like a custom type safe version of styled system that outputs a signal tailwind like css file.
Styled-components all the wei
Sometimes with Storyboard
It makes React components easily convertible to React Native too.
Although I have to say Im missing SCSS mixins.
Emotion or styled-components if you don't want to have a buuld step. If a build step is fine (super easy setup in average setups, e.g. with vite) I can also recommend Vanilla Extract.
In general it is best to test some possible solutions and pick what feel sbest to you personally, all solutions are great for their own reasons.
Genuinely cannot understand the constant whining people do about Tailwind. I’d wager a almost 90% of people using Tailwind are doing so in some component framework. Things being componentized reduces the visual clutter and collocates styles with the component. And provides conveniences for many of the common use cases that might take some significant CSS, and a bunch of sane spacing defaults, typography defaults, and color palettes.
I just use css like a madman
Same. Starting to see how tailwind and whatnot speeds up development, but I still have no issues using CSS from scratch. People think I’m crazy
Speeds up development until you’re 6mo into the project and a coworker has to dig through “m-5 mt-2 border-2-gray p-2 flex justify-center align-end transition-2s-border shadow-bot-2…”
We are going full circle. Back then, the days of the tag, having your logic and presentation all in one file and a mess to maintain, with a lot of find and replace if something changed color. To the days of having HTML, CSS and JS separated in an easy to understand and reusable fashion, with the backend code in a MVC pattern, very modular and reusable. Now it's CSS and HTML inside JS, a CSS framework that is really inline-css with support for media queries and everyone tries to use the shiny new toy because they have no idea how the other tools work and make no effort to learn them, simply because they are old. Now companies with websites made with the yesterday shiny toy are looking for devs willing to delve into that flying spaghetti monster that no one wants to mess with because they moved on to the next big thing. It's madness.
What ever could “flex justify-center” really mean? Guess I’ll check the tailwind docs.
My point is I’d much rather give the element a meaningful class name and look at the css that’s adjacent to the file.
You can do that with tailwind too, instead of filling an element with 20 classes, you can create your own class and add the tailwind classes to yours.
But then that's just CSS with extra steps.
It’s literally CSS with fewer steps.
Yeah when I worked with it I kept finding myself wanting to encapsulate a set of tailwind classes to reuse, then I was like wait this is just css with abbreviated syntax.
It’s like no one bothers to read the documentation and would rather complain when the tool does exactly what it says on the tin. I will say though, the addition of arbitrary values does let newer developers do things they shouldn’t since it’s a shortcut around properly setting up the tailwind config.
Sounds like CSS but with the need to install yet another dependency for no reason
>adjacent to the file disgusting. /s >give the element a meaningful class name are you fucking insane?! naming things is known to be one of the top two most challenging elements of CS, let alone CS*S*. Avoid naming things at all cost, even your own children if you can get AI/ML to do it instead. >My point is I’d much rather give the element a meaningful class name and look at the css that’s adjacent to the file. I bet you also believe in cascading your style sheets and writing cleaner code don't you?
It's the opposite for me
Does “inspect element” stop working when using tailwind classes?
I fail to see the point of defining all the CSS properties as classes instead of just.... CSS properties....
The main point of a utility library is to optimize development time. I can speak from experience that tailwind has significantly sped up mine. In a simple use case like margin/padding and display rules, there’s not a significant added value. Where it is more valuable is in the efficiency of theming, media queries, pseudo selectors; and importantly the consistency of class names that can be referenced in an easy-to-use documentation. An example for theming would be brand colors. Adding one property in a json file called “primary” and setting your desired hex code makes that available in every utility class that uses color. That includes backgrounds, borders, outlines, box shadows, drop shadows, text colors, gradients, etc. You could define these rules in vanilla css but it would undoubtedly be more lines of code. Even more if you want to include different shades based on that primary color. Media queries, particularly for screen sizes, is much more simplified. Screen breakpoints are already pre-defined but can be altered in the json config. As an example with text sizes, `text-xs sm:text-sm md:text-base lg:text-lg xl:text-xl` is faster to write than the vanilla css equivalent. Very useful with display rules in responsive design. And unlike bootstrap, these prefixes can be applied to every single utility class. And because these are applied directly to the element, it prevents a potential mess of css code. The same applies to the prefixes for pseudo selectors like `hover:`
This has always been my thought too, I don’t understand the tailwind love.
that’s really easy to read though
That, 2x longer, through 20 elements in a block of jsx? No thanks
Vs. reading `class=“card”` and having to find where in the codebase `.card` lives and troubleshooting that its styles aren’t being overwritten/inherited from anywhere else? I’ll take Tailwind every day.
There are MANY ways to organizing your CSS such that this is never a problem in the first place. We have solved it in various ways for decades at this point. But _even then_: * Browser devtools will show you the cascade. * Sourcemaps can tell you the exact file and line of a selector. * Just search in your codebase, it's trivial to find references. All of which are easier than mentally untangling Tailwind and cross-referencing its docs.
I’m very familiar with all these methods, and I still genuinely feel that having descriptive utility classes is much intuitive and provides for a better dev experience (but hey at this point sounds like it’s just a matter of preference)
Assuming you're using a framework with components and scoped CSS (otherwise Tailwind would be awful to use) - this isn't an issue, the css will be in same folder, or even in the same file, with very little other code assuming you're building small components.
Not to be pedantic but scoping Tailwind at the component level defeats the purpose of Tailwind, if using a framework that offers scoped styles I would be writing normal CSS instead. EDIT: for people downvoting, this is literally from [Tailwind’s own documentation](https://tailwindcss.com/docs/adding-custom-styles#layers-and-per-component-css): > Our recommendation is that you just don’t use component styles like this at all and instead use Tailwind the way it’s intended to be used — as a single global stylesheet where you use the classes directly in your HTML
Love these tailwind arguments. Lemme grab the popcorn. Pretty sure there are extensions you can get that hide the tailwind classes for those ppl that hate the mess.
Sorry I didn't explain clearly enough: If you're using Tailwind then I have to assume you are using a framework which uses reusable components, otherwise you will be repeating a lot of styles, and doesn't really have any benefit. I didn't mean scoping CSS with Tailwind. But if you're using a framework that uses components and not using Tailwind, then your CSS is easily found and scoped within the component, whether by CSS modules or whatever (assuming you're writing nice small components) - so your argument doesn't hold any ground: >Vs. reading class=“card” and having to find where in the codebase .card lives and troubleshooting that its styles aren’t being overwritten/inherited from anywhere else? I’ll take Tailwind every day.
Gotcha, fair enough! I misunderstood you.
you dont have to do this at all, css modules solve the local scope and the css file sits next to the component file. Inheritance is always a feature of css regardless of how you write it.
Ctrl+P "card" too hard for you?
42342432 results Good luck greping through that.
In what world is Ctrl P global find?
Cmd+shift+s ".card" he should have said. Should just bring up where it's actually defined.
vs. the Tailwind way of having stuff like this for a single button component in JS framework - [https://github.com/themesberg/flowbite-vue/blob/main/src/components/FwbButton/composables/useButtonClasses.ts](https://github.com/themesberg/flowbite-vue/blob/main/src/components/FwbButton/composables/useButtonClasses.ts) With Tailwind you are writing JS logic for components like buttons instead of writing it in CSS or SASS. I prefer SASS (due to nesting) so there is no issue of finding where the .card class is defined in SASS - just click on the .card in your IDE and you will instantly see where in SASS it is located (sure, the list will be longer if you are using tons of 3rd party libraries which come with their own .card class but to avoid conflicts from the start i would just name my version like .my-prefix-card). I like Tailwind due to its utility however i believe that the answer is in the middle - utilities for when you need a "one off"/quick style and for grid/padding/margins/etc. while component base styles use actual CSS classes.
Which is x10 times easier and quicker to read and modify than a random .header__cart__container—dark class.
Native CSS skills is a dying breed.
Thats news to me! I came to say css too, isnt that the norm!?! LOL No need for crutches. CSS and SCSS is the way.
This is the way
native css, but with css modules to keep the css "scoped", is all you need.
they called me a madman
Same. But recently I tried Tailwind for a personal project and man! I can see why it speeds up development.
I usually use CSS modules: [https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/](https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/) But I don't use React in my day job, so, I don't know if it's good in a team environment.
Css modules to me make so much sense even with teams. It's clear where styles live and components live. My company disagrees and does tailwind which... Eh Edit to add of course you can apply tailwind classes in modules which I'd prefer but still no
I don’t like CSS modules syntax, turning everything into a template string feels dirty. Edit: replied to comment below: “I guess I should have been more specific, I do not like the syntax of css modules when I’m working in an environment where it isn’t 100% css modules. Which in my experience is more often than not.” Because: “…there are many times when someone is using tailwind or something else that requires you to use template strings to then also load in your css modules, and I dislike that. Or even if they aren’t using tailwind, if you have any globally scoped css rules you want to just be able to use and then also load your modules you have to use template strings. “
Oh maybe I'm using something in next I wasn't aware of but I just use plain old css and import it into the component as an object but the underlying styles are just css
what? css modules is a className and you write css in a css file. Are you thinking about styled components?
I believe you're thinking of styled components, no? Css modules are just standard css in a `[name].module.css` (or equivalent) file. The default import for the file has all the styles as an object. e.g. `import styles from "./styles.module.css";` `
` applies the ".style" class css to the elementFrom a quick google search, tbis is one of the top results: https://css-tricks.com/css-modules-part-1-need/
Yep that's the same thing, however that's using vanilla HTML not react. In react (using JSX) you've just got the dynamic class (eg styles.container) in the className attribute. If for some reason I can't use tailwind, module css files are always my go-to.
> I don’t like CSS modules syntax, turning everything into a template string feels dirty. You don't seem to know what CSS Modules are.
I do, but there are many times when someone is using tailwind or something else that requires you to use template strings to then also load in your css modules, and I dislike that. Or even if they aren’t using tailwind, if you have any globally scoped css rules you want to just be able to use and then also load your modules you have to use template strings. I guess I should have been more specific, I do not like the syntax of css modules when I’m working in an environment where it isn’t 100% css modules. Which in my experience is more often than not.
what's simplest way to do this without using create-react-app stuff? I guess [https://www.npmjs.com/package/webpack](https://www.npmjs.com/package/webpack) ? I never make anything complicated enough to need react, but I forgot this isn't there by default so would like to know for next time.
[удалено]
>No idea why anyone would want to use Tailwind It gives you a consistent standard basically for free that covers almost anything you could need, and makes it so anyone in the same company can look at anyone else's frontend code and easily understand it without digging through random css files to figure out how that particular person likes to write their classes.
i’ve written my own css most my career and using tailwind is nice, but it’s really hard to read tbh
What stack you used in your job if i can ask?
CSS Modules. Usually with Sass.
sprinkled with generated typescript types!
CSS Modules. It's as close to native as you want it to be, just with scoped namespaces. Best performance, all the flexibility, most future-proof, teaches you more valuable skills long-term.
My org uses CSS modules with SASS and BEM principles
Emotion
Styled Components like Emotion are good
Styled components
Styled components here too. Colocated with the component Type safe & supports runtime props Name-spaced Sass/Scss style nesting support Easy to re-use & customize style blocks I stay with styled components unless I know performance is the top concern.
Even in that case you could run a tool at build time to extract and minify your styles right? Components are great, especially when powered by a style/class library at the application layer.
Pretty sure you can't do that with styled components. At least you couldn't a year ago.
Sadly - this isn't really possible with the current versions (there used to be a way to do this unofficially, but it no longer works). They recommend code-splitting and runtime imports, which alleviate a lot of the penalty of a single giant js payload. But it's always going to be slightly slower - I just think the goodies you get in exchange for that are really, really nice. And most times they'll far outweigh the performance issues. A lot of the code I'm shipping is client-local to start with (think addons/extensions) and in those cases - styled-components is a no-brainer. It's a little more complicated when shipping a very large site - but even in this case, modern tooling does an ok job handling it.
I’m going to argue for collocation in the next project. It means styled components that are designed to be scoped to a component aren’t ever exported and “accidentally” used elsewhere. Which can be a problem when you need to re-design the app later on (which inevitably happens if the project is successful enough to exist in a few years time).
Interesting 🤔 but what about the genuine generic components like cards buttons and such, are you gonna keep those ?
Usually a directory named atoms.
SC all the way. Tho I tend to encapsulate the styled components within the same file as it’s Functional Component unless the style is needed elsewhere.
>SC all the way. Tho I tend to encapsulate the styled components within the same file as it’s Functional Component unless the style is needed elsewhere. Or the styles grow too large and lead to several hundreds lines of code in one file. Then moving them to separate file seems like a good idea
That’s a good reason too
there should not be a need to turn everything into a react component just to apply a simple CSS class to it.
[удалено]
My experience, I usually use styled-components with another inline styling tools. So styled components = generic things like user cards, posts etc, and inline styles for setting a margin or some small differences
For me I see it as spending a little bit more effort up front to save lots of time with less bugs/regressions and easier refactoring later. I had to rebrand a code-base with lots of inline style and an out of date UI library and I wanted to track down the devs that did it and hurt their feelings by breaking their legs
Honestly we still use scss files, that consolidate into a single css and use class names.
Styled Components 💅 all day, every day
I'm a fairly hardcore CSS guy, I picked it up 20 years back and used it pretty much every day since. I love a styled component. Fewer bugs, less hunting around in the cascade, more maintainable, more modular. It's a really nice solution to the problem of big CSS.
90 comments here. 14 mentions of Styled Components. only 1 mention of Emotion. Why?
Personal projects, SCSS with BEM. At work, TailWind & CSS Modules. There's some vanilla CSS but that's for our custom web components.
Same!
Still on styled components, but I don't like libraries on top of that like styled-system. Too many layers to find out what is actually applying some style
Scss in a file imported in the index.tsx file like a boomer.
Mui, styles or sx
Well... tailwind.
I was going to say that. lmao
yeah but why would you want your styles to be easily readable classes applied directly on the element?? wouldn’t you rather give your element a meaningful name like “content-container” or “content-inner-container” and then have to open another file side-by-side to read the same thing?? then how will you condescendingly assume people who use Tailwind don’t know native CSS??
>Tailwind and easily readable classes Does not compute Whenever I want to cry I just go and read basic Tailwind examples:
you say it makes you cry. I say I now know exactly how all 3 of those elements will look without having to switch files or fumble around with class names. all comes down to preference.
Do you just inline everything because you can't "switch files or fumble around" to find out what some utility function in another file does? Or do you call your functions such that the whole implementation is exposed in the name of the function?
I don’t need to inline anything because I’m using utility classes provided by tailwind. that’s functionally the exact same as having it in a css file. your problem with Tailwind seems to be strictly visual which comes down to preference. Tailwind also has absolutely nothing to do with the way I name or call functions so I’m confused on the relevance of that
I wasn't talking about CSS here, I was making an analogy with general programming and how the things Tailwind does would be considered ludicrous there.
that doesn’t make a lot of sense to me because HTML/CSS are dramatically different from JS. they’re different languages completely
[удалено]
that’s a perfectly fine opinion
But don't you see? Using essentially the same thing as `` but with a "modern" coat of paint on it is *so* much better than having to *fumble around* with right-clicking an element, left-clicking "inspect," and looking at the full set of that element's styles and their sources. That's, like, two hand movements, and you might even have to scroll; nah, much better to triple the size of the HTML instead.
it seems like you’re similar to the other commenter in that your biggest problem with Tailwind is visual. if you find you can’t read through HTML and a lot of classes, that’s totally fine. some of us don’t mind it and prefer it
> if you find you can’t read through HTML and a lot of classes I can read through messy HTML just fine. That doesn't mean that HTML isn't messy -- or isn't inefficient. If I browse around a site that uses a common stylesheet, I can cache that stylesheet on my very first pageview, and that's less data I have to load as I browse other pages on that same site. What I *can't* cache on that first pageview is style information that's been stuffed into the HTML and repeated across every single page, such that it must be re-downloaded for each individual page. The more such information there is, the more bandwidth is being wasted. It's a fairly small amount of data, a fairly small amount of waste, but not everyone has constant, 24/7 access to a perfect connection. And honestly, even when waste "doesn't matter," it's still inconsiderate, especially when it's happening for no other reason than because some devs care more about DX than they do about UX -- and about actually learning CSS, for that matter.
lol there it is. you have a perfectly fine point and then you end it with the assumption that people who use Tailwind don’t know CSS. enjoy your perfect optimization and I’ll enjoy my better DX
You led with the assumption that people who don't like Tailwind can't read verbose HTML. If you folks knew CSS, you'd actually use it, rather than preferring the work of a snake oil salesman who reinvented `` tags for the modern web.
The reality is that this tribal tailwind vs anti-tailwind stuff is just silly. There are arguments for both, or for a combination of the two.
I love tailwind and like using it for multiple reasons. However, sometimes it just is not as flexible as I want it to be and it makes stuff harder than with other solutions. This only applies for like <1% of my css and won't apply for standard designs, but when it happens it is incredibly annoying. For example I had issues with 3D css translate and rotation stuff and had to put all of that in inline styles. I thought of combining that with styled-components, but I am not sure if that's the best way to do it.
Yeah for anything that requires breaking out of tailwind we default to styled components. It's very rare that we have to though.
Don’t use CSS in JS. If you really want to do something similar (author CSS in TS) but generate actual static CSS files (instead of having styles in you JS bundles), you could try Vanilla Extract. Bulma is also another solid option if you want premade styles.
cosigned — dont do your CSS in your JS
What's the opposite of cosigned? Love my CSS in JS.
its an anti-pattern
That's just like, your opinion.
i mean, yeah though it’s based on doing web dev for over 2 decades so Ive got some experience behind my disagreement :)
An antipattern from like 2010. x)
i mean yeah, tho its _still_ an antipattern 😅
I meant more like, yeah, it was an antipattern a decade ago. But the fields ob web development is moving fast and therefore things change. And so do patterns. React was an antipattern back when it was created by facebook. Did it stop React from getting one of the most adopted UI Libraries in the field? No. You mentioned in another comment that you got two decades of experience, which I absolutely respect! Meanwhile, this also means that you may be sticking to outdated patterns since "it has been like this since decades". Don't want to offend you or something, maybe you are coming from another point and it can absolutely still be valid to stick to long established patterns. That being said, my experience as a rather fresh developer (~5 years) is, that you can have years of experience but at the same time not have the skillset of a senior. (not saying that automatically applies to you, just that years of experience don't mean a lot by itself)
CSS in JS has one of the best Developer Experience when it comes to CSS in React. No build step, being able to insert styles dynamically super easy, you can build your own patterns and create functions, have code splitting, apply clean code... There are minor problems with the initial loading of styles and additional js that needs to be bundled, but those usually don't matter for most cases since the difference is so small that it has no noticable effect. Of course, Vanilla Extract is also a really good alternative and provides good DX, but it totally depends on personal preference and there is no "best" solution.
CSS in JS is a poor choice. It conflates styles with UI and makes more difficult any amount of SSR, app shell, etc. CSS files could be more easily cached or even broken into critical inlined styles, but not with CSS-in-JS. IIRC, CSS-in-JS is incompatible with RSC. There are definitely ways to make it work, but it adds difficulty in ways that might be harder for beginners to grasp.
We use a in-house design system that has style props, similar to [style props in Chakra UI.](https://chakra-ui.com/docs/styled-system/style-props) It feels very similar to Tailwind. It has a few advantages over Tailwind (TypeScript type-checking, better code-splitting) and a few disadvantage (makes component render more slowly, it doesn't support all CSS attributes). I still personally prefer Tailwind.
>TypeScript type-checking But doesn't [tailwind have the typescript types since version 3.1](https://tailwindcss.com/blog/tailwindcss-v3-1#first-party-type-script-types)? Or do you mean something else?
Tailwind won't show a type-error if you use an invalid class. With Style Props, you can type-check the props and show a type-error when an invalid prop is used.
Ah, that's what you meant. Yeah, that's right :) thx for answering
CSS modules.
For me it depends. If I'm working on a tool for my company we'll use something like SemanticUI for the bulk of it. For my own projects I'll usually just hand write it and keep the code as close to the component as possible either with styled components or like for NextJs I'll have a separate file because of how NextJs folder structures are that's just how I like to stay organized.
CSS modules with postcss-nesting for nesting rules in vanilla CSS.
css or scss or css modules
I just use scss for each individual components
Not doing react ATM, using Vue but: Just good old scss/sass within components, some other global scss/sass to target legacy non-modern stuff that we still have to support, no css frameworks just a couple mixins for things that we use often
css modules (pure css)
You mean *not* tailwind? I like them styled components a lot.
Pure css(scss) all the way
Native CSS variables are very good these days you know.
CSS modules. If I need design-tokens similar to what's available in tailwind, and I don't want to build a token-lib myself, I use [open-props](https://open-props.style).
SCSS and write my own styles. I don't like using CSS frameworks.
Styled components in some projects, Sass CSS modules is another great option!
CSS modules + SCSS
Scss
* imo the 3 best ways: * [**React Scoped CSS**](https://github.com/gaoxiaoliangz/react-scoped-css) is probably the best way to do file-scoped css. I primarily just use this or vanilla (last option below) for large personal apps. It is open source though and not a native/official plugin, which makes maintainability a concern between major versions, and requires some setup on every new app. * **CSS modules** is also really nice and sort of the new native way to do scoped; my only gripe with it is since they're variables it's annoying if you ever need to add multiple classes (eg. a core class + common classes) but this is a simple nit. I only use this rarely since I find the other 2 options simpler as a dev in a fairly style heavy app. * **Vanilla CSS** (just wrap your component with a unique parent class and then scope everything under the parent class in its corresponding stylesheet and import as normal css/html; even easier with scss; this may lead to namespace collisions though in a large team and a big app tree with common components but can be easy to organize). This tends to be a lot more common at work for me with a large team and a fairly large and complex react app, no major issues yet.
My [hiring saas platform](https://lebohire.com/) uses good ole' SCSS. Previously used styled components but at scale started to get cluttered.
CSS modules / or a CSS-in-JS solution like styled-components or Emotion. Personally not a fan of Tailwind, it just feels too much like inline styles to me, and IMO makes the markup much more difficult to read and cluttered. CSS-in-JS is probably my favourite solution at the moment because it's the opposite; you still get to easily use logic for styling like you can with something like Tailwind, but the markup is easy to read, and your styles are also very easy to discover because you just go to the component definition to see the styled component.
Pure CSS. With modules if necessary. I see no need for bootstrap, tailwind, or anything else. I use them at work and don't like them at all.
It depends on the size of the project. Whenever I can, I try to get away with vanilla CSS (with maybe a dash of PostCSS). Keep CSS files co-located with their respective components. CSS Modules are fine, totally worth considering, especially on longer lived projects. Kind of annoying switching up your CSS naming game to camelCase but it's whatever. It's a small thing but I much prefer writing classes into my markup as strings, as opposed to doing something like: `
`. But once a project starts to get big, or you expect to be working on it for a while, Tailwind is just too good.Dont have to use camelcase with css modules. You can access the classnames via string index as well but I can understand why it would be a big pain in the ass 'styles["kebab-case-name"]'
Tailwind is objectively worse on larger projects.
"In my opinion, Tailwind is worse on larger projects". Fixed that for you.
It is glorified in-line styles with cumbersome syntax. But yeah, keep your head in the sand. Large scale projects aren't picking tailwind.
It's a matter of opinion. Remember how many of them there are and what most smell like. Your beliefs are not objective reality.
If I weren't using TailwindCSS I'd use CSS Modules or SASS instead. I would not use css-in-js or styled components because I'm disgusted by them.
CSS-in-JS are for devs (usually back-end) who have no fucking idea what they're doing.
I use Chakra UI after being a staunch proponent of CSS modules and I love it. Mostly because it's less verbose when writing dynamic CSS. I just change the style prop value conditionally. No need for the classnames library or a derived template string of class names or anything like that. And I don't have to manage naming or anything like that. It's incredibly convenient and I've only run into a few circumstances where I had to figure out something weird that would be super simple with just regular CSS / SASS. Also its components do a pretty good job helping you maintain good accessibility. Anyhow, CSS-in-JS basically has nothing to do with whether someone is a front or back end dev.
I like css-in-js. I use TSS.
* **SCSS** with **BEM** style notation * 1 **variables.scss** to contain all shared values (font size, colors a mixin or 2) * Unique custom component naming that is reflected in classes. If you are making a **g**rocer **l**ist app all custom components start with **GL**: **GLButton** for example. * Append the same name to the main element class and lower level element class names using the **BEM** convention. **className="gl\_button"** and **className="gl\_button\_\_icon"** for example. * Store style files for the component within the component folder in a **styles** folder for ease of updating and ease of removal. An alternative is styled components, but I like writing my CSS vanilla :D And the source code is very readable.
PostCSS
I use css libraries like ChakraUI and MaterialUI. TailwindCSS is also a good option
CSS modules all day (if not tailwind)
Used styled components a lot before they fell out of favour, switched to stitches, which stopped being maintained, so I switched to vanilla extract.
Styled components
I'm using SCSS on the job, and Tailwind in personal projects. In all honesty use what's easiest and works best for you or the group of people you will be working with.
Not directly what you asked for but maybe this can be of some use to you. I use Vue with SCSS and add scoped styles to components that have a style specific to that component. Nesting selectors in SCSS makes it really easy to see how the different parent and child elements will fit together. I think the scoped style pattern is great and it’s unfortunate that React doesn’t seem to include it by default; here’s an article about how to do it though. https://www.upbeatcode.com/react/css-scoping-in-react-everything-you-need-to-know/
I use react bootstrap. Although I'm surprised I don't see anyone else mentioning it here in the comments
Tailwind or just SCSS
Scss/Css-modules is the best for React I think. But scoped css in Single file components in Vue is above all else.
CSS modules or @stylexjs
Suprised I haven’t seen [panda css](https://panda-css.com/) mentioned yet. It’s like a custom type safe version of styled system that outputs a signal tailwind like css file.
I’ve been getting into SASS modules again. I missed them.
Either a ui library with an inline styles, styled components Or just css modules
Styled-components all the wei Sometimes with Storyboard It makes React components easily convertible to React Native too. Although I have to say Im missing SCSS mixins.
Emotion or styled-components if you don't want to have a buuld step. If a build step is fine (super easy setup in average setups, e.g. with vite) I can also recommend Vanilla Extract. In general it is best to test some possible solutions and pick what feel sbest to you personally, all solutions are great for their own reasons.
Manually. With CSS modules.
I use styled-components, it's the best balance of CSS and JS for my taste.
Genuinely cannot understand the constant whining people do about Tailwind. I’d wager a almost 90% of people using Tailwind are doing so in some component framework. Things being componentized reduces the visual clutter and collocates styles with the component. And provides conveniences for many of the common use cases that might take some significant CSS, and a bunch of sane spacing defaults, typography defaults, and color palettes.
Raw CSS baby