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.
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
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.
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
> 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.
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
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.
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.
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.
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.
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.
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.
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?
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?
[+] [-] halostatue|3 years ago|reply
[+] [-] derrikcurran|3 years ago|reply
[+] [-] lries|3 years ago|reply
And libraries like mjml-react make it really easy.
https://github.com/wix-incubator/mjml-react/
[+] [-] santialbo|3 years ago|reply
- 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?
[+] [-] effisfor|3 years ago|reply
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.
[+] [-] Theryston|3 years ago|reply
[+] [-] munbun|3 years ago|reply
[+] [-] Hansenq|3 years ago|reply
This project is cool, but doesn't solve the fundamental issue that CSS support in email clients is just very poor.
[+] [-] wbobeirne|3 years ago|reply
That's precisely the thing it's trying to solve.
[+] [-] Theryston|3 years ago|reply
[+] [-] sonicgear1|3 years ago|reply
[+] [-] tdeck|3 years ago|reply
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.
[+] [-] Theryston|3 years ago|reply
[+] [-] throwaway2016a|3 years ago|reply
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/
[+] [-] Theryston|3 years ago|reply
[+] [-] pstoica|3 years ago|reply
Another tip, I highly recommend a CSS minifier which inlines styles to fix a variety of CSS priority issues.
[+] [-] rgbrgb|3 years ago|reply
Anyone reading this, feel free to hit me up if you want help onboarding.
[+] [-] KrishnaShripad|3 years ago|reply
[+] [-] shortformblog|3 years ago|reply
[+] [-] 3np|3 years ago|reply
Even Gmail/Outlook/Yahoo users may disable js and/or HTML when reading mail.
[+] [-] andirk|3 years ago|reply
[+] [-] tdeck|3 years ago|reply
[+] [-] tambourine_man|3 years ago|reply
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.
[+] [-] nvegater|3 years ago|reply
[+] [-] djitz|3 years ago|reply
[+] [-] theshadowmonkey|3 years ago|reply
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.
[+] [-] oynqr|3 years ago|reply
[+] [-] gcommer|3 years ago|reply
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.
[+] [-] gempir|3 years ago|reply
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.
[+] [-] sentrms|3 years ago|reply
[+] [-] Theryston|3 years ago|reply
[+] [-] eric4smith|3 years ago|reply
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”.
[+] [-] Theryston|3 years ago|reply
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?
[+] [-] gerardnico|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] anonymous344|3 years ago|reply
[+] [-] Theryston|3 years ago|reply
[+] [-] KrishnaShripad|3 years ago|reply
[+] [-] dhritzkiv|3 years ago|reply
It's decent.