JSX Mail: Ending All Your Problems When Creating Email Templates

https://jsx-mail.org

by Theryston • 4 years ago

101 57 4 years ago

jsx-mail.org

3np• 4 years ago

Just don't forget the plaintext version!

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

andirk• 4 years ago

Furthermore, save for some nice branding color schemes, better font sizing, and maybe a few other useful UI features, an email should be almost all text and images. It should be treated more like a postal letter or a chatroom message.

tdeck3• 4 years ago

I'm assuming this precompiles the HTML before sending it, given the render() call.

adamzochowski• 4 years ago

Does render() also generate plaintext?

hombre_fatal3• 4 years ago

A Plaintext email would show the html tags in plaintext. It’s probably not something this library wants to solve since stripping html tags from an html email isn’t necessarily a coherent plaintext email either.

Generating a plaintext message dynamically isn’t much of a pain point but html emails can be.

sentrms• 4 years ago

Have been using TSX for email templates for quite some time now. Works really well with just ReactDOMServer.renderToStaticMarkup() and juice to inline css.

Theryston11• 4 years ago

jsx mail also accepts tsx. it's important to remember that jsx has several things that pure React doesn't have

tdeck3• 4 years ago

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.

Theryston11• 4 years ago

there you have it, the example was so good that you even got it wrong, the first one was just a Button that would be reused in other files, but with all the code you thought it was an entire document, when in the second you obviously see that it's just a button component

tdeck3• 4 years ago

The first one has a <DOCTYPE> tag. When do you see that embedded within a larger document?

Hansenq2• 4 years ago

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.

wbobeirne• 4 years ago

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.

Etheryte• 4 years ago

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.

sonicgear1• 4 years ago

Exactly. JSX Solves nothing here.

Theryston11• 4 years ago

greater compatibility email clients (because it blocks you from using css not allowed) offers components to facilitate and give compatibility to email clients, has an email client simulator, allows using jsx, allows using styled-components, is being applied to turn css not allowed by email clients you make into css allowed (automatically by the compiler) how can this be useless?

Theryston11• 4 years ago

agree, that's exactly why we're starting with css transformation issue. for example you can use flexbox in your css and the jsx mail compiler will turn flexbox into something that email clients understand. but this is still in the beginning, however currently jsx mail blocks you from using css stuff that email clients won't understand

Hansenq2• 4 years ago

Oh, now that's actually really cool and useful! If you pair that with a way to preview what the email looks like in different email clients (like Litmus), that would significantly increase the value of this tool.

I didn't see any mention into how the tool's able to translate modern CSS into email-client-supported CSS; might be worth calling that out as the main value prop, as that's the real thing that I care about when building emails.

pstoica• 4 years ago

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.

rgbrgb• 4 years ago

Thanks for the plug, I’m one of the mailing.run authors <3!!

Anyone reading this, feel free to hit me up if you want help onboarding.

KrishnaShripad2• 4 years ago

Okay this looks really cool! Thanks for sharing!

shortformblog• 4 years ago

I’m a big fan of MJML (https://mjml.io), but I respect the nice work done here.

eric4smith• 4 years ago

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

Theryston11• 4 years ago

I've already listed the good things about jsx mail, but here goes:

halostatue• 4 years ago

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.

derrikcurran• 4 years ago

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

BiteCode_dev• 4 years ago

Because you get 2 levels of indirection instead of 1.

If 1 does the job equally well, you should choose 1.

In fact, MJML can be used with any templating solution, so if your system already uses JSX, JSX doesn't add indirection, and you should use it.

But if your system is not, adding JSX on top has just prevents you from hacking a shell scripts that generates the email in a few lines, generating the email from whatever backend you use, or just writing the template in a free form file without anything to install.

You gain complexity, you loose flexibility.

lries• 4 years ago

Agreed that MJML is great, but I wouldn't call JSX a useless abstraction. Using JSX as a templating language for MJML has real benefits, like being able to use javascript directly in templates instead of having to remember handlebars/mustache/nunjucks/etc templating syntax.

And libraries like mjml-react make it really easy.

https://github.com/wix-incubator/mjml-react/

rockwotj• 4 years ago

Came here to saw we use mjnl react and it's awesome to be able to wrap mjml in your own components.

evv• 4 years ago

MJML-React is awesome to use because of the JSX support: 1. you can integrate real JS without using some templatey thing, and 2. type safety with TS, helpful for auto-completion and robustness

Anyways it seems that Wix is no longer maintaining the project and Faire has taken it on: https://github.com/Faire/mjml-react

funstuff007• 4 years ago

Agreed. We use Python + Jinja to create dynamic mjml.

Theryston11• 4 years ago

if you read a bit of the jsx mail documentation you will see that it not only allows you to use jsx in emails, it does that and gives you a complete development environment with even an email client simulator for you to be your email in time real

santialbo• 4 years ago

I'm using mjml-react which gives me:

- proper i18n with any react i18n library

- js to create complicated emails

- nicer component reuse story.

- syntax highlighting and completion when used with Typescript

- can be integrated with other nice js tools like Storybook for seeing all emails in one place and play with their props.

How is that useless?

hombre_fatal3• 4 years ago

HNers need to learn to just ask people why they use a given tech instead of dismissing it outright because the HNer likes to do things a different way.

The discourse would be much less boring.

Theryston11• 4 years ago

I don't call it useless, I know the power he has, so I think he must have more competitors and we're here for that.

effisfor• 4 years ago

I'm currently integrating MJML into a React/JSX context. From my vantage point, MJML is the abstraction.

I once worked with a guy who kept looking over my shoulder and saying 'just use binary'. Nice guy, but they had to let him go.

munbun• 4 years ago

Early versions of MJML used JSX class components.

Theryston11• 4 years ago

jsx mail not only solves the compatibility issue like others do, it also has things like a mail client emulator. especially if you want to use it without being linked to a programming language, you can just use the CLI that will give you pure HTML and CSS, among that several features that were designed to improve and facilitate the creation of email templates

tambourine_man• 4 years ago

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.

djitz• 4 years ago

You are not alone

nvegater2• 4 years ago

It probably targets developers that learned web development while learning React. It is at least a good idea for them. I think jsx-email wants to be the jsx version of mjml.

hombre_fatal3• 4 years ago

Or anyone who wants a tempting system or anyone who wants to conditionally render html esp in a templating system they already use, integrated with components and libraries they already have defined.

gcommer• 4 years ago

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.

throwaway2016a• 4 years ago

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/

Theryston11• 4 years ago

of course, jsx mail also solves many of these problems and even more problems than k MJML, but as it is in the beginning we do not recommend that you use it in production. Just wait for it

KrishnaShripad2• 4 years ago

I am surprised people haven't brought up Maizzle yet: https://maizzle.com/

dhritzkiv• 4 years ago

I use this! Or at least a version from two years ago – I haven't needed to create a new template in a while.

It's decent.

oynqr• 4 years ago

If you send me HTML-only mail, you go in the bin.

gempir• 4 years ago

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.

theshadowmonkey• 4 years ago

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.

gerardnico• 4 years ago

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.

anonymous344• 4 years ago

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?

Theryston11• 4 years ago

JSX Mail: Ending All Your Problems When Creating Email Templates

Related Stories