Payload size implications

[aaronjensen]

Hi there,

I really like the idea of twin.macro. I'm curious there if the ramifications to payload size have been considered at all. The nice thing about tailwind and other utility css frameworks is that you only have to pay the penalty of a utility class once, no matter how many times you use it. With twin.macro, it seems that the utility class is actually inlined everywhere it's used, which not only increases its size, but it also increases the number of css rules added to the dom.

I could see a macro adding the classes used directly and including the appropriate stylesheet, still obviating purgecss. That'd obviously not play nearly as well with Emotion, which is the whole point...

Anyway, just curious what thoughts have been had about this. Thanks!

[ben-rogerson]

Twin doesn't handle any cross-component style de-duplication.
The main task is just converting Tailwind classes to CSS objects. Then you're in control of what you do then with the output.

I understand that your question needs to be asked as this is an important issue with CSS-in-JS.
Personally I've had no issues with duplicated styles contributing to excessive transfer/render times using Twin with Emotion when compared to vanilla Tailwind.

There's plenty of resource out there already that discuss these CSS-in-JS duplication issues.
If there's any further discussion required, it would be most constructive to see some real-world comparisons with vanilla Tailwind where style duplication becomes a real issue.

Also - I'd like to put together some resources on this as there's bound to be more questions on the topic in the future.

[aaronjensen]

A list of those resources would be great.

We're just kicking off a project and considering all of our options. I agree that it's very hard to discuss without a real example. I imagine some sort of synthetic example may not be sufficient either. It also greatly depends on the size of the site. If twin were used only as a replacement for classnames (that is, the prop, not the template string), then it would be easy to swap out with the regular className prop so that things could be tested. That'd probably require a real site using it in exactly that way, so we may not get to that.

Tailwind has its own problems even with purgecss of not really being amenable to code splitting, which means that every page has to ship the entire payload unless you do some additional critical css extraction.

[ben-rogerson]

Closing up this issue now 👋
I'm still aiming to compile those resources - let me know if you come across any you'd like to see 👍

[mrchief]

There's very little overhead with large amount of duplicated text if your output is being gzipped or compressed. Most everyone serves gzipped or brotli-ed assets including HTML anyway and CDNs can take care of it with little to no effort. So the additional complexity of de-duping during build time may not be worth the time or effort depending on how your delivery/distribution is setup.