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