Generate tailwind class names before deployment

[ben-sommer]

Goals

1. Reduce INCREDIBLY long delays caused by converting tailwind class names into style object notation
2. Reduce runtime memory use

Background

Building a very basic email template with just a handful of components takes 2-3 seconds on AWS Lambda with 512MB of allocated memory. Before I used AWS SES templates and they rendered and sent almost instantly, but they were a pain to update.

I manually converted all my tailwind classes to style attributes using this tool and my email now builds in 500ms. It doesn't make any sense to resolve all these tailwind classes EVERY time an email is rendered, when it could be done once when the templates are updated.

Proposal

An optional build step should be added which copies all .jsx and .tsx files to a build folder, but with all className attributes processed. Tailwind classes would be removed, resolved and then added to the style attribute, while non-tailwind classes would remain to allow custom css to function.

I am happy to start work on this as I think many others would find it useful, especially those rendering emails in pay-per-second serverless environments.

[ben-sommer]

I am aware of this discussion but I am not seeing the same performance improvements. I am on the latest version of @react-email/tailwind (0.0.15).

[gabrielmfern]

Have you tested this with the versions prior to 0.0.13? The performance improvements were made then, and back then it was much, much worse.

[gabrielmfern]

But I do think that the newer versions have a bigger impact on rendering on low-ram environments. #1383 should help with that.

[gabrielmfern]

It's probably a better idea for us to somehow cache the class names to be re-used across renders. The issue mostly is that the user might apply or not a certain class name depending on the props, so we would need to know if they are doing this for a certain class name or not.

[ben-sommer]

Surely we could just go through every .jsx or .tsx file, find all the class names using regex or similar and then create a JSON cache file with a map of className: {style properties}. When the render function is then called, we can just import that?

Thinking about it, we just want a way to compile all the needed tailwind classes into a regular CSS file and then import that in the already supported way. That would be the cleanest in my opinion.

[ben-sommer]

It's not a huge issue if we import classes that aren't used because they are down unused routes of conditional logic. Tailwind already recommends keeping whole class names together instead of dynamically changing parts of the class name, so it shouldn't be an issue for our system to pick up classes within conditional rendering blocks.

[gabrielmfern]

Thinking about it, we just want a way to compile all the needed tailwind classes into a regular CSS file and then import that in the already supported way

That isn't supported, actually, so it would be a bit more complicated than that. Also, since we run our transformations on React's element tree, we can't see class names that were not used, so conditional classes would really suffer from this.

The only way to do this kind of thing would be to completely change our integration with Tailwind, which I won't remove as an option, but I still think we can cache with the current setup and avoid having to transform the classes. #1383 Also will make this much easier, since I do think Tailwind already does this caching themselves, so just re-using the same Tailwind internal context should suffice.

Tailwind already recommends keeping whole class names together instead of dynamically changing parts of the class name,

Yeah, but since we inline all styles, you won't be able to use stuff like data attributes (at least yet), which I guess would be the other way you would conditionally apply these classes.

[ben-sommer]

Some sort of runtime caching would work fine if the render function was called in a persistent server environment such as AWS EC2, but does nothing to help the first render duration on serverless function services such as AWS Lambda. The only way to improve the initial render time for this use case, that I can see at least, is to generate some sort of cache file after updating the templates. The dev server uses a persistent environment so the cache will not need hot reloading. A command to add to a CI/CD pipeline would be the simplest in my opinion. This script would look through the files, identify all tailwind classes and then build them to a JSON file. The only real modification to the react-email source code would be to add a js script to build this cache, add that to npm scripts in the package file and then check this cache before asking tailwind to resolve any classes.

[gabrielmfern]

The only way to improve the initial render time for this use case, that I can see at least, is to generate some sort of cache file after updating the templates

Yeah, for serverless it's going to be a bit more tricky. It might be worth it, benchmarking and checking the flame graph to see what takes the longest in the newer versions. It could be that the issue isn't Tailwind resolving classes, but rather something else. Maybe something caused by running on low RAM environments.