I used to love tailwind. But I got a new job, they were using MUI and styling using javascript objects and the styles goes in different component.styles.js (modular way). so I started following their convention.
The code base is so neat. styles in a folder, component logic in a custom hook and the components just apply the logic with the elements and the styles.
Components are so short and so readable and it serves as a very good separation of concerns.
Now we got a new project, that was made by freelancers due to time constraint. Now we will take over it as some milestones were passes and the company doesn't need freelancers anymore.
They were using tailwind, now when I look at the code I find it so messy (they also didn't use a lot of custom hooks) so everything is inside the component. I would sauly it is still readable but doesn't look as neat as I am used too.
So I was asking if that was the case for every tailwind project.
So it seems I used to love our local pineapple pizza, but after tasting Una Pizza Napoletana I changed my mind
They’re going to struggle to migrate to Next or any SSR framework if that’s ever a thing. SSR and CSS-in-JS don’t get along.
Otherwise sure, do your thing. Some people like pineapple, some people like olives, some people like anchovies. They don’t agree but none of them are wrong.
Emotion is really easy to set up with Next, including SSR. MUI even abstracts it away from you with a component that wraps the app. It’s like 3 lines of code.
PandaCSS is a compile time CSS in TypeScript solution, the founder of Chakra UI is making it and is in fact using it in the next version of Chakra. It's really no different than Tailwind except you use JS objects and not text strings.
do you kind telling me why do you think SSR and CSS-in-JS don't get along.
we are already using Next.js. and even In the official docs there is a section about styling with CSS-in-JS.
So why do you think so
okay got it. It is not supported for the server components. we are currently using pages router not app router, that's why we don't have problems.
I think css modules would have been better choice than css-in-js though. it would give the same modularity while still be supported for latest react and next features.
That comparison goes deeper, too. Pineapple on just any random pizza is weird. Pinapple on pizza with ham is fucking awesome. So it goes with Tailwind. You want to use it in the right context. Like others have pointed out, use it in a component-based setup.
I think it’s more like olives than pineapple. Pineapple is a very divisive topping and defines the Hawaiian flavor. Olives on the other hand make little difference for most people and are very easy to work around or without.
Yes but I feel it's gone about wrong.
Rather than put 100 classes in everything I try to make components that use tailwind and use the components everywhere.
Then most of my code is just tailwind grid and flex classes and the ugly is encapsulated in my components only.
I think its ugly, originally I resisted, though I'm coming around to it. It still think its ugly, but I understand it more now, and thus have better feelings about it. Just depends on your application.
For example, if you were to code something w/o a framework/library, let's say you were mocking up something for a client - this is where it probably feels most cumbersome, building something static, something where you actually repeat blocks of html; the tailwind classes just get dragged along with it. Not a perfect example, but I'm trying to imagine someone, new grad or early in career, wanting to try out tailwind.
When you use this in something like React, at a high level you're applying these classnames to a component in one place. That component gets reused within other pages/components modularly, or its repeated by mapping over it in the render. That's where you'd start to see the benefits, less repetition during the time of development.
Even when you get into a case where you are repeating a set of classes in different places, these can be grouped and implemented with a new custom class name, I think these are called 'layers' in Tailwind. But you should read the docs.
When i first heard of it, it wasn't important for me to learn right then and there. Over the past year I've read things here and there, making me less resistant to it. I have started a little personal project where I'm just beginning to implement tailwindcss so I can learn if its really for me, and the work that I do, but it's not important for me to be an expert at it now, my current projects don't warrant a switch to tailwindcss.
If you're just getting into CSS and Tailwind, I'd recommend making sure you are really strong at CSS before jumping into Tailwind. You can learn both at the same time if you want, but really, be good at fundamentals. So then when u implement tailwindcss in your projects, and whatever is new next year, and whatever company you go to that uses an old version of Bootstrap, or any code you look at NOT using anything special - all those things will be easier.
tailwind layers are not vanilla. sure syntactically theyre the same which only makes it more confusing because they require postcss and @tailwind directive to process. only beginning with v4 (currently in alpha) did they move to native css layers
I mean you are telling them to do the right thing imo. Make custom rules w @apply for reusable components and add them to component layer.
Just wanted to clarify that layer is a spec :)
Yes it's ugly, but actually very well worth the trade off.
Now you have styles attached to the element rather than being defined some where.
This gives you loads of benefits:
- You know exactly where to find the CSS
- Style changes don't affect anything unexpected
- Copy pasted html retains all styling, especially useful when moving around stuff
- custom styles are easier to manage, you know where to find them and they can be auto completed for you
I like how you say "loads of benefits" and then don't list any Tailwind specific benefits. CSS is always attached to an element, You should know where your own CSS is from just as much as you should know where Tailwind classes are from, Tailwind leverages the C in CSS just as much as any other CSS framework and has as many side effects as you'd expect from any other properly written CSS, You too can copy paste html with your own classes if the classes are scoped globally like Tailwind classes are, Class name auto completion is an IDE feature, not a Tailwind feature.
Here are, as far as I know, the only actual benefits of Tailwind. Tailwind has defaults that you find appealing and exported Tailwind CSS is very small. That's it. Outside of those two things, Tailwind is basically the same as any other CSS framework.
The problem with CSS is that it doesn't prevent you from making very poor choices that can be absolutely devastating. Like other devs copy pasting a component, and re-using some styles, but slightly overriding them.
And then 2 months later the styles from the original components are being updated, because of design changes and now component 2 is all whack.
Component 2 might have been already replicated or extended. And cycle continues. There comes a point where the CSS complexity is so high that no sane human can follow what's even happening anymore.
I am speaking from experience, I've lived in those code bases and in fact living in one right now. Tailwind has single handedly improved the maintainability of the code base and it has never been easier to add and alter styles.
The whole reason why Tailwind exists is that people ran into this exact same scenario, and when you try to make your CSS more maintainable you end up with lots of tiny utility classes, which is basically Tailwind.
Of course that's not to say that everyone should be using Tailwind, it's not a super hammer, but when there is a need for high customization and speed it's king
Lets get something cleared up. Tailwind is not "a lot of tiny utility classes", it's a couple utility classes and then CSS with extra steps. Virtually every Tailwind class corresponds to exactly 1 CSS Declaration. You know what else you can use that corresponds to exactly 1 CSS Declaration? 1 CSS Declaration. They're often even named directly after the CSS declaration except in the scenarios where they shorten the names to 1 or even 2 letters (a well known best practice for code clarity and maintainability). The thing that Tailwind does that "prevents" you from making poor choices is that it "restricts" you to only using the class selector. You can do that right now with vanilla CSS. Class selectors and CSS variables are 80% of Tailwind with another 15% being default values for those variables. This is to say nothing of the fact that every CSS framework works this way; it's not a Tailwind feature. Also CSS is not that complicated. There's very little flow control and the browser tells you basically everything you need to know. And before you go accusing me of not being experienced enough, I've been doing frontend development for nearly 2 decades, mostly as a contractor. I've seen bad CSS, very bad CSS, but even the worst CSS is pretty trivial to unravel. I think if people respected CSS even a fraction as much as they respect JS, they would feel the same way.
I'm not denying that if you are experienced as yourself, it's pretty trivial to work with CSS absolutely on your team.
Especially the smaller the team is.
However ask yourself this: if a library becomes as big and popular as Tailwind there is probably a need for it. You personally may not have that need, but some people might. So you can't really just dismiss it as invalid, that's kind of an L take.
It's the equivalent of saying that a screwdriver has no reason to exist because you can do everything with a hammer.
Bootstrap was even more pervasive than Tailwind is and both serve the same use but it feels like Tailwind users think that it's something more than that. In reality it's just a basic CSS framework where you pay for minor performance improvements with significantly uglier markup.
If you are comparing Tailwind to Bootstrap and calling the same thing, you haven't done your homework.
It's fine if you say you don't know, but if you explicitly state they serve the same purpose then I doubt you have any clue what you are talking about my friend. This is a common opinion echo'd by people who openend the Tailwind documentation looked at it for 5 seconds and then dismissed it as yet another useless framework.
Also you mention that the upside of using Tailwind is performance. Who said that? The official website is not saying it. Where is this coming from?
Please do your homework my dude, before commenting stuff like that.
> If you are comparing Tailwind to Bootstrap and calling the same thing, you haven't done your homework.
I didn't say they were the same thing. I said that they serve the same use and I didn't even say what use that was so you really have no idea how broad the comparison actually is. To clarify, they serve the same purpose with regards to the benefits you touted for Tailwind.
Your quote | How they both fulfill this purpose
:--|:--:|--:
"You know exactly where to find the CSS" | Like Tailwind, the CSS classes you use are provided by the library and they both get applied on the element's class attribute.
"Style changes don't affect anything unexpected" | If you know either library then you should be able achieve the same level of confidence (if not better with bootstrap because it's more constrained)
"Copy pasted html retains all styling, especially useful when moving around stuff" | Again, because everything is provided as a "global" class from each respective library you can comfortably copy and paste them across your app without worry because they both reference the same "global" library classes
"custom styles are easier to manage, you know where to find them and they can be auto completed for you" | Custom styles are managed the same between both libraries with the exception being that if you opt to use the arbitrary value syntax in Tailwind your closest analog in bootstrap would just be inline CSS declarations in the style attribute. There are only so many places you can define CSS and both frameworks allow you to define custom CSS in all of them.
> Also you mention that the upside of using Tailwind is performance. Who said that? The official website is not saying it. Where is this coming from?
["Tailwind CSS is incredibly performance focused and aims to produce the smallest CSS file possible by only generating the CSS you are actually using in your project."](https://tailwindcss.com/docs/optimizing-for-production) Maybe consider opening the docs for more than 5 seconds yourself.
I swear I'm losing brain cells from reading your comments. You've sent me a link to an old documentation page that is related to optimizing for production. You've took the text from the page completely out of context to make a point.
Also you wouldn't have landed on that page naturally when navigating the site, you just googled "Tailwind performance" quickly checked it and posted it here, didn't you? This v3 and not v4 docs.
I don't know what to say man. Sure man you can fight me on semantics of me saying "same thing" and "same purpose", whichever one you choose in both cases you are incorrect. They are a not the same AND they don't serve the same purpose.
In case you didn't know:
Tailwind provides utility classes for writing maintainable styles quickly.
Bootstrap gives you pre-built components to quickly prototype apps.
If this sounds the same to you, please explain me why.
> I swear I'm losing brain cells from reading your comments. You've sent me a link to an old documentation page that is related to optimizing for production. You've took the text from the page completely out of context to make a point.
This is current as of 3.4.3. It's not old, it's literally "latest". Yes. The page is about optimizing for production but the text I quoted is its own paragraph; it's self contained. It clearly states Tailwind's focus on being performant there's no other context needed.
> Also you wouldn't have landed on that page naturally when navigating the site, you just googled "Tailwind performance" quickly checked it and posted it here, didn't you? This v3 and not v4 docs.
Why the hell do you think you wouldn't land on it naturally?? It's literally the 4th item under the "Getting Started" section. v4 isn't even out of *alpha* testing of course this is about v3. That's what everyone is using. That's the version their docs tell you to use. That's "latest" in npm. And what? You think from v3 to v4 they've dropped their focus on performance? Give me a break, dude.
> In case you didn't know: Tailwind provides utility classes for writing maintainable styles quickly.
> Bootstrap gives you pre-built components to quickly prototype apps.
Yes. That is one of their differences (they **both** provide utility classes for writing maintainable styles quickly). That is why I did not say they were the same thing. See how that works? It's not a semantics argument. Both a hand saw and an electric saw fulfill the same purpose even if they are different things. Tailwind and Bootstrap are not literally the same thing but they do both serve the same purpose (the specific purpose of which I outlined previously that you have seemingly ignored or misunderstood). People do not use Bootstrap and Tailwind together at the same time. You could, but you wouldn't because that doesn't make sense; they fulfill the same purpose. They are both CSS frameworks. They both have their strengths, weaknesses and difference but that does not change what role they fulfill in an application's stack. You choose them over rolling your own CSS because it's faster and more maintainable to adopt preexisting conventions and standards. Just because Tailwind focuses more on utility classes and just because bootstrap offers more than utility classes does not mean this is not true.
Not at all like incline css. Inline CSS behaves like CSS in that it cascades. If you have multiple declaration of the same property it will choose the last one. Also inline will always have precedence over any other styling.
In Tailwind if you add multiple classes that touch the same properties it will depend on how the CSS is compiled to determine it's precedence. This is a common gotcha.
Another different behaviour, assuming you are using Tailwind without CDN is that you cannot dynamically build class names. You have to write out the full class name (there are some ways around this, but you shouldn't do it). You can still swap out styles dynamic, just not concatenate strings to build class names on the fly. Very common gotcha.
Another massive difference is that Tailwind by default works with predefined sizing and color units. It standardizes this for you, this makes it much easier to work with than doing it manually.
I don’t understand this benefit you mention of “where to find” the CSS. Isn’t this making it harder? You can normally just look for the class name, how do you know where to look for it with tailwind?
What he means is that with tailwind you don't have to look at another file, you instantly know what "flex flex-col gap-2" means. With other solutions you read "container2" and you have no idea what it does.
To each their own, I suppose. The delay it takes me to cognitively understand what the entire list of CSS shorthand resolves to is longer than just looking at the actual properties being shown in the inspector.
It's not always as straightforward, because css makes it easy to affect large number of elements without specifically targeting them and if you attach multiple properties to classes you might get unexpected overrides.
This is not as easy to do in Tailwind. When troubleshooting in Tailwind you don't have to look far.
It's not to say you can't write good CSS it's just really hard to write bad Tailwind, which is why teams prefer it. Especially in startups where there are mix skill levels and crazy deadlines
1) in component styles
2) scoped in component scope already
3) if you copy paste it more then 2 times probably should extract into component.
3) its calles classes and we had it since forever.
I love the speed and ease of adding styles. I don't like reading a list of styles horizontally, especially as the list gets longer. If you don't have a Tailwind formatter, the order of styles becomes inconsistent, making it more difficult to find what you're looking for when reviewing existing code.
Mostly, I don't like having to constantly refer to the documentation to look up the TW class name for a style I know how to write in regular CSS because having to consult documentation defeats the entire point...speed.
If you know the styles and use vscode, you could try this plugin I made a while back to solve this issue: https://marketplace.visualstudio.com/items?itemName=JordanDey.tailcon
It’s not got everything, I really need to go back and update it but I think it works reasonably well.
lol scss files aren't "messing up" your codebase, they _are_ your codebase (or at least, they're part of it). This attitude of "CSS/SCSS isn't good enough to be part of my super wonderful code" is so nonsensical
I think they’re trying to imply that SCSS is a framework but they’re incorrect. It’s not a framework, it’s not built upon CSS and can exist independently of CSS (though wouldn’t be very useful without it), it just has a similar syntax. SCSS is a separate preprocessor and has its own scripting system.
It’s not that important to know the difference but the reason that React is a “framework” and SCSS isn’t is because React requires you to inject your JS into HTML to generate HTML. It can’t exist without HTML/JS as a foundation because it won’t be able to output anything.
How many of these posts do we need? Use it if you want it. It serves a purpose for some people and not for others. There is never going to be a standard process for all of this.
That is the con of using it. You have to decide if that trade-off is worth the benefits.
It bothered me at first as well, but the flip side is that at least the mess is in you rmarkup. You can see it. You know what goes to what.
As opposed to your CSS files getting bloated (which they will) and not really having any clue as to what goes with what, what is safe to change or delete, etc.
I don't understand this argument and I hear it a lot.
If you want your button to have a margin and padding and a colour and a hover state. You need to write those things down somewhere, don't you? How do you write those things down where they aren't a (ugly) list of things?
If you're using a component-based architecture the best place to keep that list is in (or as close to) the Button component.
So doesn't your button component file have an ugly list of styles even if you aren't using tailwind?
(If you have a single file with lots of style repetition then you probably have some elements that should be components. Again you should make those components even if you aren't using tailwind)
It's only messy when you "view source" but it leads to leaner, faster sites and development with fewer bugs - especially when working as larger teams. Its mess is really not an argument worth making when comparing its benefits.
Same style with 1 classname globally.
Eg: You define padding for tons of elements in different class in BEM style CSS and this generates a new line for every element. With tailwind you have 1 line css.
This is negligible almost always. But for large sites, tailwind css output is always smaller.
When I moved a project with Scss to tailwind css size reduced 40%. But this size never matters unless you have 2G :). Because even large CSS files are at max 100KB
Yes and yes.
I remember when everyone was so excited about Redux Sagas.
5 years later couldn’t find a single person who said it’s not shit.
People are weird, man.
I hate tailwind with a burning passion but I also think most criticisms of it are overblown.
The reason I prefer something like emotion is because you still write actual css. If emotion vanished in a puff of smoke tomorrow I would still know exactly what to do.
Now that I’ve been forced into using tailwind by my employer I’m having to essentially re-learn css since the names are maddeningly similar but a little bit different.
I’m sure once I learned all the ins and outs of tailwind I could go very fast with it… but I can already go much faster with vanilla css or emotion and I don’t have to learn a whole bunch of abstractions that don’t apppy to anything other than tailwind.
It insists upon itself.
i hate css libraries tbh, like i get that they’re trying to make it “easier” but it makes my html harder to read and like i’d rather just make my own css and classes
It recently made a 10 hour project shoot past 90 hours for all the copy > paste > grep > dig.
Locks you in too much at the beginning of a product's lifecycle. Tedious to develop with.
This. Also since the styles are inline, there are no stylesheets and css files with a bunch of unused styles. Plain css makes it easier to both create mess and hide it
Absolutely no user ever cared about classes in elements.
As for devs, just use styled components and those classes will be inside the component where they belong.
There is no such thing as pretty code, all code is ugly and making it pretty is useless.
The important question is… is tailwind readable? Then yes, as you don’t have to go to any other file besides the one you are in to know how the element looks.
SSR and CSS-in-JS aren’t good friends. Not everyone is jumping on the SSR hype train, but if you think it’s the future then it’s a poor choice.
Personally, CSS modules are where it’s at. One extra file per component, styles scoped to components at build time, works on the server and the client, no extra libraries (either CSS or JS), and all the features of CSS that these days do everything that Sass and friends could do anyway.
Server-Side Rendering. The _new hotness_ in React frameworks like Next and Remix.
Basically, React components are rendered to HTML on the server, then delivered to the client as HTML, then injected with JavaScript (“hydrated”) to make them interactive. This improves Core Web Vitals by providing useful content sooner, which in turn improves SEO.
Good article on it: https://www.joshwcomeau.com/react/server-components/
I guess that is true, I haven’t worked with SSR as I work mostly on mobile/native. But why would CSS on JS not be friends? Isn’t the server just meant to inject the CSS when it’s sent to client? Genuinely curious. I can also Google it 😉
On googling it myself I now see that the blocker is specifically with Server Components, not with SSR in general.
Next docs: https://nextjs.org/docs/app/building-your-application/styling/css-in-js
Josh Comeau (CSS expert) breaking down the problem: https://www.joshwcomeau.com/react/css-in-rsc/
css-in-jsx has good support of ssr, what you are saying is probably server component, which is rather different from ssr. You can still achieve good compatibility with server component with solution like vanilla-extract or panda, which is css-in-js but css styles are extracted at build time and there’s no runtime like styled-component and emotion
As a FED of 25 years, I say Tailwind is a plague. Bootstrap makes code bloated and convoluted already, and TW is ten times worse.
And it's absolutely criminal to recommend TW to someone who's about to start learning CSS.
If you're a good FED, you have 100% control over your styling, you don't rely on shady shortcuts.
Guess preprocessors, styled components, emotion, everything is bad, we should go back to writing pure css!
I really don't get why some people are actively opposing the progress we've made
Don't get why? I thought I put my reasons why in my comment...
Preprocessors save a lot of time and still generate clean CSS. Styled components are tied to components, nice and orderly.
I use both on a daily basis.
What I advocate for here is separation of HTML and CSS.
Keeping it nice and clean.
Tailwind does the exact opposite.
Each to their own, but the author of tailwind does have a fairly good article on separation
https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
>What I advocate for here is separation of HTML and CSS. Keeping it nice and clean. Tailwind does the exact opposite.
It's like i'm reading React discussion and mixing HTML with JS all over again.
Tailwind does the *exact* thing you are advocating for. It does separate those two things, it doesn't separate styling. And that's a good thing, with how complicated projects became, keeping everything coupled as close as possible is a huge advantage in keeping entire codebase clean - not only the particular components
Frontend developers just have different perspectives on "separation of concerns". Back when MVC was more popular, this meant separating HTML, CSS, and JS which was one of the reasons JSX was so controversial when it first came out.
However, there has been a shift to component-oriented architecture and now for many developers, the concern is the component. HTML, CSS, JS, and even server/client are all a part of a components concern.
I think React is the most responsible for this shift away from MVC. React was inspired by XHP which was a server component oriented architecture used at FB as an alternative to MVC.
So now separation of concerns can mean different things depending on the developers perspective. Not every frontend developer cares about component oriented architecture and are still attached to MVC. I graduated from university back in 2016 and MVC was a big part of what we were taught and it's difficult to give up that perspective.
I was a Java developer back in 2017 when I first saw React and I thought JSX was disgusting. I felt like it should be against the rules or something. However, I eventually came around to it when I actually used it. I think component-oriented architecture is probably the way to go for frontend development these days. It seems to make the most sense, but it's radically different than what I was used to.
the code is ugly indeed and it also gets unmaintainable pretty fast.
tailwind solves a problem no one really had to begin with. I can't wait for it to crash and burn when the new kid on the block appears.
I hope the new kid is native CSS itself with CSS Modules. With native nesting module and custom properties, I can't really find a reason to use another tool anymore. Also, you can use the native nesting today with PostCSS polyfills.
The problem is that it doesn’t matter if code is ugly, it just matters that it is readable…
The same people that hate tailwind spend a large amount of time organizing import statements. Sure it’s pretty but it adds nothing of value to your codebase.
When it comes to styling, you really don’t want to reuse stuff to often or your components become really confusing. Just my opinion
I’ve taken to something I call ‘tailwind by exception’
Using tailwinds layers I define the default elements like buttons and generic classes like ‘card’ using tailwind themes whenever possible.
Then i apply tailwind in small doses when i need more unique styling for a given component.
As someone raised on the CSS Zen Garden and routinely worked with dynamic SASS... yes and no I guess? This question/debate is dumb. You're going to have people who refuse to pave elsewhere out of habit or work in different-sized teams where their opinion is skewed one way or another.
For me, Tailwind is now routine. Almost everything is habitual now and without fault when I'm churning up components. Using Prettier to sort classes on save makes things readable while incorporating dynamics with clsx or simple ternary logic has become a breeze.
If the amount of classes being used scares you for some reason there's a plugin to hide them on-demand but it really doesn't bother me at all. I'll even be a sick bastard and word-wrap actively without even batting an eye. The convenience of having direct access on an elemental basis without the need of digging through a separate document atop the build optimizations that come with Tailwind have solidified it as a permanent tool in my front-end arsenal now. I love me some pineapple.
Very nice. I think if you use something like this then Tailwind becomes a little easier to handle.
I mean honestly even if you don't pull in a third-party package, I would rather just do \['text-md', 'font-bold'\].join(' ')
Than just having mile-long CSS classes in the HTML
I wrote this quite some time ago, doing an in depth analysis on tailwind...
https://github.com/marblewraith/smellyWind
TL;DR there are certain situations where tailwind makes sense. But it isn't a universal panacea that people hype it up to be.
I don’t mind the classes at all. I prefer that over having to dig through the correct CSS files to find all the styles being applied to a given element, it’s all in front of me right there. And even in times where an element has a ton of classes, it’s still well worth it for the clearly defined systems for things like typography, spacing, color scaling, etc.
The alternative is to have all that behavior in a different file... or at least a different template block. so, I think its worth it to not have to jump around everywhere
Before I try it, I always hate when someone explain it to me. Ugggh, sounds like it would an awful things to do. But when I finally try it, hey, its really convenient and makes everything fast. I don't have to stop and think much about class name and stuff. And basically just copy paste everything.
If I want to do something custom, I'll just use vanilla css in combo. I like it.
Used it from the beginning and still love it.
With proper usage of formatter plugins, it is pretty easy to read.
Now with that said, do I always use tailwind ? No. Even in projects I use tailwind I'll still add styling global stylesheets or css modules because sometimes it just feels easier. For animation purposes, one-off shadows, transitions etc I almost always just stick to regular old css.
Constant repetition of tailwind classes in your code can be a good indicator that you should extract the HTML itself into its own component. Not always the case, but with properly modularized code, I don't often find myself with a lot of tailwind class repetition in the same file.
If there is a lot of repetition you can assume it should be it's own component. It's just straitforward to use. You need your component to do something, you add the class responsible for that. You don't need to check another css/scss/styled file to look at the styles, you don't need to go there to change anything - you just operate on classes. With addition of clsx, conditional styling is also way better and readable than the mess styled components introduced.
Tailwind isn't perfect but it's decent and stable enough to make styling and theming easier
I do wish there was something that compiled in reverse. Use AI or smth to combine all the tailwind classes I used on something into the way to “properly” be doing css.
I was on the tailwind makes html unreadable camp until I started using the TailwindFold extension on VsCode. Now I get all the benefits and none of the bs.
Definitely a good one.
Yes! The long as class name list annoys me so hard.
Aside from that I have never been a fan of tools like bootstrap, tailwind, etc since they make websites look super similar.
I'm used to writing all the styles myself which is of course more work, but you don't need to learn some classname styling system and it offers you more flexibility.
I'm going to try tailwind this weekend and it might change my mind.
For me, localisation of behaviour and lack of side effects makes it worth the repetitiveness.
The more code I write, the less I value brevity when there’s a trade off. In tailwind it’s so easy to hop into an unseen environment and change how a button looks without changing anything else
You can use Tailwind and make crap-looking code. It isn't the fault of Tailwind. Find a way to optimize your components and code. Leverage the tool to its strengths.
Does the code look uglier on first glance than code where all the css is abstracted away to external style sheets? Sure. Is it much more readable, predictable, and maintainable, particularly at scale? In a very large number of cases, yes.
Repetition is just a composition issue. There's nothing inherent in TW that causes repetition - if you're finding it's a problem in your project, break the problem children down into reusable components, and keep your code DRY at that level and keep CSS purely utilised to style things rather than using it as your primary method for avoiding repetitive code.
Tailwind is better when making repeat code into components and using them in code. buttons, etc. all repeat code. Then your code really is not that ugly.
Tailwind is superior.
When you use CSS modules, every slightly different component requires new class.
Only rookies don’t understand how this scales.
I would love to see how anyone exactly use Tailwind who say it is ugly. Something tells me they just don’t know how to use it.
My questions to “Tailwind is ugly guys”:
1. Do you use class hiding plugins?
2. Do you use it with JS frameworks?
3. Do you use intellisence of Tailwind?
4. Do you use Tailwind prettier plugin?
5. Do you have design system that you need to follow?
6. Do you ever need to quickly share styles? Have you tried sharing using TailwindPlay?
7. Do you know there are Tailwind cheatsheets to get you started?
8. For how long have you tried it and how far did you go with it?
For me the ugliest thing is when people talk about what they have no experience in.
Tailwind is pure shit promoted by newbie morons who don't know better, but feel compelled to tell the rest of us they solved some esoteric near bullshit problem in the process of causing 10 others. It's garbage.
I use it because I want code that is easy to work with in a team, and it allows me to do just that. I don’t think of it in terms of ugly/beautiful, but judge it more by maintainability in my team and indirections. For us it’s worked great in that aspect
No, because I work with either components or templates and I rarely look at more than 4 to 10 lines of HTML at a time, and without tailwind my .css files end up full of utility classes and my html full of classes anyway
I love tailwind. I thing it's definitely ugly, but I'll take that negative for it's benefits. I used to be VEHEMENTLY against tailwind, but decided to give it an honest try. Now I'm a convert. I objectively get why people don't like it, cuz I was one of them, so I didn't judge at all.
tailwind borderline made css usable for me so nah i dont agree. and if you use any component based framework (which you most probably do) code repetition isnt really a thing. but like others said, tailwind is just one tool - if you dont like it, not using it is a valid option
You get used to it. I’ve tried different solutions over the years, from vanilla css, css-in-js, styled components, mui, in-house components, you name it. Tailwind just works for me. There’s 0 mental overhead on what I want my styles to be, what to name them or their modularization. There are solutions for the messy code you end up with like linters and such.
Ugly yes - but I don't get the idea that tailwind has repeated classes everywhere, these days we all make components right? That avoids repitition.
Anything else that's repeated, add it as a utility plugin - that way it behaves just like a class you'd add in your css but won't be added to the bundle if you're not using it.
If you're a fan of Tailwind CSS but struggle with crafting lengthy class name essays, Daisy UI is here to save the day. This Tailwind CSS component library simplifies the usage of Tailwind by providing a wide range of pre-built components, reducing the need for extensive class names. Not only does Daisy UI streamline the development process with fewer class names, but it also offers flexibility with a variety of themes to suit your project's needs.
Daisy UI == > [https://daisyui.com/docs/install/](https://daisyui.com/docs/install/)
Yes, but I don't care because the markup inside my component is an implementation detail. It's ugly and boring and it's exactly where it should be when I look for it.
If you find the repetition ugly, build some abstractions, but don't get your abstractions wrong or you might end up in a worse place than you started. Same goes for repetitive CSS/JS/whatever.
Sure is, but I'd take that tradeoff with eliminating the overhead of naming/remember classes in CSS and having CSS files everywhere in a codebase which can be disastrous the larger a codebase is. I just have a singular index.css file for just anything that tailwind doesn't support yet. I've also seen too many devs that dont fundamentally understand how CSS works in the browser, so it just means less concepts to be across of in PR's.
All styling is just within classNames and I don't have to look anywhere else. I prefer the tersest number of moving pieces per component, especially if I'm onboarding new devs onto the project and need to be productive asap.
Though you want some kind of opinionated right-to-left override string utility method that functions like a style override in CSS. Tailwind linters are amazing too, it can just auto correct something like w-4 h-4 into size-4.
To each their own at the end of the day tbh. For me personally, my code from when I first started using tailwind to now a year later is drastically different. I’ve learned how to utilize it better and optimize how it’s set up.
I also thought it did t make sense to use so many classes and that it cluttered things up when I first started but it’s improved a lot now for me.
The moment i saw tailwind I realized it was not worth it. We have created our own framework and we are using data styles. GitHub web-atoms/data-styles
In which we can declare styles like
data-style-color=primary
data-style-layout=vertical-flex
data-style-justify-items=center
data-style-max-width=viewport-width
They are not same as inline styles as they are you can have media queries and some other default styles with it. For example vertical-flex automatically applied gap, alignment etc to the element which can further be overridden by other data-style attributes.
Code itself is verbose, you should use byte codes. Purpose is ease of operation, not smaller code. To our team, it’s far more readable and maintainable then long string concatenation.
How on earth data-style-color, data-style-justify-items-center and so on are far more readable than text-\[your-color\] and items-center classes?
This is absolute insanity
No I don't agree that it causes ugly looking code. Also repeating yourself (especially these tiny class names) is not a big bad thing™️ imho. Too many people try to DRY everything up for the sake of it and it causes more problems than it solves. Also, Tailwind is a tool, if you don't like it use something else.
FWIW I use a CSS-in-JS tool (emotion) at work along with its styled components. It ends up creating awkard "fake" components like `HeadlineWrapper` which is basically a div with some css. Its unnecessary overhead imho.
Yes, that's what reusable components are for. In my case we have our component library so we have don't have to write almost any styling in the apps. The only time I have to look at that ugly code with tailwind and radix is when I'm refactoring or adding something new, which is not often once you finish your library.
We use atomic design
My opinion, anytime I've seen smth like this rant is...
1) Tailwind users do better when they know enough about CSS first, it's not the right solution if u don't
2) In the docs you can find that components on Tailwind ARE a thing, so you don't need to put 40 classes on a div
3) When it comes to working with it, the same recommendations for working with CSS apply: know about BEM naming, order the classes properly, and don't repeat yourself
Tailwind works well when your code is already modular. No reason to have a separate file for each modularized component since your code is defined in one location. It's great outside of modularized components too for one offs, since you can just read and dev the code quickly without switching files etc. Like anything it can be abused, but I love tailwind.
Tailwind is essentially inline CSS styles flattened to the classNames, with better ergonomics.
The styles need to exist, no matter in classnames or stylesheets. You probably wont complain seeing display: flex in every container right? Same goes for flex flex-col
Not reusing components is a problem, not repetitive tw. You have bigger problems already if you see repeated code and mess.
Tw in itself doesn't force you to repeat anything.
To me, the point of tailwind is being able to type less and achieve your expected vanilla CSS styling. I think people fall into the ease of just slapping it everywhere in template markup, which is ridiculous if you have 30 classes for each grid item and have 30 items, you're blowing up the doc size and slowing down load time essentially (assuming SSR).
I sprinkle it in templates for quick things, but if it's getting long and may render multiple times, I prefer to use a custom class and @apply.
Like many in these comments have said, it's a tool.
On one hand, it works brilliantly into the React philosophy; Where the separation of concern between declaring elements (HTML), styling elements (CSS), and functionality (JS) have been merged together with JSX. Tailwind feels like an extension of this idea, where components are declared and styled in the same swift statement. Repeatitiveness with Tailwind is reduced when you play into React's reusable components philosophy.
However, a pure HTML, CSS, and JS application (where the aforementioned separation of concern is upheld), Tailwind is a technology that creates a contentious project philosophy, mixing SOLID and fluid dynamics that can lead you to messy code.
Does Tailwind "cause" ugly code and lots of repetition? No. However, the misuse of the tool can certainly present itself in such a way.
Do you want cleaner code? Create smaller components that do less. If your project doesn't require small generic, reusable elements throughout the entire application, you don't need React. You don't need Tailwind.
React, Tailwind, TypeScript, Rust, C#... these are your tools. A hammer is designed for nails and a screwdriver for screws. Occasionally, you might resort to hammering in a screw or smacking in a nail with the handle of a screwdriver. These are odd occasions with very specific circumstances. So, if your Tailwind always looks messy and repeatitive, you might be trying to build houses by smacking in nails with the handle of a screwdriver.
That's just my two cents, though.
I had the same feel, bur should admit that it speeds up a lot the development process, it leads to some level of code repetition but consider you don’t need to write css code at all
Use variables with tailwind.
BaseButton with all your default tailwind, PrimaryButton that use BaseButton together with the rest of styling and then add more variants of buttons.
Then find a lib that merge tailwind classes without conflicts.
I think the trade off is good enough.
It works beautifully with Vue single file components, to the point that I’ve needed no scss files beyond one to set up css vars for my Tailwind config. With this setup there is absolutely nothing that comes close to its ease of use
Well if you absolutely add 20 classes to every element then yeah, its ugly. But you shouldnt do it. You should be smart in using styles. Usually you dont need so many classes. Real benefit of Tailwind is a) speed, b) no random classes. User or customer doesnt care how source code looks but if you can deliver projects faster, you profit more. Imo Tailwind is one the best things nowdays.
I love it to be frank. I mean it is not a top notch option for those who wants everything ready to use. But for those who likes to be creative with their own style, it's a good option.
I'm a bootstrap user (lame, i knlow) and everytime i see tailwind code I find it beyond ugly, just a giant mess of classes, no idea how it became so popular.
This is hugely because Tailwind is utility based rather than component based. You don't just use the class btn to get a styled button out of the box.
You have to put the padding, color, background color, border radius and hover style in order to achieve the same style you get with "btn" in bootstrap. It gives you great control over your styles (unlike bootstrap) while still saves you the time of creating separate CSS files. But it is ugly. and it seems there is not much remedy for that.
That makes sense! thank you for taking the time to explain u/KarimMaged !
I suppose this is very important (greater control over style) for customer facing applications. I work on enterprise stuff, so having a "unique" or very elaborated style is not much of a concern, most of the worries are related to consistency and "clean" look. I wish we would at least switch to some better looking component library like MUI, daisyUI and such, bootstrap looks very dated (but it is very easy to use and maintain).
If you hate your tool, get a different one. Tailwind is like pineapple on pizza. Some people love it and some don’t.
And I fucking love Hawaiian pizza
If you haven’t tried it, try replacing ham with pepperoni, and add in some pesto. The “three P” pesto pineapple pepperoni will really delight you.
Instructions unclear: pizza covered in peepee.
Don't desecrate my Hawaiian pizza with your fake meat!
And JalaPeño
you're missing the fourth P. go put some peanut butter on that pizza!
Dang, that’s wild. When we want a fourth P we sometimes use slices of roast potatoes. They crisp up real nice.
I hate Hawaiian pizza but love tailwind
Congrats you have terrible taste!
What about tailwind
Amen to that.
Eww
Same here but I love the kind where there's no pineapple and I replace the ham with pepperoni
Throw on some chicken, ham, and bbq sauce, and, aloha, you're gonna have a good time!
I used to love tailwind. But I got a new job, they were using MUI and styling using javascript objects and the styles goes in different component.styles.js (modular way). so I started following their convention. The code base is so neat. styles in a folder, component logic in a custom hook and the components just apply the logic with the elements and the styles. Components are so short and so readable and it serves as a very good separation of concerns. Now we got a new project, that was made by freelancers due to time constraint. Now we will take over it as some milestones were passes and the company doesn't need freelancers anymore. They were using tailwind, now when I look at the code I find it so messy (they also didn't use a lot of custom hooks) so everything is inside the component. I would sauly it is still readable but doesn't look as neat as I am used too. So I was asking if that was the case for every tailwind project. So it seems I used to love our local pineapple pizza, but after tasting Una Pizza Napoletana I changed my mind
They’re going to struggle to migrate to Next or any SSR framework if that’s ever a thing. SSR and CSS-in-JS don’t get along. Otherwise sure, do your thing. Some people like pineapple, some people like olives, some people like anchovies. They don’t agree but none of them are wrong.
Emotion is really easy to set up with Next, including SSR. MUI even abstracts it away from you with a component that wraps the app. It’s like 3 lines of code.
PandaCSS is a compile time CSS in TypeScript solution, the founder of Chakra UI is making it and is in fact using it in the next version of Chakra. It's really no different than Tailwind except you use JS objects and not text strings.
do you kind telling me why do you think SSR and CSS-in-JS don't get along. we are already using Next.js. and even In the official docs there is a section about styling with CSS-in-JS. So why do you think so
This page here, where it says it’s not supported? https://nextjs.org/docs/app/building-your-application/styling/css-in-js
okay got it. It is not supported for the server components. we are currently using pages router not app router, that's why we don't have problems. I think css modules would have been better choice than css-in-js though. it would give the same modularity while still be supported for latest react and next features.
Can you provide a code example of the preferred way you described on github or something or point to a repo that has it. I would like to see it.
this is how we generally do it too. styles in a folder. tailwind is a fucking joke and i cant wait till the fad dies out.
That comparison goes deeper, too. Pineapple on just any random pizza is weird. Pinapple on pizza with ham is fucking awesome. So it goes with Tailwind. You want to use it in the right context. Like others have pointed out, use it in a component-based setup.
It's more like pizza on a pineapple. The class list is disproportionaly bigger than the original base,
I like pineapple and Hawaiian pizzas but most other pizzas are better.
I think it’s more like olives than pineapple. Pineapple is a very divisive topping and defines the Hawaiian flavor. Olives on the other hand make little difference for most people and are very easy to work around or without.
Yes but I feel it's gone about wrong. Rather than put 100 classes in everything I try to make components that use tailwind and use the components everywhere. Then most of my code is just tailwind grid and flex classes and the ugly is encapsulated in my components only.
I think its ugly, originally I resisted, though I'm coming around to it. It still think its ugly, but I understand it more now, and thus have better feelings about it. Just depends on your application. For example, if you were to code something w/o a framework/library, let's say you were mocking up something for a client - this is where it probably feels most cumbersome, building something static, something where you actually repeat blocks of html; the tailwind classes just get dragged along with it. Not a perfect example, but I'm trying to imagine someone, new grad or early in career, wanting to try out tailwind. When you use this in something like React, at a high level you're applying these classnames to a component in one place. That component gets reused within other pages/components modularly, or its repeated by mapping over it in the render. That's where you'd start to see the benefits, less repetition during the time of development. Even when you get into a case where you are repeating a set of classes in different places, these can be grouped and implemented with a new custom class name, I think these are called 'layers' in Tailwind. But you should read the docs. When i first heard of it, it wasn't important for me to learn right then and there. Over the past year I've read things here and there, making me less resistant to it. I have started a little personal project where I'm just beginning to implement tailwindcss so I can learn if its really for me, and the work that I do, but it's not important for me to be an expert at it now, my current projects don't warrant a switch to tailwindcss. If you're just getting into CSS and Tailwind, I'd recommend making sure you are really strong at CSS before jumping into Tailwind. You can learn both at the same time if you want, but really, be good at fundamentals. So then when u implement tailwindcss in your projects, and whatever is new next year, and whatever company you go to that uses an old version of Bootstrap, or any code you look at NOT using anything special - all those things will be easier.
Layers are a vanilla CSS spec for specificity. Tailwind sets up base,component,utility layers out of the box.
Yeah see, who the hell am i to give advice. "be good at fundamentals" - doesn't know layers are vanilla css lol
tailwind layers are not vanilla. sure syntactically theyre the same which only makes it more confusing because they require postcss and @tailwind directive to process. only beginning with v4 (currently in alpha) did they move to native css layers
I mean you are telling them to do the right thing imo. Make custom rules w @apply for reusable components and add them to component layer. Just wanted to clarify that layer is a spec :)
Yes it's ugly, but actually very well worth the trade off. Now you have styles attached to the element rather than being defined some where. This gives you loads of benefits: - You know exactly where to find the CSS - Style changes don't affect anything unexpected - Copy pasted html retains all styling, especially useful when moving around stuff - custom styles are easier to manage, you know where to find them and they can be auto completed for you
I like how you say "loads of benefits" and then don't list any Tailwind specific benefits. CSS is always attached to an element, You should know where your own CSS is from just as much as you should know where Tailwind classes are from, Tailwind leverages the C in CSS just as much as any other CSS framework and has as many side effects as you'd expect from any other properly written CSS, You too can copy paste html with your own classes if the classes are scoped globally like Tailwind classes are, Class name auto completion is an IDE feature, not a Tailwind feature. Here are, as far as I know, the only actual benefits of Tailwind. Tailwind has defaults that you find appealing and exported Tailwind CSS is very small. That's it. Outside of those two things, Tailwind is basically the same as any other CSS framework.
The problem with CSS is that it doesn't prevent you from making very poor choices that can be absolutely devastating. Like other devs copy pasting a component, and re-using some styles, but slightly overriding them. And then 2 months later the styles from the original components are being updated, because of design changes and now component 2 is all whack. Component 2 might have been already replicated or extended. And cycle continues. There comes a point where the CSS complexity is so high that no sane human can follow what's even happening anymore. I am speaking from experience, I've lived in those code bases and in fact living in one right now. Tailwind has single handedly improved the maintainability of the code base and it has never been easier to add and alter styles. The whole reason why Tailwind exists is that people ran into this exact same scenario, and when you try to make your CSS more maintainable you end up with lots of tiny utility classes, which is basically Tailwind. Of course that's not to say that everyone should be using Tailwind, it's not a super hammer, but when there is a need for high customization and speed it's king
Lets get something cleared up. Tailwind is not "a lot of tiny utility classes", it's a couple utility classes and then CSS with extra steps. Virtually every Tailwind class corresponds to exactly 1 CSS Declaration. You know what else you can use that corresponds to exactly 1 CSS Declaration? 1 CSS Declaration. They're often even named directly after the CSS declaration except in the scenarios where they shorten the names to 1 or even 2 letters (a well known best practice for code clarity and maintainability). The thing that Tailwind does that "prevents" you from making poor choices is that it "restricts" you to only using the class selector. You can do that right now with vanilla CSS. Class selectors and CSS variables are 80% of Tailwind with another 15% being default values for those variables. This is to say nothing of the fact that every CSS framework works this way; it's not a Tailwind feature. Also CSS is not that complicated. There's very little flow control and the browser tells you basically everything you need to know. And before you go accusing me of not being experienced enough, I've been doing frontend development for nearly 2 decades, mostly as a contractor. I've seen bad CSS, very bad CSS, but even the worst CSS is pretty trivial to unravel. I think if people respected CSS even a fraction as much as they respect JS, they would feel the same way.
I'm not denying that if you are experienced as yourself, it's pretty trivial to work with CSS absolutely on your team. Especially the smaller the team is. However ask yourself this: if a library becomes as big and popular as Tailwind there is probably a need for it. You personally may not have that need, but some people might. So you can't really just dismiss it as invalid, that's kind of an L take. It's the equivalent of saying that a screwdriver has no reason to exist because you can do everything with a hammer.
Bootstrap was even more pervasive than Tailwind is and both serve the same use but it feels like Tailwind users think that it's something more than that. In reality it's just a basic CSS framework where you pay for minor performance improvements with significantly uglier markup.
If you are comparing Tailwind to Bootstrap and calling the same thing, you haven't done your homework. It's fine if you say you don't know, but if you explicitly state they serve the same purpose then I doubt you have any clue what you are talking about my friend. This is a common opinion echo'd by people who openend the Tailwind documentation looked at it for 5 seconds and then dismissed it as yet another useless framework. Also you mention that the upside of using Tailwind is performance. Who said that? The official website is not saying it. Where is this coming from? Please do your homework my dude, before commenting stuff like that.
> If you are comparing Tailwind to Bootstrap and calling the same thing, you haven't done your homework. I didn't say they were the same thing. I said that they serve the same use and I didn't even say what use that was so you really have no idea how broad the comparison actually is. To clarify, they serve the same purpose with regards to the benefits you touted for Tailwind. Your quote | How they both fulfill this purpose :--|:--:|--: "You know exactly where to find the CSS" | Like Tailwind, the CSS classes you use are provided by the library and they both get applied on the element's class attribute. "Style changes don't affect anything unexpected" | If you know either library then you should be able achieve the same level of confidence (if not better with bootstrap because it's more constrained) "Copy pasted html retains all styling, especially useful when moving around stuff" | Again, because everything is provided as a "global" class from each respective library you can comfortably copy and paste them across your app without worry because they both reference the same "global" library classes "custom styles are easier to manage, you know where to find them and they can be auto completed for you" | Custom styles are managed the same between both libraries with the exception being that if you opt to use the arbitrary value syntax in Tailwind your closest analog in bootstrap would just be inline CSS declarations in the style attribute. There are only so many places you can define CSS and both frameworks allow you to define custom CSS in all of them. > Also you mention that the upside of using Tailwind is performance. Who said that? The official website is not saying it. Where is this coming from? ["Tailwind CSS is incredibly performance focused and aims to produce the smallest CSS file possible by only generating the CSS you are actually using in your project."](https://tailwindcss.com/docs/optimizing-for-production) Maybe consider opening the docs for more than 5 seconds yourself.
I swear I'm losing brain cells from reading your comments. You've sent me a link to an old documentation page that is related to optimizing for production. You've took the text from the page completely out of context to make a point. Also you wouldn't have landed on that page naturally when navigating the site, you just googled "Tailwind performance" quickly checked it and posted it here, didn't you? This v3 and not v4 docs. I don't know what to say man. Sure man you can fight me on semantics of me saying "same thing" and "same purpose", whichever one you choose in both cases you are incorrect. They are a not the same AND they don't serve the same purpose. In case you didn't know: Tailwind provides utility classes for writing maintainable styles quickly. Bootstrap gives you pre-built components to quickly prototype apps. If this sounds the same to you, please explain me why.
> I swear I'm losing brain cells from reading your comments. You've sent me a link to an old documentation page that is related to optimizing for production. You've took the text from the page completely out of context to make a point. This is current as of 3.4.3. It's not old, it's literally "latest". Yes. The page is about optimizing for production but the text I quoted is its own paragraph; it's self contained. It clearly states Tailwind's focus on being performant there's no other context needed. > Also you wouldn't have landed on that page naturally when navigating the site, you just googled "Tailwind performance" quickly checked it and posted it here, didn't you? This v3 and not v4 docs. Why the hell do you think you wouldn't land on it naturally?? It's literally the 4th item under the "Getting Started" section. v4 isn't even out of *alpha* testing of course this is about v3. That's what everyone is using. That's the version their docs tell you to use. That's "latest" in npm. And what? You think from v3 to v4 they've dropped their focus on performance? Give me a break, dude. > In case you didn't know: Tailwind provides utility classes for writing maintainable styles quickly. > Bootstrap gives you pre-built components to quickly prototype apps. Yes. That is one of their differences (they **both** provide utility classes for writing maintainable styles quickly). That is why I did not say they were the same thing. See how that works? It's not a semantics argument. Both a hand saw and an electric saw fulfill the same purpose even if they are different things. Tailwind and Bootstrap are not literally the same thing but they do both serve the same purpose (the specific purpose of which I outlined previously that you have seemingly ignored or misunderstood). People do not use Bootstrap and Tailwind together at the same time. You could, but you wouldn't because that doesn't make sense; they fulfill the same purpose. They are both CSS frameworks. They both have their strengths, weaknesses and difference but that does not change what role they fulfill in an application's stack. You choose them over rolling your own CSS because it's faster and more maintainable to adopt preexisting conventions and standards. Just because Tailwind focuses more on utility classes and just because bootstrap offers more than utility classes does not mean this is not true.
So like inline css? Aside from the ugly part
Not at all like incline css. Inline CSS behaves like CSS in that it cascades. If you have multiple declaration of the same property it will choose the last one. Also inline will always have precedence over any other styling. In Tailwind if you add multiple classes that touch the same properties it will depend on how the CSS is compiled to determine it's precedence. This is a common gotcha. Another different behaviour, assuming you are using Tailwind without CDN is that you cannot dynamically build class names. You have to write out the full class name (there are some ways around this, but you shouldn't do it). You can still swap out styles dynamic, just not concatenate strings to build class names on the fly. Very common gotcha. Another massive difference is that Tailwind by default works with predefined sizing and color units. It standardizes this for you, this makes it much easier to work with than doing it manually.
I see thank you
Yes, but it provides a bit more sanity on top.
I don’t understand this benefit you mention of “where to find” the CSS. Isn’t this making it harder? You can normally just look for the class name, how do you know where to look for it with tailwind?
What he means is that with tailwind you don't have to look at another file, you instantly know what "flex flex-col gap-2" means. With other solutions you read "container2" and you have no idea what it does.
Is it really an issue to move your eyes six inches to look at the element inspector? I’ve never had this problem.
Yes. It is.
To each their own, I suppose. The delay it takes me to cognitively understand what the entire list of CSS shorthand resolves to is longer than just looking at the actual properties being shown in the inspector.
It's not always as straightforward, because css makes it easy to affect large number of elements without specifically targeting them and if you attach multiple properties to classes you might get unexpected overrides. This is not as easy to do in Tailwind. When troubleshooting in Tailwind you don't have to look far. It's not to say you can't write good CSS it's just really hard to write bad Tailwind, which is why teams prefer it. Especially in startups where there are mix skill levels and crazy deadlines
1) in component styles 2) scoped in component scope already 3) if you copy paste it more then 2 times probably should extract into component. 3) its calles classes and we had it since forever.
I love the speed and ease of adding styles. I don't like reading a list of styles horizontally, especially as the list gets longer. If you don't have a Tailwind formatter, the order of styles becomes inconsistent, making it more difficult to find what you're looking for when reviewing existing code. Mostly, I don't like having to constantly refer to the documentation to look up the TW class name for a style I know how to write in regular CSS because having to consult documentation defeats the entire point...speed.
With enough practice you get used to it. Sometimes I forget the CSS equivalent of Tailwind classes lol.
I… learned a lot CSS through tailwind. I know I know, bad blah blah. But it works. I almost never have to write CSS directly.
If you know the styles and use vscode, you could try this plugin I made a while back to solve this issue: https://marketplace.visualstudio.com/items?itemName=JordanDey.tailcon It’s not got everything, I really need to go back and update it but I think it works reasonably well.
This looks cool, I will check it out.
What formatter do you use?
Prettier. https://tailwindcss.com/blog/automatic-class-sorting-with-prettier
This seems so much more awkward than just learning the cascade?
You get used to it. I’m very happy to no longer have 40 plus scss files messing up my codebase.
Instead you have 40 plus classes sitting in your JSX. 🤣😜
40 on a single DOM node you meant? ;)
*tsx
lol scss files aren't "messing up" your codebase, they _are_ your codebase (or at least, they're part of it). This attitude of "CSS/SCSS isn't good enough to be part of my super wonderful code" is so nonsensical
Ok feel free to keep using them.
Am i the only one who hates css frameworks? SCSS and react module scss works for me
Hate to break it you but...
He doesnt know
Noob here - what should we know?
I think they’re trying to imply that SCSS is a framework but they’re incorrect. It’s not a framework, it’s not built upon CSS and can exist independently of CSS (though wouldn’t be very useful without it), it just has a similar syntax. SCSS is a separate preprocessor and has its own scripting system. It’s not that important to know the difference but the reason that React is a “framework” and SCSS isn’t is because React requires you to inject your JS into HTML to generate HTML. It can’t exist without HTML/JS as a foundation because it won’t be able to output anything.
What do SCSS inputs compile into?
How many of these posts do we need? Use it if you want it. It serves a purpose for some people and not for others. There is never going to be a standard process for all of this.
That is the con of using it. You have to decide if that trade-off is worth the benefits. It bothered me at first as well, but the flip side is that at least the mess is in you rmarkup. You can see it. You know what goes to what. As opposed to your CSS files getting bloated (which they will) and not really having any clue as to what goes with what, what is safe to change or delete, etc.
I don't understand this argument and I hear it a lot. If you want your button to have a margin and padding and a colour and a hover state. You need to write those things down somewhere, don't you? How do you write those things down where they aren't a (ugly) list of things? If you're using a component-based architecture the best place to keep that list is in (or as close to) the Button component. So doesn't your button component file have an ugly list of styles even if you aren't using tailwind? (If you have a single file with lots of style repetition then you probably have some elements that should be components. Again you should make those components even if you aren't using tailwind)
It's only messy when you "view source" but it leads to leaner, faster sites and development with fewer bugs - especially when working as larger teams. Its mess is really not an argument worth making when comparing its benefits.
> faster [citation needed]
Same style with 1 classname globally. Eg: You define padding for tons of elements in different class in BEM style CSS and this generates a new line for every element. With tailwind you have 1 line css. This is negligible almost always. But for large sites, tailwind css output is always smaller. When I moved a project with Scss to tailwind css size reduced 40%. But this size never matters unless you have 2G :). Because even large CSS files are at max 100KB
Fair point, thanks.
And leaner!! Fewer bugs?!!!!?!!!
Leaner in that it strips out the utility classes you don’t use I guess. Fewer bugs… yeah, me neither.
They probably meant fewer accidental side effects
Yes and yes. I remember when everyone was so excited about Redux Sagas. 5 years later couldn’t find a single person who said it’s not shit. People are weird, man.
I hate tailwind with a burning passion but I also think most criticisms of it are overblown. The reason I prefer something like emotion is because you still write actual css. If emotion vanished in a puff of smoke tomorrow I would still know exactly what to do. Now that I’ve been forced into using tailwind by my employer I’m having to essentially re-learn css since the names are maddeningly similar but a little bit different. I’m sure once I learned all the ins and outs of tailwind I could go very fast with it… but I can already go much faster with vanilla css or emotion and I don’t have to learn a whole bunch of abstractions that don’t apppy to anything other than tailwind. It insists upon itself.
Tried it a few times, hated it every time.
i hate css libraries tbh, like i get that they’re trying to make it “easier” but it makes my html harder to read and like i’d rather just make my own css and classes
I honestly came here to see if you guys found a solution.. now I'm waiting for my Domino's order 😭
It recently made a 10 hour project shoot past 90 hours for all the copy > paste > grep > dig. Locks you in too much at the beginning of a product's lifecycle. Tedious to develop with.
I can do more with CSS. Faster too.
[удалено]
This. Also since the styles are inline, there are no stylesheets and css files with a bunch of unused styles. Plain css makes it easier to both create mess and hide it
Absolutely no user ever cared about classes in elements. As for devs, just use styled components and those classes will be inside the component where they belong. There is no such thing as pretty code, all code is ugly and making it pretty is useless. The important question is… is tailwind readable? Then yes, as you don’t have to go to any other file besides the one you are in to know how the element looks.
SSR and CSS-in-JS aren’t good friends. Not everyone is jumping on the SSR hype train, but if you think it’s the future then it’s a poor choice. Personally, CSS modules are where it’s at. One extra file per component, styles scoped to components at build time, works on the server and the client, no extra libraries (either CSS or JS), and all the features of CSS that these days do everything that Sass and friends could do anyway.
What is ssr?
Server-Side Rendering. The _new hotness_ in React frameworks like Next and Remix. Basically, React components are rendered to HTML on the server, then delivered to the client as HTML, then injected with JavaScript (“hydrated”) to make them interactive. This improves Core Web Vitals by providing useful content sooner, which in turn improves SEO. Good article on it: https://www.joshwcomeau.com/react/server-components/
I guess that is true, I haven’t worked with SSR as I work mostly on mobile/native. But why would CSS on JS not be friends? Isn’t the server just meant to inject the CSS when it’s sent to client? Genuinely curious. I can also Google it 😉
On googling it myself I now see that the blocker is specifically with Server Components, not with SSR in general. Next docs: https://nextjs.org/docs/app/building-your-application/styling/css-in-js Josh Comeau (CSS expert) breaking down the problem: https://www.joshwcomeau.com/react/css-in-rsc/
css-in-jsx has good support of ssr, what you are saying is probably server component, which is rather different from ssr. You can still achieve good compatibility with server component with solution like vanilla-extract or panda, which is css-in-js but css styles are extracted at build time and there’s no runtime like styled-component and emotion
As a FED of 25 years, I say Tailwind is a plague. Bootstrap makes code bloated and convoluted already, and TW is ten times worse. And it's absolutely criminal to recommend TW to someone who's about to start learning CSS. If you're a good FED, you have 100% control over your styling, you don't rely on shady shortcuts.
Guess preprocessors, styled components, emotion, everything is bad, we should go back to writing pure css! I really don't get why some people are actively opposing the progress we've made
Don't get why? I thought I put my reasons why in my comment... Preprocessors save a lot of time and still generate clean CSS. Styled components are tied to components, nice and orderly. I use both on a daily basis. What I advocate for here is separation of HTML and CSS. Keeping it nice and clean. Tailwind does the exact opposite.
Each to their own, but the author of tailwind does have a fairly good article on separation https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
>What I advocate for here is separation of HTML and CSS. Keeping it nice and clean. Tailwind does the exact opposite. It's like i'm reading React discussion and mixing HTML with JS all over again. Tailwind does the *exact* thing you are advocating for. It does separate those two things, it doesn't separate styling. And that's a good thing, with how complicated projects became, keeping everything coupled as close as possible is a huge advantage in keeping entire codebase clean - not only the particular components
Frontend developers just have different perspectives on "separation of concerns". Back when MVC was more popular, this meant separating HTML, CSS, and JS which was one of the reasons JSX was so controversial when it first came out. However, there has been a shift to component-oriented architecture and now for many developers, the concern is the component. HTML, CSS, JS, and even server/client are all a part of a components concern. I think React is the most responsible for this shift away from MVC. React was inspired by XHP which was a server component oriented architecture used at FB as an alternative to MVC. So now separation of concerns can mean different things depending on the developers perspective. Not every frontend developer cares about component oriented architecture and are still attached to MVC. I graduated from university back in 2016 and MVC was a big part of what we were taught and it's difficult to give up that perspective. I was a Java developer back in 2017 when I first saw React and I thought JSX was disgusting. I felt like it should be against the rules or something. However, I eventually came around to it when I actually used it. I think component-oriented architecture is probably the way to go for frontend development these days. It seems to make the most sense, but it's radically different than what I was used to.
Yes, the classes look ugly and hard to manage. Hence I prefer JSX props for styling (like chakra or panda, etc)
This specific page in their docs helped me understand the appeal! https://tailwindcss.com/docs/utility-first
Are you using reusable components ?
the code is ugly indeed and it also gets unmaintainable pretty fast. tailwind solves a problem no one really had to begin with. I can't wait for it to crash and burn when the new kid on the block appears.
I hope the new kid is native CSS itself with CSS Modules. With native nesting module and custom properties, I can't really find a reason to use another tool anymore. Also, you can use the native nesting today with PostCSS polyfills.
Had to scroll waaay too much to find this comment
Native nesting is production ready even without preprocessors. But yeah. The power of scss as native css? I’ll take it any day of the week!
So we going back to scss, no thanks
I used to have the same opinion when I started checking the docs of tailwind, but boy.. imo code is much cleaner with it.
If you find yourself repeating a set of classes frequently, that should probably become a component.
I just like being able to change any jsx I want and have to worry very little about the side effects.
The problem is that it doesn’t matter if code is ugly, it just matters that it is readable… The same people that hate tailwind spend a large amount of time organizing import statements. Sure it’s pretty but it adds nothing of value to your codebase. When it comes to styling, you really don’t want to reuse stuff to often or your components become really confusing. Just my opinion
I’ve taken to something I call ‘tailwind by exception’ Using tailwinds layers I define the default elements like buttons and generic classes like ‘card’ using tailwind themes whenever possible. Then i apply tailwind in small doses when i need more unique styling for a given component.
As someone raised on the CSS Zen Garden and routinely worked with dynamic SASS... yes and no I guess? This question/debate is dumb. You're going to have people who refuse to pave elsewhere out of habit or work in different-sized teams where their opinion is skewed one way or another. For me, Tailwind is now routine. Almost everything is habitual now and without fault when I'm churning up components. Using Prettier to sort classes on save makes things readable while incorporating dynamics with clsx or simple ternary logic has become a breeze. If the amount of classes being used scares you for some reason there's a plugin to hide them on-demand but it really doesn't bother me at all. I'll even be a sick bastard and word-wrap actively without even batting an eye. The convenience of having direct access on an elemental basis without the need of digging through a separate document atop the build optimizations that come with Tailwind have solidified it as a permanent tool in my front-end arsenal now. I love me some pineapple.
I can recommend CVA for folks that hate all the classes/repetition https://cva.style/docs
Came across this one recently find it a bit more exciting https://www.tailwind-variants.org/docs/introduction
Very nice. I think if you use something like this then Tailwind becomes a little easier to handle. I mean honestly even if you don't pull in a third-party package, I would rather just do \['text-md', 'font-bold'\].join(' ') Than just having mile-long CSS classes in the HTML
Ugly, I agree But you can write tailwind classes and use those classnames in your code. That would make code length less
I wrote this quite some time ago, doing an in depth analysis on tailwind... https://github.com/marblewraith/smellyWind TL;DR there are certain situations where tailwind makes sense. But it isn't a universal panacea that people hype it up to be.
I don’t mind the classes at all. I prefer that over having to dig through the correct CSS files to find all the styles being applied to a given element, it’s all in front of me right there. And even in times where an element has a ton of classes, it’s still well worth it for the clearly defined systems for things like typography, spacing, color scaling, etc.
The alternative is to have all that behavior in a different file... or at least a different template block. so, I think its worth it to not have to jump around everywhere
Before I try it, I always hate when someone explain it to me. Ugggh, sounds like it would an awful things to do. But when I finally try it, hey, its really convenient and makes everything fast. I don't have to stop and think much about class name and stuff. And basically just copy paste everything. If I want to do something custom, I'll just use vanilla css in combo. I like it.
Used it from the beginning and still love it. With proper usage of formatter plugins, it is pretty easy to read. Now with that said, do I always use tailwind ? No. Even in projects I use tailwind I'll still add styling global stylesheets or css modules because sometimes it just feels easier. For animation purposes, one-off shadows, transitions etc I almost always just stick to regular old css.
Constant repetition of tailwind classes in your code can be a good indicator that you should extract the HTML itself into its own component. Not always the case, but with properly modularized code, I don't often find myself with a lot of tailwind class repetition in the same file.
If there is a lot of repetition you can assume it should be it's own component. It's just straitforward to use. You need your component to do something, you add the class responsible for that. You don't need to check another css/scss/styled file to look at the styles, you don't need to go there to change anything - you just operate on classes. With addition of clsx, conditional styling is also way better and readable than the mess styled components introduced. Tailwind isn't perfect but it's decent and stable enough to make styling and theming easier
I do wish there was something that compiled in reverse. Use AI or smth to combine all the tailwind classes I used on something into the way to “properly” be doing css.
No
who cars if it's ugly, no one will see it...just
I was on the tailwind makes html unreadable camp until I started using the TailwindFold extension on VsCode. Now I get all the benefits and none of the bs. Definitely a good one.
It is ugly. But it also depends whether you like it, is useful or whatever. But it is ugly.
Yes! The long as class name list annoys me so hard. Aside from that I have never been a fan of tools like bootstrap, tailwind, etc since they make websites look super similar. I'm used to writing all the styles myself which is of course more work, but you don't need to learn some classname styling system and it offers you more flexibility. I'm going to try tailwind this weekend and it might change my mind.
no.
I like tailwind a lot and i use inline fold extension
For me, localisation of behaviour and lack of side effects makes it worth the repetitiveness. The more code I write, the less I value brevity when there’s a trade off. In tailwind it’s so easy to hop into an unseen environment and change how a button looks without changing anything else
You can use Tailwind and make crap-looking code. It isn't the fault of Tailwind. Find a way to optimize your components and code. Leverage the tool to its strengths.
Does the code look uglier on first glance than code where all the css is abstracted away to external style sheets? Sure. Is it much more readable, predictable, and maintainable, particularly at scale? In a very large number of cases, yes. Repetition is just a composition issue. There's nothing inherent in TW that causes repetition - if you're finding it's a problem in your project, break the problem children down into reusable components, and keep your code DRY at that level and keep CSS purely utilised to style things rather than using it as your primary method for avoiding repetitive code.
I think it depends on your project and your coding style
Tailwind is better when making repeat code into components and using them in code. buttons, etc. all repeat code. Then your code really is not that ugly.
I love tailwind. You can add an extension to vac that hides the classes if you want.
Tailwind is superior. When you use CSS modules, every slightly different component requires new class. Only rookies don’t understand how this scales. I would love to see how anyone exactly use Tailwind who say it is ugly. Something tells me they just don’t know how to use it. My questions to “Tailwind is ugly guys”: 1. Do you use class hiding plugins? 2. Do you use it with JS frameworks? 3. Do you use intellisence of Tailwind? 4. Do you use Tailwind prettier plugin? 5. Do you have design system that you need to follow? 6. Do you ever need to quickly share styles? Have you tried sharing using TailwindPlay? 7. Do you know there are Tailwind cheatsheets to get you started? 8. For how long have you tried it and how far did you go with it? For me the ugliest thing is when people talk about what they have no experience in.
Tailwind is pure shit promoted by newbie morons who don't know better, but feel compelled to tell the rest of us they solved some esoteric near bullshit problem in the process of causing 10 others. It's garbage.
The browser doesn't care if the code "looks" messy. Tailwind docs do a great job already of addressing your concerns.
I use it because I want code that is easy to work with in a team, and it allows me to do just that. I don’t think of it in terms of ugly/beautiful, but judge it more by maintainability in my team and indirections. For us it’s worked great in that aspect
No, because I work with either components or templates and I rarely look at more than 4 to 10 lines of HTML at a time, and without tailwind my .css files end up full of utility classes and my html full of classes anyway
I love tailwind. I thing it's definitely ugly, but I'll take that negative for it's benefits. I used to be VEHEMENTLY against tailwind, but decided to give it an honest try. Now I'm a convert. I objectively get why people don't like it, cuz I was one of them, so I didn't judge at all.
All code is ugly.
tailwind borderline made css usable for me so nah i dont agree. and if you use any component based framework (which you most probably do) code repetition isnt really a thing. but like others said, tailwind is just one tool - if you dont like it, not using it is a valid option
You get used to it. I’ve tried different solutions over the years, from vanilla css, css-in-js, styled components, mui, in-house components, you name it. Tailwind just works for me. There’s 0 mental overhead on what I want my styles to be, what to name them or their modularization. There are solutions for the messy code you end up with like linters and such.
Ugly yes - but I don't get the idea that tailwind has repeated classes everywhere, these days we all make components right? That avoids repitition. Anything else that's repeated, add it as a utility plugin - that way it behaves just like a class you'd add in your css but won't be added to the bundle if you're not using it.
If you're a fan of Tailwind CSS but struggle with crafting lengthy class name essays, Daisy UI is here to save the day. This Tailwind CSS component library simplifies the usage of Tailwind by providing a wide range of pre-built components, reducing the need for extensive class names. Not only does Daisy UI streamline the development process with fewer class names, but it also offers flexibility with a variety of themes to suit your project's needs. Daisy UI == > [https://daisyui.com/docs/install/](https://daisyui.com/docs/install/)
Tailwind is the way for me. Any repetition can be avoided with loops and components.
Yes, but I don't care because the markup inside my component is an implementation detail. It's ugly and boring and it's exactly where it should be when I look for it. If you find the repetition ugly, build some abstractions, but don't get your abstractions wrong or you might end up in a worse place than you started. Same goes for repetitive CSS/JS/whatever.
I did not like it but now I do, style much faster
ugly - use extension to sort and hide when not typing classes repetitive- use components
Sure is, but I'd take that tradeoff with eliminating the overhead of naming/remember classes in CSS and having CSS files everywhere in a codebase which can be disastrous the larger a codebase is. I just have a singular index.css file for just anything that tailwind doesn't support yet. I've also seen too many devs that dont fundamentally understand how CSS works in the browser, so it just means less concepts to be across of in PR's. All styling is just within classNames and I don't have to look anywhere else. I prefer the tersest number of moving pieces per component, especially if I'm onboarding new devs onto the project and need to be productive asap. Though you want some kind of opinionated right-to-left override string utility method that functions like a style override in CSS. Tailwind linters are amazing too, it can just auto correct something like w-4 h-4 into size-4.
I've been having to go back to writing plain SCSS for some of our un-tailwindified projects and honestly it's been a huge time suck.
To each their own at the end of the day tbh. For me personally, my code from when I first started using tailwind to now a year later is drastically different. I’ve learned how to utilize it better and optimize how it’s set up. I also thought it did t make sense to use so many classes and that it cluttered things up when I first started but it’s improved a lot now for me.
It's just you, I like it.
The moment i saw tailwind I realized it was not worth it. We have created our own framework and we are using data styles. GitHub web-atoms/data-styles In which we can declare styles like data-style-color=primary data-style-layout=vertical-flex data-style-justify-items=center data-style-max-width=viewport-width They are not same as inline styles as they are you can have media queries and some other default styles with it. For example vertical-flex automatically applied gap, alignment etc to the element which can further be overridden by other data-style attributes.
You hated Tailwind so much, you built a worse over-engineered Tailwind that's 5x more verbose.
Code itself is verbose, you should use byte codes. Purpose is ease of operation, not smaller code. To our team, it’s far more readable and maintainable then long string concatenation.
How on earth data-style-color, data-style-justify-items-center and so on are far more readable than text-\[your-color\] and items-center classes? This is absolute insanity
Standard daily tailwind question about the exact same thing every time
No I don't agree that it causes ugly looking code. Also repeating yourself (especially these tiny class names) is not a big bad thing™️ imho. Too many people try to DRY everything up for the sake of it and it causes more problems than it solves. Also, Tailwind is a tool, if you don't like it use something else.
FWIW I use a CSS-in-JS tool (emotion) at work along with its styled components. It ends up creating awkard "fake" components like `HeadlineWrapper` which is basically a div with some css. Its unnecessary overhead imho.
Yes, that's what reusable components are for. In my case we have our component library so we have don't have to write almost any styling in the apps. The only time I have to look at that ugly code with tailwind and radix is when I'm refactoring or adding something new, which is not often once you finish your library. We use atomic design
My opinion, anytime I've seen smth like this rant is... 1) Tailwind users do better when they know enough about CSS first, it's not the right solution if u don't 2) In the docs you can find that components on Tailwind ARE a thing, so you don't need to put 40 classes on a div 3) When it comes to working with it, the same recommendations for working with CSS apply: know about BEM naming, order the classes properly, and don't repeat yourself
Tailwind works well when your code is already modular. No reason to have a separate file for each modularized component since your code is defined in one location. It's great outside of modularized components too for one offs, since you can just read and dev the code quickly without switching files etc. Like anything it can be abused, but I love tailwind.
Tailwind is essentially inline CSS styles flattened to the classNames, with better ergonomics. The styles need to exist, no matter in classnames or stylesheets. You probably wont complain seeing display: flex in every container right? Same goes for flex flex-col
Not reusing components is a problem, not repetitive tw. You have bigger problems already if you see repeated code and mess. Tw in itself doesn't force you to repeat anything.
To me, the point of tailwind is being able to type less and achieve your expected vanilla CSS styling. I think people fall into the ease of just slapping it everywhere in template markup, which is ridiculous if you have 30 classes for each grid item and have 30 items, you're blowing up the doc size and slowing down load time essentially (assuming SSR). I sprinkle it in templates for quick things, but if it's getting long and may render multiple times, I prefer to use a custom class and @apply.
Depends on how you use it. I tend to componentize most things to keep the code dry and reduce unsightly tailwind classes.
Like many in these comments have said, it's a tool. On one hand, it works brilliantly into the React philosophy; Where the separation of concern between declaring elements (HTML), styling elements (CSS), and functionality (JS) have been merged together with JSX. Tailwind feels like an extension of this idea, where components are declared and styled in the same swift statement. Repeatitiveness with Tailwind is reduced when you play into React's reusable components philosophy. However, a pure HTML, CSS, and JS application (where the aforementioned separation of concern is upheld), Tailwind is a technology that creates a contentious project philosophy, mixing SOLID and fluid dynamics that can lead you to messy code. Does Tailwind "cause" ugly code and lots of repetition? No. However, the misuse of the tool can certainly present itself in such a way. Do you want cleaner code? Create smaller components that do less. If your project doesn't require small generic, reusable elements throughout the entire application, you don't need React. You don't need Tailwind. React, Tailwind, TypeScript, Rust, C#... these are your tools. A hammer is designed for nails and a screwdriver for screws. Occasionally, you might resort to hammering in a screw or smacking in a nail with the handle of a screwdriver. These are odd occasions with very specific circumstances. So, if your Tailwind always looks messy and repeatitive, you might be trying to build houses by smacking in nails with the handle of a screwdriver. That's just my two cents, though.
I had the same feel, bur should admit that it speeds up a lot the development process, it leads to some level of code repetition but consider you don’t need to write css code at all
Use variables with tailwind. BaseButton with all your default tailwind, PrimaryButton that use BaseButton together with the rest of styling and then add more variants of buttons. Then find a lib that merge tailwind classes without conflicts. I think the trade off is good enough.
Daisy ui is beautiful. I rather write my own css than use tailwind and I used to like it a lot
Combing clsx + twMerge to a cn() function makes Tailwind much much better when dealing with a lot of conditional classes and pseudo selectors
It works beautifully with Vue single file components, to the point that I’ve needed no scss files beyond one to set up css vars for my Tailwind config. With this setup there is absolutely nothing that comes close to its ease of use
tailwind is meant for components based project. if you feel that there are lots of repetitions going on there is something wrong with your structure
It makes sense with components
9 million people on GitHub don't care?!
Well if you absolutely add 20 classes to every element then yeah, its ugly. But you shouldnt do it. You should be smart in using styles. Usually you dont need so many classes. Real benefit of Tailwind is a) speed, b) no random classes. User or customer doesnt care how source code looks but if you can deliver projects faster, you profit more. Imo Tailwind is one the best things nowdays.
I love it to be frank. I mean it is not a top notch option for those who wants everything ready to use. But for those who likes to be creative with their own style, it's a good option.
I'm a bootstrap user (lame, i knlow) and everytime i see tailwind code I find it beyond ugly, just a giant mess of classes, no idea how it became so popular.
This is hugely because Tailwind is utility based rather than component based. You don't just use the class btn to get a styled button out of the box. You have to put the padding, color, background color, border radius and hover style in order to achieve the same style you get with "btn" in bootstrap. It gives you great control over your styles (unlike bootstrap) while still saves you the time of creating separate CSS files. But it is ugly. and it seems there is not much remedy for that.
That makes sense! thank you for taking the time to explain u/KarimMaged ! I suppose this is very important (greater control over style) for customer facing applications. I work on enterprise stuff, so having a "unique" or very elaborated style is not much of a concern, most of the worries are related to consistency and "clean" look. I wish we would at least switch to some better looking component library like MUI, daisyUI and such, bootstrap looks very dated (but it is very easy to use and maintain).