4 ms·

Or make a Button component in your framework of choice. function Button = ({ children }) => <button className={80 tailwind classes here}>{children}</button

Or make a Button component in your framework of choice. function Button = ({ children }) => <button className={80 tailwind classes here}>{children}</button> <Button>Create</Button> <Button>Edit</Button> // Same style <Button>Delete</Button> // Same style

JasonCannon 5y ago
Even then, I would still recommend using the postcss extend tag. Much easier to read that way. Also, postcss doesn't require any frameworks, you can still do everything with plain ol' html and javascript.
montroser 5y ago
No, we don't want all of the buttons to look identical. Some are big and some are small; some are bold and primary and some are muted and secondary; some have icons; some have shadows; some are disabled, etc, etc. It's easy to make them identical. The challenge is to be as flexible as necessary in a mature application, while minimizing verbosity and complexity. In my experience Tailwind hurts more than it helps here. It forces you to use your component system to abstract things which otherwise wouldn't warrant the extra level of indirection.
- reactor 5y ago
  How would you have done it without TailWind? You'd still have to create classes for each of them in plain css anyway, except it would probably be in a different .css file. The inherent complexity pertaining to your app is not taken away, it just moved the places.
  - montroser 5y ago
    My point is that plain CSS is already good at this. So then you don't need to make more components with their own interface to learn. <button class="btn large shadow">Edit</button> .btn { ...default button styles } .btn.large { font-size: larger; } .btn.shadow { box-shadow: 0 0 8px #0004; }
    - iovrthoughtthis 5y ago
      but now to understand what a single class might do to an elements style i have to check for ever possible combination .e.g .btn.large {} .field.large {} .fieldgroup.large {} .title.large {} .link.large {} .large {} to find all the elements that the .field.large declaration impacts we need to enumerate all the elements that have both .field and .large in any order. we've coupled out html and css files
- Adrig 5y ago
  You should look more into design systems. It's not only for Figma files but can structure your whole frontend. To extend on the example above, you can do something like : <Button variation="primary" size="large">Primary Button</Button> <Button variation="secondary" size="medium">Medium</Button> <Button variation="tertiary" size="small">Small</Button>
- jbergens 5y ago
  If you a 100 different types of buttons I can see your problem, if it is more like 5 then you just create them first and then makes the code more DRY. For example when using React you can create 5 button components first and the refactor your code to make the 5 buttons use/call a generic button. Or have 2 generic buttons if the combinations are hard to handle. The thing with atomic CSS like Tailwind is that it very easy to quickly create a few different buttons.

JasonCannon 5y ago

Even then, I would still recommend using the postcss extend tag. Much easier to read that way. Also, postcss doesn't require any frameworks, you can still do everything with plain ol' html and javascript.

montroser 5y ago

No, we don't want all of the buttons to look identical. Some are big and some are small; some are bold and primary and some are muted and secondary; some have icons; some have shadows; some are disabled, etc, etc. It's easy to make them identical. The challenge is to be as flexible as necessary in a mature application, while minimizing verbosity and complexity. In my experience Tailwind hurts more than it helps here. It forces you to use your component system to abstract things which otherwise wouldn't warrant the extra level of indirection.

reactor 5y ago
How would you have done it without TailWind? You'd still have to create classes for each of them in plain css anyway, except it would probably be in a different .css file. The inherent complexity pertaining to your app is not taken away, it just moved the places.
- montroser 5y ago
  My point is that plain CSS is already good at this. So then you don't need to make more components with their own interface to learn. <button class="btn large shadow">Edit</button> .btn { ...default button styles } .btn.large { font-size: larger; } .btn.shadow { box-shadow: 0 0 8px #0004; }
  - iovrthoughtthis 5y ago
    but now to understand what a single class might do to an elements style i have to check for ever possible combination .e.g .btn.large {} .field.large {} .fieldgroup.large {} .title.large {} .link.large {} .large {} to find all the elements that the .field.large declaration impacts we need to enumerate all the elements that have both .field and .large in any order. we've coupled out html and css files
Adrig 5y ago
You should look more into design systems. It's not only for Figma files but can structure your whole frontend. To extend on the example above, you can do something like : <Button variation="primary" size="large">Primary Button</Button> <Button variation="secondary" size="medium">Medium</Button> <Button variation="tertiary" size="small">Small</Button>
jbergens 5y ago
If you a 100 different types of buttons I can see your problem, if it is more like 5 then you just create them first and then makes the code more DRY. For example when using React you can create 5 button components first and the refactor your code to make the 5 buttons use/call a generic button. Or have 2 generic buttons if the combinations are hard to handle. The thing with atomic CSS like Tailwind is that it very easy to quickly create a few different buttons.