384kb at runtime to just render an email

[enfipy]

I didn't come from NextJS and React world so I may not understand something, but is it okay for everyone that I need to include +384kb (111kb gzipped) of JS just to render a simple email at runtime (with @react-email/render)?

Disclaimer: I love the way react-email gives simple tools to design emails from react and I think that the idea of moving emails to code is great!

But isn't it just overkill for backend-only servers (not NextJS) like simple Hono over Cloudflare Workers - to load whole React Email render logic? Perhaps it's better to prerender React emails at build time and then simply replace properties at runtime with some template engine and zero runtime footprint. But somehow I have found no discussions around this topic at all.

I would be very glad if someone pointed me to a solution that I missed.

[gabrielmfern]

Perhaps it's better to prerender React emails at build time and then simply replace properties at runtime with some template engine and zero runtime footprint.

It would be better for performance but not for the DX. The reason it might be so big is because we use react-dom under the hood.

Another idea would be to bundle react-dom as well, (which can cause issues, so it should be done very carefully), and treeshake what is needed from it as we don't really need that much code.
Also, maybe you can consider using a bundler for tree shaking at least 🤔.

[enfipy]

I think tree shaking in this case would be just a work-around and not win a lot. But perhaps I am wrong - need to test it. The easiest way I think is to just async load at runtime the @react-email/render library. But still, for example, CF Workers have limits on how big a single worker can be.

Regarding not having good developer experience when converting emails at build time - why do you think it's bad? I actually think it can look pretty nice with reusing Props types from email files and just rebuilding emails every time they change (like through hooks). I may try to make some PoC on the weekend. Anyway, I was impressed that nobody even asked about this question anywhere. If you have seen some similar discussions - let me know.

[gabrielmfern]

Regarding not having good developer experience when converting emails at build time - why do you think it's bad?

You wouldn't be able to do much logic with the data at the point of rendering and it could very foot gunny if not clear enough to everyone. You would probably need special syntax to do stuff like loops and other things as well.
This experience is actually what some users have that need to pre-render emails and apply templating languages into it.

[enfipy]

Perhaps you are right. Also, I think it's not very important how fast you can render different emails from a cold start of Edge runtime.

Anyway, if you want to close this discussion - go ahead. I don't think I have anything to add. Or just leave it open in case anyone bumps into it?

[gabrielmfern]

I think tree shaking in this case would be just a work-around and not win a lot. But perhaps I am wrong - need to test it.

People would certainly complain about us bundling react-dom but it certainly could take off of the weight in the applications that use it without bundling themselves.