> Then there comes the point where I have to use Tailwind for work and I am blocked by an offical account and – that feels kind of stupid? Getting blocked by a company entity for having an opinion is kind of… strange?
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.
Honestly, the only stupid thing is that Twitter won’t show you public posts from an account who has blocked you. Of course you can log out and see everything. That’s just silly. Twitter may as well say “this account has blocked you, so complete this tedious minigame to see their content.”
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.
Simply logout or use a private browsing window if you want to see the public posts of someone who's blocked you. It's really, really not a big deal at all.
That's why it's a stupid decision from Twitter. Twitter could say "type your username backwards to see this tweet" and you could say "just type your username backwards, it's really not a big deal." It would still be a stupid decision from Twitter.
I agree. I see nothing “strange” of a very small company blocking criticism on Twitter (even if it is a fair criticism). A bank have thousands of employees, tens of which (maybe even hired agencies) have a full time job handling social media.
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
Well, you mentioned being blocked, so I searched your name + tailwind.
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.
It's simpler than this honestly — the Tailwind CSS Twitter account is managed entirely by me (I made Tailwind), and I'm the only one who tweets from it and checks the notifications to see if there are people doing interesting work I can help elevate or having problems I can help with.
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.
There’s a difference between disagreeing and being an ass. If you wanted to engage with them then try to have a conversation. All you did was say how terrible it was and not to use it. Big difference.
I agree, but none of those tweets were directed at the authors. They were just talking about Tailwind in general. One was a poor joke.
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.
Twitter blocking is not about owing attention, a Twitter block prevents the blockee from seeing your tweets. The company is basically punishing Wolf for their critical tweet.
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.
I don't know how Twitter works exactly but if I was using it for promotion I'd probably block the negative nancies from piggy backing on my posts if I could too.
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.
> after I wrote a bit of criticism that got popular.
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?
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.
One sentence in the article suggested that, ideally, people making websites would just learn CSS, but since that‘s an unrealistic expectation (why?), Tailwind can be useful if you have big team of “front-end engineers” who don’t quite understand the markup languages that they use in their jobs.
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'll try and clarify what I mean here. Tailwind seems to appeal to devs who feel they never fully grasped CSS + design.
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.
Counter-example: I’ve been building with CSS for about 20 years, and am very competent with it, but I’m a fan of the paradigm of atomic styles and eschewing the cascade. I don’t particularly love Tailwind, but a lot of the ideas and reasoning behind it are rock solid.
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.
So are we supposed to unlearn CSS because we want to make sure that unskilled people can take over the project?
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.
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.
That went bad quickly!
You are putting words in the mouth of the original comments for no reason.
"a dev who doesn't fully grasp CSS + design" does not mean a stupid dev; it can be a dev who decides that he doesn't need to fully grasp CSS + design to do a great job.
Why is that weird that the owner of an App design service agency prefers pure CSS over a library?
yes this is all rooted/connected to the truth that the huge influx of dev/engineer-centric approach to everything web design has basically ruined/messed up front-end for the 5+ years
Yes. I've most commonly seen it used for exactly that purpose – people who have no interest in knowing CSS but need to style something.
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.
Not just that: I know CSS reasonably well, and I understand what most of Tailwind classes do on their own.
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".
Apparently. This is how I interpreted this passage in the article:
“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.
Congratulate to the author. At this day, it takes quite a bit of self-awareness to be able to look at some previously (openly published) opinions, reconsider them, and admit that the opinion changed.
He never said that his opinion changed. He just said that he accepted that Tailwind is now part of the frontend dev landscape (for better or for worse, time will tell), and tried to name some good parts of it.
There’ll always be people hearing about a thing for the first time.
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!
As someone who's building an MVP, I just want to express how unbelievably grateful I am for Tailwindcss, Tailwindui, Heroicons, and HeadlessUi. Fantastic work.
Agreed. I bought TailwindUI not because I am interested in how the UI actually works or even writing custom components from the start, but rather because I wanted to get a professional look initially and focus on the business logic of the app. UI isn't the most important thing, after all.
If anyone is on the fence with pre-made UI components around Tailwind I just put out a video the other day reviewing Tailkit (it has 300+ Tailwind components, layouts and pages). The author was also kind enough to giveaway 2 copies which is covered in the video. That giveaway ends Saturday July 10th.
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.
Well I have to support legacy browsers so I won't be using tailwind, but that doesn't mean I won't "cheat" on css by using material design lite. I literally have a 14 day deadline with no designer on hand. I know I need a framework its just in my case the less sexy MDL is more useful because it has great support for legacy browsers.
Most people who think they need to support legacy browsers don't actually need to. Evergreen browsers upgrade themselves. Clients should also know that running an ancient browser poses a security risk, so you could use that as reasoning, too.
> Just like I don’t like React I will probably never really like Tailwind.
>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.
The context is that we're primarily a design company, the front-end is a way to express our designs.
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.
Some tech is easier to sell than others, depending on your market. If you're an agency chasing startupy clients, for instance, the more technical people on the other side of the table want to hear that you're going to use tech that they think will look good on their résumés and/or enable them to easily hire startup-type developers, so making sales means choosing some subset of that tech that will make them nod in agreement when you name-drop it, and also enables you to deliver working software efficiently—even if you think there are better tools for the job. For several years this has meant talking about how much your teams just looooove React (whether they actually do is irrelevant).
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.
I think you're underestimating the degree to which fashion imposes de facto requirements on day-to-day working conditions.
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.
> It's non-trivial to pick up a front-end/full-stack engineering position at this point without having committed to React-specific development
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.
I still don't get Tailwind either but I found https://github.com/seek-oss/vanilla-extract recently which solves the TS/CSS modules nicely. All the styles are extracted at compile time so no overhead like most CSS-in-JS.
vanilla-extract combined with Sprinkles is roughly comparable to the Tailwind software architecture, but without the default configuration out of the box. There’s definitely room for someone to come along with a default configuration that covers similar functionality to Tailwind’s.
The underlying problem I see that Tailwind solves is component-izing a single idea. And that it doesn't get in the way with opinions like Bootstrap, et al. It does that pretty well. You can point to a single stack of code and say "this one thing is a navbar" and it's easy to know where to make changes. No searching, no stress.
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:
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 curious if there are Tailwind users out there that could teach me if Tailwind solves other problems I'm not seeing.
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 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.
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.
> the only thing I can think of is that what people are complaining about is too many ways to define cross-cutting abstraction
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.
Possibly I'm not understanding what you're getting at, so maybe it's worth another round of exchange.
> 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?
When I talk about cross-cutting I'm very specifically referring to restricting the values of properties to the ones matching the design system at the CSS language level and not the can I arrange the page to be styled level.
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.
Here's a tip: if a lot of smart, informed people have a very positive view of a technology but it doesn't click for you, it may not be the right tool for you but it very likely is not a "sign of dementia".
Thank you, I can be wrong obviously, but your argument in light of our current times would actually indicate that a lot of smart informed people are more tending to idiotic brainless emanations than anything else.
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.
Good luck finding anybody with a "very positive" view of C++ other than maybe Bjarne.
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.
Slightly less typing (compared to CSS), pre-defined memorable names, good documentation and a library of examples.
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.
After years of wrestling with what the “right” UI framework was and marrying your project to the syntax and rules, Tailwind has entirely removed that concern from my life.
But honest question, wouldn't those years of wrestling with the right UI framework be better spent learning the underlying CSS rules and adopting a simple pre-processor that gives you programmatic generation for repetitive bits?
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.
Have you tried it? I don't know what you mean by "sign of dementia", but I find the approach taken by tailwind makes me a lot more successful in applying designs. Doesn't feel like dementia to me.
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.
> 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.
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.
We're trying to find the balance between semantic classes and utilities now with @apply. I've always found layout to be easier with utility classes (regardless of Tailwind, this counts for Bootstrap 4 too).
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.
So yeah, I agree with pre-processing utilities - but this is just the same problem as with CSS and I think the apply idea is actually pretty neat...
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.
It also eliminates the possibility of using a regular preprocessor.
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.
Most people don't actually do design systems, because most organizations aren't set up to make/reward systematic design approaches.
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.
This is the thing, not all projects are super giant web applications being maintained by hundreds of front-end developers. For a dummy like me who curses at the laptop every time he needs to center a div and whose style sense pretty limited, tools like tailwind are a bless. I do a small library of components, copy what people who knows more than me does (taking examples from here https://tailwindcomponents.com/) adapt them to my needs and that's it. I dont have neither the skills, nor the time or the inclination to spent time on other alternatives. I like the style (more than bootstrap) and I am willing to pay the price of a cluttered html.
I personally wouldn't trust a person who can center a div on the first try - something isn't right with them!
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?
Having worked with Tailwind, Bootstrap, and mUI, Tailwind is by far my favorite. With bootstrap and mUI you have to work very hard to go against the grain of the design they ship with, while Tailwind forces you to make your own designs, to an extent.
Sites can _feel like_ bootstrap or mui sites, but rarely have I seen something and immediately thought “this is a Tailwind site.”
For one, Tailwind has a minimal learning curve if you already know CSS. That's a huge thing going for it.
Secondly, UI frameworks are more suitable for full-blown applications, whereas Tailwind can be used for anything—applications, Wordpress themes, static sites, etc.
Material-UI React specifically has terrible performance. It's been a known issue for a while and it's still causing problems on the latest version. One of my projects has a seemingly random 400~500ms render time on any component that uses even a single Material-UI component, which I believe to be an issue with their styling engine. It's incredibly frustrating.
Since Tailwind is literally just CSS classes, at the very least I know I won't ever run into this.
Not liking React, and Tailwind, is a bit like saying 'I don't like Netty/Sprint Boot, I'll write my own web server'.
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.
How is saying "I don't like tailwind" leading to "I'll write my own webserver"? If tailwind was, magically, the only alternative to hand-rolling everything, perhaps, maybe, but it's not.
My analogy, which seems to be a poor one judging by the downvotes, is that css is lowest level you can get for layout in browser, so it's inevitable that someone will write something of a higher abstraction to simplify it's usage (discoverable with limited class names), give it a particular purpose (consistent scales), and make it reusable. This is exactly what a library (webserver) is written on top of a language of your choice (java).
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.
The downvotes probably came from your 'all or nothing'. There are, and have been, multiple abstractions at various levels, for years. Implying that if someone doesn't like these particular abstractions, they advocate "build it yourself" is wrong, and that's how it came off.
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.
[0]: https://twitter.com/wolfr_2/status/1310887766595637248
[1]: https://twitter.com/wolfr_2/status/1280949237820383232