5 ms·

A bit of light in the dark ages of Tailwind and CSS-in-JS. It's difficult to realize how significant CSS Zen Garden was 20 years ago or so.

by pier25 2y ago

memonkey 2y ago
They published a book that I purchased when I was first learning CSS. Truly a different era.
spiderfarmer 2y ago
It made me fall in love CSS for sure. But it didn’t prevent me from understanding the appeal of Tailwind for large scale projects.
- nuw 2y ago
  Please enlighten me of the benefits of using tailwind in large projects as opposed to using inline styles.
  - ookblah 2y ago
    mobile selectors, "group" selectors, hover styles... the list goes on and on. like all things, it depends on how your workflow. if you have a super defined hierarchy and naming scheme you can reference then sure, centralize all your CSS. if you have many components and multiple people working on them sometimes it's better to separate everything out and enforce with a guide. i can't tell you how frustrating it is to open a component and have no idea what you're looking at because you worked on the thing months ago, or you change one thing in your centralized CSS and have no idea what the side effect are. with tailwind i can see exactly the styles i'm looking for. FOR ME, works better to have a core style file and then move everything to something like tailwind per component for maintenance. tired of seeing the same simplistic arguments against utility frameworks. if you can't see the merits of it then you obviously aren't working on projects that need that, but don't criticize it blindly. it's not for lack of CSS knowledge.
    - deleted 2y ago
      [deleted]
    - zelphirkalt 2y ago
      The thing is, when you are doing CSS properly, you will "anchor" your selectors appropriately. What I mean is the following: Ltes say you got some "component" or whatever you want to call it, and have a button in it, that is special in some way. Of course you are not gonna write "button a {someproperty: specialvalue}". You should be writing the selector as specific for that component in this case, for example "my-special-component button a {...}". If the design is implemented thoughtfully, then most of the problems people claim to have with CSS are simply non-existent. Like "side-effect" you mention. That can only happen, if the design is implemented reusing parts of other design definitions, where they are not meant to be reused. Any other side effect would be intentional. For example button text color and paragraph text color. If one wants them both to change, when one of them is changed, then one reuses the style definition, but probably in most cases one does not, and therefore has separate definitions and therefore has no silly side effects, even after a few months not looking at the project.
      - ookblah 2y ago
        yeah i'm just tired of making the same argument over and over. for what it's worth i've been doing CSS "properly" since the time when that site was a thing. back in the backbone days, now vue/react and before tailwind this is EXACTLY what we did, scope the styles down to the component, then layer it on top of the global styles. so sure, .my-selector a is specific to that component. the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions. so with that out of the way, let's say you do get your global styles like 90% of the way there. so in each component you scoped it down. now lets say for one button you had to adjust the margin a bit, or another the styling is somewhat diff. multiply this by 100s of different components. tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component. at some point you can't possibly create the number variations you need and you can't extract out "reusable" parts. maybe you have 5 buttons and only 2 need the 20px margin. do you create a "button 20px" class and do that in each component? no. at some point you will just inline it because it's easy, or you will create your utility class except it will be worse than tailwind.
  - parrit 2y ago
    Even on one element you can combine tailwind classes. With styles you need to write out the final result. Then you can also use @apply if you wish but leave that out of the argument as it is considered unidiomatic. Of course if using React you can also use styles directly and then create your own utilities to determine how they compose. Which might give you much of the Tailwind edge without needing the compile step.
    - zelphirkalt 2y ago
      Even on one element you can combine CSS classes. Easily.
  - halflife 2y ago
    Configuration. Inline styles are direct style Implementations in your html, tailwind is an abstraction that lets your configure and refactor easily. I can say from experience, being in charge of developing a large product that was bought and merged into a larger corporation, using tailwind from the start allowed us a refactor our app’s design within 1 day instead of it being several weeks worth of work. And as a bonus it provides best practices in css scaffolding of a product design (typography, grid, colors)
    - croes 2y ago
      So how does that work exactly? For instance now I have class some-button to make the button blue. Next week I‘m told make them yellow. It’s a change in one class What would be the equivalent in Tailwind?
      - K0nserv 2y ago
        You use components, e.g. react, and replace the `bg-blue-500` class with `bg-yellow-500` in your button component.
        moron4hire 2y ago
        HTML already has a button component. How is this better than creating a root CSS style for buttons using CSS variables to abstract the colors?
        K0nserv 2y ago
        For this contrived example it isn't better. I was very sceptical of tailwind before I tried it, but in certain scenarios it's nice. I think it shines if you are already using a component focused development process. As others have said you don't need to come up with class names for every thing you want to style. Rather than cross-reference between js/html files and css files everything (structure, style, and interactivity) is in one place. You also don't need to care about specificity. Personally I think it gets a bit mad when you start wanting to do :hover, :active and media queries, but you can still use classes (using the @apply directive) for that if you wish.
  - 9dev 2y ago
    Not having to name a myriad of things! Sure, things like BEM can help you at least avoid naming conflicts, but you still have to decide a few thousand times what something is called semantically correct, in a way that you and your French colleagues and the intern of next year are going to understand it. When I got productive with Tailscale, I finally realised how many brain cycles I wasted on this. I’m, like, a programmer; of course I’ll obsess over picking the perfect name. Of course I will not be happy with the names my junior picked, and of course I will constantly be unhappy with some of them. This game of self-inflicted bike shedding is just a trap for people that like logic and order, and it’s… wholly irrelevant. With tailwind, you just declare how something is supposed to look and feel like, at the place where it is, in the context of your configurable design system. No names, no bike shedding. Okay, that’s not a hundred percent true; you can name group selectors, because as opposed to plain inline styles, Tailwind can target children, siblings, pseudo elements—there are no restrictions. It’s a truly elegant solution for authoring web pages.
    - ardleon 2y ago
      Using webcomponents there is no problem with identifiers, you can repeat the same identifier as many times as you need.
    - the_other 2y ago
      Do you treat your JS and TS the same way, eschewing semantic clarity?
      - troupo 2y ago
        Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.
        skydhash 2y ago
        So you can name a component, but you cannot name the styles attached to that component?
  - spiderfarmer 2y ago
    Tailwind makes things like dark mode and group hover/focus states dead simple with modifiers (dark:, group-hover:), keeping all your logic in your HTML. With inline CSS, you’d need messy JS, extra classes, or bloated style tags to handle the same. It also enforces a design system (spacing, colors, fonts), while inline CSS often leads to small, inconsistent differences everywhere. It’s a great solution to a problem a lot of people were having. That’s why it’s so popular.
  - Sateeshm 2y ago
    media and container queries. Pseudo selectors
paavohtl 2y ago
CSS-in-JS (like how Styled Components and Emotion do it) is primarily a solution to code organization. It doesn't fundamentally change how CSS works.
- pier25 2y ago
  But it's a performance killer https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-4g9b https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-... Edit: See also this thread on Bluesky https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7 https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7
  - MrJohz 2y ago
    It can be, depending on how it's used. But most of the modern tools I've seen are specifically designed to compile away the dynamic aspects of CSS-in-JS, meaning it essentially becomes a different way of writing normal CSS.

A bit of light in the dark ages of Tailwind and CSS-in-JS. It's difficult to realize how significant CSS Zen Garden was 20 years ago or so.

by pier25 2y ago

A bit of light in the dark ages of Tailwind and CSS-in-JS. It's difficult to realize how significant CSS Zen Garden was 20 years ago or so.

memonkey 2y ago

They published a book that I purchased when I was first learning CSS. Truly a different era.

spiderfarmer 2y ago

It made me fall in love CSS for sure. But it didn’t prevent me from understanding the appeal of Tailwind for large scale projects.

nuw 2y ago
Please enlighten me of the benefits of using tailwind in large projects as opposed to using inline styles.
- ookblah 2y ago
  mobile selectors, "group" selectors, hover styles... the list goes on and on. like all things, it depends on how your workflow. if you have a super defined hierarchy and naming scheme you can reference then sure, centralize all your CSS. if you have many components and multiple people working on them sometimes it's better to separate everything out and enforce with a guide. i can't tell you how frustrating it is to open a component and have no idea what you're looking at because you worked on the thing months ago, or you change one thing in your centralized CSS and have no idea what the side effect are. with tailwind i can see exactly the styles i'm looking for. FOR ME, works better to have a core style file and then move everything to something like tailwind per component for maintenance. tired of seeing the same simplistic arguments against utility frameworks. if you can't see the merits of it then you obviously aren't working on projects that need that, but don't criticize it blindly. it's not for lack of CSS knowledge.
  - deleted 2y ago
    [deleted]
  - zelphirkalt 2y ago
    The thing is, when you are doing CSS properly, you will "anchor" your selectors appropriately. What I mean is the following: Ltes say you got some "component" or whatever you want to call it, and have a button in it, that is special in some way. Of course you are not gonna write "button a {someproperty: specialvalue}". You should be writing the selector as specific for that component in this case, for example "my-special-component button a {...}". If the design is implemented thoughtfully, then most of the problems people claim to have with CSS are simply non-existent. Like "side-effect" you mention. That can only happen, if the design is implemented reusing parts of other design definitions, where they are not meant to be reused. Any other side effect would be intentional. For example button text color and paragraph text color. If one wants them both to change, when one of them is changed, then one reuses the style definition, but probably in most cases one does not, and therefore has separate definitions and therefore has no silly side effects, even after a few months not looking at the project.
    - ookblah 2y ago
      yeah i'm just tired of making the same argument over and over. for what it's worth i've been doing CSS "properly" since the time when that site was a thing. back in the backbone days, now vue/react and before tailwind this is EXACTLY what we did, scope the styles down to the component, then layer it on top of the global styles. so sure, .my-selector a is specific to that component. the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions. so with that out of the way, let's say you do get your global styles like 90% of the way there. so in each component you scoped it down. now lets say for one button you had to adjust the margin a bit, or another the styling is somewhat diff. multiply this by 100s of different components. tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component. at some point you can't possibly create the number variations you need and you can't extract out "reusable" parts. maybe you have 5 buttons and only 2 need the 20px margin. do you create a "button 20px" class and do that in each component? no. at some point you will just inline it because it's easy, or you will create your utility class except it will be worse than tailwind.
- parrit 2y ago
  Even on one element you can combine tailwind classes. With styles you need to write out the final result. Then you can also use @apply if you wish but leave that out of the argument as it is considered unidiomatic. Of course if using React you can also use styles directly and then create your own utilities to determine how they compose. Which might give you much of the Tailwind edge without needing the compile step.
  - zelphirkalt 2y ago
    Even on one element you can combine CSS classes. Easily.
- halflife 2y ago
  Configuration. Inline styles are direct style Implementations in your html, tailwind is an abstraction that lets your configure and refactor easily. I can say from experience, being in charge of developing a large product that was bought and merged into a larger corporation, using tailwind from the start allowed us a refactor our app’s design within 1 day instead of it being several weeks worth of work. And as a bonus it provides best practices in css scaffolding of a product design (typography, grid, colors)
  - croes 2y ago
    So how does that work exactly? For instance now I have class some-button to make the button blue. Next week I‘m told make them yellow. It’s a change in one class What would be the equivalent in Tailwind?
    - K0nserv 2y ago
      You use components, e.g. react, and replace the `bg-blue-500` class with `bg-yellow-500` in your button component.
      - moron4hire 2y ago
        HTML already has a button component. How is this better than creating a root CSS style for buttons using CSS variables to abstract the colors?
        K0nserv 2y ago
        For this contrived example it isn't better. I was very sceptical of tailwind before I tried it, but in certain scenarios it's nice. I think it shines if you are already using a component focused development process. As others have said you don't need to come up with class names for every thing you want to style. Rather than cross-reference between js/html files and css files everything (structure, style, and interactivity) is in one place. You also don't need to care about specificity. Personally I think it gets a bit mad when you start wanting to do :hover, :active and media queries, but you can still use classes (using the @apply directive) for that if you wish.
- 9dev 2y ago
  Not having to name a myriad of things! Sure, things like BEM can help you at least avoid naming conflicts, but you still have to decide a few thousand times what something is called semantically correct, in a way that you and your French colleagues and the intern of next year are going to understand it. When I got productive with Tailscale, I finally realised how many brain cycles I wasted on this. I’m, like, a programmer; of course I’ll obsess over picking the perfect name. Of course I will not be happy with the names my junior picked, and of course I will constantly be unhappy with some of them. This game of self-inflicted bike shedding is just a trap for people that like logic and order, and it’s… wholly irrelevant. With tailwind, you just declare how something is supposed to look and feel like, at the place where it is, in the context of your configurable design system. No names, no bike shedding. Okay, that’s not a hundred percent true; you can name group selectors, because as opposed to plain inline styles, Tailwind can target children, siblings, pseudo elements—there are no restrictions. It’s a truly elegant solution for authoring web pages.
  - ardleon 2y ago
    Using webcomponents there is no problem with identifiers, you can repeat the same identifier as many times as you need.
  - the_other 2y ago
    Do you treat your JS and TS the same way, eschewing semantic clarity?
    - troupo 2y ago
      Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.
      - skydhash 2y ago
        So you can name a component, but you cannot name the styles attached to that component?
- spiderfarmer 2y ago
  Tailwind makes things like dark mode and group hover/focus states dead simple with modifiers (dark:, group-hover:), keeping all your logic in your HTML. With inline CSS, you’d need messy JS, extra classes, or bloated style tags to handle the same. It also enforces a design system (spacing, colors, fonts), while inline CSS often leads to small, inconsistent differences everywhere. It’s a great solution to a problem a lot of people were having. That’s why it’s so popular.
- Sateeshm 2y ago
  media and container queries. Pseudo selectors

paavohtl 2y ago

CSS-in-JS (like how Styled Components and Emotion do it) is primarily a solution to code organization. It doesn't fundamentally change how CSS works.

pier25 2y ago
But it's a performance killer https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-4g9b https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-... Edit: See also this thread on Bluesky https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7 https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7
- MrJohz 2y ago
  It can be, depending on how it's used. But most of the modern tools I've seen are specifically designed to compile away the dynamic aspects of CSS-in-JS, meaning it essentially becomes a different way of writing normal CSS.