6 ms·

So tailwind at this point is basically just a bunch of custom CSS classes which are granular to the point of single CSS properties? How is that better, than ju

by Varqu 4y ago

So tailwind at this point is basically just a bunch of custom CSS classes which are granular to the point of single CSS properties? How is that better, than just writing custom CSS classes for components + having some util CSS classes?

lmiller1990 4y ago
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.
- champagnepapi 4y ago
  Agreed. I was a hater at first, but now I’ll never go back. Took me a couple months to get used to it. However i split my time between both frontend and backend.
- agos 4y ago
  I've built a few small projects with it, and as much as I love the design tokens the idea of having a CSS class for every value of every possible property feels like abusing CSS, and it makes it feel like it has the same complexity of css
  - withinboredom 4y ago
    that's how I felt until my first `dark:text-white`. I got 'dark mode' out of the box and only needed to change a few things. I didn't need to google how to set up the css, then define a whole new dark mode. I was able to do iteratively, right on the component I was changing. This made 'more work' on the dev side, but on the testing side, you just had to find a single instance of the component and verify it looked reasonable. I think the ability to mix up things like that is what makes it quite powerful. You don't have to go digging through your sources to find all instances of '.my-one-off-class-that-some-random-dev-also-used'.
  - agloe_dreams 4y ago
    Yes. It is intended to be equally complex, short of inheritance. But keep in mind that it doesn’t actually ship every class, it trims them out.
  - Okawari 4y ago
    It does feel radically different from the more traditional way of doing things, but I think it is for the better. I wouldn't call it abusing. Tailwind together with view components has changed how I structure my code and it creates quite a bit less work than my company's old more BEM centric approach where we would create lots of tightly coupled CSS code controlled by variables and such. I find it easier to grok as well, because I don't need to reference SCSS files to determine the implications of applied classes when debugging or similar. Now most of the component requirements can be codified in a few classes in our view component instead. Does it look kinda ugly, yeah sure. But I'm sure it has saved quite a few hours for me since I switched over. This might just be because old process was even worse, regardless it has been a very positive change for me personally.
eajakobsen 4y ago
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.
- eurasiantiger 4y ago
  SCSS wins for maintainability. You could import your favourite design framework (say, bootstrap) as SCSS, change its variables to suit your design, and create any custom components using @extend: .custom-component { @extend .some-bootstrap-class } Also nothing prevents you from creating mixins, functions, etc. Just keep it first-order, as SCSS functions cannot return new functions.
  - jeffhuys 4y ago
    In tailwind, it's in the tailwind config. Same stuff, basically.
victorbjorklund 4y ago
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
- resonious 4y ago
  Except for 2, I think these points could similarly advocate for just using the `style` attribute. Even then, `1em` is a pretty good "default" for "I just want padding" in vanilla CSS.
  - jen729w 4y ago
    Or SCSS variables. Which is what I’ve gone back to after a brief love affair with Tailwind. Not bashing Tailwind. It’s amazing. But I found myself making thatsamefuckingwebsite.com again and god damn if I didn’t want something to look different. And as soon as you’re writing your own CSS, you might as well just write your own CSS. Like literally the first time you write your own particularly uniquely styled component and have to mash your own classes in with Tailwind’s you think, hang on, why don’t I just… Edit: like this site. Just found it via elsewhere. https://www.usebubbles.com/ https://www.usebubbles.com/ First thought: justanotherfuckingtailwindwebsite.com
    - throwaway26920 4y ago
      You can change Tailwind configuration. For example, it's entirely possible to design 1:1 iOS-like UI using Tailwind with custom style config. The default style is overused, but it's cool to have a pretty base for small projects that don't have their own corporate identity yet.
pilif 4y ago
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. What am I misunderstanding here?
- adamwathan 4y ago
  You can’t do things like hover styles, media queries, etc. with `style=`. Re: separating presentation from page structure, Tailwind is designed around the opinion that that whole idea was mostly wrong, similar to how frameworks like React brought back the `onClick=` attribute when everyone was saying “unobtrusive JavaScript” was the best practice Wrote about this in depth a few years ago shortly before releasing Tailwind, can read here: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...
robertwt7 4y ago
that is better because: 1. naming is hard 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
jmull 4y ago
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.
barrell 4y ago
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.
DanielHB 4y ago
> 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
- megous 4y ago
  > Only works well in component-based web development (ie React, Svelte, Vue, etc) as opposed to inheritance-based styling (old school CSS+HTML) Funny how that's not how it's advertised on the landing page. The first animation of its use is just basically plaintext HTML document. I can't imagine using it for that.
  - agloe_dreams 4y ago
    It is on the landing page. Roughly halfway down. That said, that hero example would be impossible to show in anything other than plain HTML as you would need a react version, an Angular Version and a Vue version. It is a demo of what it can do rather than than how.
tannhaeuser 4y ago
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.
- sharperguy 4y ago
  Funny it seems like the biggest thing that tailwind solves is the "naming things is hard" problem.
hoofhearted 4y ago
I’ve copied my comment from above: 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.
richeyryan 4y ago
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.
Lockal 4y ago
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.

by Varqu 4y ago

lmiller1990 4y ago

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.

champagnepapi 4y ago
Agreed. I was a hater at first, but now I’ll never go back. Took me a couple months to get used to it. However i split my time between both frontend and backend.
agos 4y ago
I've built a few small projects with it, and as much as I love the design tokens the idea of having a CSS class for every value of every possible property feels like abusing CSS, and it makes it feel like it has the same complexity of css
- withinboredom 4y ago
  that's how I felt until my first `dark:text-white`. I got 'dark mode' out of the box and only needed to change a few things. I didn't need to google how to set up the css, then define a whole new dark mode. I was able to do iteratively, right on the component I was changing. This made 'more work' on the dev side, but on the testing side, you just had to find a single instance of the component and verify it looked reasonable. I think the ability to mix up things like that is what makes it quite powerful. You don't have to go digging through your sources to find all instances of '.my-one-off-class-that-some-random-dev-also-used'.
- agloe_dreams 4y ago
  Yes. It is intended to be equally complex, short of inheritance. But keep in mind that it doesn’t actually ship every class, it trims them out.
- Okawari 4y ago
  It does feel radically different from the more traditional way of doing things, but I think it is for the better. I wouldn't call it abusing. Tailwind together with view components has changed how I structure my code and it creates quite a bit less work than my company's old more BEM centric approach where we would create lots of tightly coupled CSS code controlled by variables and such. I find it easier to grok as well, because I don't need to reference SCSS files to determine the implications of applied classes when debugging or similar. Now most of the component requirements can be codified in a few classes in our view component instead. Does it look kinda ugly, yeah sure. But I'm sure it has saved quite a few hours for me since I switched over. This might just be because old process was even worse, regardless it has been a very positive change for me personally.

eajakobsen 4y ago

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.

eurasiantiger 4y ago
SCSS wins for maintainability. You could import your favourite design framework (say, bootstrap) as SCSS, change its variables to suit your design, and create any custom components using @extend: .custom-component { @extend .some-bootstrap-class } Also nothing prevents you from creating mixins, functions, etc. Just keep it first-order, as SCSS functions cannot return new functions.
- jeffhuys 4y ago
  In tailwind, it's in the tailwind config. Same stuff, basically.

victorbjorklund 4y ago

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

resonious 4y ago
Except for 2, I think these points could similarly advocate for just using the `style` attribute. Even then, `1em` is a pretty good "default" for "I just want padding" in vanilla CSS.
- jen729w 4y ago
  Or SCSS variables. Which is what I’ve gone back to after a brief love affair with Tailwind. Not bashing Tailwind. It’s amazing. But I found myself making thatsamefuckingwebsite.com again and god damn if I didn’t want something to look different. And as soon as you’re writing your own CSS, you might as well just write your own CSS. Like literally the first time you write your own particularly uniquely styled component and have to mash your own classes in with Tailwind’s you think, hang on, why don’t I just… Edit: like this site. Just found it via elsewhere. https://www.usebubbles.com/ https://www.usebubbles.com/ First thought: justanotherfuckingtailwindwebsite.com
  - throwaway26920 4y ago
    You can change Tailwind configuration. For example, it's entirely possible to design 1:1 iOS-like UI using Tailwind with custom style config. The default style is overused, but it's cool to have a pretty base for small projects that don't have their own corporate identity yet.

pilif 4y ago

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. What am I misunderstanding here?

adamwathan 4y ago
You can’t do things like hover styles, media queries, etc. with `style=`. Re: separating presentation from page structure, Tailwind is designed around the opinion that that whole idea was mostly wrong, similar to how frameworks like React brought back the `onClick=` attribute when everyone was saying “unobtrusive JavaScript” was the best practice Wrote about this in depth a few years ago shortly before releasing Tailwind, can read here: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...

robertwt7 4y ago

that is better because: 1. naming is hard 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

jmull 4y ago

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.

barrell 4y ago

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.

DanielHB 4y ago

> 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

megous 4y ago
> Only works well in component-based web development (ie React, Svelte, Vue, etc) as opposed to inheritance-based styling (old school CSS+HTML) Funny how that's not how it's advertised on the landing page. The first animation of its use is just basically plaintext HTML document. I can't imagine using it for that.
- agloe_dreams 4y ago
  It is on the landing page. Roughly halfway down. That said, that hero example would be impossible to show in anything other than plain HTML as you would need a react version, an Angular Version and a Vue version. It is a demo of what it can do rather than than how.

tannhaeuser 4y ago

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.

sharperguy 4y ago
Funny it seems like the biggest thing that tailwind solves is the "naming things is hard" problem.

hoofhearted 4y ago

I’ve copied my comment from above: 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.

richeyryan 4y ago

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.

Lockal 4y ago

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.