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.
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