Tailwind CSS provides low-level utility classes, wich usually inlcude only one CSS rule.
daisyUI classes are a combination of multiple CSS rule that are named semantically for each part of the UI.
So, to put it simple, Tailwind re-implements css property-value pairs as classnames, whereas daisyui re-implements css classnames.
It seems like the whole dance is to avoid
class="btn" style="font-color: #3e3"
So what is different from above is that a style override is now possible via class like
class="btn font-color-3e3"
(or whatever tailwind provides as builtin class). Are these layers of indirection worth it, and still needed with modern css?
I remember we came to css frameworks and BEM because it was difficult to scope css.
I suspect this reflects the cultural problem that in many organizations no one really wants to create or stick to a systematic design.
Scoping CSS isn't trivial as a site grows large, but it's far from intractable.
Tailwind's orientation on concrete details everywhere is the "just give up" solution -- stop trying to get the organization and culture to do work they don't want to do.
EDIT: I'd also guess there's an element of poor feedback loops for most development tools. When people people talk about things like "I don't want to have to look up what every class means", they're speaking to one reality of code componentization across the multiple dimensions of styling/semantics/markup/logic in development environments that often can't support interactive, legible, and interconnective feedback as development is done. There are probably solutions to this but they're more involved and less well known or fungible than just collapsing styling/semantics/markup into a single dimension around a consistent constrained UI domain language you can add to your resume in a week tops. This is friendlier to the predominant "culture" for building front ends right now.
> Tailwind's orientation on concrete details everywhere is the "just give up" solution
Yes, and that is why I am genuinely curious whether going the nuclear approach is still needed, or that css variables, @scope and what-not of today solves the problems of the past.
Because it seems that Tailwind introduces problems that CSS sought to resolve, and now DaisyUI seeks to resolve the problems of Tailwind.
Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved?
> Because it seems that Tailwind introduces problems that CSS sought to resolve
> Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved?
You should read all of https://tailwindcss.com/docs/styling-with-utility-classes. Experienced developers use Tailwind because it solves real problems with CSS that are hard to understand until you've worked on complex sites, with complex designs, and/or with large teams. People will often tar Tailwind users as people that don't understand CSS well when this isn't the case.
Plain CSS is fine for simple designs and document based sites, but e.g. cascading styles, specificity, and the way styles are spread between files becomes a nightmare to grow and maintain later. CSS wasn't invented with the kinds of complex responsive UIs and designs we need to write now, so it's not a surprise the traditional way doesn't scale well.
Ever worked on Java/OOP code with huge complex fragile inheritance trees spread across files where you can't figure out which piece of code is overriding something, or how to make your change without breaking something else? It's not unlike that, yet people will blindly defend the traditional CSS approach because the flaws aren't widely accepted yet.
Problems/friction here is still: now I'm forced to give verbose names to all my divs, CSS is verbose, responsive CSS is very verbose, you can't easily compose the styles from different classes (like adding a shadow or text styling from elsewhere, where each was multiple lines of CSS), styling is split between the HTML and CSS files which slows down editing and debugging, it's hard to keep styling/spacing/sizing consistent unless you (verbosely) use variables everywhere.
All of these add up to make writing and maintaining CSS a draining and frustrating experience, especially if you want to quickly iterate on a design where you're not quite sure yet how it should look.
I'm not a user of DaisyUI but Tailwind still has a lot of pros over standard CSS and BEM.
> to put yet another block on the Jenga tower.
In a similar thought, why not write the styles directly on the HTML? Heavily restyling a site always requires modifying the HTML along with the CSS and adding divs that are only there for styling, so let's admit they're not separate and remove a layer of indirection and remove the extra verbosity BEM brings? BEM is mostly admitting that cascading and specificity are CSS features to avoid, so why stop there?
It seems to me really learning CSS has been something most devs who started doing anything else have long wanted to avoid. I suspect it just scratches different itches and feels more like configuration than programming. And of course once an abstraction layer becomes key in established development culture, the opportunities for reward are probably broader with the abstraction than with the layers underneath it. Not sure styling has coalesced around Tailwind or DaisyUI enough to lock that in, though.
I'd guess css vars, @scope, etc do solve some problems. I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there. Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering (which I'd guess largely boil down to a combination of the incentives towards conversion-oriented tinkering and bikeshedding pride among recognized product stakeholders).
> I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there
You said native, but could a CSS preprocessor in the meantime fill that gap? If @layer and @scope would fix the problems pre-BEM, I think we are done then.
> Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering
Yes, if it is people just don't want to reuse, but want to have a quick hack for something like
<button class="class_6447823468">
then it is more a tool for an organization/skill problem I guess.
I just don't see how you can reach and enforce a consistent, maintainable styling across a medium to large website with something like Tailwind. Do people trade quality, consistency and freedom for a limited set of design tokens that might be applied inconsistently?
I have to admit I have not done much in css since a long time, and given the enthusiasm for Tailwind I wonder if my understanding is lacking.
Just want to say thanks for this -- I hadn't seen it before, and it touches effectively on a number of practical criticisms I have of Tailwind plus some I hadn't articulated yet.
And I'm really glad it brings the context of web craftsmanship into this, I think it's related. As I've argued elsewhere in-discussion, a fair portion of Tailwind's appeal probably comes from the way it fits with the "grain" of business web dev culture, which itself is driven by product management culture oriented around conversion metrics (often wielding iffy A/B testing) and rewards for bikeshedding. The benefits of craftsmanship or systematic design are less legible and so design direction and front-end tasks tend to be one-off screen-by-screen and pretty churn-y. Semantics are an afterthought and invisible to most stakeholders, attempts to systematize are often seen as irrelevant if not obstacles to business goals.
Tailwind just gives up. Give the business and its agents what they want, get through your task list, and find somewhere else to care about the subtleties of quality.
I didn't address it as much in the article as I probably should have, but in the time since I've written it, one of the other things that I've really come to terms with is the fact that a very large number of developers don't view frontend as "real" programming.
These developers come from all sorts, backend, mobile, whatever, but all share a uniform disdain for frontend web. It's something to get done and get out of the way so you can get back to "real" programming.
And so anything that slows down the "getting things done" step is seen as an obtuse undue burden. Learning JS gets a small pass (a lot of criticism too, some justified, some tired, and some unjust) since its at least got the dressings of a "real" programming language, and HTML is simple enough that you can learn most of what you need in an afternoon. But CSS doesn't get that pass. Its not really a programming language, and its not drop dead simple. Its actually rather complex, and used to be even harder.
And so, time and time again, we see these tools that aim to be a panacea for this issue. ExtJS, Bootstrap, BEM, Tailwind, there's a long lineage of these things. And they all try and shield the poor developer from having to actually learn to use the tools at hand.
I'm not going to use the tired analogy of a carpenter not knowing how to use a hammer so he uses a rock instead, because that does some disservice to tools like Tailwind, which are impressive engineering feats in their own right. Rather, its a guy normally used to working with sheet metals being tasked to frame a house. He uses his peen hammer to drive nails, and it works well enough, as long as he's just putting nails into wood. But the moment he needs to remove some sticks to open up a new doorway where there were previously studs, suddenly he finds that he has no claw on the end to pull the nails out, and has to resort to using a screwdriver and a pair of pliers.
Thats what tailwind is. The peen hammer. You can write a frontend just fine with it. But the moment you have to change anything already written down, you run face first into its limitations. So you find yourself working your way through templates or whatever the analog in your project is, pulling out bg-blue-300 and replacing it with bg-purple-300, maybe using some find-and-replace to help with the process, but knowing you cant rely on it entirely because there are some blue-300 things you want to stay blue and others you don't.
In my experience, after now something like 5 years of using Tailwind in projects large and small, it scales reasonably well. You just do what the authors suggest: encapsulate styling in components instead of CSS classes.
Now, that isn't quite the panacea it can sound like. The standard components like buttons and dropdowns are solved quickly and then you have the unusual components that always show up here and there, which are more likely to stand out. But, that was my experience with BEM/Bootstrap/whatever before that as well.
For me, it's always been much less of a technical thing, and much more that the material coming out of the product design part of the business is never actually consistent enough that you can have a single consistent CSS file drive the whole site.
Yeah -- that's a big part of what I mean with "stop trying to get the organization and culture to do work they don't want to do" or "just give up."
I do think there are tooling shortcomings that could change required investments and therefore organizational outlooks, and that the Tailwind approach comes with some technical debts that could an alternative like that worth it. But it'd take a team with a good amount of free time, experience, and unusual levels of insight to produce such a thing. Probably some clout to get it off the ground.
In the meanwhile, Tailwind represents a plausibly acceptable local maxima that coincides with a lot of other things about larger web dev practices and culture.
And to be clear, mine is a descriptive assessment, not a normative one. Tailwind is functionally adaptive to the dysfunctions as well as the functions of the predominate business web dev culture, not an expression of worthy ideals.
It's a bias to think the problem is people not knowing how to architect a good CSS solution. The reality is projects are maintained by multiple people over the course of its life. OOCSS only brings technical debt and constraints, and not to mention bloated CSS files. A good explanation why OCSS is bad https://www.fcss.club/manifesto and why functional CSS or atomic css is better in the short and long-term https://www.fcss.club/why. Tailwind just brings more complexity.
It's not font-color 3e3, it's font-red-300. That's an important distinction, because the second one respects the design system your art team spent a lot of time establishing. By using their language you normalize the set of styles utilized in an application, instead of individually and repeatedly hard coding the hex values.
Second off, tailwinds true power becomes way more obvious if you consider pseudo selectors like lg: and hover:.
It seems like the whole dance is to avoid
So what is different from above is that a style override is now possible via class like (or whatever tailwind provides as builtin class). Are these layers of indirection worth it, and still needed with modern css? I remember we came to css frameworks and BEM because it was difficult to scope css.