Hybrid mode to allow for built-in Tailwind classes

[macrini]

The proposal is to add an option to check if a css class exists in the style sheets before creating it. For example, using https://developer.mozilla.org/en-US/docs/Web/API/StyleSheetList, or some other method.

The objective is to allow for build-time Tailwind classes to co-exist with runtime classes. The check results can be cached so that each class is checked at most once.

Advantages

1. it can be made opt-in only, avoiding an unwanted check and backwards compatibility issues.
2. it can be used to experiment with twind without having to change a project that already uses tailwind.
3. it doesn't force one to choose between a top-down or bottom-up approach. Both have their merits under different scenarios.
4. it allow one to choose a pure build-time (include all and purge) or pure css-in-js approach (only generate on demand).
5. it enables the use of Functions & Directives such as @apply .
6. it ensures that selected "core" tailwind classes exist before any JS is loaded.
7. it allows for over-pruning without risks since twind creates whatever is missing, which is useful for optional components and dynamic module imports.

It might be the case that after using a hybrid approach, a team might end up converging to either pure-build-time or pure-runtime classes. The main point being that it gives a dev team the option to experiment with both approach without changing existing code. It might also be that there are apps in which a pure approach is not optimal, and the only optimal solution is a hybrid one.

[lukejacksonn]

Hey @macrini thanks for the post! It is an interesting idea however just because we can do something doesn't mean we should. I'm curious to see if anyone else would benefit from such an approach as I imagine it would be quite an involved change to Twind core.

Another thing I'd suggest is just giving it a go! Try bolt on Twind to an existing Tailwind project and see what happens, note down any issues like style conflicts or precedence overloads etc. The runtime cost of double generation is indeed a thing but it shouldn't be of concern. I'm struggling to find any upsides to a top down approach (with purging) since trying bottom up ones, doing both feels like you would suffer the downsides of both as well as the upsides, this might work out to be a net negative.

[macrini]

Thank you your reply.

After thinking a bit more about this, I came to the conclusion that it should already be possible to have build-time tailwind and runtime twind at the same time. The only issue would be that some classes would be overridden at runtime, but that should not cause any issues. The rest is just managing the settings for the purge directive based on what one needs to achieve.

In the end, this proposal was an interesting mental exercise to consider the potential of combining the solutions. Now I have to give it a go in practice. We have a project where we could try it out.

[sastan]

That sound interesting. Please keep us in the loop and please report any issue you encounter. 👍

[sastan]

Thanks for the detailed write-up. I've added my thoughts inline...

The proposal is to add an option to check if a css class exists in the style sheets before creating it. For example, using https://developer.mozilla.org/en-US/docs/Web/API/StyleSheetList, or some other method.

I agree that this is possible.

The objective is to allow for build-time Tailwind classes to co-exist with runtime classes. The check results can be cached so that each class is checked at most once.

Is there currently an issue with having tailwind and twind on the same page? If there is twind could be configured to hash its classNames.

Advantages

1. it can be made opt-in only, avoiding an unwanted check and backwards compatibility issues.

Totally agree.

2. it can be used to experiment with twind without having to change a project that already uses tailwind.
3. it doesn't force one to choose between a top-down or bottom-up approach. Both have their merits under different scenarios.
4. it allow one to choose a pure build-time (include all and purge) or pure css-in-js approach (only generate on demand).
5. it enables the use of Functions & Directives such as @apply .

2 – 5 are pointing to a problem using tailwind and twind together. What problem have you found? We want to support this.

6. it ensures that selected "core" tailwind classes exist before any JS is loaded.

If tailwindcss is used those classes are already available. For a twind only site this can be achieved using static extraction which would only include the classes that are used within the html.

7. it allows for over-pruning without risks since twind creates whatever is missing, which is useful for optional components and dynamic module imports.

I agree. Generate minimal static css using tailwindcss and use twind to provide the dynamic classes. Sounds good.

It might be the case that after using a hybrid approach, a team might end up converging to either pure-build-time or pure-runtime classes. The main point being that it gives a dev team the option to experiment with both approach without changing existing code. It might also be that there are apps in which a pure approach is not optimal, and the only optimal solution is a hybrid one.

That may be the case.

I just do not see how analyzing the existing stylesheet would help. Sorry. Maybe i'm totally missing the point.

[macrini]

Thank you for considering the proposal. I now think that it's probably more efficient to let twind override css classes that have it check if they already exist. Under that assumption, one just have to configure the purge directive to only look at folder in which the build-time css classes are used.

I imagine a core app with optional packages installed on it. The packages will rely on twind, while the app can use build-time tailwind if it so desires.

I also realized that I had used the shim for experimentation, but the tw() method is different in that it already requires a commitment to using twind.

Our regular use-case is a SPA with self-made, standalone packages installed on it. With material UI, we have to define peer-dependencies to avoid duplicating the css framework. I don't know how taildwind changes that because purge wouldn't be configured to look under node_modules. So twind seems like the right way to go for that case, and it doesn't matter what the host app chooses to do with its own css.

I don't know if this all made any sense to you, but it helped me organize the architecture for what I have in mind.

Thank you for engaging with this idea!