Coming to Terms with Tailwind
johanronsse.be
johanronsse.be
I don't understand comments like this. You still have access to tailwindcss.com for documentation.
The company doesn't owe you space in their social media conversations. The company has real customers and potential customers who they want to engage with. Engaging with people who tweet "Tailwind is a terrible way to write CSS" [0] and "Refactor tailwind out of your codebase" [1] isn't a good use of the company's time. Blocking those people will also downrank their comments in @tailwindcss threads, which seems useful from the company's perspective. They're running a business, not a grievance forum.
Maybe, one could argue, the company should engage strenuously with critics like this to try to convert them. But for me, no, they should focus on supporting the people who want to be their customers.
Now, since we bought Tailwind UI to do our work, we are technically also a customer.
Probably the company monitors the tailwind and tailwindcss keywords, saw those tweets, and decided that their signal-to-noise ratio for doing customer engagement would be better if they blocked you.
It's not a statement about your twitter account in general, or you as a person. It's just that their corporate objective wasn't served by your tweets. Now that your company is paying them, perhaps you can ask to be unblocked. Or perhaps not, as the support channels for Tailwind UI (the paid product) are GitHub, email and their private Discord.
I just genuinely wonder if blocking people that don't agree with you is a good strategy.
I guess over time things also changed, Tailwind 2y ago was not the same as Tailwind now. They hired a bigger team and became much more of a company.
Nobody owes you their attention.
My 3 blog posts were a genuine attempt at trying to dissect what I didn't like about the framework. Many people wrote in to thank me for that perspective.
I find it unfair to single out two historical tweets neither of which is directed at the authors.
If you are going to trash my product, I'm absolutely going to block you. If I have a say in what the company that sells that product does, I will absolutely have that company block you.
No one is owed anyone in this scenario, but it's just crappy behaviour from Tailwind. They probably are just tired from the negativity, I mean just look at their site the framework does look terrible, they even admit to this with this quote on their site front and center:
"If you can suppress the urge to retch long enough to give it a chance, I really think you'll wonder how you ever worked with CSS any other way."
Even though the code is offensive to the senses, it apparently works really well. Judging from the adoption and the beautifully designed UI's they are showcasing people do recognise its usefulness.
Where is the problem that justifies blocking?
You can block anyone on social media for any reason or no reason at all and you don’t have to justify it to anyone.
But social convention was my point - the social convention is it's always fine to block and you never need to explain, in my opinion.
Seeing a bunch of incessant vitriol in the mentions all the time about something I've worked really hard on for many years is very distracting and upsetting to put it mildly, and on days when my emotional reserves are already low from the stresses of figuring out how the hell to make money working on the project or having a young family it's really not a healthy thing to have to deal with.
Criticism being delivered in good faith is welcome and productive, but constant holier-than-thou "wow whoever created this is extremely stupid compared to me and clearly has no idea what they are doing" is not that.
I've only ever blocked two people for this sort of abusive crap since 2017, in case that provides some perspective.
Tailwind CSS is a "company" now in the sense that Steve and I built a commercial product to make the OSS stuff sustainable, and it turned out to be successful enough that we could hire handful of other people to help out, but I certainly don't think of us as some sort of faceless corporate entity. We don't plan to grow the team and I don't plan to become a full-time manager — I just want to keep working on interesting OSS projects and we decided to use the revenue from our commercial stuff to make that possible by hiring people to help with customer support, working full-time on existing OSS things from the ecosystem (we hired the person who built the OSS Tailwind IntelliSense extension for example), and to keep up with the barrage of GitHub issues we see as a popular project.
Tailwind CSS itself is very much a personal project of mine and a labor of love, and for better or for worse it's not as easy to detach yourself from projects you pour that much into as people (who have no perspective on the emotional challenges of being the face of a popular and polarizing project) make it sound.
The end result is pretty ridiculous: because this author wrote posts critics of a very popular piece of software, the author must log out of Twitter temporarily in order to see any relevant posts or announcements from the official Twitter account of that piece of software.
I think Twitter is engineered to make people angry at each other.
That bit rubbed me the wrong way.
A small company has zero people whose full time job is to handle social media, so it makes sense for them to clean their feed up anyway they like it. I also see zero effect on their business.
Not sure why the author made a big thing out of this block too. It is not a big deal for neither involved
Anyway, I think the tooling around Tailwind (at least in React/next) has gotten much better since the author wrote his initial criticisms AND tailwind is even more ubiquitous now-- which for better or worse makes it more acceptable even if some of the CSS mappings change over time. We put up with that sort of problem with JS as a matter of course so maybe my attitude is too blasé on that point though.
Nah, you was just jumping on the bandwagon of hating on Tailwind without even trying to understand the fact you are meant to use components with it.
Given that this bandwagon regularly attacks Tailwind (or anything modern in fact) and the fact that you tweeted completely antagonistic and unneeded "refactor tailwind out of your codebase" to someone who was showing an interesting way of doing animation in Vue, I can't blame them for blocking all the N number of accounts that are harassing them. Anyone is in their rights to block someone that is antagonistic or nasty or just generally hurtful on a constant basis to them.
Arguing against something knowingly in bad faith (e.g. stating incorrect facts about X to hate on X) is 100% antagonistic. Actions have consequences?
https://twitter.com/wolfr_2/status/1280949237820383232
And even now you continue with "Now, getting blocked by a person, that’s one thing. I guess Adam’s coping strategy with criticism was an “I don’t want to hear it.”. Yeah, again, I can see why he blocks accounts of people like this. Flippantly phrasing it as "Oh, I guess they don't like being criticised" shows a lack of appreciation for why someone might block someone. Because they just don't want to put up with someone's shit. Who can blame them?
> I don’t know if I was entirely productive at first because I first had to shake up my dev stack to add in support for PostCSS, PurgeCSS and figure out all kinds of Tailwind specific things.
Fortunately you don't need to purge anymore, as it instead creates the CSS file you need upfront instead of purging it after.
I can’t argue with that. But it suggests that if you work alone or in a small group, actually learning CSS might make more sense.
“I can forever claim that people should just learn CSS but if that happens to be a difficult thing, maybe we should try to make a deliverable that is more… malleable.”
I could have misinterpreted that, however; I found much of the writing confusing.
I think this is probably one of the most common sources of complaints. Some people who already know CSS in-depth will see Tailwind being endorsed by others, take a look themselves, and come to the conclusion "why on earth would I ever use this".
I totally understand that, because it's how I feel. But it's important to remember that people still want to style things without being CSS experts, and one of the things Tailwind is good at is letting that happen. It clearly fills a need and yelling at the proverbial clouds isn't going to help.
But for the life of me I could never come up with a consistent set of rules like margins, paddings, colors etc.
Tailwind is a mini design system on its own (even if it's "just a utility-first CSS framework"). I don't have to spend too much time thinking which margins to add or set the typography right. Set an `m-2` and a `text-sm`, and you're done :)
All/Most of that can definitely be replicated with, say, CSS vars, but then you're back to "okay, how do I consistently name these components".
Because it provides a copy-pastable subset of reliable classes where you end result will look good.
As a company we are often hired to fill a knowledge gap (exactly in design and front-end). The nature of agency work is to leave a deliverable for the client to work with.
My idea is that when the project is over and the design/front-end gap still exists in the team, perhaps it is better to leave something more manipulatable (I used the word malleable originally).
I think with the great docs that Tailwind has it might be easier for someone who is not a front-end dev to manipulate a `<div class="p-4">` to `<div class="p-3">` than to come across a BEM/ITCSS component, written in SCSS* where you have to understand much more concepts to manipulate it skillfully.
*(our preferred stack really)
What I needed today is for a rando on the internet to call me stupid, a dev who doesn't fully grasp CSS + design.
I use tailwindcss and so do other devs. Many of those devs are better than me and you.
Instead of assuming that everyone who disagrees with your choices is stupid, maybe reflect on popularity of tailwindcss and assume, in an Ockham's Razor kind of way, that it's a good technology. Even if it's not a technology that you personally want to use.
Just like I, a front-end dev + designer am thankful for something like Firebase, because my backend skills are fairly nonexistent.
We need to move past the rhetoric of “Tailwind is for people who don’t know CSS”, when it’s only true in a correlatory sense because the majority of tech is always going to be newcomers. People who are CSS experts are just as capable of concluding that these newer paradigms are worth investing their time in.
I believe that quick deliverable you mention, will become a big burden for that client in some future.
I saw already multiple projects where both Tailwind and regular CSS are used. This seems like unavoidable, since Tailwind looks like easy-peasy, but it actually can't be understood and without understanding CSS in the first place. Maintaining this kind of mix must be fun...
It's kind of sad that not-learning is hyped over mastering.
This cannot be overstated. The included Figma file alone is arguably worth Tailwind UI's asking price.
Figma is quickly replacing Sketch (which replaced Photoshop and Fireworks) as the preferred tool for web and app design, and they’re just raised a round at a valuation of $10B. So it’s a pretty major player now!
The video is here: https://nickjanetakis.com/blog/reviewing-tailkit-300-tailwin...
I've been using it in a few projects and it's really nice. There's no affiliate links or kick backs for promoting Tailkit either, I'm just a happy user.
>But that doesn’t mean that I can’t be a professional and write the best Tailwind code I can if that’s what’s asked of me.
This is something that I can’t understand. Maybe it’s just me, but we’re incredibly fortunate to be in a market with huge demand. It’s not like we live in a React only world.
You can make a pretty good living writing in whatever language, framework, ecosystem you choose. I’m terrible at self promotion and still I manage.
It’s great when what’s fashionable matches your personal taste. It happened to me a few times. But when it doesn’t, it’s pretty fine as well.
A big reason for me is that I want the bigger group in our company to experiment with several CSS techniques to grow as front-end developers. If I (as a manager) set a constraint on one type of CSS it is difficult to learn more.
As an agency it makes sense to have broad capabilities. I think as a freelancer it's super fine to just constrain yourself to what you like, as you state there is huge demand out there.
It's just that the post comes across as resignation, as if these techs are a fact of life.
Same holds for ordinary jobs. Depending on the kinds of jobs you want, it can be a reasonable choice to settle on tech you don't really like, just because the hiring market's hot for that tech, so it's much easier to get hired and/or to command a higher salary.
That's the thing. If you enjoy the tech, you can make a great living write the code you love. If the start-up name-droping life style is more important to you, than sure, go for it, just don't complain that the market demands XYZ.
It's non-trivial to pick up a front-end/full-stack engineering position at this point without having committed to React-specific development. Even knowing a runner-up (Angular, Vue, Svelte, maybe Ember) can put you on the bottom side of probabilities, and not having bought into any big-name framework will likely change your chances by an order of magnitude.
And fashion mismatches are often enough about more than aesthetics -- they're often about the kinds of problems you're well-equipped to regularly solve.
Some fashions build up enough momentum that anyone who doesn't want to solve the problems it introduces (or use its proposed solutions to existing problems) is justified in being worried that the fashion will choose them.
I’m speaking from experience. I write PHP, jQuery and plain CSS. There’s plenty of market. Never felt React (or Angular, Ember, Backbone) where worth the trouble. Same for SASS, Typescript, WebPack. So I don’t use it. And it’s fine.
There’s of course job opportunities for a specific tech. Just don’t get those if you dislike them. There are plenty others.
Our industry is indeed much more fashion driven than it should for a field that aspires to be a hard science. But it is also so freaking huge that even niches can support a lot of people.
What I haven't seen Tailwind do well on my projects is respond to change in the same way other methods would. I'm not saying it isn't possible, just that the several projects I've seen, it was a big pain.
A method I've been quite fond of to accomplish the same task, but remove the difficulties this author's other posts articulate, is to recreate the concept of a component in a single folder. Much like you would a Vue single-file component. If you read the "Components" heading here you'll get a good feel for it by looking at the folder/file structure:
* https://github.com/flyntwp/flynt#components
That same idea I've enabled in a framework/language-agnostic way with an NPM module I created (not public). It watches the folder, namespaces css/js like a single-file Vue component would (using a manifest name or defaults to the folder name). It's a freeing feeling to create a folder and just start coding sass and js without having to wire anything together. As it's auto-namespaced, sass files are very clean too, you can use generic naming like ".heading" without a problem.
This solution is nice because:
1. devs get the "one source of editing" in a single folder. Even image assets or your language's logic files.
2. Immense benefit with static analysis tools. Want to assert all your components have a readme.md? or generate docs from all component readmes? Sure.
3. it's performant, with vendor/tree-shaking and inheritance built in. Also parallel build execution of all components.
4. it's agnostic to language/frameworks. Include any linters or unit tests you want.
5. is a paradigm shift from themes to components, just like Tailwind
6. No more wiring together components! specify a global like Vue or your favorite sass package, and all components can inherit it
7. Simple setup.. all you do is point to a folder of components, specify a dist folder, and you're done unless you want to modify specific behaviors
I'm curious if there are Tailwinders out there who could teach me if Tailwind solves other problems I'm not seeing. Or if this type of solution would be something I should open source. It ends up being a pretty simple Webpack file under the hood, and it has been an absolute dream to work with over the past year.
I'm building a RAD platform (I hate the term low code) and just pushed through Tailwind as the only method for styling apps and banned custom CSS.
The primary value Tailwind provides is a reasonably well considered design system. I believe CSS' primary weakness is the general inability to define cross-cutting abstractions. I think of the style of an object as a composition of concerns: spacing, position, size, typography, color, decoration, etc. Programming languages have interfaces or traits or protocols to handle this sort of thing but there's no equivalent in CSS. The addition of CSS variables provides limited ability to do this like you can set up a primary color and use that everywhere but CSS variables alone don't let you set up type or spacing scales. I realized this in 2009 and switched over to defining these abstractions as sass mixins that basically boil down @apply with Tailwind utilities where my mixins were the first part of the utility name and the argument(s) the last part. Having a design system simplifies the job of both the designers and developers. There's no guessing on whether it's a 5px or 6px margin, it's a `margin(2)`. Further, if you pick cooperating scales, the page tends to fall into a vertical rhythm, which is tough to do ad-hoc.
Tailwind is an improvement over my self-designed sass mixins mostly because it has more effort behind it and enough people banging on it that it's been expanded to cover a majority of the CSS you need to implement apps. I add a set of CSS-variable based color names to handle theming (`pri` for primary, `sec` for secondary, `ter` for teritary, and `acc` for accent, with `-dark` and `-light` variations) and allow custom utilities for the project. The latter provides an unsupported escape hatch but is enough friction that I'm hoping people won't abuse it excessively.
For my specific use case there are other benefits:
* No specificity issues
* Having to come up with a name for elements is a significant source of friction in a graphical interface
* Naming CSS classes well requires some concept of the overall system and how the element being targeted fits into it. I do not expect my users to have this knowledge.
* I only allow modification of specific points in a component that have a data- attribute containing component-unique names. This will allow me to change the underlying markup and have a fighting chance at successfully migrating custom styles.
* By breaking the link between styling intent and page structure I have the potential to translate apps into non-browser programming environments.
I find Tailwind markup to be quite ugly and think it doesn't have as much advantage in other situations but it fits my specific problem well.
I see this come up and it's so strange to me; the only thing I can think of is that what people are complaining about is too many ways to define cross-cutting abstractions (variables and mixins / other apply boosters and even css classes themselves) so the imposition of a framework-specific way to do it feels like it relieves a burden.
Similarly, I'd guess that you'd see a lot of overlap between people who'd chosen their own conventions for addressing this in combination with other design systems and people who don't like Tailwind much.
I meant exactly what I wrote. The primary axis for styling is applying a set of properties using a selector. The cross-axis abstraction for providing restrictions on what values the properties contain has not been part of the language for the vast majority of its existence.
> variables and mixins / other apply boosters and even css classes themselves
The only options here that are actually CSS are variables (which are relatively new to the language) and utility classes, which work against the general desire for semantic class names and separating structure from presentation. I'm familiar with the proposals for the others but I'm not aware of them being standardized and I know they aren't supported in any browsers.
There are plenty of reasons to not like Tailwind but I expect most people who do like Tailwind aren't coming off a project with an established design system and method for applying it. I have some complaints about Tailwind's choices but it's a fine set of defaults and has enough customization for me to disable or replace the utilities I don't like.
> The only options here that are actually CSS are variables (which are relatively new to the language) and utility classes
So before widespread adoption of SASS/LESS, I might have expected some places that took a systematic approach to design to use utility classes as kind of a mid-tier in a three-layer model that took care of balancing general, cross-cutting, and specific concerns:
- general (or very widely cross-cutting) concerns would go at high levels: *, html, body, sometimes qualified with semantic classes for varying pages (e.g. body.departmentname, html.sitesection). A lot of type/line related information would go here, probably some page level margin/padding/alignment and a few other instructions. Then there'd be some kind of generalizations for other tag-level elements (ul, p, table, h1-6, etc).
- modestly cross-cutting concerns would get their own utility class names, roughly grouped by categories you're talking about (spacing, position, size, typography, color, decoration, etc), so you'd see .box-I, .type-IV, .col-X, .scheme-C
- specific/exceptional "last mile" scoped concerns would get semantic class names (also usually used for attaching behavior via JS).
The rise of SASS/LESS seemed to change one major thing: a lot of the middle/modest layer of cross-cutting concerns could/would find their way into mixins and then get imported into semantic class names, keeping the concerns centralized while cutting down on utility class name clutter in the markup. Some shops would use variables instead. Either way, it streamlined the already existing manner of handling the middle layer of cross-cutting concerns.
Now, mixins/@apply aren't part of native CSS yet (and though variables are, they're are probably inferior from a DRY/structural perspective), but existing preprocessors have had such widespread adoption for most of the last decade that it's confusing to me for someone to approach Tailwind as if isolating cross-cutting concerns weren't a problem solved in other ways previously. Certainly Tailwind's @apply isn't native either and I'm not clear on why its utility classes would be inherently superior to other pre-existing utility practices.
Hence my assumption that most of Tailwind's fans are people who hadn't found themselves working with these concepts before they picked it up. And if Tailwind is people's introduction to working that way -- and it was that hard to come by beforehand -- maybe if nothing else it is in fact doing people that favor, albeit with the overhead of being married to a level of utility classes that I think is simultaneously too scattered and duplicative and its own specific tooling.
Or maybe there's something else I don't understand about it yet?
I haven't explained my biases. Perhaps a technicality but I don't consider the reset styles to really be a consideration. They're something set up at the start of a project and not really touched day to day. With the rise of component-based development, I strongly prefer my styling to not be context dependent and so I avoid relying on styles cascading from outside the component aside from the reset styles. Neither of these is required but I think this is relatively common. This leaves the utility/mixin layer in your taxonomy and thus my focus on it.
> existing preprocessors have had such widespread adoption for most of the last decade
I'd mentioned using Sass mixins as my workaround in my initial post. The compile-to-CSS languages have solved the problem but that doesn't mean it's not a weakness in CSS itself.
Despite having the tools to solve the problem, I'm quite confident very few people have. Virtually all Sass/Less use I've encountered outside the Sass online community has been nested selectors and variables.
> most of Tailwind's fans are people who hadn't found themselves working with these concepts before they picked it up.
Yes, this is the primary advantage for most. Most developers do not have a design system let alone come up with the idea to design something to enforce it. I had to derive mine from Bringhurst's Elements of Typographic style, adapt it to every designer I worked with (they're generally familiar with the overall concept, it just doesn't make it to the popular frontend body of knowledge) and then sell the approach to every team I worked with. I ran into utility CSS much later and then only in online articles until Tailwind.
Since you're familiar with the concepts, you won't encounter a lot of new material here but might find some of the details interesting (I mention some specifics below).
> Or maybe there's something else I don't understand about it yet?
Tailwind's scattered/duplicative nature is a good match for people with the biases matching my own. It's largely competing with inline styles, CSS-in-JS, or scoped CSS. The redundancy of setting styles without relying on the cascade is a feature for component-focused uses where they're desired to stand alone for use in multiple places. The comprehensive (i.e. scattered) nature of the utilities allows for a nothing-but-utilities approach. This avoids class name conflicts and specificity issues, which competing approaches were specifically created to address. Psychologically it also keeps people focused on finding utilities (and thus staying in the design system) instead of hacking in their own CSS.
There's less duplication than I thought at first. Recommended coding style uses component-local cascade for things like font or text color and parent shortcut utilities like space, divide, and gap cut down on the really painful duplication.
I do think Tailwind takes their utilities too far. I think the transition/animation, gradient, and transform utilities are ridiculous even if I do respect the effort. Going the other way, the layout options are underwhelming (grid is anemic) and there really isn't anything around handling images. I consider these relatively minor, nit-picking concerns and simply define custom utilities has solved all the issues I've had here.
In my mind, the more substantive argument against it is an only-utility approach completely tramples on the idea of separating markup from presentation. This leads to a lot of edits and workarounds when trying to use a single component in multiple design contexts, which is a general problem for the component-local approaches. Straightforward css-var things like color are easily handled by making custom utilities with css vars in them. There's also a straightforward general solution in the form of @apply in a named class.
Tailwind is gaining popularity because it's a pretty good fit for the space. My current project is my first professional one on Tailwind but I expect to be using it over my own system going forward simply because it largely does the same thing and is an easier sell.
What it does is force you, as other frameworks, to learn all its intricacies, design decisions, use an heavy and complex development environment (that besides that reads files it doesn't have anything to go about reading?) so that you don't need to learn the underlying language.
Then it nudges you to write a soup of classes (that you need to learn, and need to learn the config because it seems by default it has -400 but not -500, or whatever, and need to learn their priorities), that you need to keep changing and copying pasting (yes you can write classes that coalesce your styling... but that's kinda the point of CSS and/or any other pre-processor), and forget about semantically marking your html. (I'm not saying you have to write it badly, it's just that writing it poorly seems much easier - and is the same with CSS).
I just don't see the point - with the exception of the pre-processing part of course - CSS can use some little help in some places to generate programatically some things but I think those are better served by a pre-processor and not a framework as the framework tends to guide the overall design of the remaining things.
I like "atom"-like components better with semantic classes. In BEM/ITSS I'd make a component for -everything-. But in Tailwind we'd only make one for common "atoms" such as buttons, tags, inputs etc.
Code example: write ".t-button" and then use @apply to put the classes there. Keeping the design constrained to a set of tokens.
.t-button {
@apply border
inline-flex
items-center
px-3
leading-5
font-medium
rounded
focus_outline-none
focus_ring-2
focus_ring-offset-2
focus_ring-blue-500;
}But... I need to know all those classes to know why the final rules are put in place, I need to know that they don't have conflicting properties, or if they have, their priorities. And when you add your own custom apply's in there, then it can also break just the same. And when you customise your tailwind classes it ends the same problem. So when you're trying to figure out why rows in a table with the same number of headers and same number of td's have different sizes because some no-breaking space class was applied, and why your a.btn isn't getting the same styling as your button.btn and etc, I always feel like I've wasted more time than I should (perhaps because I know css and used it extensively)
I might have been a bit harsh on saying "dementia" as it's disrespectful for those who've put the work in writing it and releasing. It's better than all previous frameworks - I just personally think that it's problem searching for a solution as you can't really win.
The Tailwind dev environment is literally one Javascript file with a few settings. Not that complex. Tailwind is worthless if you don't know CSS, so I'm not sure that second point works either.
> Then it nudges you to write a soup of classes (that you need to learn...
Is that bad? Not using Tailwind forces you to have a separate stylesheet that hides tag to property relationships, among other hidden abstractions. The class names barely need to be learned. With an IDE, you get class name completion, and there are only a few properties that have unexpected names.
> yes you can write classes that coalesce your styling... but that's kinda the point of CSS and/or any other pre-processor
What do you mean "the point of CSS"? Read the spec. It says nothing about the number of properties a class should contain.
> and forget about semantically marking your html.
Tailwind's reset styles mean you can use whatever "semantic" HTML5 elements you want. If you mean classnames should be higher level abstractions than CSS properties, well, that's a convention that developed during the CSS Zen Garden days. Before that we used HTML attributes for styling. Conventions come and go.
> Is that bad? Not using Tailwind forces you to have a separate stylesheet that hides tag to property relationships, among other hidden abstractions. The class names barely need to be learned. With an IDE, you get class name completion, and there are only a few properties that have unexpected names.
Well, the purpose is actually to have separate stylesheets, so that you can name them in a relevant manner, I don't know, like menus.[s]css, panels.[s]css, just like so you know where things are, and so that you can use a class to define repeating elements across a codebase. There's no abstractions in CSS that aren't present or amplified in tailwind - there's pre-processing utilities that are useful in tailwind but they're present in any pre-processor without the remaining stuff. And in fact the logical way of using CSS is by defining classes and then defining modifications to those classes, when needed, when they're part of a hierarchy of classes that requires it. They're one grep away of being discovered in all css files.
> What do you mean "the point of CSS"? Read the spec. It says nothing about the number of properties a class should contain.
Uhh. Yeah, I might one day, but I don't get what you're saying.
> If you mean classnames should be higher level abstractions than CSS properties,
A classname is a selector token, that you can place in CSS hierarchies and define a set of rules, that affect the elements using that classname. It's obviously a higher abstraction than a style rule.
I wasn't talking about semantic html5, I'm talking about semantic markup for readers of the code. If I see "t-4 h-3 w-2 mongo-xyz bg-pearl-800 flex flex-col m-4" I can understand it after reading all of those properties in tailwind, perhaps and how they all interact. But I'll need to understand that it uses relative sizes (like, why...) that m-px is one 1px, m-4 is 1rem, but what I want is fixed sizes 99% of the time. That someone might have disabled some of the sizes generation. Then I don't know, if someone asks me to change the styling now I have to go through all the codebase, searching for elements that are styled like that, because I have not way of identifying it and I have to change all their classes to the new style. Obviously, it's much harder to have it placed in a single file. Inline classes are better somehow than inline styles (although you can't know exactly what it's affecting), and there's a place for inline styles, but 99% of the time it's bad.
Using the Tailwind-defined values for font sizing, spacing and colors in SCSS is trivial.
This, combined with ITCSS and BEM becomes a huge time saver, especially if your browser-base allows for the use of CSS Grid.
Naming components is the only overhead but with a clear naming and file structure is not really an issue.
So far, writing SCSS, and much less of it (because of ITCSS), is a benefit—compared to learning a proprietary framework aiming to replace CSS at a similar enough abstraction level.
Because in the end, tailwind is better than bootstrap, but it's still the wrong way and incentivises wrong patterns.
And by making it "standard" it makes everybody new to the field start with it and use it, foregoing learning the CSS. And will be supplanted at some point, and then there'll be the dance again. And again. It's just this that I don't understand.
At the point you're customising tailwind and classes you run into the same problems as with CSS without clear guidelines/organisation. So the only way to not run into that it's to use it as inline styles but with classes...
I’d used plain CSS for years following the Zen of CSS approach which I was very fond of and I was a big fan of SASS for simplifying it too. Dealing with browser quirks got old though.
The issue is that most CSS is approached from a perspective that you’re going to reuse a specific part over and over in your HTML as a single tag.
Tailwind realizes that this happens, but simply argues that in most code it happens in templated loops instead of all over your source code. So instead it focuses on reusable parts that cover all of the browser quirks and can be easily combined.
It’s such a boost to productivity and practicality that I can’t believe it hasn’t been around forever.
I think this is an important point, good standards evolve by adopting real world proven practices. If everyone only used 'the standard', then it would never improve.
You can do anything you want with it without a reliance on predefined widgets, modals or layouts key to a specific framework.
If you want that, there’s TailwindUI but it’s by no means necessary.
What makes me concerned with tailwind is that its yet another API to remember. Why would I pick it over material UI with some theming or chakraUI? Why Did you pick tailwind over material or chakra?
Sites can _feel like_ bootstrap or mui sites, but rarely have I seen something and immediately thought “this is a Tailwind site.”
Secondly, UI frameworks are more suitable for full-blown applications, whereas Tailwind can be used for anything—applications, Wordpress themes, static sites, etc.
Since Tailwind is literally just CSS classes, at the very least I know I won't ever run into this.
Super-uber-duper-friendly suggestion: Proofread your comments before posting them.
It's just convenient, that's it. Ideologically I don't like it; for getting work done, it's nice.
Theoretically you could achieve much of it in a "more correct" way, but we don't have the resource to do that in our company and ultimately it wouldn't be much of a value-add. Tailwind saves time.
Like any system that doesn't plan/support for its own maintenance, this means that most systemic/semantic approaches break down. The larger the team/projects, the greater the entropy inputs.
Solution: don't do it. Drop your styles (or some mediated subset) directly into a component. This also "solves" the overhead of separating style from content and other ways in which CSS suffers from "everything happens somewhere else"-itis.
Personally, I think tailwind is the wrong solution to these problems and we'll see posts about how this turned out to be a local maximum at best in about 2-4 years (or, hey, recently by the author of this post), but people climb to local maxima for a reason.
People that do real work with C++ will give you an honest assessment of its strengths and weaknesses. There are good reasons it's still so widely used and it's still the right tool for some jobs. Using it for something it's not well suited for is a mistake, of course.
Of course it's also a tool with a lot of legacy cruft accumulated over decades so it's not a great analogy for Tailwind.
This is of course unrelated to tailwind and the words I used there were pretty uncharitable - it's open source after all - but I have yet to see a good example of it clicking, the way I've seen it, in my assumedly small real use sample pool, doesn't seem good at all.
css (and javascript/webasm) are the lowest levels in web development, of course people are going to build on top of them.
Building a design system on top of css is not a surprising outcome. It's not different to building a library on top of a language.
The only problem I have with tailwind is that it reminds me of the days of 'save this Word document as HTML' and the horror that was MS markup in HTML.
Having said that, I use it, I like it, and it allows me to just do things and move on. If I don't know something, the design is discoverable with a bit of thought, unlike the underlying css.
It's not unreasonable to expect someone to take a similar approach to tailwind and write a similar thing that targets something even more specific such as animations.