11 ms·

Obligatory: Tailwind

gentleman11 2y ago
Explain?
seanwilson 2y ago
I tried to avoid mentioning that, but Tailwind is showcasing how to write CSS using composition from inheritance. But it can't overcome the knee-jerk reaction from many CSS developers that don't see the problems that comes with CSS cascade/inheritance. I think this is mostly because leaning on cascading rules is seen as a best practice and most aren't going to question best practices much.
- Fauntleroy 2y ago
  Tailwind is not a panacea—it has its own problems which withhold adoption, "kneejerk reactions" notwithstanding.
- danielvaughn 2y ago
  I'll never understand why a lot of CSS devs are opposed to it. I can understand the initial gut reaction, but I've been writing CSS for 14 years and I love Tailwind. The cascade is a wonderful idea that has unfortunately not played out well in practice. Anyone who thinks it's just a skill issue is deluding themselves. In all my years, I've never seen CSS that (a) leverages the cascade, and (b) scales elegantly. It all breaks down past a certain point. Tailwind has it's flaws, but it doesn't have the scaling problem.
  - explaininjs 2y ago
    Mainly because nobody is a "CSS Dev". If someone's entire job was developing CSS, you might expect that they would be willing to learn one new slightly different way of doing it. But in reality the pushback comes from full stack developers who already have a million other things to worry about, such that relearning all the basic CSS they already know, to achieve benefits that are rather minuscule in the grand scheme of things, is a low priority. I personally am working on a Tailwind product that is fairly small (~10k lines, perhaps), and the Tailwind isn't an annoyance per-say, but it's definitely less ergonomically friendly than the well-engineered enterprise application I was working on before, which was 100x the size and used exclusively pure CSS. Personally, my dream would be if inline styles supported the full CSS gamut of pseudo selectors and the child element selector. Then you'd have the admitted benefits of not needing to synchronize the two files, along with the benefit of not needing to relearn all of CSS. Edit: it's funny, in a way, that all these developers complaining about how CSS "doesn't scale" are likely writing their Tailwind in an large scale application styled entirely via CSS. https://github.com/search?q=repo%3Amicrosoft%2Fvscode++language%3ACSS&type=code https://github.com/search?q=repo%3Amicrosoft%2Fvscode++langu...
    - danielvaughn 2y ago
      On the contrary, Tailwind's ergonomics are what attract me to it. With the autocomplete features via the VSCode intellisense plugin, I'm able to create UIs at a pretty extraordinary pace. As a trivial example, let's imagine we need to apply a border radius to an element. Without Tailwind, it looks like this: 1. I find the element I need to style 2. I look at which class it's using 3. I navigate to my CSS file 4. I scroll down until I find the selector 5. I type "border-r", then tab on the auto-complete to fill in "border-radius" 6. I type the colon character, then space 7. I think about what unit is appropriate - rems, ems, pixels, percentage 8. I think about what value is needed for the design 9. I also look around to see if this style is used elsewhere 10. If the style is used elsewhere, I think about whether I need to refactor 11. I type in the desired value 12. I type a semicolon to mark the end of the statement 13. I type cmd+s to save the css file Here's the same example, with Tailwind: 1. I find the element I need to style 2. I type `round` and wait for the autocomplete to present my options 3. I use my arrow key to select which one I want 4. I type enter to add the desired tailwind class 5. I type cmd+s to save the html file The Tailwind interaction path takes less than half of the concrete steps to complete. But it's even more dramatic than that, because several of the steps taken in the first example require enough thought that it breaks your workflow and takes you out of your flow state. Then you have to get back into that flow state to keep working. But this keeps happening, so you're constantly stopping and restarting. With Tailwind, I tend to find myself staying in that flow state, because as I demonstrated above, there's very little getting in my way.
      - seanwilson 2y ago
        Fully agree with this. The regular arguments against Tailwind like "it's just inline styles", "learn CSS properly", "it looks ugly" and "normal CSS is easy" say nothing about how fast the Tailwind approach lets you make edits and stay focused in comparison. Normal CSS is usually worse than this too e.g. you hit save, and your edit doesn't change anything, so you have to use the web inspector to hunt down which class is overriding your style then weigh up options for how you're going to refactor while jumping between multiple files. It's exhausting when you're trying to focus on styling.

Explain?

I tried to avoid mentioning that, but Tailwind is showcasing how to write CSS using composition from inheritance. But it can't overcome the knee-jerk reaction from many CSS developers that don't see the problems that comes with CSS cascade/inheritance. I think this is mostly because leaning on cascading rules is seen as a best practice and most aren't going to question best practices much.

Fauntleroy 2y ago
Tailwind is not a panacea—it has its own problems which withhold adoption, "kneejerk reactions" notwithstanding.
danielvaughn 2y ago
I'll never understand why a lot of CSS devs are opposed to it. I can understand the initial gut reaction, but I've been writing CSS for 14 years and I love Tailwind. The cascade is a wonderful idea that has unfortunately not played out well in practice. Anyone who thinks it's just a skill issue is deluding themselves. In all my years, I've never seen CSS that (a) leverages the cascade, and (b) scales elegantly. It all breaks down past a certain point. Tailwind has it's flaws, but it doesn't have the scaling problem.
- explaininjs 2y ago
  Mainly because nobody is a "CSS Dev". If someone's entire job was developing CSS, you might expect that they would be willing to learn one new slightly different way of doing it. But in reality the pushback comes from full stack developers who already have a million other things to worry about, such that relearning all the basic CSS they already know, to achieve benefits that are rather minuscule in the grand scheme of things, is a low priority. I personally am working on a Tailwind product that is fairly small (~10k lines, perhaps), and the Tailwind isn't an annoyance per-say, but it's definitely less ergonomically friendly than the well-engineered enterprise application I was working on before, which was 100x the size and used exclusively pure CSS. Personally, my dream would be if inline styles supported the full CSS gamut of pseudo selectors and the child element selector. Then you'd have the admitted benefits of not needing to synchronize the two files, along with the benefit of not needing to relearn all of CSS. Edit: it's funny, in a way, that all these developers complaining about how CSS "doesn't scale" are likely writing their Tailwind in an large scale application styled entirely via CSS. https://github.com/search?q=repo%3Amicrosoft%2Fvscode++language%3ACSS&type=code https://github.com/search?q=repo%3Amicrosoft%2Fvscode++langu...
  - danielvaughn 2y ago
    On the contrary, Tailwind's ergonomics are what attract me to it. With the autocomplete features via the VSCode intellisense plugin, I'm able to create UIs at a pretty extraordinary pace. As a trivial example, let's imagine we need to apply a border radius to an element. Without Tailwind, it looks like this: 1. I find the element I need to style 2. I look at which class it's using 3. I navigate to my CSS file 4. I scroll down until I find the selector 5. I type "border-r", then tab on the auto-complete to fill in "border-radius" 6. I type the colon character, then space 7. I think about what unit is appropriate - rems, ems, pixels, percentage 8. I think about what value is needed for the design 9. I also look around to see if this style is used elsewhere 10. If the style is used elsewhere, I think about whether I need to refactor 11. I type in the desired value 12. I type a semicolon to mark the end of the statement 13. I type cmd+s to save the css file Here's the same example, with Tailwind: 1. I find the element I need to style 2. I type `round` and wait for the autocomplete to present my options 3. I use my arrow key to select which one I want 4. I type enter to add the desired tailwind class 5. I type cmd+s to save the html file The Tailwind interaction path takes less than half of the concrete steps to complete. But it's even more dramatic than that, because several of the steps taken in the first example require enough thought that it breaks your workflow and takes you out of your flow state. Then you have to get back into that flow state to keep working. But this keeps happening, so you're constantly stopping and restarting. With Tailwind, I tend to find myself staying in that flow state, because as I demonstrated above, there's very little getting in my way.
    - seanwilson 2y ago
      Fully agree with this. The regular arguments against Tailwind like "it's just inline styles", "learn CSS properly", "it looks ugly" and "normal CSS is easy" say nothing about how fast the Tailwind approach lets you make edits and stay focused in comparison. Normal CSS is usually worse than this too e.g. you hit save, and your edit doesn't change anything, so you have to use the web inspector to hunt down which class is overriding your style then weigh up options for how you're going to refactor while jumping between multiple files. It's exhausting when you're trying to focus on styling.