You do end up doing the same but with whatever framework you use, anyway.
If in react/svelte/vue , you'll create components that have their own sets of tailwind styles on the component and then you use the component everywhere.
The only tailwind classes repeated everywhere are the layout ones (margins/display/padding,etc)
All i'm doing is, making it easier to move the components across codebases, I can use the above in a server rendered golang based codebase or a laravel codebase and not have to re-write the design system for every framework I decide to experiment with.
another way to do this is to use web components but I don't see the performance benefit since they won't work on older browsers, hence the above approach.
I've got my own utilities for layouts for react and react native so I don't have to deal with tailwind classes and inline styles separately in both codebases, that's one case where I don't mind getting locked to the 2 libraries (react and react native)
Everything needs the team to learn something so the easiest one for me has always been vanilla css, no setup, no fancy quirky stuff.
I do still use tailwind but mostly to create component classes in css with the tailwind processor
so a very simple button might look like this
and I use my own libs for layout stuff since they can be used across frameworks and make it easier to reuse stuff (copy paste)
Writing like this ruins the whole point of tailwind
You do end up doing the same but with whatever framework you use, anyway.
If in react/svelte/vue , you'll create components that have their own sets of tailwind styles on the component and then you use the component everywhere.
The only tailwind classes repeated everywhere are the layout ones (margins/display/padding,etc)
All i'm doing is, making it easier to move the components across codebases, I can use the above in a server rendered golang based codebase or a laravel codebase and not have to re-write the design system for every framework I decide to experiment with.
another way to do this is to use web components but I don't see the performance benefit since they won't work on older browsers, hence the above approach.
I've got my own utilities for layouts for react and react native so I don't have to deal with tailwind classes and inline styles separately in both codebases, that's one case where I don't mind getting locked to the 2 libraries (react and react native)
Anyway,
tailwindcss.com/docs/reusing-style...
tailwind does recommends using it when needed.
makes a lot of sense, may give it a try too sometime