3 ms·

You claim that you can only move faster with Tailwind when one of these is true: when you don't care about 'badly structured' CSS, or when you are completely ne

by cal85 3y ago

You claim that you can only move faster with Tailwind when one of these is true: when you don't care about 'badly structured' CSS, or when you are completely new to CSS, or when you don't care about reusable modules. I care very much about the structure of the CSS files I generate with Tailwind. I have been writing CSS for over 20 years. And I care very much about reusable modules – before good composable component systems came along, CSS classes were the best solution for this, but not any more imo. And I can certainly move faster with Tailwind in most situations. Sorry for the negativity btw, I don't want to discourage people posting about their experiences with a tool. I just doubt you have really given Tailwind a fair trial. You're obviously a seasoned front ender who understands CSS deeply, but I don't believe you have understood Tailwind properly before coming to your conclusions about it.

tipiirai 3y ago
Copy/pasting directly from the article, because you have reworded my claims. Here's what I mean exactly: ---- You can move faster with Tailwind. But only when: 1. You are comparing Tailwind with your earlier, badly structured CSS or you are completely new to CSS development. 2. You don’t care about building reusable modules for later use. That is: you are not naming things that repeat. ----
- cal85 3y ago
  Sorry, I can't see any meaningful difference in my rewording. Could you clarify?
  - tipiirai 3y ago
    Saying this: > when you don't care about 'badly structured' CSS Is a completely different claim than this: > You are comparing Tailwind with your earlier, badly structured CSS I'm sure we both care about CSS structure. My claim talks about developers' past experiences. If you enjoy semantic CSS, you probably won't switch to (unsemantic) Tailwind. And vice versa: if you never mastered semantic CSS (even hated it), you are more eager to switch and find the new way more enjoyable.
    - cal85 3y ago
      OK, I'm not sure how that affects my point. The point is, I'm living proof you are wrong on this particular claim. Tailwind makes me faster, and it's not for any of the reasons you said could be the only reasons. The more general issue is your article doesn't demonstrate that you have grasped the purported benefits of Tailwind. You just deny they exist. It would be fine if you showed that you understand the purported benefits before explaining why you still prefer handwritten CSS on balance. In particular, I can tell you don't understand that no longer using CSS classnames for reusability (and instead extracting components for reusability) is exactly what Tailwind users love about it, and no, not because they "haven't mastered semantic CSS". I know from experience that is initially unintuitive to a long-time CSS author, because I had a kind of Stockholm Syndrome for naming everything semantically and keeping my DOM super clean and avoiding extra divs. With Tailwind, you generally only name things when you extract them to components, and it's hard to explain but I after a while I came to realise this is just the perfect moment to name something, leading to better conceptual separation of semantics and styling logic, and much less proliferation of 'things' and ossification of the DOM. I am not arguing Tailwind should be used for everything. I still use hand-written CSS for many things. And it is fine for someone to not like Tailwind after understanding it. I am just saying that you haven't understood it yet. Perhaps you wouldn't like it anyway, but imo it's worth really giving it a try. By the way, giving it a try means on a real project. If I have a one-off, never-to-be-edited-again page design such as the example in your article, then I would probably use handwritten CSS with semantic classnames, as the exercise would be to make the cleanest, most elegant and fast-loading bundle of HTML and CSS possible. But in more realistic component-based projects that are expected to change over time, Tailwind can be an excellent trade-off, sacrificing a tiny (really, tiny) amount of elegance and bandwidth for a lot of engineering flexibility.

by cal85 3y ago

tipiirai 3y ago

Copy/pasting directly from the article, because you have reworded my claims. Here's what I mean exactly: ---- You can move faster with Tailwind. But only when: 1. You are comparing Tailwind with your earlier, badly structured CSS or you are completely new to CSS development. 2. You don’t care about building reusable modules for later use. That is: you are not naming things that repeat. ----

cal85 3y ago
Sorry, I can't see any meaningful difference in my rewording. Could you clarify?
- tipiirai 3y ago
  Saying this: > when you don't care about 'badly structured' CSS Is a completely different claim than this: > You are comparing Tailwind with your earlier, badly structured CSS I'm sure we both care about CSS structure. My claim talks about developers' past experiences. If you enjoy semantic CSS, you probably won't switch to (unsemantic) Tailwind. And vice versa: if you never mastered semantic CSS (even hated it), you are more eager to switch and find the new way more enjoyable.
  - cal85 3y ago
    OK, I'm not sure how that affects my point. The point is, I'm living proof you are wrong on this particular claim. Tailwind makes me faster, and it's not for any of the reasons you said could be the only reasons. The more general issue is your article doesn't demonstrate that you have grasped the purported benefits of Tailwind. You just deny they exist. It would be fine if you showed that you understand the purported benefits before explaining why you still prefer handwritten CSS on balance. In particular, I can tell you don't understand that no longer using CSS classnames for reusability (and instead extracting components for reusability) is exactly what Tailwind users love about it, and no, not because they "haven't mastered semantic CSS". I know from experience that is initially unintuitive to a long-time CSS author, because I had a kind of Stockholm Syndrome for naming everything semantically and keeping my DOM super clean and avoiding extra divs. With Tailwind, you generally only name things when you extract them to components, and it's hard to explain but I after a while I came to realise this is just the perfect moment to name something, leading to better conceptual separation of semantics and styling logic, and much less proliferation of 'things' and ossification of the DOM. I am not arguing Tailwind should be used for everything. I still use hand-written CSS for many things. And it is fine for someone to not like Tailwind after understanding it. I am just saying that you haven't understood it yet. Perhaps you wouldn't like it anyway, but imo it's worth really giving it a try. By the way, giving it a try means on a real project. If I have a one-off, never-to-be-edited-again page design such as the example in your article, then I would probably use handwritten CSS with semantic classnames, as the exercise would be to make the cleanest, most elegant and fast-loading bundle of HTML and CSS possible. But in more realistic component-based projects that are expected to change over time, Tailwind can be an excellent trade-off, sacrificing a tiny (really, tiny) amount of elegance and bandwidth for a lot of engineering flexibility.