I am building a version 2 of my FCSS framework. https://github.com/meerita/FCSS2 check it out, fork it, use it, you're welcome.
I don't recommend Tailwind CSS
101–110 of 179 posts
Re: I don't recommend Tailwind CSS
#102We need to talk about two use-cases separately:
CSS for design systems is fine. You can define a .button[data-variant=”primary”]. It’s intuitive, performant, makes sense.
CSS for application code is terrible — specifically layout & typography. The different kinds of flex/grid layouts are tightly coupled to the dom structure. Tailwind is a great fit here:
Title
Subtitle
I havent seen this discussed a lot. The old Radix team had a short note: https://www.radix-ui.com/blog/themes-3#the-best-of-both-worl...
Re: I don't recommend Tailwind CSS
#103CSS Modules are a better solution. They compile classnames into unique identifiers, so there's no need for BEM or SMACSS conventions: https://x.com/efortis/status/1888304658080256099
I disagree. I don't want to jump between two files constantly. With Tailwind I can stick to one file and never need to think about naming things.
Right so it is easier to write code quickly, but not to maintain a system. Tailwind is the right tool if you want to generate a prototype with LLM agents. It can be quickly deleted or can be used as visual prototype to create reusable components. And once the component is built for long term maintenance as priority, the collective knowledge has been built up so naming becomes simpler, important and elucidating.
Re: I don't recommend Tailwind CSS
#104Earlier quoted context omitted.
I disagree. I don't want to jump between two files constantly. With Tailwind I can stick to one file and never need to think about naming things.
Right so it is easier to write code quickly, but not to maintain a system. Tailwind is the right tool if you want to generate a prototype with LLM agents. It can be quickly deleted or can be used as visual prototype to create reusable components. And once the component is built for long term maintenance as priority, the collective knowledge has been built up so naming becomes simpler, important and elucidating.
The component itself is the semantics, adding naming over CSS classes adds no value whatsoever, only adds cognitive load and requirement of context switching to understand "what does this named class actually do?"
Re: I don't recommend Tailwind CSS
#105In my opinion, the main problem with Tailwind is that it attempts to replace all CSS. Tailwind classes are often non-semantic and don't align well with CSS property names. Where pure CSS can be used, the code will be cleaner and more readable. It's important to remember that HTML has a "style" attribute, and it's often much easier to define a style block directly in the "style" attribute than to use a fragment and Tailwind's cumbersome CSS classes.
Re: I don't recommend Tailwind CSS
#106This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…
> If you end up programmatically layering class names, you're looking at a code smell. Why wouldn't you? Suppose you have Button class with `btn btn-primary`. The Button accepts className override so you can do . In this case you use tailwind-merge or clsx. Your Button implementation would be clsx('btn btn-primary', className), in which case right most class name prevails. Other than that, I agree tailwind is great.…
There is this implicit debate in web application development of cascading+overriding vs non-cascading-no-overriding. A lot of people don't even realize this is where the line is drawn and mix both together. I call them "component-based", "document-based" and "mixed".
Component-based applications are usually better of with no styling cascading and no styling overriding. It makes things significantly easier because components are self contained and don't change in appearance based on styling of parent-elements on the tree (besides physical dimensions available and transparency effects of course).
Document-based applications are usually better of with cascading and overriding. Although no-cascading-no-overriding can work too, but requires more code.
Component-based is quite difficult to do without some tooling (like tailwind or css-modules, etc). Most CSS tooling support both though.
Tailwind implicitly forces you into the component-based paradigm but never explains it properly. There is a reason why people who love tailwind say it just makes things much more manageable. It is mostly because it removes the "mixed" mode that projects silently fall into[1] unless there is some guiding force towards component-based.
However component-based approach is quite doable with many different CSS solutions. Tailwind just _forces_ you into it.
For example CSS-modules component-based just means one .css file per component with only .className {} CSS selectors and not relying on cascading values from above in the tree (a few global rules can solve this).
[1]: Mixed mode as I call it is mixing hyper-local rules with cascading rules. They fall into this mode because that is how plain CSS works without extra tooling and guidelines.
Re: I don't recommend Tailwind CSS
#107Pre-llm era Tailwind was great for the backend people who did not want to learn CSS. Nowadays agents got this. Openprops might be a good option even with agents, at least for me it works well. Not a surprise that Tailwind popularity dropped significantly.
I think the another llm-victim is React. For a while it was great to have a heavy framework that somewhat standardised webdev's JS approach. Astro just become the default goto lightweight option that is great to quickly build a nice simple UI.
Re: I don't recommend Tailwind CSS
#108Earlier quoted context omitted.
Projects with a single gigantic CSS file also work and you can onboard people etc. That's not an argument.
they do work… for any value of work . I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another prepro…
Tailwind trades cascade complexity for design drift when working across teams. You can’t ignore that it encourages a different kind of undisciplined sloppiness.
Would I take it over the 1000 line cascade problems? Probably, but I’d still prefer css modules over tailwind.
Re: I don't recommend Tailwind CSS
#109My personal experience (for what it's worth): I've used Tailwind across various project of different sizes for about one year then simply stopped using it. I just don't see any real advantage to use it over regular CSS.
Re: I don't recommend Tailwind CSS
#110I registered my first domain 1997 and before that already coded websites: members.aol.com/…/
I saw the inception of CSS, the infamous ACID test, IE6, web standards movement - anything and everything.
To this day, CSS is something that is not separating design from markup (try logic, you will get it), and as all things technology is now a mix of technical constraints, backwards compatibility, totally conflicting decisions.
I am traumatized with floats and clearfix, and there was a lot of debate around CSS 3, JavaScript.
Layout wise, “the web” aka web traditionalists or whatever went bezerk against any attempts to allow for what today is dominating: print layout as role model.
Formerly flow was all about responsive web design, being as fluid as it gets.
CanIUse had to be brought to life to solve the questions, what features needed to be done in JavaScripts, which not.
Stylus, BEM, bootstrap, SCSS etc.
All kind of conventions and preprocessing helpers.
CSS is hard and will stay hard, in fact I am stunned by the author’s total ignorance of where CSS came from, why something is the way it is.
Maybe he is just a young gun and thinks that CSS is only flow, grid and CSS3 and always waiting for cool new features which do what? What purpose do they have, which problem do they solve?
Tailwind is genius. There is pro and con for everything but looking back it is just another evolutionary step on the shoulder of the mentioned giants.
To this day no framework or system was more simple and elegant than Tailwind.
The author’s naive conclusion is a variation of the running gag that started with https://youmightnotneedjquery.com/
Tailwind is shadowing native CSS functionality? I felt pain reading this because so what? That”s not the point.
We use preprocessors, postprocessors, optimizers - what I don’t want to do is using CSS’s own bad naming nomenclature which is used because of backwards compatibility.
In fact abstracting away basic functionality and simply let the compiler decide what is best given the situation is mentally helpful.
Working in large teams, or many teams. Guess what will happen: we build our own CSS framework, well we build ten because everyone knows best.
The author really should be thankful for the genius job Tailwind does, because he seems extremely inexperienced and never faced hard challenges.
In fact if your only problem is to decide between two frameworks, you are lazy and not considering other people.
Browser compatibility, breaking changes, different CSS as well as JavaScript engines - this was brutal.
Today? Luxury discussions.
The fact that Tailwind allowed for a gazillion of partly stunning CSS design systems and React components like ShadCN and others is proof enough that Tailwind is a platform with the best pro/con ratio so far.
This has never been the case before. This is a singularity.
I was founder and product lead for a huge and critical to business financial platform, seeing others easily augmenting your platform via interfaces or plugin patterns as a structured approach is genius.
Extensibility is a sign of elegance and perfect abstraction.
Are there downsides? Who cares with all these never seen before massive benefits?
The killer against laissez fair CSS is exactly this: have you ever lead an approach to develop a framework? Why do you want to build yet another TW?
Drop it. It won’t work. The question or better your solution hints at being a solo dev.
This is fine but you seem so one sided in your views, I am puzzled.
If I could use just native CSS boy oh boy - do you really know everything about it? Could you understand a floating layout? Could you see pro and contra for its use case or do you just not allow its usage? If yes, why if you cannot answer the question?
How do you make sure, there is standardization? How do you train and coach people so that they know and can use CSS?
What are your naming conventions? Why this way, no other way?
How do you deal with devs leaving, new joiners?
Who is overseeing the repository? Who has merge rights? Who does the code reviews?
What do you do if there was an emergency and some big shot or very important order had to be accommodated and now you have garbage CSS in your platform that you must maintain and everyone can use?
Boy oh boy - I love Tailwind. The versatile solution that was 30 years in the making.
All you delusional freaks out there with the hubris belief: tell me how it went.
I just covered a few questions. Deployment is yet to debate etc.