JSX Mail: Ending All Your Problems When Creating Email Templates • Hacker News Board

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

#31

Post by theshadowmonkey » Thu, Oct 06, 2022, 6:33 AM UTC

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.

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

#32

Post by BiteCode_dev » Thu, Oct 06, 2022, 6:49 AM UTC

derrikcurran wrote: post #17

halostatue wrote: post #16

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.

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

#33

Post by gerardnico » Thu, Oct 06, 2022, 7:02 AM UTC

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.

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

#34

Post by evv » Thu, Oct 06, 2022, 7:31 AM UTC

lries wrote: post #21

halostatue wrote: post #16

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.

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/

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

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

#35

Post by sonicgear1 » Thu, Oct 06, 2022, 7:33 AM UTC

Hansenq wrote: 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.

Exactly. JSX Solves nothing here.

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

#36

Post by lucideer » Thu, Oct 06, 2022, 8:33 AM UTC

BiteCode_dev wrote: post #32

derrikcurran wrote: post #17

Earlier quoted context omitted.

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 whatev…

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?

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

#37

Post by nvegater » Thu, Oct 06, 2022, 8:37 AM UTC

whakim wrote: post #15

Etheryte wrote: post #14

Earlier quoted context omitted.

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 yo…

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

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

#38

Post by [deleted] » Thu, Oct 06, 2022, 8:37 AM UTC

BiteCode_dev wrote: post #32

derrikcurran wrote: post #17

Earlier quoted context omitted.

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 whatev…

[deleted]

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

#39

Post by santialbo » Thu, Oct 06, 2022, 8:40 AM UTC

halostatue wrote: post #16

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.

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?

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

#40

Post by anonymous344 » Thu, Oct 06, 2022, 8:40 AM UTC

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?