7 ms·

Sure! Most front-end teams are using React nowadays. What happens when you adopt another email service is that they want you to learn the template language tha

Sure! Most front-end teams are using React nowadays. What happens when you adopt another email service is that they want you to learn the template language that they use - Handlebars, Mustache, etc. Instead of having to learn how to do things with that language, your front-end team can re-use everything they already know from React land. Imagine being able to import the same button you have on your web app into your email template. Not only that, but you can also use stuff like Tailwind to help with the styling of your email.

mbesto 3y ago
Ya, but why does a transactional email service have anything to do with the front-end....I feel like I'm missing something very obvious but I can't seem to figure it out...
- douglaswlance 3y ago
  Emails are rendered like websites with a reduced featureset.
  - winphone1974 3y ago
    This isn't really true. More like static pages targeting a million different rendering engines with unbalanced feature support
- avree 3y ago
  I don't mean this snarkily, but have you ever used a transactional email service? Literally all of them support frontend, I'd much rather use something like React than "Handlebars" (which Sendgrid requires https://docs.sendgrid.com/ui/sending-email/how-to-send-an-email-with-dynamic-templates https://docs.sendgrid.com/ui/sending-email/how-to-send-an-em...)
  - mbesto 3y ago
    I've used pretty much all of them and in most cases you're sending the request via some message queue (front-end -> async to back-end -> message queue -> async returns to back-end DB), which is managed on the backend. I'm scratching my head as to why relying on the browsers threading to do seems like it offers any advantages...
  - al_be_back 3y ago
    I think he may have wondered how would, say a Python backend using Resend Python SDK, render a React Email template and send it. Their API docs [1] for "Send Email" has an option for specifying a 'react' component to render the message but it's only available on the NodeJS SDK. Otherwise you pass HTML and/or Text. Personally, I was expecting the api to optionally accept a React Template, along with the Data, where upon the Resend api would Render it (or fail) then Send it. Passing a 'preview' param would return the rendered HTML/Text (for testing) - just a thought. [1] https://resend.com/docs/api-reference/emails/send-email https://resend.com/docs/api-reference/emails/send-email
    - mbesto 3y ago
      Exactly this. Said differently - how many devs out there are screaming "I really need to send transactional email via React", when most apps are sending it via Python, Ruby, PHP, Java, and (back-end) JS.
      - nlh 3y ago
        Preface: I'm with you on this. But I think the targeting here is for a certain generation of companies where there is a very distinct backend/frontend split OR companies where everyone is a JavaScript dev (and the backend is Node). The backend folks send the email content and the frontend folks are responsible for building the presentation-layer stuff. The thinking here, I believe, is that those frontend guys do all their other work in React, so when they're given these transactional emails to build, they'd prefer to keep working in React. I think?
      - ovao 3y ago
        I think you’re conflating terms (or possibly concepts) here. This isn’t about sending emails via React; this is about sending HTML emails generated from React components via a backend. The examples shown on the landing page are of Node.js, Next.js route handlers and Remix loader functions, the latter two being fancy abstractions over Lambda functions (or isolates). I agree that sending an email from React doesn’t make a lot of sense, but that’s not the target at which this is aiming.
      - 3y ago
  - winphone1974 3y ago
    But the code populating and sending the email is rarely (ever?) Front end code
    - fastball 3y ago
      Sure, but presumably you want your emails to generally match the aesthetic of the rest of your product, which is easier if you can use the same tooling to make them as you do the frontend of your product.
      - verdverm 3y ago
        React doesn't do its own styling though, and since email will not run js, you are basically talking about css at this point
        f-securus 3y ago
        Maybe that is the secret sauce of this service. They render the email with react and automagically convert that to something that works for email?
        nlh 3y ago
        I think they literally just use React as a templating language, basically. You write React components and this service renders them down to email-friend HTML. Like SSR but for email.
- brigadier132 3y ago
  The business wants to maintain the same consistent style with all communications to the customer. A lot of thought goes into design systems, they don't want to throw that away in their emails.
- DylanSp 3y ago
  I _think_ the idea is just to use React as a templating language to write HTML emails, rather than dealing with the quirks of email HTML directly; it's not about sending emails from the frontend.
  - mbesto 3y ago
    But why use React to do that when you can achieve the same thing on the backend? https://mjml.io/ https://mjml.io/
    - DylanSp 3y ago
      The selling point is that this allows leveraging existing React knowledge, as per the founder's comment upthread.
    - mattwad 3y ago
      There's also react-mjml, a React wrapper around it. Works great, altho it's easy to mix up React props with mjml props. Just requires devs to actually read the documentation
      - zenorocha 3y ago
        Unfortunately, the react-mjml library is no longer maintained: https://github.com/wix-incubator/mjml-react#notice-this-project-is-no-longer-maintained-warning https://github.com/wix-incubator/mjml-react#notice-this-proj...
- cobertos 3y ago
  I've worked at a couple companies (medium-scale) with home grown email solutions. The server-side rendered templating grew into being used for HTML email as well. It helped the backend devs as the tech that rendered the webpages also rendered the emails (all server side rendering), and the frontend devs needed less training to go from just frontend to frontend + emails. It was sort of a path of least resistance thing and it did have its drawbacks.
  - mbesto 3y ago
    > It was sort of a path of least resistance thing and it did have its drawbacks. This makes sense, but ya aren't there serious scaling implications to this?
    - cobertos 3y ago
      Not really? The system worked as designed for the years I was there and sent _many_ emails. Rendering a template was never so taxing as to not scale. From a workflow perspective, each email was a template file, so if you had a ton of emails it was easy to parallelize the work across frontend devs
- solardev 3y ago
  Simpler websites often don't need a backend anymore (beyond automated, managed hosting). Many of them can just e a frontend package that can be deployed anywhere as static output files (CDN, any file host, Vercel, Netlify, Cloudflare Workers, S3, etc.) In such a system, sending an email is traditionally a pain (well, email is always a pain, but even more so when you don't have a dedicated backend). Being able to fan that out to an API call (plus a template system already in your frontend's language) just means it's easier. The API part handles the transactional email and deliverability and all that. The React part helps with the handcrafting of emails using a familiar layout composition language (React). But that part is entirely optional; it's a separate open-source project anyway and you can use the API without React at all if you so choose (or conversely, use the React email templates without Resend).
  - mbesto 3y ago
    This makes sense, but what if you're using a message queue to send transactional emails? Why would you put that logic on the browser?
    - solardev 3y ago
      Not quite sure I follow. Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later? That part of the logic wouldn't be in the browser (unless you're purposefully trying to emulate SMTP on the client for some reason). In Resend, for example, a 200 just acknowledges that their API successfully received your request and will attempt delivery soon. It doesn't necessarily mean the email was either sent from their SMTP servers or received by the recipient's server client. You can check delivery status later on in the dashboard: https://resend.com/docs/dashboard/emails/introduction#understand-email-events https://resend.com/docs/dashboard/emails/introduction#unders... (And then optionally receive that as a webhook later on, if you want to notify the user of success: https://resend.com/docs/dashboard/webhooks/event-types#email-delivered https://resend.com/docs/dashboard/webhooks/event-types#email...) ---- Edit: In case it wasn't clear, the value of something like Resend or (SES or SendGrid or whatever) is that you don't HAVE to write logic to handle the tricky parts of email delivery. You just send an API call to someone else's transactional email service and let them worry about all that. Bigger companies with dedicated staff/teams might want to inhouse a lot of that stuff, but there are a lot of smaller companies (or non tech companies) that still need to do transactional emails but don't necessarily want to maintain it in-house. In a resource-constrained team/org, it's the difference between a full-stack dev who has to split time between making the website and maintaining the backend(s) and infra, vs a cheaper frontend Javascript dev who can focus solely on the frontend UX/marketing/branding/etc.. The latter can matter more for direct-to-consumer companies who don't necessarily care about the backend as long as it works and isn't too expensive... those 3rd party services are usually much cheaper than hiring even a junior dev/sysadmin.
theallan 3y ago
I think the confusion is coming from the framing of "Email API for Developers Using React" as the title for this post. React has nothing to do with "an email API" as far as I can see. Your web-site is more clear in that it shows a Node.js snippet (and other environments, although funnily not just in the browser?). Then the site goes on to talk about the React components. Perhaps "Email API for Developers, with React components" would resolve the issue. The title as it stands suggests I wouldn't be interested in this at all since I'm not using React. But actually, as an e-mail API, I would be (e.g. with a Hugo site).
- bagels 3y ago
  Thank you, that's a lot more clear. I was going to click through to find out how they protect the mail server secrets when sending emails from the react based client.
mediumdeviation 3y ago
FWIW the Tailwind implementation in react-email is not well done. The code double render React to static markup just to parse it into DOM then parse out the style and className attributes using a lot of regex https://github.com/resendlabs/react-email/blob/main/packages/tailwind/src/tailwind.tsx#L48 https://github.com/resendlabs/react-email/blob/main/packages.... It's likely to be brittle and also very slow - slow enough to almost cause an incident when we tried to use it in production because emails were taking _seconds_ to render.
- Rapzid 3y ago
  So weird, not sure what all the requirements are. I might just call "getComputedStyles" on the DOM elements and use that to generate inline styles for all the elements. I have to imagine there are existing tools for all this..
  - mediumdeviation 3y ago
    The emails are generated server-side, so there is no native DOM here to work with. There probably are existing tools for this, so yeah it's odd they're running with basically proof-of-concept quality code here.
quickthrower2 3y ago
I think the people that will love this are NextJS/Vercel people, who have decided React is for them for 1. Frontend, 2. Backend, 3. Build Time, and now want to add 4. Emails, and might want to reuse that <Layout> component they carefully crafted for emails too. I reckon if you become another integration in Vercel, and maybe a option to install your open source react.email is presented when installing Next, that could go a long way. I almost drunk the React everywhere coolaid (and have some NextJS projects) but not sure it is for me for various reasons (personal preferences), but plenty of people love that way of developing. Another thing, thinking of living the future. You mention deliverability. Nothing more deliverable than avoiding email all together. (You are not an email company). Will Gen Alpha use email much? That's all I'll say - something to think about.
herbst 3y ago
I know mustache, handlebars and many other scripting languages. I never used react and have no idea what tailwind is. As mostly backend dev with some slight frontend skills I don't get the selling point of this.

mbesto 3y ago

Ya, but why does a transactional email service have anything to do with the front-end....I feel like I'm missing something very obvious but I can't seem to figure it out...

douglaswlance 3y ago
Emails are rendered like websites with a reduced featureset.
- winphone1974 3y ago
  This isn't really true. More like static pages targeting a million different rendering engines with unbalanced feature support
avree 3y ago
I don't mean this snarkily, but have you ever used a transactional email service? Literally all of them support frontend, I'd much rather use something like React than "Handlebars" (which Sendgrid requires https://docs.sendgrid.com/ui/sending-email/how-to-send-an-email-with-dynamic-templates https://docs.sendgrid.com/ui/sending-email/how-to-send-an-em...)
- mbesto 3y ago
  I've used pretty much all of them and in most cases you're sending the request via some message queue (front-end -> async to back-end -> message queue -> async returns to back-end DB), which is managed on the backend. I'm scratching my head as to why relying on the browsers threading to do seems like it offers any advantages...
- al_be_back 3y ago
  I think he may have wondered how would, say a Python backend using Resend Python SDK, render a React Email template and send it. Their API docs [1] for "Send Email" has an option for specifying a 'react' component to render the message but it's only available on the NodeJS SDK. Otherwise you pass HTML and/or Text. Personally, I was expecting the api to optionally accept a React Template, along with the Data, where upon the Resend api would Render it (or fail) then Send it. Passing a 'preview' param would return the rendered HTML/Text (for testing) - just a thought. [1] https://resend.com/docs/api-reference/emails/send-email https://resend.com/docs/api-reference/emails/send-email
  - mbesto 3y ago
    Exactly this. Said differently - how many devs out there are screaming "I really need to send transactional email via React", when most apps are sending it via Python, Ruby, PHP, Java, and (back-end) JS.
    - nlh 3y ago
      Preface: I'm with you on this. But I think the targeting here is for a certain generation of companies where there is a very distinct backend/frontend split OR companies where everyone is a JavaScript dev (and the backend is Node). The backend folks send the email content and the frontend folks are responsible for building the presentation-layer stuff. The thinking here, I believe, is that those frontend guys do all their other work in React, so when they're given these transactional emails to build, they'd prefer to keep working in React. I think?
    - ovao 3y ago
      I think you’re conflating terms (or possibly concepts) here. This isn’t about sending emails via React; this is about sending HTML emails generated from React components via a backend. The examples shown on the landing page are of Node.js, Next.js route handlers and Remix loader functions, the latter two being fancy abstractions over Lambda functions (or isolates). I agree that sending an email from React doesn’t make a lot of sense, but that’s not the target at which this is aiming.
    - 3y ago
- winphone1974 3y ago
  But the code populating and sending the email is rarely (ever?) Front end code
  - fastball 3y ago
    Sure, but presumably you want your emails to generally match the aesthetic of the rest of your product, which is easier if you can use the same tooling to make them as you do the frontend of your product.
    - verdverm 3y ago
      React doesn't do its own styling though, and since email will not run js, you are basically talking about css at this point
      - f-securus 3y ago
        Maybe that is the secret sauce of this service. They render the email with react and automagically convert that to something that works for email?
        nlh 3y ago
        I think they literally just use React as a templating language, basically. You write React components and this service renders them down to email-friend HTML. Like SSR but for email.
brigadier132 3y ago
The business wants to maintain the same consistent style with all communications to the customer. A lot of thought goes into design systems, they don't want to throw that away in their emails.
DylanSp 3y ago
I _think_ the idea is just to use React as a templating language to write HTML emails, rather than dealing with the quirks of email HTML directly; it's not about sending emails from the frontend.
- mbesto 3y ago
  But why use React to do that when you can achieve the same thing on the backend? https://mjml.io/ https://mjml.io/
  - DylanSp 3y ago
    The selling point is that this allows leveraging existing React knowledge, as per the founder's comment upthread.
  - mattwad 3y ago
    There's also react-mjml, a React wrapper around it. Works great, altho it's easy to mix up React props with mjml props. Just requires devs to actually read the documentation
    - zenorocha 3y ago
      Unfortunately, the react-mjml library is no longer maintained: https://github.com/wix-incubator/mjml-react#notice-this-project-is-no-longer-maintained-warning https://github.com/wix-incubator/mjml-react#notice-this-proj...
cobertos 3y ago
I've worked at a couple companies (medium-scale) with home grown email solutions. The server-side rendered templating grew into being used for HTML email as well. It helped the backend devs as the tech that rendered the webpages also rendered the emails (all server side rendering), and the frontend devs needed less training to go from just frontend to frontend + emails. It was sort of a path of least resistance thing and it did have its drawbacks.
- mbesto 3y ago
  > It was sort of a path of least resistance thing and it did have its drawbacks. This makes sense, but ya aren't there serious scaling implications to this?
  - cobertos 3y ago
    Not really? The system worked as designed for the years I was there and sent _many_ emails. Rendering a template was never so taxing as to not scale. From a workflow perspective, each email was a template file, so if you had a ton of emails it was easy to parallelize the work across frontend devs
solardev 3y ago
Simpler websites often don't need a backend anymore (beyond automated, managed hosting). Many of them can just e a frontend package that can be deployed anywhere as static output files (CDN, any file host, Vercel, Netlify, Cloudflare Workers, S3, etc.) In such a system, sending an email is traditionally a pain (well, email is always a pain, but even more so when you don't have a dedicated backend). Being able to fan that out to an API call (plus a template system already in your frontend's language) just means it's easier. The API part handles the transactional email and deliverability and all that. The React part helps with the handcrafting of emails using a familiar layout composition language (React). But that part is entirely optional; it's a separate open-source project anyway and you can use the API without React at all if you so choose (or conversely, use the React email templates without Resend).
- mbesto 3y ago
  This makes sense, but what if you're using a message queue to send transactional emails? Why would you put that logic on the browser?
  - solardev 3y ago
    Not quite sure I follow. Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later? That part of the logic wouldn't be in the browser (unless you're purposefully trying to emulate SMTP on the client for some reason). In Resend, for example, a 200 just acknowledges that their API successfully received your request and will attempt delivery soon. It doesn't necessarily mean the email was either sent from their SMTP servers or received by the recipient's server client. You can check delivery status later on in the dashboard: https://resend.com/docs/dashboard/emails/introduction#understand-email-events https://resend.com/docs/dashboard/emails/introduction#unders... (And then optionally receive that as a webhook later on, if you want to notify the user of success: https://resend.com/docs/dashboard/webhooks/event-types#email-delivered https://resend.com/docs/dashboard/webhooks/event-types#email...) ---- Edit: In case it wasn't clear, the value of something like Resend or (SES or SendGrid or whatever) is that you don't HAVE to write logic to handle the tricky parts of email delivery. You just send an API call to someone else's transactional email service and let them worry about all that. Bigger companies with dedicated staff/teams might want to inhouse a lot of that stuff, but there are a lot of smaller companies (or non tech companies) that still need to do transactional emails but don't necessarily want to maintain it in-house. In a resource-constrained team/org, it's the difference between a full-stack dev who has to split time between making the website and maintaining the backend(s) and infra, vs a cheaper frontend Javascript dev who can focus solely on the frontend UX/marketing/branding/etc.. The latter can matter more for direct-to-consumer companies who don't necessarily care about the backend as long as it works and isn't too expensive... those 3rd party services are usually much cheaper than hiring even a junior dev/sysadmin.

theallan 3y ago

I think the confusion is coming from the framing of "Email API for Developers Using React" as the title for this post. React has nothing to do with "an email API" as far as I can see. Your web-site is more clear in that it shows a Node.js snippet (and other environments, although funnily not just in the browser?). Then the site goes on to talk about the React components. Perhaps "Email API for Developers, with React components" would resolve the issue. The title as it stands suggests I wouldn't be interested in this at all since I'm not using React. But actually, as an e-mail API, I would be (e.g. with a Hugo site).

bagels 3y ago
Thank you, that's a lot more clear. I was going to click through to find out how they protect the mail server secrets when sending emails from the react based client.

mediumdeviation 3y ago

FWIW the Tailwind implementation in react-email is not well done. The code double render React to static markup just to parse it into DOM then parse out the style and className attributes using a lot of regex https://github.com/resendlabs/react-email/blob/main/packages/tailwind/src/tailwind.tsx#L48 https://github.com/resendlabs/react-email/blob/main/packages.... It's likely to be brittle and also very slow - slow enough to almost cause an incident when we tried to use it in production because emails were taking _seconds_ to render.

Rapzid 3y ago
So weird, not sure what all the requirements are. I might just call "getComputedStyles" on the DOM elements and use that to generate inline styles for all the elements. I have to imagine there are existing tools for all this..
- mediumdeviation 3y ago
  The emails are generated server-side, so there is no native DOM here to work with. There probably are existing tools for this, so yeah it's odd they're running with basically proof-of-concept quality code here.

quickthrower2 3y ago

I think the people that will love this are NextJS/Vercel people, who have decided React is for them for 1. Frontend, 2. Backend, 3. Build Time, and now want to add 4. Emails, and might want to reuse that <Layout> component they carefully crafted for emails too. I reckon if you become another integration in Vercel, and maybe a option to install your open source react.email is presented when installing Next, that could go a long way. I almost drunk the React everywhere coolaid (and have some NextJS projects) but not sure it is for me for various reasons (personal preferences), but plenty of people love that way of developing. Another thing, thinking of living the future. You mention deliverability. Nothing more deliverable than avoiding email all together. (You are not an email company). Will Gen Alpha use email much? That's all I'll say - something to think about.

herbst 3y ago

I know mustache, handlebars and many other scripting languages. I never used react and have no idea what tailwind is. As mostly backend dev with some slight frontend skills I don't get the selling point of this.