What is it about everyone using Tailwind? It inevitably becomes a mess in every codebase I've used it in; it's like Perl, a write only language.
I just use Vanilla Extract (with their Sprinkles API) and call it a day, it uses TypeScript as the preprocessor language and then compiles it to raw CSS, similar to SCSS but without writing SCSS.
I’ve recently started working on 2 legacy codebases, one with tailwind and one with scss. The #1 problem — that has cost me multiple hours! — is inheritance, because how developers write CSS and how business people think about design are very different. I constantly find myself causing side effects when making any change to the css, it’s a headache.
I don’t think tailwind is perfect but coming into a well-established codebase I am so much happier to see tailwind. I can’t think of a single issue I’ve encountered with tailwind in this context.
You can certainly write good, maintainable CSS and I’m sure tools like Vanilla Extract make it easier but to say tailwind is worse is just wrong (in my experience, anyway).
I work in React so all of our CSS is scoped, at the very least with CSS modules, so we never get to a point where we have global CSS, at all. If you're working on a project that uses global styles, then yes, it will be extremely painful.
But in the days of components, Tailwind simply is worse to me from a maintainability perspective than just having scoped CSS. It is at best equal to CSS classes because inevitably the pattern used is with @apply or making a space separated string of all the Tailwind classes in JS in order to add that as a variable to whatever div you needed to. Which is, well, CSS classes reinvented.
And many people don't work in components or scoped CSS. Utility classes help so much in those cases.
The only problem with tailwind is it goes super overboard with the idea. You want to use probably 30% of tailwind and use their naming convention. But once people start to write some long on demand single classes its always better just name a class and use CSS.
I think its because the authors need to be seem they are making updates all the time and can't accept that it's pretty much finished project. They also don't want to accept that utility classes are not solution to everything and good old CSS still has lots of use.
What I’ve found from our Tailwind codebase is this:
If you have a design system, Tailwind.config can be used to both extend and limit the classes. Notably, we cut all tailwind colors out and only define theme colors. We also define all sizing, shadows, and text styles around our design system. This constrains your design down to only “legal” values. This doesn’t mean every design will be magically right, but it separates the possibility of non-standard values out at the very least and has actually caught bad mocks as well.
I think, to me, tailwind isn’t done and I need one thing: let me group classes with modifiers.
I want xl:[text-bold p-4] instead of xl:text-bold xl:p-4
Ultimately I don’t think tailwind is perfect at all…but no CSS framework is. In fact, I think part of the reason it is a hit is because mixing custom components with both custom css AND bootstrap is a mess as well in the real world. At least Tailwind has a single source of truth.
If you look how marketing teams / agencies use tailwind its exactly for it's ability to customize. Utility frameworks in the past (like Tachyons) were not very useful for them because they didn't have the customization. Every project starts with config and many things are turned off. Not only colors but also for example typography is too constrained in TW by default and it's better to make your own utility classes for likes .text-xl (because of media queries).
Your example xl:[text-bold p-4] is performance anti-pattern. Don't forget that main reason utility classes came to be was performance. It's fastest to put class directly on element and you end up with very small css file because you don't repeat.
When you start to do xl:[text-bold p-4] you will end eventually write xl:[text-bold p-4 pb-2] or even xl:[p-4 text-bold]. Now you lost one of the main advantages of utility classes and end up in more confusing world than pure css.
I’m fine with a find and replace at build time with xl:text-bold xl:p-4 for that very reason, that would be my expectation.
Yes you can make utility classes for typography styles..that’s entirely the point of extending the framework, they are extremely clear that you should even.
None of this precludes the idea that it is configurable to the point of making it a better solution for one’s needs.
Personally the vanilla extract example looks like literal boilerplate hell for any sort of actually complex application. It might make complete sense if the whole thing was based on a declarative template where the objects also define elements but here it is just SCSS done elsewhere.
The reason why people like Tailwind at build time is that it removes a step of defining classes out of the flow and puts all your styles in one place. That is the innovation: mental, not technical. I have a pet theory that Tailwind is more preferred by those with ADHD as it completely removes a mental blocker element.
VE is a SCSS substitute for those that like TypeScript instead of SCSS as a language, you can do the same stuff in either one. They even have custom utility classes too. Why I like it is it enforces a design system onto your code. In the Tailwind world the library CVA does the same thing so it's not a novel concept.
Why use @apply if your CSS is component scoped anyway.
Additionally, CSS Modules is not a replacement for TailwindCSS. TailwindCSS ships and strongly promotes the use of design tokens. It is harder to NOT use design tokens in TailwindCSS.
Because of this, there is no CSS Modules v. TailwindCSS. It is CSS Modules + X v. TailwindCSS. Where in the worst case "X" is just a stand-in for "everybody does whatever" which produces horrendous unmaintainable stylesheets whether they are global or not.
I’ve found what you said to be completely untrue unless you’re totally lazy. If you’re building up a bunch of components, the tailwind classes are mainly within the basic components.
In the first example of vanilla extract, it uses exact px measurements which already demonstrates it’s not geared to solve one of the primary selling points of tailwind (using config as a constraint to reduce mental overhead when building things).
And have you had to work on hundreds of components that you had to refactor before? It's a write only language.
> I’ve found what you said to be completely untrue unless you’re totally lazy.
Ah yes, the laziness argument. Let's not blame our tools but ourselves for the tools are always good and righteous. If only those darn C programmers weren't so lazy writing their memory leaks.
> And have you had to work on hundreds of components that you had to refactor before? It's a write only language.
Once you know the syntax of Tailwind you can jump into any codebase and instantly know what’s going on. With “standard” CSS you’re forever jumping between components and class definitions.
Once you know the syntax of CSS properties you can jump into any codebase and instantly know what’s going on. With Tailwind you’re forever jumping between components and figuring out what that one long line of class names is actually doing.
> With Tailwind you’re forever jumping between components and figuring out what that one long line of class names is actually doing.
Only if you already have no clue what CSS is. If you know CSS and can’t figure out what a given tailwind class does, then I don’t know if anyone can help you.
That said, I do often feel that I might as well just write the css directly. Writing tailwind feels like another translation layer.
Your last paragraph is precisely what my point is. I simply don't understand why people like the indirection. Sure, it feels amazing to clap together a few classes and not have to think about naming them, until you later find that you don't know what the hell a given div is and have to spend a bunch of time parsing the one long line of Tailwind classes. If you try grouping the Tailwind classes using @apply for readability, congratulations, you have reinvented CSS classes, except with a DSL on top.
When I come back to a bit of code I haven't looked at for a long time, I find the class names I set on the individual elements extremely helpful, like comments that never go out of date. I can immediately orient myself and know which classes to look at (I use scoped/namespaced classes; not like BEM which is too dependent on HTML structure, just a namespace with the element class, like .Banner-icon).
I've never fully committed to TailwindCSS, but I have tried out my own utility classes on a smaller scale, and I found myself having to parse the entirety of the code to figure out what was going on.
My preference now is a mix of utility classes for super basic things that would be tedious to set a class on, and custom classes for everything else. Especially if media queries are involved, because good lord is that ever tedious to do with utility classes. If I find myself setting more than 2-3 utility classes on an element, I usually end up moving that to a CSS class for one reason or another. I don't define the utility classes until I need them, and I really don't use very many.
That's a good way to do it personally, and I might start taking that approach too. The Tailwind syntax for some of the more complex stuff is appalling.
One of my most-used utility class is "reset". Default styles are great, but they often get in the way, so I'll throw this on an element whenever I want to start from a blank slate, alongside other utility classes or a custom class. This can significantly cut down on the length of my CSS files, as well as make them much less brittle and less dependent on the HTML structure, because I don't need to repeatedly undo default styles in every rule I write. My scoped CSS files are typically under 100 lines, even for somewhat complicated things.
You mean the readability of "p-2 bg-red-500 text-lg font-medium" or "i-dont-remember-what-this-class-does"?
I'd argue the readability in Tailwind is better. Tailwind is highly indicative of what it does and doesn't waste time when it comes to consistency.
The only real argument is that it adds extra length to the class attribute, but then again, it doesn't cause issues like finding the same class in 50 different CSS files or not having any auto-completion.
> You mean the readability of "p-2 bg-red-500 text-lg font-medium" or "i-dont-remember-what-this-class-does"
No, I'm pretty sure he means the readability of "absolute bottom-0 text-sm md:text-base text-white leading-relaxed tracking-tighter transition-all duration-300 ease-in-out m-3 md:m-4 px-6 md:px-8 py-4 md:py-6 opacity-0 w-full", as opposed to a single well-named class such as "image-caption".
Yeah, it's bgcolor="#30312c" all over again. (One thing I like about Tailwind though is that at least it enforces some kind of grid and design tokens, but you can (and should!) easily reproduce it with CSS variables.)
Well at least I won't have to have 2 split windows just to know what 'image-caption' is and the tailwind class you wrote, perfectly readable and understandable.
If long class names aren't your thing, then sure, use CSS, but I'd rather save time and have understandable code than maintain those CSS classes like "image-caption".
> since you yourself don't want to maintain your code in the future apparently.
Well, I don't appreciate the snarky comment, quite honestly. But okay, I'll assume you have had more experience than me, and you've managed things I haven't, have a good day.
> Well at least I won't have to have 2 split windows just to know what 'image-caption' is
> I'd rather save time and have understandable code than maintain those CSS classes like "image-caption".
Sorry, but the snarkiness was in your comment first, and when you said you didn't want to maintain those classes, that's exactly what it sounded like to me, that, well, you didn't want to maintain said code. If you had a different point I'd be happy to hear it.
No, one is a restricted subset of the other, and that means you can better reason about a less expressive language. This is basically what you would have with a non-Turing complete language vs Turing complete one.
Subsets and DSLs can often be worse than the language they're supposed to replace, and moreover, you need to learn a new proprietary language on top of that. There is no need for me to write Tailwind classes when I can just write their equivalent properties in CSS instead.
To quote you from another thread in this discussion:
> I've often found that people who are in the frontend don't properly learn CSS and just hack it together. That was me too for a long while which is why I hated it. Then I started learning it from first principles and it makes a lot of sense. Now I can build whatever I need in plain CSS classes.
So sometimes people just... misunderstand or use the tool wrong?
I have, yes. It’s fine and no more annoying than css, styled or whatever else. If anything it’s easier because there’s consistent and constrained bunch of classes you can use.
Then just use CSS at that point, since the classes literally just map onto CSS properties anyway (and sometimes not even, since they have to spend time to make new, or even older, rules work). That's what I don't get about Tailwind, at its best it's as good as CSS, but oftentimes stuff like SCSS, CSS-in-TS etc are simply better.
> Then just use CSS at that point, since the classes literally just map onto CSS properties anyway
CSS is definitely a write-only language. I've yet to see anyone understand CSS in a large system and refactor it. You end up with dozens and hundreds one-off classes and overrides everywhere.
So, the same as Tailwind then? That's also why I'd consider Tailwind a write only language, except with CSS you at least have the chance of organizing it properly.
With Tailwind you have a consistent set of classes scoped usually per component. Thos p-x, m-x, and others don't change from component to component or from project to project.
Hell if I know what `.chip-text__content` is, how it's different from `.icon-button__content`, why it interferes with my CSS, and what other 15 CSS classes I need on top of that to make it work.
I think there is a disconnect between what I'm talking about regarding CSS and what everyone else is. Yes, BEM and global styling is unmaintainable, I agree with you there. However these days even with Tailwind their approach is to componentize. In the same way, I can just use CSS modules with no global styles and get the same benefits of scoped styling like Tailwind provides without having something else break as a result of what I use in the current component. However, if you're using HTML without a JS framework, Tailwind can be superior to BEM and global styles, but still not as much as CSS modules, CSS-in-TS, and the like, due to maintainability concerns.
> However, if you're using HTML without a JS framework, Tailwind can be superior to BEM and global styles, but still not as much as CSS modules, CSS-in-TS, and the like, due to maintainability concerns.
How are you going to maintain consistent values across components such as spacing colors etc? Those tend to grow to the size of Tailwind
Every design system I've come across contains any combination of:
- rigid inflexible components that need complex overrides even for the simplest cases
- multiple classes with seemingly innocuous names like "col col-8" that get increasingly obtuse and one-off like "uxg-menu-header uxg-avatar-hero-block uxg-avatar" [1] or "fas fa-fw fa-bell pf-c-alert pf-m-info pf-c-alert__title" [2]
- multiple often contradicting css variables (esp. colors)
- ... i'm missing something else, but it's late here and my brain doesn't work ...
I've often found that people who are in the frontend don't properly learn CSS and just hack it together. That was me too for a long while which is why I hated it. Then I started learning it from first principles and it makes a lot of sense. Now I can build whatever I need in plain CSS classes.
I've often found that people that want to criticize Tailwind immediately dismiss anyone that likes it as lacking understanding of CSS.
I've been writing CSS since 1997 and tried every fad technique that's come along. Tailwind is the first one that didn't make me dread dealing with CSS.
I'm sure they can in Tailwind, but it hasn't been my experience, and that's what I meant by my rhetorical question, anecdotal evidence doesn't really matter.
Saying people use Tailwind because they don't know CSS well enough is simply untrue. I feel like you don't even want to understand why people actually like Tailwind. It's not like you arguing against it will make us stop using something we love.
Lots of examples of it online of people using Tailwind because they don't know CSS well enough, it's not even debatable when they themselves literally claim that's why they use it.
I understand perfectly well why people like Tailwind. The problem is not initial productivity; indeed, I can write bash scripts too very quickly that make me feel infinitely productive. It's what comes afterwards, the maintenance, the teasing of code written, that Tailwind makes so difficult.
Tailwind classes map very directly onto CSS properties and those properties and their values for all tailwind classes are very prominently displayed in the Tailwind documentation. There are going to be some classes that do a bit more for you than set a property, but they're not the majority.
I have a really hard time seeing someone use Tailwind as a shortcut because they don't know CSS. That comment does not say what you think it is. They are not saying they use it because they don't know CSS.
The maintenance is what makes Tailwind awesome. I've written CSS professionally since Internet Explorer 6 and have gone through many different strategies for writing maintainable CSS (BEM, OOCSS, SCSS and multiple different CSS-in-JS methods) but Tailwind is the first time I actually feel relieved of all the issues. To me, it's such an enormous improvement from normal CSS that people arguing against it feels like someone trying to convince me not to use syntax highlighting.
Funny, to me arguing for Tailwind is like arguing for copy pasting code around instead of using functions and classes, which the Tailwind devs literally tell you to do by the way. I mean, when I saw their official recommendation for maintenance of code and reusing styles was to use multiple cursors, I had to laugh out loud.
If you're not using scoped styles, yes. However, in an apps these days most people use something like CSS modules or CSS in JS which automatically scope styles. Creating classes is to me more of a composable model that still preserves the ability to refactor easily as well as being able to be readable.
The point is that I will never go back to not using syntax highlight, and I'm sure you understand that it would be futile trying to convince me otherwise. I wouldn't take anyone doing that seriously, and similarly I can't take you seriously.
Yes, being able to copypaste self-contained HTML with all styling included and no depedencies is amazing.
That's nice for you. Similarly, I cannot take anything recommending copy pasting code seriously either, and I'm sure you understand that it would be futile trying to convince me otherwise. I wouldn't take anyone doing that seriously, and similarly I can't take you seriously.
The difference here is that we're not trying to force you to use Tailwind. You asked "What is it about everyone using Tailwind?" and we responded, but you refuse to accept our answers and keep arguing that we're uninformed and wrong for using something we love.
Your copy pasting analogy makes no sense because "syntax highlighting" was referring to you trying to convince me to stop using something I can't live without and had nothing to do with Tailwind. Anyway, nothing wrong with copy pasting code and avoid premature abstractions until they are needed. Being religious about DRY and trying to shoehorn subsequent iterations of similar code into an inflexible abstraction leads to unmaintainable monstrosities.
I don't think you understood the analogy in what I was saying. The finality of your statements regarding you being unable to take me seriously is the exact same thing I could say to you, which is why I phrased it the way I did. You like Tailwind, fine, use it. I don't, but don't try to convince me to use it, just like there's no way I could convince you to not use syntax highlighting.
No it's more like functional programming with small, single-purpose elements. Semantic CSS is more like object oriented programming with big bloated classes with poorly designed and leaky abstractions.
CSS makes sense, but it will still f*ck up a completely different page than the one you are working on because that property you changed somehow got tangled with that shitty Angular stylesheet and it was only spotted in prod.
It doesn't become a mess, but it's interesting you chose to comment on Tailwind and not KonstaUI despite topic being KonstaUI. Do you have any opinion to share on KonstaUI or any other helpful insight, except giving yourself credit for what you use and being negative towards the rest?
> on Tailwind and not KonstaUI despite topic being KonstaUI
Eh, when the heading prominently mentions TailwindCSS, I’d say the topic is very much about that choice. If it were a minor implementation detail, it would be different.
So what you're saying is that it's important to talk about the _tool_ used to build the look and feel of project being under discussion, not the project itself? And you managed to get all of that from the title. Interesting.
Unless your team has incredible discipline, CSS across a large system very often becomes a tangled mess where you can’t change one thing without unintentionally affecting another.
When you change the Tailwind classes on an element, you know there’s no risk of subtly breaking something somewhere else.
Don’t conflate “visually busy” with “unmaintainable”.
If you're using global CSS or BEM etc, you're right, Tailwind sounds like a dream. I work in React apps however where CSS modules or CSS-in-TS already solves the scoping problem for us. So now we're left with just the "visually busy" part that's unmaintainable and not better than CSS classes.
I used Tailwind on landing pages and marketing materials too, it was a pain to change things around even then. And as you say, it's especially worse with web apps, but apparently everyone wants to make UI toolkits with Tailwind as their base.
Using it wrong on every codebase that wasn't even made by me but instead by my employers? If it's happening that many times, the tool is to blame.
More likely that the people who use it and like it (for now) have never have to handle large amounts of components and refactoring them. It's basically impossible.
Trends come and go, who's to say that in a few years we decide, like jQuery, that hey, maybe this utility first approach isn't all that great? Yet at that point we'd have lots of legacy code to refactor, again just like jQuery.
> Using it wrong on every codebase that wasn't even made by me but instead by my employers? If it's happening that many times, the tool is to blame.
There is no number here, you are basing this on your own experience and without any statistical analysis. Also no one really knows whether you or people you work with are genuinely trained and able to use the tools and/or program in a scalable, maintainable way.
Therefore, what you wrote is just a biased opinion based on a tiny, negligible amount of user(s).
Not taking into account opinions of other devs here, who claim the tool really helped them, turns this into a multiplayer monologue. You're adamant the tool is to blame and you found what works for you. Why continue to comment on Tailwind and not on the tool that's posted for discussion? Can you articulate what kind of win you expect here?
I assure you these aren't really small companies with no one knowledgeable about frontend coding standards. Insinuating that they're "using the tool wrong and therefore it doesn't work for them" doesn't do it any favors. If I see the same patterns everywhere and which even online people ran into the same troubles, I will blame the tool, absolutely. Tools are not dogmatic, they are meant for us to use. If we use them wrong, it is the tool that must change, not us.
The tool posted for discussion prominently displays its usage of Tailwind, so why wouldn't I comment on it? Must I only comment on the tool itself without anything in its periphery? We see a lot of people on HN comment on a Rust based tool too, it's not uncommon. You are free to comment on it or something else as you please too.
You can assure me with the might of 1000 exploding suns, but it STILL means nothing.
I'm not insinuating that those unknown entities that only you know of are using the tool wrong. I'm literally claiming that they are because being "not really small company" says absolutely nothing about the way their engineers do their job.
> If I see the same patterns everywhere
"everywhere" is, again, something that exists in your head only and no one else knows what "everywhere" is. Where is everywhere? Who exactly are the people who are running into these unknown troubles? Are they knowledgeable engineers? Do they understand underlying problem that the tool solves? I'd say that you are consuming resources which gather people who run into problems due to their lack of knowledge, such as stackoverflow.com so yes, the pattern you'll see is problems.
> I will blame the tool, absolutely
Because the tool needs to bridge the gap between what people understand and what they want to achieve, there's literally no responsibility on the human in this story. Great thinking, let's see how that plays out :)
> If we use them wrong, it is the tool that must change, not us.
If you want to achieve the goal, the easiest thing to change is you and not the world around you. But by all means, you do you, the only currency you'll effectively pay with is your invaluable and irreplaceable time.
> Must I only comment on the tool itself without anything in its periphery?
I didn't tell you what you *must*, I asked why you didn't. You still have the option to do so, but that would require that you actually invest time into checking out Konsta UI - which you didn't, right? Is my assumption correct? You just didn't do it but you commented on what you disliked. I think that's all there is to it.
I asked for numbers, which you don't have. Had you read what's written, you'd see it. That would convince anyone, and does not require me to trust a random stranger with ego issues.
Self-proclaimed professional like you should not skim text. You miss the point that way.
> You can assure me with the might of 1000 exploding suns, but it STILL means nothing
> I'd say that you are consuming resources which gather people who run into problems due to their lack of knowledge, such as stackoverflow.com so yes, the pattern you'll see is problems.
Whatever numbers I give you will be unconvincing to you, is what I meant. So why should I try to convince you, when you yourself also pull No True Scotsman if I tell you I worked with good engineers who knew what they were doing? You will just say I am "consuming the wrong resources." Anything I say will not convince you.
Therefore there is nothing I could say to convince you further.
I am parodying the parent's broad over generalization of tools. Yes, by their logic, they would concede that all software is bad. That doesn't mean some tools aren't better or worse than others. Just because hammers have flaws doesn't mean I'd use a hammer to screw in a nail, even if some do.
That’s not what you said though, better or worse is just moving the goal posts, and it’s of course contextual and relative. And no, by my logic most software is bad, not all, and I would actually say that’s true.
> Using it wrong on every codebase that wasn't even made by me but instead by my employers? If it's happening that many times, the tool is to blame
Wait, are we talking about CSS? Because I have yet to see a big enough application where the CSS wasn’t some “whack-a-mole” game when you had to change something supposedly locally.
On other projects I use React with CSS Modules or CSS-in-TS so this whack-a-mole never happens to me since every class is local. If that's not your setup then sure Tailwind works fine (but it's probably still more maintainable to use CSS Modules at the very least) but if it is then it's much less ergonomic to use Tailwind.
If chainsaws are popping off arms, then maybe we should have safety features, you know, like many blade driven devices already do these days. Again an example of a tool that evolves to meet users' needs instead of resorting to "you're using it wrong," this is a basic principle of product design.
The idea of approaches changing and becoming obsolete and having to be changed is a natural part of software. Shouldn’t stop innovation. TW works well for many experienced people who are very happy with it.
If it's real innovation, like jQuery imperatoveness to React et Al's declarativeness, sure I'd agree with you. But Tailwind is simply not innovation, it's at best repackaging normal CSS properties that when composed together act just like...regular CSS classes. So there's literally no point in using them.
The only people I know who dislike tailwind are those who either have never used it to make a project because of bias (hello past me) or those who dislike having faster development speed.
Tailwind objectively saves time, yes, objectively.
I am being forced to use it if my employer does, don't I? I find it more interesting that people get upset whenever others mention the downsides of Tailwind.
I guess if the other engineers around you have coalesced around using Tailwind you may need to reasses how you go about presenting your position as you clearly aren't having the impact you feel you should be.
Not all decisions are so easily reversed. We have started rewriting parts out of Tailwind but it was chosen initially because it seemed good. That doesn't mean the engineers today continue to want to use it, and indeed many don't, hence the rewrite.
What a weird definition of force, but okay. It doesn't seem like you're interested in any negative criticism of Tailwind but yes we will have a post mortem.
“High-level languages at best repackage normal machine code instructions that when composed together act just like.. regular machine code. So there's literally no point in using them“
Not having CSS inheritance anywhere already make it much much better. Sure, it is not novel, but it does fix many warts of “normal CSS”.
I see the Tailwind fans come out on any criticism of their library. I posted my comment a few minutes ago and already got a few combative comments almost immediately afterwards.
Yeah because you’ve jumped in on the attack on a post about something built with a tool that clearly gives a lot of people joy, in order to hawk your own thing. Getting whiny about people defending their own thing in response is kind of disingenuous.
People got tired of vue people continuously doing the same thing about anything vaguely related to react, too.
No, what I'm actually getting tired of is people getting on the hip new proprietary but trendy JS/CSS thing like Tailwind and leaving other devs to clean it up in a few years.
And your Typescript CSS in JS thing using some new thing? TW is at least well documented and widely used and based on a fairly formalised bunch of classes that builds upon a concept that’s been used for 10+ years.
Then just use CSS at that point, it's been here 20+ years then. I simply don't understand how it can be superior to regular CSS in any way simply because it maps one to one onto CSS properties anyway.
I do bare CSS for quick POCs but never on real projects. Vanilla JS & CSS sounds romantic when you solo but in a team setting it's better to use something we're all familiar with.
At work we switched over from SCSS modules+global styles to Tailwind last year and it has been great so far:
1. No more custom CSS. No need to think how to name your classes. No more unused CSS.
2. Code completion (VSCode plugin for TW classes)
3. Well documented. Even our BE developers are able to jump in and do minor changes.
The long CSS class name strings look funny but nobody complained about it in our team. Choose whatever works for your team. Tailwind has been nothing but a pleasure for us.
I did, I even read Adam's initial post here on Hacker News itself. Just because they say it's better doesn't make it actually better. Indeed, to me, it is strictly worse.
> Just because they say it's better doesn't make it actually better.
They didn't say it's better. They said go ahead and use it first, before pulling out opinions. I perfectly understand your position, I've been there too but it's a complete 180 experience after you build just 1 project with it. It's a "won't go back" experience.
I think you missed my previous comments saying how I've used it extensively the past few years for employers. It's like a bell curve, you like it and think, wow, this is amazing. Then as the years pass and you start having to maintain it, you steadily dislike it until you get to not wanting to use it anymore at all. The people who currently like Tailwind might simply not have gotten to this later stage yet.
> Then as the years pass and you start having to maintain it, you steadily dislike it
> The people who currently like Tailwind might simply not have gotten to this later stage yet.
And yet somehow the projects you were assigned did? I don't mean any disrespect, but I find it a bit questionable that any big project that uses Tailwind has had maintainability issues when Tailwind itself is pretty new to the scene.
It'd be hard for you to prove this to be honest, while on the other hand, I could give you hundreds of thousands of testimonials countering your argument.
Hundreds of thousands of testimonials from companies using it in production and had been for the past few years and as not a new project? Sure, send me a list. I expect to see all of the hundreds of thousands of them on the list. My email is in my profile.
It's anecdotal experiences at this point. As I said, I was using Tailwind from the beginning and loved it at first. Then the problems started.
I should have meant proprietary as in non-standard, not non-open-source. By proprietary I meant that they wrote their own DSL and in the future if it needs to be ported over, it will be much harder. It's like CoffeeScript versus Javascript/TypeScript.
Sure, you could see it that way. That's generally why I also don't use libraries that haven't shown themselves to be durable; I'll use React because it's ten years old and has enough support so that if people do decide to migrate later on (due to technological improvements à la jQuery to pure JS and TS), it's easy to do so, and it's why I don't use much newer libraries like Svelte or SolidJS.
There's two distinct camps talking past each other:
- Devs who make relatively small e-commerce-type websites, who loves tailwind, bootstrap, etc. Good defaults, fast throughput, maintenance is less important
- Devs who make relatively big web apps, who hates them. Everything ends up customized one way or another, maintenance is most of the work, tailwind and bootstrap end up only getting in the way.
The problem here is that this distinction is seldom make explicit, and here we are.
Problem is tailwind is not hard to maintain. I would argue it's easier. Folks look at it and it looks like a nightmare (the documentation even says so) but you have to actually give it a fair shake. I can always jump back into a tailwind codebase and not only do I know what mr-4 does I know where it is when looking at the rendered component.
You find yourself having to do "Right click > inspect" a whole lot less often to figure out what's going on
Tailwind is not easier to maintain than vanilla CSS in any way. There are no standards in Tailwind, tomorrow if they wanted they could rename everything. CSS actually has standards to adhere itself to. On top of this, Tailwind has to go through a process to adopt bleeding edge CSS changes, which makes maintenance a chore when you really wanted that new feature.
Tailwind is not easier than a custom internal design system either, as that has been tailored to your company and the maintenance of that system is integral to your design team. You might think that offloading to Tailwind is better, but you're just doubling up duties because someone internally is going to have to customize away from the defaults.
Tailwind can be easier to maintain than similar libraries. After trying most of these, I can't say whether that actually shows itself during development. I suppose if one was exclusively used to Vue or was brought up in the world of overzealous BEM, Tailwind might seem easier/refreshing. But if you've worked with Bootstrap or its alternatives (of the time), Tailwind isn't much different and can feel like a step back when you now have to rely on additional libraries like Konsta, Daisy, or Tailwind UI to create premade components for you.
Your example confuses me too, because why wouldn't your devtools be open anyways? You're in development so use the tools you have to make your job less of a guessing game. I guess what you say might be true, you can load a page and just tell a component has a margin right but you're going to be opening the devtools anyways to double check.
I still think Tailwind is great for solo devs, it's a design system with sane defaults they can rely on and get something in production very fast. Every other reason I've seen Tailwind devs give winds up confusing me about how they're actually working, or if they've ever bothered with anything else.
If you compare a given snapshot of code containing utility css vs well defined CSS, then yes, it looks worst.
The reality is that if the codebase and style code is in flux, that idealized CSS stylesheet will churn towards a being a mess of tech debt. Utility CSS contain redundancies (on the HTML side of things), but the rule of dumb is that you shouldn't refactor redundancies until you are absolutely sure what the unit of abstraction / isolation should be. In the case of prototype and fleshing out your designs, having a concise CSS stylesheet won't work, especially if you work with other people who are tunnel visioned on one specific scenario (a sort of tragedy of the commons) and not thinking hollistically as you would as an solo developer. We can think of that idealized, perfectly concise, stylesheet an "unstable saddle point" whereas utility CSS is not already at the saddle point but it does converge towards a stable one.
> The reality is that if the codebase and style code is in flux, that idealized CSS stylesheet will churn towards a being a mess of tech debt.
Interesting. That’s not been my experience. People tend to clean up as they go, eg if the design says we now need a thinner padding / gaps or a different colour blue, we change the variable, and if we spot cut and pastes we fix them.
It’s certainly much easier to refactor than visual classes mixed into HTML.
Tailwind doesn’t force people to do anything more than using regular CSS does. Or any technology - it’s really difficult to change human behaviour with technology.
What you describe is not representative of how CSS is maintained in most companies. You always end up in a situation where it's impossible to track down what styles affect what elements so you start overriding and duplicating because you're afraid to touch existing CSS.
Come on, do you honestly gonna tell people that just because a Turing-machine somehow managed to untangle that mess, it is humanly parsable? Most sites are not HN with like 3 lines of CSS, dev tools will list you like 10s of different rulesets that together determine the output — of course one can see what’s the end result, but now try changing some property that gets applied by multiple rules. That can get very difficult/impossible since you may not have control over every stylesheet.
Nothing is impossible but it becomes hard because the element is styled through multiple cascades, and you need to track it down both ways. When changing a class or a style you need to know what elements that change affects, which will be hard to track down because of the same reasons.
I don't write CSS (normally) and yet I understand every single statement, and can easily find which statement I'd need to change for a given. It's that simple.
You could argue "well you should learn CSS!" but at the end of the day, I don't need CSS often enough to want to bother. Frameworks like TailwindCSS have been great for people like me.
I can't even imagine what raw CSS lovecraftian horror captures all of the corner cases the classes you linked are hiding away from me (and to be clear, I'd rather not know or care)
For someone who knows CSS I don't see it as a big downgrade in readability?
But for someone like me, the right side of that equation isn't something I could go around writing in my HTML, the left form is.
Even if all it's doing is acting as a short form for CSS that allows me to do a "no-no" and embed CSS in my markup, it enables me to be infinitely more productive in CSS than I've ever been.
-
And the reality is, if one day I work on a product that's so cursed with success that breaking that encapsulation starts to bite me:
a) It's rare there won't be a lot about the design that has to change anyways
b) I can hire/pay people who do this stuff for a living.
And in the meantime I'll still get a ton of value from it
Tailwind may not be targeted towards you. For me, it was a solution to many of my CSS problems. However, I'm not an expert in CSS, and I can recognize that for someone who already has extensive experience with CSS, it might just appear as a complex abstraction.
Also, you can find a lot of Tailwind templates/components and they just work. You don't have to worry about a snippet clashing with or overwriting some other CSS you have like you would with plain HTML/CSS snippets.
Sure, HTML looks uglier when I add a dozen classes to an element instead of adding one class with a dozen of CSS rules, but I'm more than willing to accept that as a compromise.
Overall, Tailwind made frontend design more accessible to me than it ever was, and I never have to use `!important` again.
I find that some people are upset by the "democratization" aspect of this honestly.
It usually comes out as commentary along the lines of "well what's so hard about learning when to use !important?", "that tells me your CSS is poorly organized"... or sometimes just a drive-by downvote
In my experience that comes from a misguided idea that people who jump at it are somehow uncurious, or irresponsible, for "wanting the sausage without learning how it's made" and not caring anything at all about the craft.
-
I don't know if it occurs to them that there are some of us who have our hands in so many pies that, regardless of will or want, there is simply no more time for more pies:
The last time I picked up CSS, it was to write a static page to serve as a control interface for firmware I wrote for an MCU, for accessing an API engine I had just written for said MCU, embedded in a circuit design I had created and hand assembled, which was in turn embedded in a stepper actuated 3d printed assembly I had designed and printed. And all that was in a weekend: the last thing on earth I had time for at the end of it was figuring out what the idiomatic CSS way to style some buttons was...
The fact is, I get it: I am able to appreciate craft, and I understand how so casually throwing best practices to the wind "because it's easy" could come across as offensive. But at the end of the day, sometimes it really doesn't matter how the sausage gets made as long as it gets made.
100% agree, in fact my comment got a couple of those drive-by downvotes. The closest equivalence I can think of in my line of work as a sysadmin is me being upset that non-sysadmins can run things with `docker-compose up -d`.
I'm not. I have no interest in learning more, same way as frontend developers have no interest in learning to build custom Dockerfiles or Kubernetes deployments. It's not that it's difficult to pick up, we just can't be bothered to. People that do frontend just want their things to run, and I just want to be able to make a website that doesn't look like shit without spending a ridiculous amount of time on it.
Anything that bridges these gaps is a win in my book. Tailwind is better than Bootstrap (granted, it's been years since I've last tried it), better than drag-and-drop website builders, worse than pure CSS if you know what you're doing. It won't make your job obsolete, it just makes things easier for the rest of us. Same goes for docker-compose.
This is a component you reuse across tons of sites, it's not a one off component you're building for yourself. It's also not just a CSS framework like Bootstrap. This is full CSS + JS component's with functionality, Vue/React/Svelte framework integration, and events built in.
Whether css-in-JS as a whole makes sense beyond these generic component type systems is a good question. There's plenty of complexity introduced.
But for a generic component being used in plenty of use cases - not just UI usecases - but highly interactive JS driven ones as well, then it makes a lot more sense to have styling tied to programming languages and conditionals and options and JS data structures.
Css in JS (as in, inline styles) is just going to be a lot worse than class names because JS is fundamentally performance bottlenecked way harder than CSS is.
I'm not sure I understand what you mean by CSS in JS, since you say inline styles next. Are you talking about JSX having a style component? Or Tailwind within the className in JSX? Or CSS in JS libraries like styled-components?
Can you explain what you mean by this? Do you mean just generating hundreds of strings (with long atmoic class names) to style each component vs loading a global CSS?
IDK about React but Vue also has things like scoping, where the elements get unique IDs appended as data tags so you don't have to worry about CSS global scope clashes. Plus with Webpack/Vite the CSS automatically gets extracted and via HTTP2 only loads the tiny JS and CSS files needed only for the components used on the page.
In that case giant blobs of CSS and JS would be less efficient.
It used to be, that CSS-in-JS meant people naively writing something using a computed string to use the HTML style attribute, like so
var style="color:blue;text-align:center;"
return <h1 style={style} />
and some CSS in JS frameworks compile down to pretty much that. However, this is a bad practice, because you will consistently see worse performance than just using css files and classnames instead.
Sure true, in the old jquery plugin sort of way, I forgot that. Although that's not really what people call JS component's these days with Web Components/react/Vue sort of styles mixed with JS within the self-packaged components rather than a CSS framework with a couple optional jquery plugins.
Unless they modernized it in recent years, haven't used it in 5yrs.
As much as I like Tailwind, I too does not understand the Tailwind-in-js thing for basic components likes buttons or checkboxes.
Why not just create a button component in whatever framework you are using with scoped styles. This just seems like unnecessary coupling to me.
Sure, the way I phrased it. I just think it's a bit weird to chose this "direction" for a button. No matter if you are creating something new och using something already made, like this.
Depends on work. If you need lots of bespoke styles then you quickly realize Tailwind only is wrong approach.
For sure there is huge trap in webapp developers who mostly copy paste HTML partials from Tailwind UI who succumb to Tailwind marketing and completely forget CSS.
Developers mostly don't like CSS so not many care. That's why there are so many solutions how to avoid it.
But utility classes (and tailwind as most popular utility classes generator) are super useful even if you are not just copy paste UI guy.
You want to see that. You immediately see how an element is styled without any hidden CSS that has applied styles through cascading. You immediately know what to change and where when you need to update it, without it indirectly affecting other elements. It's self-contained and you can copy paste it everywhere without any dependencies.
These kind of libraries are always easy to spot in the wild because of their transitions on things like modals and action sheets don’t match native. They’re just not as smooth.
And that's fine; it's a compromise sacrificing native look & feel and performance for cross-platform development and being able to assign web developers to mobile projects.
I mean personally I think any developer worth their salt should be able to learn native development, and any company that wants to make a good app should hire and invest in native developers / development. But that's a hard sell these days.
Anyone notice all the gambling sponsors? Looks like they're fed from OpenCollective (see BACKERS.md in the github repo). Feels like they're trying to get backlinks as their URLs end up as anchor tags on the site
Such a weird ecosystem the sponsorships have created. I see a lot of other sites with irrelevant sponsors and non-trivial amounts of money, there just for the SEO/ranking
Seems like a win-win situation to me: open source projects get the funding they need, and the sponsors get their SEO traffic. Gift horses mouth and all.
It's the same with having advertisers on your website I guess, you don't actually know what is shown on your webpage, just that you earn money to turn a blind eye.
I originally thought it was something like DaisyUI but for React Native with NativeWind, but this seems quite different, and almost a little strange haha.
I'm very impressed by the polish of the project but am curious about the main use case for a library like this.
(I guess, in what situation would one want a webpage to feel like a system native app? Potentially this paves the way for PWAs?)
> in what situation would one want a webpage to feel like a system native app?
When one has an app that can function as an SPA, wants to distribute outside of app stores but still give a native visual presentation. Currently working on such a side app myself right now. And that I can use this and continue implementing in Vue is a big plus for me.
Konsta UI looks exciting but their Framework7 App Framework looks even more so.
> I'm very impressed by the polish of the project but am curious about the main use case for a library like this.
I'd be very interested in something like Tamagui (https://tamagui.dev/) but for Tailwind. I tried Tamagui but it's a bit too complicated when it comes to styling and layouts.
On the tailwind argument I don't really feel like ever going back in spending a good 2 minutes coming up with a non conflicting yet descriptive class name only to end not using it at all cause I decided to implement the requirement in a different way. Not to mention the relief from the constant css/html context switch you undergo indefinitely.
I can't really comment on how it scales in big projects tho.
I always find the criticism of localised styles and so-called separation-of-concerns violations amusing, given that the vast majority of user interface APIs to have ever existed have you set the styles directly on the elements.
I think there’s maybe a few desktop UI APIs that use a similar approach to CSS, but having a separate declarative style sheet is almost unique to the web in the grand scheme of things.
I guess it’s mostly people with a document-first mindset to stuff on the web, but I don’t think CSS is a good way to style application UIs.
Desktop UI APIs had/has the benefit of some OOP inheritance and a good set of standard components, plus separating layouts from styling. The web has only recently caught up with 2nd, and solved the 3rd in its own way - but it really is funny how insane amount of work is needed to have a custom date picker on the web vs on even something like WinForms.
This. And for big projects it comes with the advantage of locking everyone into the tailwind.config. Everything has tradeoffs.
But to me, removing the context switch is like an ADHD cheat code. I’ve grown to enjoy the ability to look at one block and know exactly what it looks like as well. There’s no key value search to know why some bit of text is red for example.
- 1 for the CSS parts: basically a DSL to define a giant tree of Tailwind CSS class properties, with some conditionals to take care of the context (iOS vs. Material) and other optional features.
- 3 for the React/Vue/Svelte components. They seem to provide the same features, each implemented independently.
There is definitively a separation of concern between style and behavior, so the style part could be reused in other frameworks.
But there is also a "DRY" violation with the 3 independently developed framework-dependent parts. Could this be improved by having a framework-independent part (you suggest Web Components, what would be the easier way to get this part done?) and framework-dependent adapter, or would this extra layer of indirection make things harder to understand?
Really curious about this. Can you link to some context?
We're looking to find the lowest common denominator of expressing UI components and thinking about JSON metadata instead of Web Components. With this, we'd have to implement some adaptor that maps JSON to each UI library, but in our case we really only have to worry about React and Native Mobile.
> Most people who use React don’t use Web Components, but you may want to, especially if you are using third-party UI components that are written using Web Components.
So it seems like this would be exactly the kind of use case where using web components would be ok.
My startup team is working on a new project and elected Tailwind this week. Konsta looks like a great fit as we want to work well on mobile.
Wondering if there are plans to add a grid with drag+drop? We're looking to emulate the iOS homescreen where you have a grid of Icons that can be dragged/dropped using https://shopify.github.io/draggable. Having an integrated solution would help us avoid haphazard glue code.
After taking a quick look at their documentation page, I noticed that some of the buttons, especially the default secondary and a few of the outline buttons, seem to have a low contrast ratio when viewed in default light mode: https://daisyui.com/components/button/ Hopefully, developers won't use these components as is.
Although I'm not very familiar with Tailwind and its component library ecosystem, I found the DIY approach taken by https://github.com/shadcn/ui to be better suited to my needs. This approach offers greater customization and flexibility in designing UI components, which is where I find the most enjoyment in building UI. Of course, pre-built component libraries like OP can provide a quicker solution if resources are limited.
I’m using Ionic heavily and judge it through this lens.
- The components for iOS look nice, but some things are off: Sheet modal is weird. Animation of modals or side panels feel too slow.
- There are no animations when navigating forward or backwards.
- The demo has scrolling issues on iOS Safari and doesn’t always show the header.
- Unfaithful communication: it claims to give you native look and feel, which can never be true for HTML/CSS-based UIs that merely replicate native components.
- I see no point in using this instead of Ionic, because Ionic has the same or more components with less bugs, because it has been around a lot longer.
Yes I'm impressed by their extensive documentation and the Ionic integration seems well thought out but it's not clear to me why I would use that instead of the integrated Ionic components that looks almost identical to this library.
While these projects may add additional complexity and potentially detract from the simplicity of functional CSS, they can still be a valuable option in comparison to traditional CSS architectural paradigms like BEM: http://minid.net/2019/08/12/in-defense-of-functional-css/
On mobile, the scrolling seems to be all over the place. Based on what you select, the title and top part of the next screen is often slightly obscured.
One small regret: I wish the library was structured like https://ui.shadcn.com/ , which I love because it allows to copy paste the source code of each component and customize it further in your app, rather than importing a rigid pre made component into your app
Ehm, this remind me that there is https://framework7.io/ too and i spot a similarity on the web sites ;-)
IMO Framework7 has way more components available and it can be used in many use cases.
Tailwind does not have their own UI library as reusable self-contained components. Instead Tailwind UI gives you the source code of these components so you can customize them to your needs. I much prefer that approach to that of pre-baked rigid components
No, the components come with specific JS behaviours, and the documentation has the Tailwind classes you need to add separately (which means it's still modifiable if necessary).
I just use Vanilla Extract (with their Sprinkles API) and call it a day, it uses TypeScript as the preprocessor language and then compiles it to raw CSS, similar to SCSS but without writing SCSS.
https://vanilla-extract.style