4 ms·

> It's not like Tailwind is SAP or something. It's just CSS. You shouldn't need to re-work your entire process around it. No, your designers should already be

by rvense 6y ago

> It's not like Tailwind is SAP or something. It's just CSS. You shouldn't need to re-work your entire process around it. No, your designers should already be working to scales for size, colour etc. which you can implement in Tailwind. If they don't, now's a good time to start. > How the hell does that help with consistency? You have to copy paste that mess every time you create a new button You're extremely not supposed to copy-paste that. You're supposed to extract it somehow, either with your Javascript component framework, or by making a semantic class with the @apply directive. https://tailwindcss.com/docs/extracting-components https://tailwindcss.com/docs/extracting-components The difference is that Tailwind allows you do some quick work without coming up with abstractions. So you work bottom up instead of top down. > then guess what happens if the button you copied from needed special margin? That's the beauty of it! You have a button class, and then if your button needs "a little extra" you add the button class and the margin utility. At my previous job, when this situation came up, the normal way was to make a BEM class specific to the location, import the button in that (with a SCSS mix-in) and add the margin. So the HTML would have a class name that was specific to this one button, but you didn't know what it added: class="info-page__navigation__button". With Tailwind, you get 'class="btn mx-2"' and you can basically see what it's going to look like.

pembrook 6y ago
> with your JavaScript component framework If I’m using React components, tailwind makes even less sense. I’ve already separated my button large out as a component, guess what happens in a mature design system? The system gets updated and changed to fit the needs of the product. So what happens when you need to change button large in tailwind? You need to restyle the button with the spaghetti mess (maybe add something to the config), then re-extract the mess into a tailwind component. Now you’ve got components within components just to emulate the abilities CSS has right out of the box. Guess what you could have done? Just had a .btn-lg class in an old school style sheet where you updated to the new font weight and padding and you’re done! There is no need for this layer of complexity and abstraction of CSS. CSS is literally the easiest thing in the entire stack. Why do you want to make it so complicated? Rube Goldberg machines are extremely elegant in their beauty, but they are not the most efficient way to get something done.
- dikaio 6y ago
  In regards to you needing to change your button when the design system needs to change I think you may be thinking about how to apply your current naming conventions or methodology as something like sass for instance what you could do is create the default button component and anything that you think you may need to change about that button you have props with defaults already set this way if you have one button requirements you just include it in the prop of that button, if you need to change all of them then you update the default prop. In other wards instead of doing <button class=“btn-lg><button/> you're doing <Button {...specs}/>.
- z3t4 6y ago
  CSS is difficult. First start with content. Then add semantic markup. Only add classes if you really need to. Try to avoid div and span.
- rvense 6y ago
  I'm guessing you haven't actually used it. It's a fantastic fit for React or similar frameworks. There's honestly nothing spaghetti messy or Goldbergian about it. It's just generating a stylesheet. I absolutely do have a .btn class in my Tailwind projects, that's a given. For consistency, it's built from the utility classes that Tailwind provides, but buttons are kind of a pathological case in many ways, they're really not how you should evaluate a framework. When I put two buttons next to each other, I don't make a new class for one of the to get some spacing, I just slap a "ml-4" on one of them, and that matches all my other spacings. But the real magic is when I'm building up my mid-level components, I don't have to try to come up with names or abstractions for the CSS, I just make things look and work right, and as I notice patterns I can break them out into semantic classes as needed. It's a great way to work and the results have been good for me. In my mind, the real mess is a bunch of poorly named CSS classes that end up being specific to the place where they're used. Specificity battles, 40 character BEM selectors, mismatched margins sizes and randomized colour palettes. Setting up a Tailwind configuration is a very ergonomic way of turning your basic design system into CSS.

by rvense 6y ago

pembrook 6y ago

> with your JavaScript component framework If I’m using React components, tailwind makes even less sense. I’ve already separated my button large out as a component, guess what happens in a mature design system? The system gets updated and changed to fit the needs of the product. So what happens when you need to change button large in tailwind? You need to restyle the button with the spaghetti mess (maybe add something to the config), then re-extract the mess into a tailwind component. Now you’ve got components within components just to emulate the abilities CSS has right out of the box. Guess what you could have done? Just had a .btn-lg class in an old school style sheet where you updated to the new font weight and padding and you’re done! There is no need for this layer of complexity and abstraction of CSS. CSS is literally the easiest thing in the entire stack. Why do you want to make it so complicated? Rube Goldberg machines are extremely elegant in their beauty, but they are not the most efficient way to get something done.

dikaio 6y ago
In regards to you needing to change your button when the design system needs to change I think you may be thinking about how to apply your current naming conventions or methodology as something like sass for instance what you could do is create the default button component and anything that you think you may need to change about that button you have props with defaults already set this way if you have one button requirements you just include it in the prop of that button, if you need to change all of them then you update the default prop. In other wards instead of doing <button class=“btn-lg><button/> you're doing <Button {...specs}/>.
z3t4 6y ago
CSS is difficult. First start with content. Then add semantic markup. Only add classes if you really need to. Try to avoid div and span.
rvense 6y ago
I'm guessing you haven't actually used it. It's a fantastic fit for React or similar frameworks. There's honestly nothing spaghetti messy or Goldbergian about it. It's just generating a stylesheet. I absolutely do have a .btn class in my Tailwind projects, that's a given. For consistency, it's built from the utility classes that Tailwind provides, but buttons are kind of a pathological case in many ways, they're really not how you should evaluate a framework. When I put two buttons next to each other, I don't make a new class for one of the to get some spacing, I just slap a "ml-4" on one of them, and that matches all my other spacings. But the real magic is when I'm building up my mid-level components, I don't have to try to come up with names or abstractions for the CSS, I just make things look and work right, and as I notice patterns I can break them out into semantic classes as needed. It's a great way to work and the results have been good for me. In my mind, the real mess is a bunch of poorly named CSS classes that end up being specific to the place where they're used. Specificity battles, 40 character BEM selectors, mismatched margins sizes and randomized colour palettes. Setting up a Tailwind configuration is a very ergonomic way of turning your basic design system into CSS.