6 ms·

Before you ask, as it happens in every Tailwind post, what is the point of this when CSS "promotes" reuse and separation of concerns, have a look at @ 5e92cb50

Before you ask, as it happens in every Tailwind post, what is the point of this when CSS "promotes" reuse and separation of concerns, have a look at @ 5e92cb50239222b comment: https://news.ycombinator.com/item?id=29501650 https://news.ycombinator.com/item?id=29501650 And let me repeat what every Tailwind fanboy (like me) states every time this project is on HN: don't knock it till you've tried it. Look at the animated example in the front page. You'll never be able to iterate that quickly with CSS.

zodiakzz 5y ago
If you have a hammer... I am able to iterate orders of magnitude faster in Adobe Photoshop. Back and forth feedback with the customer and then the end result gets coded in non-spaghetti reusable, themeable HTML/CSS. Seems you're iterating at the wrong phase.
- crate_barre 5y ago
  Depends. I’ve never used Tailwind, so I’ll entertain your aside. If you are mostly doing flat design, truthfully you should be designing in HTML/CSS/JS. This is a failure of setting expectations for designers. If you can get developers to learn Leetcode, get designers to code their designs. Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms. You will not iterate faster than what I am suggesting. Edit: The reason why we are here, why something like Tailwind and MUI exist, is mostly because we need an abstraction layer to do what a designer does on a whim. You can flick a shadow on and off on a Photoshop layer and mess with the subtlety of a drop shadow with a slider. If a designer makes a fickle change, the developer needs this abstraction to make the fickle change as fickle as the thought that made it. That’s why you have all these quick utility methods. The designer is one layer (no pun intended) removed. In 2021 (2022 really), it’s shocking the amount of latitude we give designers to still not be able to do CSS. A half competent designer could have a modest style sheet that mostly captures their design instincts, yet here we are, unable to capture their whims and must now have an albatross utility library to have manual laborers capture the translation - all because … they still won’t learn basic shit. And for what ultimately? These aren’t baroque art pieces, it is ultimately boxes with an aesthetic applied, all very describable with semantic HTML and CSS. But alas, our brilliant artists can’t be bothered. Here, send me your masterpiece so I can transform it for you. Take the bootcamp on web dev. You are literally the people I want going there. Not the Classics major that needs money because they picked a stupid major. It’s you guys that need it, and deserve it.
  - handrous 5y ago
    > Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms. This is why all but the very best flat designs (which does not always correlate positively with the size or reputation of the firm turning them out—looking at you, Google) look to me like something I'd have turned out for a quick feature demo circa '05, with everyone at the table agreeing that, however nice the feature, a designer definitely needed to take a pass at it before it was released.
  - robertoandred 5y ago
    Nah, don’t need designers passing along broken, useless CSS that has to be redone anyway. Let designers focus on designing, developers on developing.
    - crate_barre 5y ago
      Lol, bro, making their typography and layout changes is not really development. I’d much rather they just pick that up already.
- Griffinsauce 5y ago
  > non-spaghetti reusable, themeable HTML/CSS The words of an open mind. Each of those adjectives are very open to disagreement.
  - zodiakzz 5y ago
    Perhaps. But hard coded colors, hard coded layout (flexbox etc), hard coded margins, paddings hard coded everything right in the markup. Tailwind and those adjectives are mutually exclusive. Does nobody remember themeing forums software like vbulletin? Designers weren't allowed to touch the markup in the slightest and yet so many amazing themes were made. Why? Styling wasn't hard-coded in the markup. Hell, remember the insanely customized old.reddit subreddits?
    - jf22 5y ago
      We should be comparing Tailwind to modern alternatives, not vBulletin CSS from 2004. FYI I'm a recent Tailwind convert so I agree that Tailwind is good, but your comment is like saying Tesla cars are great because they aren't horses.
      - zodiakzz 5y ago
        Whoosh. Well I prefer my "modern" alternatives to be superior than the legacy ones, not the other way around.
    - jagger27 5y ago
      All of the things you mention, including colours, are configurable or at least overridable at compile time. It's just not swapping a CSS file like the good ol' days. I won't argue if one is better than the other.
KarlKemp 5y ago
Nobody said that it’s a bad experience to use. People say that it’s evil. And, also, that it is made by and for the JS crowd that doesn’t understand CSS nor the document hierarchy it depends on, while simultaneously considering it unworthy of any learning efforts since it’s a girly making-it-pretty addition to a markup language, not a real professional STEM-grad-grade programming language.
- handrous 5y ago
  As much fondness as I have for the pure separation-of-concerns CSS Zen Garden style, I have to admit I've yet to actually see it leveraged on a real project. In 20 years of working on the Web. I'm not sure I've ever seen a significant re-working of CSS to re-theme a site without also changing the markup substantially. In practice, maybe coupling the two doesn't actually do much harm, provided consistency of approach is maintained and it doesn't go quite as far as inlining CSS all over the place.
- lghh 5y ago
  Why do you have the exact same tone and wording as this comment from a different user above? https://news.ycombinator.com/item?id=29502044 https://news.ycombinator.com/item?id=29502044
lijogdfljk 5y ago
Any thoughts as to how Tailwind can handle dynamic plugins using Tailwind? Ie it seems Tailwind relies on tree shaking to produce sanely sized CSS. But if you have plugins which rely on Tailwind, you'd have to either ship the full sized Tailwind CSS or they'd have to duplicate CSS and ship with it. So far with this plugin/extension design i've not found a way to use Tailwind and also retain nicely sized CSS.
- aniforprez 5y ago
  > it seems Tailwind relies on tree shaking to produce sanely sized CSS This 3.0 release has its biggest feature be JIT. If you read the linked blog post, CSS is no longer purged but generated dynamically by reading your source files and generating the TW classes you use. It's not tree shooken anymore
  - lijogdfljk 5y ago
    Appreciate the info! I'll have to figure out how the hell this works though lol, i watched the video and am still a bit perplexed, since i'm not using JavaScript. I'll be curious to see how i can hook into it
    - hbn 5y ago
      As far as I understand, the build system just scans for whatever Tailwind class names you use, and then generates them into CSS. Which is why you can't dynamically compose Tailwind class names and insert them into your markup, cause it wouldn't be picked up. Whether or not you're using Javascript doesn't matter (I guess unless you use the new CDN script which I haven't tried), but it does need to be run in a build system.
      - lijogdfljk 5y ago
        If it just uses regex over source material i guess it would be fine, though seems like it might hit a fair number of false positives if it's too loose. Too rigid and it might not work if you don't write your css vars in something that looks html-like. Will be interesting!
lhorie 5y ago
Some technical thoughts as someone who could care less about fanboyism: - One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes. - Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive. - Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways. - You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development. - Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while). - There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[1] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows. The main theme to be aware of: proponents of atomic CSS rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[2] vs hyperlocal development workflows interact with your organization's design culture. [0] https://en.wikipedia.org/wiki/APL_(programming_language) https://en.wikipedia.org/wiki/APL_(programming_language) [1] https://www.styletron.org/ https://www.styletron.org/ [2] https://en.wikipedia.org/wiki/Aspect-oriented_programming https://en.wikipedia.org/wiki/Aspect-oriented_programming
recursive 5y ago
What animated example? You mean the youtube video? I didn't see anything compelling in it over CSS. Stuff like "You can now style print media!". The only reason you wouldn't have been able to is because you were using tailwind. This new release is probably an improvement over tailwind v2, but I don't see any improvements over CSS. It's true that I haven't tried it. And I probably wouldn't, at least until someone can formulate at least a hypothetical advantage.
- cercatrova 5y ago
  > animated example in the front page Not the blog post, the main landing page, ie https://tailwindcss.com/ https://tailwindcss.com/
- arcdigital 5y ago
  I don't think there's a youtube video embedded anywhere on the homepage, the animation under the get started button is not a video.
  - recursive 5y ago
    With the new understanding that the linked page is not "the homepage", I can see that now. However, there's definitely a very prominent youtube video on the linked page. https://tailwindcss.com/blog/tailwindcss-v3 https://tailwindcss.com/blog/tailwindcss-v3 That's the one I was talking about.
deleted 5y ago
[deleted]
LouisSayers 5y ago
Hmmm... as a non-tailwind user I just took a look. Maybe this shows my age, but it kinda looks like an extension of - you know, that stuff that we moved away from a long time ago... Isn't this losing the point of CSS - that our "content is separate from its styling"? I know I know, we often have to adapt our HTML to allow the styling to work properly, but this is only really true for layouts, not for colors / padding / margin / fonts etc. I understand that we now have people writing React apps and componentising everything, but if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change next time a designer decides to give your webapp a makeover?
- topspin 5y ago
 > if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change If, instead, you litter your code with my-brilliant-semantic-class you create a different kind of problem. Requirements change and my-brilliant-semantic-class won't be sufficient. Now the choice is; alter my-brilliant-semantic-class and suffer all of the unintended side effects or abandon reuse and make another-brilliant-semantic-class. The likely choice is the latter and so applications become masses of ad-hoc, partially finished, inherently flawed styling abstractions scattered hither and yon among directories full of redundant styling artifacts, half of it long dead. How is that a benefit to some future re-designer? > next time a designer decides to give your webapp a makeover? I figure the odds of one approach vs the other being the greatest benefit to some future re-designer are about even, and my guess is as good as yours.
 - 1_player 5y ago
 One underrated problem with semantic naming and classic CSS is having to repeatedly do one of the two hardest problems in computing, that is naming things, 5 times per minute while you're trying to be creative. You constantly have to context switch between "design/creativity" and "logic/pragmatism" mental modes. It's awful, exhausting and doesn't enable any state of flow. The productivity loss is enormous.

zodiakzz 5y ago

If you have a hammer... I am able to iterate orders of magnitude faster in Adobe Photoshop. Back and forth feedback with the customer and then the end result gets coded in non-spaghetti reusable, themeable HTML/CSS. Seems you're iterating at the wrong phase.

crate_barre 5y ago
Depends. I’ve never used Tailwind, so I’ll entertain your aside. If you are mostly doing flat design, truthfully you should be designing in HTML/CSS/JS. This is a failure of setting expectations for designers. If you can get developers to learn Leetcode, get designers to code their designs. Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms. You will not iterate faster than what I am suggesting. Edit: The reason why we are here, why something like Tailwind and MUI exist, is mostly because we need an abstraction layer to do what a designer does on a whim. You can flick a shadow on and off on a Photoshop layer and mess with the subtlety of a drop shadow with a slider. If a designer makes a fickle change, the developer needs this abstraction to make the fickle change as fickle as the thought that made it. That’s why you have all these quick utility methods. The designer is one layer (no pun intended) removed. In 2021 (2022 really), it’s shocking the amount of latitude we give designers to still not be able to do CSS. A half competent designer could have a modest style sheet that mostly captures their design instincts, yet here we are, unable to capture their whims and must now have an albatross utility library to have manual laborers capture the translation - all because … they still won’t learn basic shit. And for what ultimately? These aren’t baroque art pieces, it is ultimately boxes with an aesthetic applied, all very describable with semantic HTML and CSS. But alas, our brilliant artists can’t be bothered. Here, send me your masterpiece so I can transform it for you. Take the bootcamp on web dev. You are literally the people I want going there. Not the Classics major that needs money because they picked a stupid major. It’s you guys that need it, and deserve it.
- handrous 5y ago
  > Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms. This is why all but the very best flat designs (which does not always correlate positively with the size or reputation of the firm turning them out—looking at you, Google) look to me like something I'd have turned out for a quick feature demo circa '05, with everyone at the table agreeing that, however nice the feature, a designer definitely needed to take a pass at it before it was released.
- robertoandred 5y ago
  Nah, don’t need designers passing along broken, useless CSS that has to be redone anyway. Let designers focus on designing, developers on developing.
  - crate_barre 5y ago
    Lol, bro, making their typography and layout changes is not really development. I’d much rather they just pick that up already.
Griffinsauce 5y ago
> non-spaghetti reusable, themeable HTML/CSS The words of an open mind. Each of those adjectives are very open to disagreement.
- zodiakzz 5y ago
  Perhaps. But hard coded colors, hard coded layout (flexbox etc), hard coded margins, paddings hard coded everything right in the markup. Tailwind and those adjectives are mutually exclusive. Does nobody remember themeing forums software like vbulletin? Designers weren't allowed to touch the markup in the slightest and yet so many amazing themes were made. Why? Styling wasn't hard-coded in the markup. Hell, remember the insanely customized old.reddit subreddits?
  - jf22 5y ago
    We should be comparing Tailwind to modern alternatives, not vBulletin CSS from 2004. FYI I'm a recent Tailwind convert so I agree that Tailwind is good, but your comment is like saying Tesla cars are great because they aren't horses.
    - zodiakzz 5y ago
      Whoosh. Well I prefer my "modern" alternatives to be superior than the legacy ones, not the other way around.
  - jagger27 5y ago
    All of the things you mention, including colours, are configurable or at least overridable at compile time. It's just not swapping a CSS file like the good ol' days. I won't argue if one is better than the other.

KarlKemp 5y ago

Nobody said that it’s a bad experience to use. People say that it’s evil. And, also, that it is made by and for the JS crowd that doesn’t understand CSS nor the document hierarchy it depends on, while simultaneously considering it unworthy of any learning efforts since it’s a girly making-it-pretty addition to a markup language, not a real professional STEM-grad-grade programming language.

handrous 5y ago
As much fondness as I have for the pure separation-of-concerns CSS Zen Garden style, I have to admit I've yet to actually see it leveraged on a real project. In 20 years of working on the Web. I'm not sure I've ever seen a significant re-working of CSS to re-theme a site without also changing the markup substantially. In practice, maybe coupling the two doesn't actually do much harm, provided consistency of approach is maintained and it doesn't go quite as far as inlining CSS all over the place.
lghh 5y ago
Why do you have the exact same tone and wording as this comment from a different user above? https://news.ycombinator.com/item?id=29502044 https://news.ycombinator.com/item?id=29502044

lijogdfljk 5y ago

Any thoughts as to how Tailwind can handle dynamic plugins using Tailwind? Ie it seems Tailwind relies on tree shaking to produce sanely sized CSS. But if you have plugins which rely on Tailwind, you'd have to either ship the full sized Tailwind CSS or they'd have to duplicate CSS and ship with it. So far with this plugin/extension design i've not found a way to use Tailwind and also retain nicely sized CSS.

aniforprez 5y ago
> it seems Tailwind relies on tree shaking to produce sanely sized CSS This 3.0 release has its biggest feature be JIT. If you read the linked blog post, CSS is no longer purged but generated dynamically by reading your source files and generating the TW classes you use. It's not tree shooken anymore
- lijogdfljk 5y ago
  Appreciate the info! I'll have to figure out how the hell this works though lol, i watched the video and am still a bit perplexed, since i'm not using JavaScript. I'll be curious to see how i can hook into it
  - hbn 5y ago
    As far as I understand, the build system just scans for whatever Tailwind class names you use, and then generates them into CSS. Which is why you can't dynamically compose Tailwind class names and insert them into your markup, cause it wouldn't be picked up. Whether or not you're using Javascript doesn't matter (I guess unless you use the new CDN script which I haven't tried), but it does need to be run in a build system.
    - lijogdfljk 5y ago
      If it just uses regex over source material i guess it would be fine, though seems like it might hit a fair number of false positives if it's too loose. Too rigid and it might not work if you don't write your css vars in something that looks html-like. Will be interesting!

lhorie 5y ago

Some technical thoughts as someone who could care less about fanboyism: - One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes. - Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive. - Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways. - You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development. - Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while). - There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[1] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows. The main theme to be aware of: proponents of atomic CSS rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[2] vs hyperlocal development workflows interact with your organization's design culture. [0] https://en.wikipedia.org/wiki/APL_(programming_language) https://en.wikipedia.org/wiki/APL_(programming_language) [1] https://www.styletron.org/ https://www.styletron.org/ [2] https://en.wikipedia.org/wiki/Aspect-oriented_programming https://en.wikipedia.org/wiki/Aspect-oriented_programming

recursive 5y ago

What animated example? You mean the youtube video? I didn't see anything compelling in it over CSS. Stuff like "You can now style print media!". The only reason you wouldn't have been able to is because you were using tailwind. This new release is probably an improvement over tailwind v2, but I don't see any improvements over CSS. It's true that I haven't tried it. And I probably wouldn't, at least until someone can formulate at least a hypothetical advantage.

cercatrova 5y ago
> animated example in the front page Not the blog post, the main landing page, ie https://tailwindcss.com/ https://tailwindcss.com/
arcdigital 5y ago
I don't think there's a youtube video embedded anywhere on the homepage, the animation under the get started button is not a video.
- recursive 5y ago
  With the new understanding that the linked page is not "the homepage", I can see that now. However, there's definitely a very prominent youtube video on the linked page. https://tailwindcss.com/blog/tailwindcss-v3 https://tailwindcss.com/blog/tailwindcss-v3 That's the one I was talking about.

deleted 5y ago

[deleted]

LouisSayers 5y ago

Hmmm... as a non-tailwind user I just took a look. Maybe this shows my age, but it kinda looks like an extension of - you know, that stuff that we moved away from a long time ago... Isn't this losing the point of CSS - that our "content is separate from its styling"? I know I know, we often have to adapt our HTML to allow the styling to work properly, but this is only really true for layouts, not for colors / padding / margin / fonts etc. I understand that we now have people writing React apps and componentising everything, but if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change next time a designer decides to give your webapp a makeover?

topspin 5y ago
> if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change If, instead, you litter your code with my-brilliant-semantic-class you create a different kind of problem. Requirements change and my-brilliant-semantic-class won't be sufficient. Now the choice is; alter my-brilliant-semantic-class and suffer all of the unintended side effects or abandon reuse and make another-brilliant-semantic-class. The likely choice is the latter and so applications become masses of ad-hoc, partially finished, inherently flawed styling abstractions scattered hither and yon among directories full of redundant styling artifacts, half of it long dead. How is that a benefit to some future re-designer? > next time a designer decides to give your webapp a makeover? I figure the odds of one approach vs the other being the greatest benefit to some future re-designer are about even, and my guess is as good as yours.
- 1_player 5y ago
  One underrated problem with semantic naming and classic CSS is having to repeatedly do one of the two hardest problems in computing, that is naming things, 5 times per minute while you're trying to be creative. You constantly have to context switch between "design/creativity" and "logic/pragmatism" mental modes. It's awful, exhausting and doesn't enable any state of flow. The productivity loss is enormous.