Live data from Hacker News

JSX Mail: Ending All Your Problems When Creating Email Templates

jsx-mail.org

11–20 of 60 posts

Re: JSX Mail: Ending All Your Problems When Creating Email Templates

#12
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”.

Re: JSX Mail: Ending All Your Problems When Creating Email Templates

#13
post #8

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.

> the main purpose of Jsx Mail is to make your email templates compatible with all email clients.

That's precisely the thing it's trying to solve.

Re: JSX Mail: Ending All Your Problems When Creating Email Templates

#14
post #8

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.

> the main purpose of Jsx Mail is to make your email templates compatible with all email clients. That's precisely the thing it's trying to solve.

Trying to solve and actually solving are two very different things. While the project does scan for unsupported CSS that's only half the job, if that. It doesn't address the problem of actually implementing complex layouts in any way.

Re: JSX Mail: Ending All Your Problems When Creating Email Templates

#15

Earlier quoted context omitted.

> the main purpose of Jsx Mail is to make your email templates compatible with all email clients. That's precisely the thing it's trying to solve.

Trying to solve and actually solving are two very different things. While the project does scan for unsupported CSS that's only half the job, if that. It doesn't address the problem of actually implementing complex layouts in any way.

I think we're talking about two different issues (support for modern CSS layouts and working around the frustrating limitations of existing email CSS). Anything that helps reduce the need to remember magic incantations (in comments!) to make your button render correctly in Outlook 2013 (made-up example) is a huge help! Worth noting that the title is slightly editorialized: the site itself doesn't claim to "end all your problems when creating email templates" - it just claims to "make your email templates compatible with all email clients." Only email providers themselves can solve the CSS support issue.

Re: JSX Mail: Ending All Your Problems When Creating Email Templates

#17

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.

MJML is terrific (haven't tried MRML) but why do you consider JSX to be a useless abstraction but not MJML?

Re: JSX Mail: Ending All Your Problems When Creating Email Templates

#19
post #9

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.

Thanks for the plug, I’m one of the mailing.run authors Anyone reading this, feel free to hit me up if you want help onboarding.

Re: JSX Mail: Ending All Your Problems When Creating Email Templates

#20
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.

Post reply on HN