61–70 of 277 posts
No mention of PHP SDK? I see your docs mention a composer package in the PHP section.
[0]: https://github.com/resendlabs/resend-php [1]: https://github.com/resendlabs/resend-laravel
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 etc I'm supposed to use your custom React components ( ...) which you will promptly compile down to the tags I mentioned above. So.…
etc"
You forgot a whole lot of , 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.
HTML emails are no fun.
[1] https://mjml.io/
But what if I'm just a regular developer who doesn't use react? /s
Resend innovates at simplicity, no crappy dashboard, clean API design.
Thanks you.
Earlier quoted context omitted.
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…
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...
Earlier quoted context omitted.
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!). Anyway, maybe I am getting too old?
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.
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.
Earlier quoted context omitted.
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…
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...
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).
I ask because it takes a long time to build up trust reputation among the major email providers to help ensure deliverability.
https://github.com/siguelaola/mjmgr
It would let you write emails in mjml and react, and upload, manage and version them on Sendgrid. I had planned to make it a flexible system with support for other providers etc.
If someone wants to maintain or build on it, let me know.
Which existing providers are you using on the backend for delivery? Mailgun, Sendgrid? I ask because it takes a long time to build up trust reputation among the major email providers to help ensure deliverability.