I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
I believe due to the way components are defined. Take a simple Vue SFC. There still is a separation of concerns between script, template and style. + they're meant to be reusable, almost like CSS classes are. So much for the theory.
It gets interesting when you try and reuse spacing, colors or even shadows over several components. The moment Tailwind's promise breaks is when I need the same color for, say a navbar AND a button component. Even worse, you probably have those util classes scattered over your whole codebase.
What if the client changes their mind? I want red instead of purple. You'll refactor the all components that use this coloring. Now you might say 'this can be done with a regex replace-statement'. At this very point, the circle closes if you directly applied Tailwind to the component instead of using dedicated classes.
I believe due to the way components are defined. Take a simple Vue SFC. There still is a separation of concerns between
script,templateandstyle. + they're meant to be reusable, almost like CSS classes are. So much for the theory.It gets interesting when you try and reuse spacing, colors or even shadows over several components. The moment Tailwind's promise breaks is when I need the same color for, say a navbar AND a button component. Even worse, you probably have those util classes scattered over your whole codebase.
What if the client changes their mind? I want red instead of purple. You'll refactor the all components that use this coloring. Now you might say 'this can be done with a regex replace-statement'. At this very point, the circle closes if you directly applied Tailwind to the component instead of using dedicated classes.
Oh my God, I hadn't even thought of refactoring or redesigns with Tailwind.
That actually caused a legit stress response in me. 😖