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

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

#51

Post by Theryston » Mon, Oct 10, 2022, 11:15 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.

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

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

#52

Post by Theryston » Mon, Oct 10, 2022, 11:20 AM UTC

nvegater wrote: post #37

whakim wrote: post #15

Earlier quoted context omitted.

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

exactly that, and about the configuration we are looking for ways to improve it.

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

#53

Post by Theryston » Mon, Oct 10, 2022, 11:23 AM UTC

sonicgear1 wrote: post #35

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.

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?

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

#54

Post by Theryston » Mon, Oct 10, 2022, 11:26 AM UTC

tdeck wrote: post #4

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

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

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

#55

Post by Theryston » Mon, Oct 10, 2022, 11:28 AM UTC

throwaway2016a wrote: post #22

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…

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

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

#56

Post by Theryston » Mon, Oct 10, 2022, 11:44 AM UTC

sentrms wrote: post #3

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

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

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

#57

Post by Theryston » Mon, Oct 10, 2022, 11:52 AM UTC

eric4smith wrote: post #12

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

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?

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

#58

Post by Theryston » Mon, Oct 10, 2022, 11:54 AM UTC

anonymous344 wrote: post #40

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?

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

#59

Post by Hansenq » Tue, Oct 11, 2022, 11:07 PM UTC

Theryston wrote: post #51

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.

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.

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

#60

Post by tdeck » Thu, Oct 13, 2022, 7:29 AM UTC

Theryston wrote: post #54

tdeck wrote: post #4

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

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 tag. When do you see that embedded within a larger document?