8 ms·
JSX Mail: Ending All Your Problems When Creating Email Templates
- 3np 4y agoJust don't forget the plaintext version! Even Gmail/Outlook/Yahoo users may disable js and/or HTML when reading mail.
- andirk 4y agoFurthermore, 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.
- tdeck 4y agoI'm assuming this precompiles the HTML before sending it, given the render() call.
- adamzochowski 4y agoDoes render() also generate plaintext?
- jeroenhd 4y agoThe 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> (https://github.com/Theryston/jsx-mail https://github.com/Theryston/jsx-mail)
- hombre_fatal 4y agoA 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 4y agoHave been using TSX for email templates for quite some time now. Works really well with just ReactDOMServer.renderToStaticMarkup() and juice to inline css.
- Theryston 4y agojsx mail also accepts tsx. it's important to remember that jsx has several things that pure React doesn't have
- tdeck 4y 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.
- Theryston 4y agothere 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
- tdeck 4y agoThe first one has a <DOCTYPE> tag. When do you see that embedded within a larger document?
- Hansenq 4y agoThe 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.
- Theryston 4y agoagree, 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
- Hansenq 4y agoOh, 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.
- wbobeirne 4y 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 4y agoTrying 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.
- 4y ago
- pstoica 4y agoCheck out https://mailing.run 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 4y agoThanks 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.
- KrishnaShripad 4y agoOkay this looks really cool! Thanks for sharing!
- shortformblog 4y agoI’m a big fan of MJML (https://mjml.io https://mjml.io), but I respect the nice work done here.
- eric4smith 4y agoMost 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”.
- Theryston 4y agoI'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?
- halostatue 4y agoJust use MJML (https://github.com/mjmlio/mjml https://github.com/mjmlio/mjml) or mrml (https://github.com/jdrouet/mrml https://github.com/jdrouet/mrml). It solves the real problems with building emails without introducing useless abstractions like JSX.
- Theryston 4y agojsx 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
- derrikcurran 4y agoMJML is terrific (haven't tried MRML) but why do you consider JSX to be a useless abstraction but not MJML?
- BiteCode_dev 4y agoBecause 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.
- lucideer 4y agoI'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?
- tambourine_man 4y 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 4y agoYou are not alone
- nvegater 4y agoIt 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_fatal 4y agoOr 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 4y agoI 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 4y agoThis 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/ https://mjml.io/
- Theryston 4y agoof 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
- deleted 4y ago[deleted]
- KrishnaShripad 4y agoI am surprised people haven't brought up Maizzle yet: https://maizzle.com/ https://maizzle.com/
- dhritzkiv 4y agoI 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 4y agoIf you send me HTML-only mail, you go in the bin.
- gempir 4y agoFunny 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 4y agoI 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 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 4y agoI’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 4y agothis 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?
- Theryston 4y agogreater 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?