Arguments against twin.macro in favor of TW
Hello all!
At work, I am in the process of making the argument for using normal Tailwind over twin.macro. Our last project used twin but in the next I am trying to push hard for abandoning it in favor of the rational stack of TW, CVA, TW merge and CLSX.
As far as I can tell, there is only downside for the end user when using JSS.
Does anyone have any concrete resources they've created or come across to demonstrate this?
I understand that TW merge can have some runtime effects on initial load, but sure it wouldn't be measurable compared to all the runtime JS in emotion, correct?
Also, I am looking for some articles or material on why "semantic css" is a problem that Tailwind is explicitly designed to solve.
Any points on this topic would be greatly appreciated!
Thanks!
3 Replies
I'm still waiting on someone to give me a good reason why anyone should use CSS-in-JS. I'm not even trying to be cheeky, just legitimately never found a good argument for it, especially with the tools we have now 🙂
Not sure why you would need JSS with the new stack though? JSS is needed to generate CSS from JS, but I don't see why you would need it with CLSX, and TW?
In regards to semantic css, I can do a bit of shameless self promotion and link a blog I've written about expressive code vs "clean code": https://dev.to/noblica/expressive-code-clean-code-59o7
It's a bit of a counter-point to another blog posts that argues against tailwind, and for "clean" class names, so might help you out.
Personally, I think the biggest and most important part of any component is it's styling, so it makes sense that it is as close to the component as possible. I also would argue against using TW merge, but I don't want to pollute your thread with personal opinions you didn't ask for 🙂
Hope this helps!
DEV Community
Expressive code > Clean code
When people say "clean code", they usually mean "code that's easy to read." I know that the full...
@noblica thanks for the response! This article is exactly what I'm looking for. I'm trying to convince my team that "semantic classnames" (or in this case semantic styled components) is just a vestigial concept and is actually a problem that Tailwind is designed to solve.
Regarding TW merge, I really only plan to use it in base components as I have seen that it can have some performance hits on load. Have you ran into issues while using it before?
Hey, no worries, glad I could help 🙂
As far as TW mege goes, I don't have anything technically against it. It's a perfectly fine library. But my approach towards developing components is that explicit styles should never be passed directly from parent to child components. If styles can be overridden directly like this, the component loses it's identity, and the whole codebase becomes way harder to maintain because everything can look like anything.
But as I said, that's just my personal approach to it, doesn't have anything to do technically with TW merge.