Help me understand the React selling point. Existing email sending software supports text and HTML because that's what email is. No email client out there supports JavaScript, virtual DOMs, event loops, SSR or any such fancy web technology.
Instead of hand-crafting an HTML template with <title> <p> <a> <h1> <img> <div> etc I'm supposed to use your custom React components (<Button> <Image> <Hr> <Link> ...) which you will promptly compile down to the tags I mentioned above. So...what value am I getting out of React at all?
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.
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).
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.
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....
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.
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..
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.
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...
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-em...)
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.
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.
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?
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.
Er, you can send the emails via whatever backend service you want. React merely acts as a templating language and when compiled down to HTML, you can then send the resultant file with Python, NodeJS, etc.
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...
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.
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.
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.
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
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).
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#unders...
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.
> 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?
No, I'm very familiar with transactional email services and why its superior to SMTP.
> You just send an API call to someone else's transactional email service and let them worry about all that.
100%. But you also need code to do that. Typically the front-end form calls a backend endpoint (a controller for example in MVC) and then the back-end manages the request with the external API. Hence why there are endless docs like this: https://docs.sendgrid.com/for-developers/sending-email/quick...
At scale, those calls are actually handled by a message queue (like Redis). If you let the front-end code handle it, you would likely get throttled by the transactional email service provider.
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.
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
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.
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.
"Instead of hand-crafting an HTML template with <title> <p> <a> <h1> <img> <div> etc"
You forgot a whole lot of <table>, all the inline CSS and all the IE11 comment hacks. Oh, and also OfficeHTML or whatever abomination that is called, because Microsoft Word 2003 also remains alive inside Outlook.
Most people doing anything of medium complexity is already using some abstraction layer, such as MJML [1]. Also remember you gotta either test on multiple clients, or use something like Litmus.
Manual coding is getting very inefficient since it takes hours plus it requires a lot of testing (ie with litmus or emailonacid).
There are modern alternatives to manual coding both for developers (embeddable editors for SAAS) such as beefree, unlayer, chamaileon, stripo and for email designers like beefree, stensul, knak, stripo, taxiforemail...
To be fair I am using a very limited 'style' for all my emails and usually they just work. Everywhere
In my experience the more shiny the email is, the more logos and whatever components are around the actual content the less clicks I get. So i try to be just a branded level above a text email.
Yes, normally I'm a little adverse to abstractions over HTML, but HTML for email is so convoluted and non-standard that I think in this domain it makes a ton of sense. There may be a world of devs specialized in HTML that works in Outlook (bless you folks) but for this dev used to targeting the browser something like mjml is a lifesaver.
HTML is not designed to work over email and is not capable of describing an email thread, a conversation. Aside from that HTML over email is ridiculously trivial. Super trivial. It isn't the HTML that is challenging but the CSS over email that is challenging. It takes some practice to figure out, but if you are even remotely competent you DO NOT need table insanity. Tables are for tabular data only.
These are screenshots of actual emails I created back in 2006 for a company that no longer exists. It's a bit easier now than it was back then.
When you have absolute freedom to design the emails around the limitations, sure, that works and is certainly much better than the soup of tables and IE11/Office stuff.
However even with that you still gotta test on multiple clients.
If you want to use something like border-radius, for example, it won't work on some versions of Outlook, for example [1]. You either show a slightly different layout or you use workarounds. There are plenty of other examples like that.
I personally just use very simple emails, so it's <p> and <h1> etc. But other people have to work around those limitations, and not everyone is a developer with design knowledge that can tweak the design to a point where it is both simple and good looking.
HTML for emails is notoriously difficult to get right. To be decent, HTML emails require arcane CSS rules, inline CSS, table layouts, etc., and testing in many different clients (because they all have their own quirks). Fixing something in for a client without breaking it for another client is not straight-forward either. Email solutions have worked around this via premade components—as a template, in React, or even as a UI with drag and drop.
I was in a meeting a while back where a team that was tasked with standing up a few dozen completely static websites was discussing what React components to use. I asked why they were using any front-end JS framework at all and not just creating static html sites, maybe using a generator like Hugo or Eleventy if they wanted to templatize. The answer was that they didn't know how to create plain html sites without JS. That was moderately shocking to me. I offered to work with them to create the static html solution and they declined, saying they could be more productive with React.
they declined, saying they could be more productive with React
As much as it pains me to say so, they're probably right. If they don't know how to make a static site, and they're familiar with something like Next, then they probably can go faster and just let the framework take care of building the assets.
I wish people still made static sites using boring tech but times have moved on, but honestly there isn't much difference in complexity between a NextJS static site and a Hugo or an 11ty static site.
Edit: And OP mentioned he suggested Hugo or some other solution which is miles behind tools in JS/TS world. Not to mention it is Python based and this team knew React
If you are building static sites, all you are doing with reactjs is abstracting parts via components, right?
All it takes is to actually write the html that goes into a component, rather than the component. I don't see how any react dev wouldn't be able to do this.
Also, I, too, would rather use react. I'd rather be able to reuse components I already have or to make some to reuse later, and to keep the project organized in that way, plus future-proofing the project to a certain degree.
Because I want to write JS(X) instead of having to suffer through learning yet another templating DSL. I don't understand why this si so hard for people to understand, templating languages suck.
You get the comfort of using react components instead of fighting with HTML tables to make your emails look nice. I think it's awesome! It's analog to what ink[0] does with CLI outputs. Sure, you could write fancy CLI outputs in bash, but ink takes the pain out of it and makes it easy.
It's also like react-pdf, where they give you react components to easily build out a PDF document without getting into the nitty gritty of the PDF spec. I'm a fan of this paradigm
Having worked on a number of product email systems where you have an existing codebase, while not exactly intuitive this is basically exactly what I've wanted. You can easily code share environment-agnostic code with your frontend (Things like user-facing text formatting, localization, handling of commonly shaped API objects like users, generating links to specific pages.)
It also leans into a lot of email code best practices. Clear inputs and outputs and unidirectional data flow with React props, building reusable and composable components that work in all email clients without having to hand-rewrite table tags, and an easy way to inject test data or build out email templates before you have real data.
I've used react-email on one project now, and would happily re-use it in a future project where a team is amenable to having some TypeScript in their backend.
My one complaint / feature request is that it'd be really nice to have a way to basically "export" react-email into low or no dependency functions, since effectively all it's doing at the end of the day is providing you a function where you pass it an object, and it returns a string.
It's what every software developer out there using mindlessly. They are just putting React components and mixing them. NextJS also helps shield them from the back-end. You'd be surprised how many of them cannot differentiate between the back-end and the front-end and which parts are being executed by the server (it's netlify!).
I don't think it's just us getting old. Newcomers to the filed don't really understand HTML and CSS. It's just "React components" to them, and they aren't looking deeper than that.
I'm getting the feeling that a lot of old timers also don't understand HTML and CSS in emails, from the responses I'm seeing here.
There are a lot of reasons to have abstractions over HTML/CSS in emails, for all but the trivial cases. It is notoriously difficult to get right, since there are some features lacking and standards in the email client space moves way slower than browser.
A regular marketing HTML email would look unrecognizable to a lot of old timers.
That's pretty unfair. It doesn't look like an html page they'd create for the web but I'm pretty sure they'd recognize html and css. Would someone who templated it in react see the connection?
As long as you stick to only HTML that was available in the year 2000, and use zero CSS, your mails will come out the same in pretty much every client.
I see it more as a way to provide better Developer/User Experience over existing mailing services. It seems to be the main selling point of the entire platform. Given that it's price-competitive with other services, it might be enough to attract users looking for new solutions and possibly even convert those already using other services.
On a side-note though, emails really need an update. No, they don't have to support JS, but at least modern CSS options. Adjusting layout with tables and CSS float just doesn't seem right nowadays. I basically always use an email builder, just because desiging a good email is so tiresome. Using React can help make it easier, but some work has to be done by the email clients to get more up to speed with modern Web standards.
Instead of hand-crafting an HTML template with <title> <p> <a> <h1> <img> <div> etc I'm supposed to use your custom React components (<Button> <Image> <Hr> <Link> ...) which you will promptly compile down to the tags I mentioned above. So...what value am I getting out of React at all?