Just use MJML (https://github.com/mjmlio/mjml) or mrml (https://github.com/jdrouet/mrml). It solves the real problems with building emails without introducing useless abstractions like JSX.
The issue with building emails is the lack of modern CSS support across most email clients. It's incredible the fallbacks you need to go to (raw CSS tables) if you can't use flexbox, css grid, or any number of modern CSS rules.

This project is cool, but doesn't solve the fundamental issue that CSS support in email clients is just very poor.

> Which of these two codes can you understand faster?

The first one, definitely! The first one shows the structure of the document and places the button in context. I cant actually tell that the second example is equivalent, since there's no "rest of the document" or if there is it's done by magic behind the scenes.

Edit: I don't want to come off as too harsh on this project, this example is relatively simple so it probably doesn't show off the power of programming your email templates as code.

This looks interesting but I think I'll stick with MJML [1] for a while.

I can see that a few other people already brought up MJML so I hope I can have some value added but basically MJML is fanatical about making sure all their changes are supported on a very wide range of email clients. They have hundreds of contributors and 10k+ starts on Github all fixing bugs and compatibility. The project has 2000+ commits. Any new framework that comes out is going to have a lot of catching up to do.

When I use MJML I feel very confident my email will work on many different email clients. And even be responsive.

[1] https://mjml.io/

Check out https://mailing.run. Similar project that can be embedded or run as a standalone API. Also uses MJML which is indispensable for cross-client compatibility.

Another tip, I highly recommend a CSS minifier which inlines styles to fix a variety of CSS priority issues.

I’m a big fan of MJML (https://mjml.io), but I respect the nice work done here.
Just don't forget the plaintext version!

Even Gmail/Outlook/Yahoo users may disable js and/or HTML when reading mail.

> Which of these two codes can you understand faster?

To me, the first one, but I’m not convinced JSX is a good idea anywhere and I’ve been writing HTML for 30 years.

I worked on a transactional email infrastructure where we used to send 50k-100k emails at a time and a few million a day. We used inky and juice to customize email generation and caching partial templates using inky worked out well at scale. Only problem was with all the fallbacks, some emails used to get large enough and gmail used to clip them at the bottom. https://get.foundation/emails/docs/inky.html

Not sure if the framework is as advanced. But, seems to solve a lot of basic issues. Surprising that providers like sparkpost or ses are not able to solve generation at scale problem with templates.

If you send me HTML-only mail, you go in the bin.
I know multiple companies doing the same thing -- it's really great to use JSX that most JS shops will already know instead of introducing a whole other template language that (typically) have a brand new syntax, weird logic-in-html, and/or poor componentization.

Lot's of cool follow-on value-adds you can do once your emails are in JS like this. Like writing test cases to validate that none of your emails are susceptible to HTML injection. Or writing tests about never exceeding Gmail's 100kb limit. Or rendering your emails in Storybook.

Funny a few years ago I built exactly this for our company mailings. We checked out several frameworks and those are great if you only need an Email to look somewhat good and not have too specific of requirements.

But our Emails had to replicate other teams designs 1:1 pixel perfect. So we mostly used the same code blocks.

I needed some sort of framework that would organize those code blocks and jsx was perfect. I generated twig templates out of the JSX and used php to send the emails.

Have been using TSX for email templates for quite some time now. Works really well with just ReactDOMServer.renderToStaticMarkup() and juice to inline css.
Most e-mail templates can be easily coded by hand these days.

E-mail clients by and large show html properly too.

A few rules:

1. Inline css of course

2. Use pixels as units

3. Don’t get too fancy.

I tuned out as soon as I read the word. “React”.

I’m using pure html with the css of bootstrap email and I in-line it.

The problem with library is that they don’t go well across language, you need to call an api. (I use Java)

As of today, most email client understand the basic css.

this feels like adding alot more problems to solve one.. just use twig and make template... i mean how often do you need to re-design the email templates?
I am surprised people haven't brought up Maizzle yet: https://maizzle.com/