Twin.macro: Comparison with tailwindcssinjs ?

[clement-buchart]

Hello,

Thank you for this great lib, I'm using it in a project of mine, it's been great.

I'm usually more of a backend developer, so please excuse me if the answer to my question seems obvious.
I was looking at https://github.com/aniftyco/awesome-tailwindcss and saw :

@tailwindcssinjs/macro - Babel macro that transforms Tailwind CSS classes into objects for CSS-in-JS libraries.

Which, to me, sounded similar to what twin.macro is doing.
So, out of curiosity, I checked out the repo https://github.com/Arthie/tailwindcssinjs, and saw this commit : https://github.com/Arthie/tailwindcssinjs/commit/7fa2d7e4255cb87bcdb459ef5edcac1699efdef3 which basically just bump the tailwind version, whereas for twin.macro, quite a lot of work is going on to make it happen here https://github.com/ben-rogerson/twin.macro/issues/45

So I guess my question is what are the differences in these projects design that cause the 2 paths of upgrade ?
Would a comparison of the projects makes sense to help people pick the lib most suited to their needs ?
Would it make sense to mention twin.macro in https://github.com/aniftyco/awesome-tailwindcss so that more people get to know about it ?

Thank you !

[rbutera]

Hi @clement-buchart, great question!

The primary difference with tailwindcssinjs/macro is that this library does not use PostCSS to infer the classes.

As a result, we are able to focus on maximising the developer experience.

On this topic @bradlc, creator of the original tailwind.macro has said:

I have noticed there's some work going on with regards to using PostCSS to get the class list. Is it your intention to use that method? I ask because that is not something that I would ever want tailwind.macro to do, as I believe it would have a large negative impact on developer experience. Note that tailwind.macro does use PostCSS to support plugins (although this work was never finished), but the intention was to make plugin support opt-in, and also parsing only plugins is much less work that parsing the entire config anyway.

@ben-rogerson is actively looking at tailwindcssinjs and the PostCSS route to validate and verify bradlc's claims that using PostCSS would have a "large negative impact on developer experience."

We hope to have a better answer for the community soon :)

[clement-buchart]

Hello,

Thanks for the answer, that's clearer for me now.
I guess, in some contexts or projects, being dependent on a third-party project that needs to catch up with tailwindcss release, and may be discontinued (like tailwind.macro was in a sense), may be an even worse developer experience, so it's great that there's an implementation of both 'solutions' out there !

I'll have a go at tailwindcssinjs in a sandbox project to figure out how it fares in my context.

Should i close the issue, or do you want to keep it open pending Ben's feedback on the PostCSS way ?

[fknop]

Hi,

I may not have understood properly but what exactly is the impact on developer experience by using PostCSS?

[ben-rogerson]

Brad means it would be slower to transform the Tailwind classes with PostCSS within a Babel Macro rather than with a custom transformer.
I'm not ruling anything out and I'd need to add a PostCSS route and perform some speed comparisons to know for sure.

@clement-buchart Thanks the recommendation - I've now added twin to awesome-tailwindcss.
Let us know how you go with tailwindcssinjs.

[bradlc]

👋 Yeah all I was getting at was that running a full PostCSS compilation every time you change your Tailwind config is always going to be slower. Whether it would be _too_ slow is perhaps up for debate. When building tailwind.macro instant feedback from config changes was a key goal. As far as I can tell both twin.macro and tailwindcssinjs don't support this, although I believe that @ben-rogerson is keen to get it working again.

Ultimately, if achieving 100% compatibility with Tailwind is a goal then PostCSS will be required as the plugin API exposes that module. i.e. Even if you reimplement Tailwind core, you'll need PostCSS for third-party plugins.