I'll post one of my previous comments here, hoping to get a discussion going...
> The problem with Tailwind for me is that Mr Wathan misrepresented « Good CSS » in his essay. His examples are BAD CSS, not good CSS. He then sets out to correct a problem with CSS that HE created by writing dirt poor CSS.
`.author-bio > div > h2 { color: red } is NOT good CSS. The div part has no reason being there (why would the div change the color of the title ?). After presenting this auto-created problem, he sets out to solve it with BEM, where you need untold numbers of classes for everything. So now, CSS has a naming problem, created to solve a non-existing auto-created CSS problem. And Tailwind now solves this pseudo-problem.
Apart from this, the thing that really bugs me is that every advantage claimed (apart from one) is also non-existing because if you do your CSS right, the same claimed advantages arise in pure CSS. Design tokens ? No need for json, custom properties are all you need. Specificity ? Cascade layers, pseudo-selectors are here for you.
The only "advantage" I see is the possibility of working in one file only rather than a couple of files. And that, for me at least, is not a real advantage but only a justification for being lazy. There's no way the price of all these processes and dependencies complexity are worth the laziness-added value.
Does someone care to "prove" me wrong here ? At least, can someone engage these arguments ?
Maybe one point not raised enough in the eternal discussion between Tailwind vs CSS properly is the cognitive load of naming and organizing things.
To do CSS properly, you need to name classes, you need to come up with CSS cascades that work.
Being programmers we would love to categorize and name things all day long. Ever heard how we over-engineer things because of the DRY principle?
But we would love to name classes and do CSS properly only theoretically. In practice, we run out of time making CSS with nothing to show a week into the task except a CSS kitchen sink demo. By the time we're done, the scope of some component has grown in a way we did not expect and is hard to represent without markup change.
Tailwind on the other hand removes the task of thinking how to name the thing we're making. A appbutton appbutton--state-user-notallowed or a touchbutton touchbutton--disabled? In Tailwind it's just a a blue-600 rounded rectangle. Scope changed? No problem, now it's a green-400 shadow special rectangle, without checking where else it was or will be used or coming up with a new name for this special rectangle.
The problem is that I’m not convinced that “good CSS” even exists. Even the very idea of separating content and style seems problematic to me, and in my experience it simply doesn’t works for anything more complex than a markdown converted to html.
Add to it that for some weird reason web’s style includes layouting, which imo should be a separate thing entirely, and this is the primary reason why any given CSS has to be specifically created for a given HTML template, and why seemingly benign CSS modifications can move that 3rd step of the checkout page, rendering it completely broken.
Restricting CSS to a subset of only cascading some very basic properties (fonts, colors, default font-size), and letting everything else be managed on a per component basis (where close coupling of style and template absolutely makes sense) and simply layouting those components to form the given design makes much more sense to me (and frankly, it was sort of figured out a few decades ago by several desktop GUI framework..). And while you can write vanilla CSS this way, tailwind just restricts you to this subset — the same way there sure exists some safe subset of C, but you need something like Rust to restrict you to that [1]
[1] I know, this is not really how it works, it’s only for the analogy’s sake
I think most developers simply don't care about this, I know I don't*. I don't see CSS as some beautiful thing I should tweak and spend time naming and doing "right". I want to be able to slap some class names onto things that quickly make it look the way I want, with a system I know others will be able to grok almost immediately with a high level of consistency and get back to building the features that are actually going to attract customers and generate more value.
The advantage of Tailwind is commoditizing CSS into something no one has to really think about as deeply as you're suggesting we do. Someone who cares to can do that thinking and put it into a Tailwind class in one of the versions. It's also portable, in that anyone who works with Tailwind can come in and immediately contribute, instead of figuring out whatever structure we've built ourselves.
Tailwind provides me a lot of value in that it lets me continue building while providing a very nice UI (which is required in modern times) and not having to engage too deeply with styles, because I'm not trying to be a master of CSS, I'm trying to build a wholistic product and I have 500 other things I need to do.
* I'm a backend guy but recognize I need nice UIs.
I used Tailwind for the first time about a month and a half ago, reworking my blog from `styled-components` [1]. I had been avoiding it because--as other people have said--it looked really ugly and unmaintainable. I was pleasantly surprised by just how easy it was to get going, however, and my fears about it all ending up as an unmaintainable soup were unfounded.
So I guess I'm a Tailwind convert :) It's very quick and easy to get stuff done using it--the design system is very well thought out. For internal dashboards I think you're still better off using an off the shelf component library like MUI, but Tailwind is a really good option for anything else imo.
Tailwind threads are always the same. And like in all of them, I'm here to say I love Tailwind, and thank you to the devs! It's such a small thing, but the 950 color is a great addition. It's one of the areas where I've reached for my own classes, so I can eliminate yet another little bit of CSS from my codebase.
I've tried Tailwind on smaller projects and it's not a bad way of writing styling. Not having to think about class naming or selectors speeds things up a bit, and it's nice that it promotes only shipping the styles you need (i.e. no classes with lots of the same properties declared).
However, one thing I'm still wondering about is how easy it would be to maintain visual consistency in a large project with lots of components, and lots of different developers working on different parts of the app.
Say the branding guidelines a certain style, like rounded corners with some shadowing and a hover styles, something that can't be done with a simple utility class. This should be consistent across many different components and pages. Then, someone in design updates the guidelines to have a different value for rounding and shadows.
With Tailwind out of the box, each component now has to be updated separately, and developers have to remember, or at least be able to check in documentation if that exists, which components use this particular style.
Is the answer then simply to use @apply for combinations of style? Doesn't this simply re-invent CSS classes, and create another layer of abstraction (you now have a class, which is composed of other classes, which themselves are composed of values set in custom properties).
I'd be very interested to hear how people manage this in large teams, over time.
That is pretty much what it has always been. The reason I like it is
1) it is more standardised (since it is written in html rather than custom classes) which means you can pretty much copy a component from one project to another without worrying that maybe the css naming overlaps etc. It just works.
2) it limits the decisions you need to make. No need to decide exactly how many pixels the padding should be. Just pick p-4. And if that is too much take p-3.
3) You dont need to worry that something in a totally different part of the app will break if you change the css to change the styling of a component
4) It is just faster to write and in my opinion easier to reason about (im sure this is personal) since I can see directly in the html what styling is applied and i dont need to go and dig in different stylesheets to find out what "custom-button-large" does
This is how it basically was since day 1. These comments always appear in Tailwind threads -- more often than not, the poster hasn't given Tailwind a good try.
It's definitely worth building a few small projects - it looks and feels bad at first, but once you get used to using it, it's really hard to go back to anything else.
It's a little more than just a bunch of custom css classes which are granular to the point of single CSS properties. It also implements a tokenized design system - basically providing you a scaled set of units.
You don't have to remember whether you had a 4px or 0.5rem or 4% border radius on your buttons, you just have to remember sm, base, lg, xl, or full. You don't have to remember the scaling of your fonts, you just use the same nomenclature.
This:
1. Creates a more cohesive codebase where most everything is using the same units (I've never worked on a project where there wasn't a rampant intermixed use of em, rems, px, and vw/vh -- except on tailwind projects)
2. Creates a more structured component feeling -- you don't ever run into the cases where border radius is off by 1 pixel or widths are using different units
3. Creates a more cohesive design feeling -- text sizes are balanced with eachother, widths are balanced nicely, colors grade smoothly, etc
I was a long holdout on tailwind. I always say it as just another way to write css except on one line (css golfing). Either I was ignorant in the beginning, or it changed along the way, but by the time I started using it around v3 I couldn't believe I was holding onto CSS for so long.
I think one of the biggest benefits, which I rarely see mentioned, is that all the class names are shared. When building your CSS for production, you can look at the classes you use and only add them to your CSS bundle. If you remove a class from somewhere in your HTML, the associated CSS gets dropped from your bundle. Your output CSS will shrink or grow with the classes that you use. Typically it's harder to remove dead CSS from traditional codebases.
Because the classes are shared to begin, there is less redundancy in the final CSS than using custom classes, perhaps with mixins to do standard flex or positioning patterns. So the resulting CSS file is typically relatively small and kept small by the dead code elimination. You can ship the entire CSS file to any page or on the initial page load for a SPA and not worry about code splitting your CSS, which can be troublesome in some builds.
> So tailwind at this point is basically just a bunch of custom CSS classes which are granular to the point of single CSS properties?
It pretty much always were?
> How is that better, than just writing custom CSS classes for components + having some util CSS classes?
1) colocation of style and layout in the code (no separate file, no "dead-code" CSS classes)
2) isolation of styling rules (this style applies ONLY to this HTML component)
3) Built-in standardization across the codebase (spacing, colors, etc)
Only works well in component-based web development (ie React, Svelte, Vue, etc) as opposed to inheritance-based styling (old school CSS+HTML)
You can get a lot of the benefits of tailwind using other tools like CSS modules (isolation) or colocation (styled-components), or with plain CSS features (CSS variables for standardization). But tailwind has a major benefit of introducing almost-zero runtime impact (vs styled-components) and having everything already built-in (vs css-modules. There is very little the user of the lib needs to think about architecture-wise when using tailwind
Apparently, because it ends discussion about CSS frameworks in a team once and for all.
That may sound absurd given tailwind classes represent single CSS property value assertions. But you can pretend and say "look we're using a preprocessor and pipeline step for our CSS" all the while you're hand-crafting your CSS like in days past, making tailwind act like a no-op submarine, and without the bad looks of inline styles.
The benefit is that you don't have to create a badass taxonomy for your frontend classes (that might or might not evolve well) just because CSS is there, especially if you're using CSS-in-JS anyway and might prefer relying on code organization via JS (that you're using anyway).
CSS rules are just a redundant syntax for markup attributes anyway.
It’s a little worse in a way, since it’s another thing to learn and use and you still need a decent knowledge and understanding of CSS.
But the advantages out-weigh the disadvantages, IMO:
- provides a simpler, thoughtful, more logically organized version of CSS (with nice ways to extend it and escape hatches if you need them).
- the “CSS” —- meaning the CSS-like classes — live right on the HTML elements they style.
It makes it feasible to directly style HTML using CSS-like classes, rather than having to build and, importantly, maintain separate CSS and your own abstractions mapping classes and element types to styles.
I really like CSS, and in my personal projects I don't use Tailwind.
However, I use it in my day job, and here it is useful to us as a team. The variables combined with the tooling ensures we write consistent styles across our site. The color names and text sizes also correspond to what our design team uses in Figma, making implementing and updating designs quick.
That said, I still find it a pain to read, and we could probably have set up something very similar with CSS Custom Properties.
or to the point, how is this different from just using `style=` attributes?
One of the big reason to not do that in the past was in order to disconnect the presentation from the page structure, but if you have individual classes for each individual css property, you're back at tying the two together.
Tailwind is not just a set of predefined classes (like bootstrap), it is a code generator (with plugins and flexible even without them).
For example, if you define class `.myclass { @apply bg-red-100 hover:bg-red-50 active:bg-red-200 p-2 md:p-3 xl:p-4 animate-pulse; }`, tailwind will generate quite a big css ruleset, with @keyframes and @media-rules. And all of these media-rules are extensible, so if you want a different size for "md" or new suffix, just define it once in config and use everywhere.
Tailwind is just a CSS design token and utility class library at its core. It’s the Bootstrap of the 2020’s.
Regarding design tokens, they are taking notes from 1996, and they realized that it is much more computational efficient to describe your component visually with inline styles compared to loading separate style sheets.
Tailwind and CSS design tokens in general make it easier to make smart, efficient choices from curated palettes. Design tokens also create a common language for everyone who uses Tailwind - both across teams and across projects, which can break down communication barriers in large scale projects.
- It's a DSL within a DSL, which as a rule of thumb I always avoid because it means circumventing any static analysis within the main language. The rest of my complaints are mostly derived from this fundamental issue.
- It reminds me (not in a good way) of bootstrap classes circa 2011
- Unlike styled components, there is no static typing or intellisense as it circumvents the TS compiler. I'm sure Tailwind has its own solutions to this problem, but I have enough tooling to deal with already
- It's an arcane "language" that needs to be learned in addition to every other language in your codebase, which makes it difficult to onboard new devs
- A string value containing a long list of short identifiers does not make for readable nor maintainable code
- In 2033, CSS will still be around. Nobody knows whether Tailwind will be, but if "reminds me of bootstrap" is any indication, the ecosystem will not be thriving.
- It's not easy to remove from your project if you decide you don't want to use it anymore (unlike solutions that use CSS or object syles, which can be more readily swapped between frameworks, e.g. migrating from MUI to Emotion or from Emotion to CSS modules)
- None of the problems it purports to solve are recognizable to me
I know that people like Tailwind, but frankly I don't see why, and I suspect there may be some element of stockholm syndrome driving its popularity. And I'm always skeptical of any technology with culty vibes around it.
As for me, my preferred solution is either CSS modules or emotion.js, using either CSS or styled objects, both of which are fully supported by intellisense and typechecking, and are based on a 25 year old standard language instead of a 3 year old DSL within that language.
> It reminds me (not in a good way) of bootstrap classes circa 2011
Unlike Bootstrap Tailwind doesn't have hardcoded components and full on UI elements like "breadcrumb-item" or "modal-title". You want components? You build them yourself.
Tailwind is literally just utility classes with a few defaults for sizes and colors thrown in.
> unlike solutions that use CSS or object syles, which can be more readily swapped between frameworks, e.g. migrating from MUI to Emotion
You're confusing a CSS framework that actually is like Bootstrap (MUI) with a way of writing CSS (emotion).
You'll have significantly more troubles trying to move away from MUI with its rigid requirements for code structure and CSS (Typography variant="subtitle1" and Button variant="outlined" etc.) than moving away from Tailwind which is really just a collection of CSS classes that you may or may not use as you wish.
So you’ll come up with hypothetical reasons you don’t like it, instead of just trying something which is loved by many people, and seeing if you actually like it.
I do not like it in a boat, I do not like it with my coat, I do not like green eggs and ham.
Have you tried it in earnest on a project? I was of the same opinion but once you try it (with VS Code and Tailwind plugin) it's hard not to fall in love with the ultra fast feedback loop and well defined colour palette.
To the people moaning about “what is the benefit”:
You ship less CSS, especially the more complex your app gets. A app built with custom classes ends up growing linearly, often with lots of repeated css code. With Tailwind, the amount of css added always ends up being logarithmic.
It also ensures consistency across the codebase in both naming conventions and styling (e.g consistent spacing ratios) without seniors having to be vigilant about policing PRs.
Finally, the majority of people who have tried it find it quicker and easier to code with. Which means you can ship more functionality in the same amount of time whilst maintaining the same or better styling standards.
So there are three of the engineering benefits to using it. If you don’t like it and don’t want to use it, fine. But stop pretending that no one can give you good engineering reasons that justify it’s existence.
I think Tailwind isn’t that great if you’re really proficient with CSS.
But if you need backend devs to fiddle with styles or have some teammates who aren’t senior css magicians then it really shines.
Anyway I’m not entirely sold, I feel good old Sass is way better than styled components and Tailwind, but only in right hands. It’s painfully easy to write unmaintainable styled components and Sass/CSS.
A reminder that if you’re having trouble naming divs, you have too many divs. Everywhere I’ve worked that used tailwind just kept adding wrappers around every ui element since they didn’t know css basics.
Have there been any comparisons written about Tailwind's performance vs thoughtfully selected CSS? I've been writing Tailwind exclusively for the last year or so and I haven't noticed anything in particular, but I find that using utility classes causes me to lose an awareness of the cascading nature of CSS. Aside from the filesize bloat due to the bigger HTML files, do long and highly-repetitive class lists slow down style parsing or DOM interaction? And if so, would @apply directives have an advantage over class lists?
Isn’t it ironic that the first section talks about extended color palettes, but their website does not honor my CSS (prefers-color-scheme: light) preference when I visit that page with JavaScript disabled. There is a moon icon in the upper right, but it’s broken without JS.
I’ve read a decent amount about Tailwind and I really appreciate what it offers. I see all the claims of people who were unsure, tried it, and fell in love, and I don’t doubt their experiences. It seems great.
The sad reality for me: I am very very productive with a mix of inline styles and Emotion/Styled-Components! I genuinely enjoy writing CSS. A library like MUI gives me a foundation of consistency and helpful utilities, but I love the ability to drop back into CSS and express ideas in a universal styling language that any experienced frontend developer should be able to understand. I move fast. I can show my code to others for feedback and they’ll be able to contribute. I genuinely enjoy it.
Tailwind does offer some ways of writing CSS but my understanding from the docs is that they are discouraged. They certainly don’t give the ease and quick feedback of in-line or Emotion.
I’m also highly suspicious of the longevity of the utility class approach and its shorthand. It makes me think of my experience with Slim templates in Ruby: it felt like a force multiplier at the time but but only other initiates appreciated it and it looked like absolute gibberish when I came back to it years later. These projects would have been better sticking with ERB since it’s the HTML everyone knows sprinkled with Ruby where needed. My initial impression of Tailwind is the same: “this looks crazy but everyone swears that it’s a breeze once you learn the syntax!” Will the end result be the same?
Again, no disrespect to anyone who enjoys it. I fully recognize the many drawbacks of inline styles and Emotion, particularly around performance. I’m currently lamenting the incompatibility of Emotion and React Server Components. I plan on giving Tailwind a fair shot soon and I’m open to having my mind changed, but I do hope it has more staying power than Slim templates.
This echoes my feelings exactly, but another aspect of it that turns me off is evident in the walking-on-eggshells qualifications you need to add to your comment to avoid being attacked by its "initiates."
In comparison, my experience with adopting TypeScript was one where my initial skepticism was met with people clearly explaining the benefits of using it. And TypeScript has a similar aspect where you need to try it to really understand its benefits, but it also has clear value propositions that can be described and considered on their fundamental merits. Tailwind does not seem to have the same kind of benefits, so the arguments boil down to variants of "with us or against us" and "look at all these people using it." And from that perspective, I see a lot of people who I respect a lot who are _not_ using it. Whereas I never saw many experts saying "TypeScript sucks don't use it" - they just quietly adopted it because type safety was important to them on its merits.
I’m surprised and a bit puzzled at what they’ve done with logical properties: they’ve completely ignored the existence of vertical writing modes (apart from single-corner border-radius, where you can’t), and named things in such a way that it would be ugly and inconsistent to subsequently support the block axis, since they’ve basically renamed inline-start and inline-end to start and end.
CSS is a tool as Jeff Atwood would say designed for pit of despair[1]. Which means, the default path is making mistakes and failing horribly.
And Tailwind CSS is a tool which is designed with Pit of Success in mind. This means, the default path is success and not anger and despair.
Not to mention, it doesn't have any performance taxes. And also, unlike other CSS framework, you should know CSS in order to utilise Tailwind CSS properly. People learn more about CSS by using Tailwind unlike many other CSS frameworks.
I love tailwind. I would like the addition for perceptual color palette. I do it by hand with HSLuv and I redefine the colors, but having a built in way to build light on ark and dark on light contrast that look good regardless of hue would be cool.
My understanding is that that's a non-trivial problem. You'd likely need some sort of AI system to do it, since the perception of colour isn't something that can be simply modelled.
Coming from bootstrap, I would say if you are not using tailwind, you are missing out. It is just breathe of fresh air.
But, but, but, seems like almost all the project that use tailwind ends up looking like linear. Not that I blame tailwind for that, there was an era when almost all bootstrap projects looked similar, I think it is the same thing.
I just tried to switch a simple quick site from bootstrap to tailwind and backed out. It seemed like I had to build my base template from scratch whereas with bootstrap they give it to me for free.
With tailwind, is there an easy way to start with a nice simple working responsive site that I can tweak?
Great to see yet another Tailwind version. I’m a huge fan. CSS is always a “get it over with” ordeal for me, and Tailwind allows me to finish the job in the quickest way. And Tailwind UI has been one of the best purchases I’ve made in the past year.
It's hilarious how every Tailwind thread ends up looking the same somehow. Use it if you want. It's just a (very good!) tool which some people find useful.
Thanks Adam and all the Tailwind contributors for your work!
[+] [-] emmacharp|3 years ago|reply
> The problem with Tailwind for me is that Mr Wathan misrepresented « Good CSS » in his essay. His examples are BAD CSS, not good CSS. He then sets out to correct a problem with CSS that HE created by writing dirt poor CSS. `.author-bio > div > h2 { color: red } is NOT good CSS. The div part has no reason being there (why would the div change the color of the title ?). After presenting this auto-created problem, he sets out to solve it with BEM, where you need untold numbers of classes for everything. So now, CSS has a naming problem, created to solve a non-existing auto-created CSS problem. And Tailwind now solves this pseudo-problem.
Apart from this, the thing that really bugs me is that every advantage claimed (apart from one) is also non-existing because if you do your CSS right, the same claimed advantages arise in pure CSS. Design tokens ? No need for json, custom properties are all you need. Specificity ? Cascade layers, pseudo-selectors are here for you.
The only "advantage" I see is the possibility of working in one file only rather than a couple of files. And that, for me at least, is not a real advantage but only a justification for being lazy. There's no way the price of all these processes and dependencies complexity are worth the laziness-added value.
Does someone care to "prove" me wrong here ? At least, can someone engage these arguments ?
Looking forward to it!
[+] [-] enkrs|3 years ago|reply
To do CSS properly, you need to name classes, you need to come up with CSS cascades that work.
Being programmers we would love to categorize and name things all day long. Ever heard how we over-engineer things because of the DRY principle?
But we would love to name classes and do CSS properly only theoretically. In practice, we run out of time making CSS with nothing to show a week into the task except a CSS kitchen sink demo. By the time we're done, the scope of some component has grown in a way we did not expect and is hard to represent without markup change.
Tailwind on the other hand removes the task of thinking how to name the thing we're making. A appbutton appbutton--state-user-notallowed or a touchbutton touchbutton--disabled? In Tailwind it's just a a blue-600 rounded rectangle. Scope changed? No problem, now it's a green-400 shadow special rectangle, without checking where else it was or will be used or coming up with a new name for this special rectangle.
It's just faster. Not strictly better.
[+] [-] kaba0|3 years ago|reply
Add to it that for some weird reason web’s style includes layouting, which imo should be a separate thing entirely, and this is the primary reason why any given CSS has to be specifically created for a given HTML template, and why seemingly benign CSS modifications can move that 3rd step of the checkout page, rendering it completely broken.
Restricting CSS to a subset of only cascading some very basic properties (fonts, colors, default font-size), and letting everything else be managed on a per component basis (where close coupling of style and template absolutely makes sense) and simply layouting those components to form the given design makes much more sense to me (and frankly, it was sort of figured out a few decades ago by several desktop GUI framework..). And while you can write vanilla CSS this way, tailwind just restricts you to this subset — the same way there sure exists some safe subset of C, but you need something like Rust to restrict you to that [1]
[1] I know, this is not really how it works, it’s only for the analogy’s sake
[+] [-] ianbutler|3 years ago|reply
The advantage of Tailwind is commoditizing CSS into something no one has to really think about as deeply as you're suggesting we do. Someone who cares to can do that thinking and put it into a Tailwind class in one of the versions. It's also portable, in that anyone who works with Tailwind can come in and immediately contribute, instead of figuring out whatever structure we've built ourselves.
Tailwind provides me a lot of value in that it lets me continue building while providing a very nice UI (which is required in modern times) and not having to engage too deeply with styles, because I'm not trying to be a master of CSS, I'm trying to build a wholistic product and I have 500 other things I need to do.
* I'm a backend guy but recognize I need nice UIs.
[+] [-] sophiabits|3 years ago|reply
So I guess I'm a Tailwind convert :) It's very quick and easy to get stuff done using it--the design system is very well thought out. For internal dashboards I think you're still better off using an off the shelf component library like MUI, but Tailwind is a really good option for anything else imo.
[1] https://sophiabits.com/blog/css-in-js-to-tailwind-better-web...
[+] [-] christophilus|3 years ago|reply
[+] [-] vancroft|3 years ago|reply
However, one thing I'm still wondering about is how easy it would be to maintain visual consistency in a large project with lots of components, and lots of different developers working on different parts of the app.
Say the branding guidelines a certain style, like rounded corners with some shadowing and a hover styles, something that can't be done with a simple utility class. This should be consistent across many different components and pages. Then, someone in design updates the guidelines to have a different value for rounding and shadows.
With Tailwind out of the box, each component now has to be updated separately, and developers have to remember, or at least be able to check in documentation if that exists, which components use this particular style.
Is the answer then simply to use @apply for combinations of style? Doesn't this simply re-invent CSS classes, and create another layer of abstraction (you now have a class, which is composed of other classes, which themselves are composed of values set in custom properties).
I'd be very interested to hear how people manage this in large teams, over time.
[+] [-] random_kris|3 years ago|reply
Then on top of this we have components library with common basic components and layouts
Then inside the apps we use the components and that Tailwind config and it works quite nice.
We have rules for tokenized colors and sizes so it all references the config.
There are problems and all, but all in all I think is quite good
[+] [-] Varqu|3 years ago|reply
How is that better, than just writing custom CSS classes for components + having some util CSS classes?
[+] [-] victorbjorklund|3 years ago|reply
1) it is more standardised (since it is written in html rather than custom classes) which means you can pretty much copy a component from one project to another without worrying that maybe the css naming overlaps etc. It just works.
2) it limits the decisions you need to make. No need to decide exactly how many pixels the padding should be. Just pick p-4. And if that is too much take p-3.
3) You dont need to worry that something in a totally different part of the app will break if you change the css to change the styling of a component
4) It is just faster to write and in my opinion easier to reason about (im sure this is personal) since I can see directly in the html what styling is applied and i dont need to go and dig in different stylesheets to find out what "custom-button-large" does
[+] [-] lmiller1990|3 years ago|reply
It's definitely worth building a few small projects - it looks and feels bad at first, but once you get used to using it, it's really hard to go back to anything else.
[+] [-] barrell|3 years ago|reply
You don't have to remember whether you had a 4px or 0.5rem or 4% border radius on your buttons, you just have to remember sm, base, lg, xl, or full. You don't have to remember the scaling of your fonts, you just use the same nomenclature.
This:
1. Creates a more cohesive codebase where most everything is using the same units (I've never worked on a project where there wasn't a rampant intermixed use of em, rems, px, and vw/vh -- except on tailwind projects)
2. Creates a more structured component feeling -- you don't ever run into the cases where border radius is off by 1 pixel or widths are using different units
3. Creates a more cohesive design feeling -- text sizes are balanced with eachother, widths are balanced nicely, colors grade smoothly, etc
I was a long holdout on tailwind. I always say it as just another way to write css except on one line (css golfing). Either I was ignorant in the beginning, or it changed along the way, but by the time I started using it around v3 I couldn't believe I was holding onto CSS for so long.
[+] [-] richeyryan|3 years ago|reply
Because the classes are shared to begin, there is less redundancy in the final CSS than using custom classes, perhaps with mixins to do standard flex or positioning patterns. So the resulting CSS file is typically relatively small and kept small by the dead code elimination. You can ship the entire CSS file to any page or on the initial page load for a SPA and not worry about code splitting your CSS, which can be troublesome in some builds.
[+] [-] DanielHB|3 years ago|reply
It pretty much always were?
> How is that better, than just writing custom CSS classes for components + having some util CSS classes?
1) colocation of style and layout in the code (no separate file, no "dead-code" CSS classes) 2) isolation of styling rules (this style applies ONLY to this HTML component) 3) Built-in standardization across the codebase (spacing, colors, etc)
Only works well in component-based web development (ie React, Svelte, Vue, etc) as opposed to inheritance-based styling (old school CSS+HTML)
You can get a lot of the benefits of tailwind using other tools like CSS modules (isolation) or colocation (styled-components), or with plain CSS features (CSS variables for standardization). But tailwind has a major benefit of introducing almost-zero runtime impact (vs styled-components) and having everything already built-in (vs css-modules. There is very little the user of the lib needs to think about architecture-wise when using tailwind
[+] [-] tannhaeuser|3 years ago|reply
That may sound absurd given tailwind classes represent single CSS property value assertions. But you can pretend and say "look we're using a preprocessor and pipeline step for our CSS" all the while you're hand-crafting your CSS like in days past, making tailwind act like a no-op submarine, and without the bad looks of inline styles.
The benefit is that you don't have to create a badass taxonomy for your frontend classes (that might or might not evolve well) just because CSS is there, especially if you're using CSS-in-JS anyway and might prefer relying on code organization via JS (that you're using anyway).
CSS rules are just a redundant syntax for markup attributes anyway.
[+] [-] jmull|3 years ago|reply
But the advantages out-weigh the disadvantages, IMO:
- provides a simpler, thoughtful, more logically organized version of CSS (with nice ways to extend it and escape hatches if you need them). - the “CSS” —- meaning the CSS-like classes — live right on the HTML elements they style.
It makes it feasible to directly style HTML using CSS-like classes, rather than having to build and, importantly, maintain separate CSS and your own abstractions mapping classes and element types to styles.
[+] [-] eajakobsen|3 years ago|reply
However, I use it in my day job, and here it is useful to us as a team. The variables combined with the tooling ensures we write consistent styles across our site. The color names and text sizes also correspond to what our design team uses in Figma, making implementing and updating designs quick.
That said, I still find it a pain to read, and we could probably have set up something very similar with CSS Custom Properties.
[+] [-] pilif|3 years ago|reply
One of the big reason to not do that in the past was in order to disconnect the presentation from the page structure, but if you have individual classes for each individual css property, you're back at tying the two together.
What am I misunderstanding here?
[+] [-] Lockal|3 years ago|reply
For example, if you define class `.myclass { @apply bg-red-100 hover:bg-red-50 active:bg-red-200 p-2 md:p-3 xl:p-4 animate-pulse; }`, tailwind will generate quite a big css ruleset, with @keyframes and @media-rules. And all of these media-rules are extensible, so if you want a different size for "md" or new suffix, just define it once in config and use everywhere.
[+] [-] robertwt7|3 years ago|reply
2. grouping css classes is also hard
3. having some unified naming for all utilities for all developers in your team is much easier to understand and maintain?
4. you reduce 3 steps from creating css file -> writing css class -> re-write them back in the html, vs writing classnames
5. you can have unified styling with color, spacing etc instead of rogue assignment
I'm a tailwind convert from bootstrap but it's definitely worth it after trying. Have created 15+ project with tailwind ever since
[+] [-] hoofhearted|3 years ago|reply
Tailwind is just a CSS design token and utility class library at its core. It’s the Bootstrap of the 2020’s.
Regarding design tokens, they are taking notes from 1996, and they realized that it is much more computational efficient to describe your component visually with inline styles compared to loading separate style sheets.
Tailwind and CSS design tokens in general make it easier to make smart, efficient choices from curated palettes. Design tokens also create a common language for everyone who uses Tailwind - both across teams and across projects, which can break down communication barriers in large scale projects.
[+] [-] chatmasta|3 years ago|reply
- It's a DSL within a DSL, which as a rule of thumb I always avoid because it means circumventing any static analysis within the main language. The rest of my complaints are mostly derived from this fundamental issue.
- It reminds me (not in a good way) of bootstrap classes circa 2011
- Unlike styled components, there is no static typing or intellisense as it circumvents the TS compiler. I'm sure Tailwind has its own solutions to this problem, but I have enough tooling to deal with already
- It's an arcane "language" that needs to be learned in addition to every other language in your codebase, which makes it difficult to onboard new devs
- A string value containing a long list of short identifiers does not make for readable nor maintainable code
- In 2033, CSS will still be around. Nobody knows whether Tailwind will be, but if "reminds me of bootstrap" is any indication, the ecosystem will not be thriving.
- It's not easy to remove from your project if you decide you don't want to use it anymore (unlike solutions that use CSS or object syles, which can be more readily swapped between frameworks, e.g. migrating from MUI to Emotion or from Emotion to CSS modules)
- None of the problems it purports to solve are recognizable to me
I know that people like Tailwind, but frankly I don't see why, and I suspect there may be some element of stockholm syndrome driving its popularity. And I'm always skeptical of any technology with culty vibes around it.
As for me, my preferred solution is either CSS modules or emotion.js, using either CSS or styled objects, both of which are fully supported by intellisense and typechecking, and are based on a 25 year old standard language instead of a 3 year old DSL within that language.
[+] [-] illiarian|3 years ago|reply
Unlike Bootstrap Tailwind doesn't have hardcoded components and full on UI elements like "breadcrumb-item" or "modal-title". You want components? You build them yourself.
Tailwind is literally just utility classes with a few defaults for sizes and colors thrown in.
> unlike solutions that use CSS or object syles, which can be more readily swapped between frameworks, e.g. migrating from MUI to Emotion
You're confusing a CSS framework that actually is like Bootstrap (MUI) with a way of writing CSS (emotion).
You'll have significantly more troubles trying to move away from MUI with its rigid requirements for code structure and CSS (Typography variant="subtitle1" and Button variant="outlined" etc.) than moving away from Tailwind which is really just a collection of CSS classes that you may or may not use as you wish.
[+] [-] stocknoob|3 years ago|reply
I do not like it in a boat, I do not like it with my coat, I do not like green eggs and ham.
[+] [-] nickspicer1993|3 years ago|reply
[+] [-] rcarr|3 years ago|reply
You ship less CSS, especially the more complex your app gets. A app built with custom classes ends up growing linearly, often with lots of repeated css code. With Tailwind, the amount of css added always ends up being logarithmic.
It also ensures consistency across the codebase in both naming conventions and styling (e.g consistent spacing ratios) without seniors having to be vigilant about policing PRs.
Finally, the majority of people who have tried it find it quicker and easier to code with. Which means you can ship more functionality in the same amount of time whilst maintaining the same or better styling standards.
So there are three of the engineering benefits to using it. If you don’t like it and don’t want to use it, fine. But stop pretending that no one can give you good engineering reasons that justify it’s existence.
[+] [-] b212|3 years ago|reply
Anyway I’m not entirely sold, I feel good old Sass is way better than styled components and Tailwind, but only in right hands. It’s painfully easy to write unmaintainable styled components and Sass/CSS.
[+] [-] stuckinhell|3 years ago|reply
[+] [-] alli_star|3 years ago|reply
[deleted]
[+] [-] nailer|3 years ago|reply
[+] [-] sjsanc|3 years ago|reply
[+] [-] zagrebian|3 years ago|reply
[+] [-] sickcodebruh|3 years ago|reply
The sad reality for me: I am very very productive with a mix of inline styles and Emotion/Styled-Components! I genuinely enjoy writing CSS. A library like MUI gives me a foundation of consistency and helpful utilities, but I love the ability to drop back into CSS and express ideas in a universal styling language that any experienced frontend developer should be able to understand. I move fast. I can show my code to others for feedback and they’ll be able to contribute. I genuinely enjoy it.
Tailwind does offer some ways of writing CSS but my understanding from the docs is that they are discouraged. They certainly don’t give the ease and quick feedback of in-line or Emotion.
I’m also highly suspicious of the longevity of the utility class approach and its shorthand. It makes me think of my experience with Slim templates in Ruby: it felt like a force multiplier at the time but but only other initiates appreciated it and it looked like absolute gibberish when I came back to it years later. These projects would have been better sticking with ERB since it’s the HTML everyone knows sprinkled with Ruby where needed. My initial impression of Tailwind is the same: “this looks crazy but everyone swears that it’s a breeze once you learn the syntax!” Will the end result be the same?
Again, no disrespect to anyone who enjoys it. I fully recognize the many drawbacks of inline styles and Emotion, particularly around performance. I’m currently lamenting the incompatibility of Emotion and React Server Components. I plan on giving Tailwind a fair shot soon and I’m open to having my mind changed, but I do hope it has more staying power than Slim templates.
[+] [-] chatmasta|3 years ago|reply
In comparison, my experience with adopting TypeScript was one where my initial skepticism was met with people clearly explaining the benefits of using it. And TypeScript has a similar aspect where you need to try it to really understand its benefits, but it also has clear value propositions that can be described and considered on their fundamental merits. Tailwind does not seem to have the same kind of benefits, so the arguments boil down to variants of "with us or against us" and "look at all these people using it." And from that perspective, I see a lot of people who I respect a lot who are _not_ using it. Whereas I never saw many experts saying "TypeScript sucks don't use it" - they just quietly adopted it because type safety was important to them on its merits.
[+] [-] iamsanteri|3 years ago|reply
[+] [-] chrismorgan|3 years ago|reply
[+] [-] unsungNovelty|3 years ago|reply
CSS is a tool as Jeff Atwood would say designed for pit of despair[1]. Which means, the default path is making mistakes and failing horribly.
And Tailwind CSS is a tool which is designed with Pit of Success in mind. This means, the default path is success and not anger and despair.
Not to mention, it doesn't have any performance taxes. And also, unlike other CSS framework, you should know CSS in order to utilise Tailwind CSS properly. People learn more about CSS by using Tailwind unlike many other CSS frameworks.
[1] - https://blog.codinghorror.com/falling-into-the-pit-of-succes...
[+] [-] kuon|3 years ago|reply
[+] [-] rmckayfleming|3 years ago|reply
[+] [-] whoisjuan|3 years ago|reply
I’m just going to say that Tailwind, IMHO, is the best thing that has happened to CSS.
It’s by far the simplest and cleanest abstraction of CSS, and it accomplishes a lot through a very straightforward implementation.
At this point I can’t see myself writing CSS in any other way.
[+] [-] debarshri|3 years ago|reply
But, but, but, seems like almost all the project that use tailwind ends up looking like linear. Not that I blame tailwind for that, there was an era when almost all bootstrap projects looked similar, I think it is the same thing.
[+] [-] rrosen326|3 years ago|reply
With tailwind, is there an easy way to start with a nice simple working responsive site that I can tweak?
[+] [-] Someone1234|3 years ago|reply
[+] [-] heresjohnny|3 years ago|reply
[+] [-] sadn1ck|3 years ago|reply
Thanks Adam and all the Tailwind contributors for your work!