JSX Mail: Ending All Your Problems When Creating Email Templates(jsx-mail.org)
jsx-mail.org
JSX Mail: Ending All Your Problems When Creating Email Templates
https://jsx-mail.org
59 comments
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?
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.
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.
I'm not sure what you mean by indirection in this instance. How does JSX use 2 levels?
> MJML can be used with any templating solution
Wouldn't that add complexity where JSX has less? Why use 2 systems (MJML + [templating]) when you can get away with 1 (JSX)?
> adding JSX on top has just prevents you from hacking a shell scripts
As far as I understand both are npm libraries so I can't see how one allows this where the other doesn't? Surely their application is the same usage pattern?
> MJML can be used with any templating solution
Wouldn't that add complexity where JSX has less? Why use 2 systems (MJML + [templating]) when you can get away with 1 (JSX)?
> adding JSX on top has just prevents you from hacking a shell scripts
As far as I understand both are npm libraries so I can't see how one allows this where the other doesn't? Surely their application is the same usage pattern?
[deleted]
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/
And libraries like mjml-react make it really easy.
https://github.com/wix-incubator/mjml-react/
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
Anyways it seems that Wix is no longer maintaining the project and Faire has taken it on: https://github.com/Faire/mjml-react
Came here to saw we use mjnl react and it's awesome to be able to wrap mjml in your own components.
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
Agreed. We use Python + Jinja to create dynamic mjml.
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?
- 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?
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.
The discourse would be much less boring.
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.
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.
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.
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
Early versions of MJML used JSX class components.
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.
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.
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.
It works around the limitations by introducing custom components that are widely supported by multiple email clients[0]. Currently only 3: Button, Group and Image. It solves at least that and it seems to be scalable to build more components. In my opinion JSX is a great template language, I'm happy to use that abstraction, even though the setup is a bit annoying.
[0]: https://jsx-mail.org/docs/components/button
[0]: https://jsx-mail.org/docs/components/button
exactly that, and about the configuration we are looking for ways to improve it.
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
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.
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.
Exactly. JSX Solves nothing here.
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?
> 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.
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.
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
The first one has a <DOCTYPE> tag. When do you see that embedded within a larger document?
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/
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/
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
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.
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 <3!!
Anyone reading this, feel free to hit me up if you want help onboarding.
Anyone reading this, feel free to hit me up if you want help onboarding.
Okay this looks really cool! Thanks for sharing!
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.
Even Gmail/Outlook/Yahoo users may disable js and/or HTML when reading mail.
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.
I'm assuming this precompiles the HTML before sending it, given the render() call.
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.
Generating a plaintext message dynamically isn’t much of a pain point but html emails can be.
Does render() also generate plaintext?
The example on Github doesn't seem to:
// js-side
import { render } = from 'jsx-mail';
const template = await render('Welcome', { name: 'John' });
console.log(template) // <html>...<h1>John Welcome to jsx-mail</h1>...</html>
> 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.
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.
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.
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.
You are not alone
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.
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.
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.
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.
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”.
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've already listed the good things about jsx mail, but here goes:
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?
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?
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.
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.
[deleted]
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?
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?
I am surprised people haven't brought up Maizzle yet: https://maizzle.com/
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.
It's decent.