[HN Gopher] Launch HN: Resend (YC W23) - Email API for developer...
___________________________________________________________________
Launch HN: Resend (YC W23) - Email API for developers using React
Hi HN! I'm Zeno, founder of Resend (https://resend.com). We're
building a modern email sending platform focused on providing the
best developer experience. Why? When you look at all the biggest
competitors like Sendgrid, Mailgun, Postmark, and SparkPost, you'll
notice that they were all founded around 2009/2010, and they all
have been acquired by now. Because of that, it's common to see them
only prioritizing enterprise requirements and optimizing for sales-
led growth. Nobody is building an exceptional developer
experience. Nobody is trying to innovate. There isn't a single
developer-first email platform in the market today. We want to
change that. Email sending is the kind of thing that you should
integrate and forget, but instead, you have... - Templates that
are hard to build: Typically, you can only send emails using HTML
or plain text. Although we support both, we're introducing a new
way of developing and sending your emails. With Resend, you can
code your email using React instead of outdated <table> layouts
thanks to our open source project (https://react.email). - Slow
performance: Current solutions only offer a single region for email
sending, even when all your end users are located in another part
of the world. We allow you to choose what region your emails should
be sent from (US, Europe, or LATAM), which minimizes latency and
improves time-to-inbox. - Poor observability: Most tools keep you
in the dark without knowing what really happened after you sent an
email. Resend exposes all the events associated with your email via
webhooks. - Designed for marketers only: Existing solutions are
too generic and built exclusively for product marketers and product
managers. We're building a platform with a clean REST API and SDKs
for Node.js, Python, Ruby, Elixir, Go, and Java. We also have
examples of how to send emails using Vercel Edge Functions,
Cloudflare Workers, Supabase Edge Functions, and other serverless
solutions. What's our backstory? When I was a CPO at Liferay, I
faced the problem of sending emails at scale. We had enterprise
customers complaining about deliverability, and I've been
frustrated with existing services ever since. More recently, as a
VP of Developer Experience at WorkOS, I once again had to deal with
emails landing in the spam folder. After looking at all the
different solutions out there, I've been obsessed with the idea of
solving this problem once and for all. We need to stop developing
emails like it's 2010 and rethink how email can be done in 2023 and
beyond. We believe that email development needs a revamp. A
renovation. Modernized for the way we build apps today. That's why
we're building Resend. What issues have you had with email
sending? I would love to hear your ideas, experiences, and feedback
on any and all of the above.
Author : zenorocha
Score : 357 points
Date : 2023-06-13 12:16 UTC (10 hours ago)
(HTM) web link (resend.com)
(TXT) w3m dump (resend.com)
| Dowwie wrote:
| +1 for supporting Elixir from the starting line
| renewiltord wrote:
| For me, the biggest annoyance was not being able to Zapier in new
| entries into a drip campaign. I just refused to use providers I
| couldn't zapier together. For the section of the market that is
| small time, I am not going to implement custom API integration.
| No zap, no deal.
| SCUSKU wrote:
| Small piece of feedback, but I clicked on the Get Started button
| expecting to see docs on how easy it would be to use your product
| but instead was directed to a login page, so didn't look any
| further.
| codegeek wrote:
| So I have used Sendgrid, Mandrill, SparkPost and SES in
| production and dabbled with Mailgun for side projects. The
| biggest issue I have is with Logs where other than Mandrill, no
| one shows the actual Body of the email in logs. For our purposes,
| we need that.
|
| Do you log the Email body ? If yes, I will give it a shot.
| bashy wrote:
| Postmark[0] have that and store it for 45 days[1] which is
| really handy. I use them, not affiliated.
|
| [0] https://postmarkapp.com/ [1] https://postmarkapp.com/email-
| analytics
| ozr wrote:
| They announced extended retention as well recently, up to a
| year.
| bashy wrote:
| Yes, 'paid' add-on.
|
| Don't store content - Requirements
|
| 7 days - $5 per month 28 days - $5 per month 45 days
| (Default) - Free 90 days - $5 per month 180 days - $8 per
| month 365 days - $12 per month
| dazbradbury wrote:
| Mailgun will store the email body for 3-7 days (depending on
| plan/settings). I'm definitely not an advocate of mailgun as a
| whole, but their logs are really good in my opinion.
|
| Are you stating you want the email body indefinitely though?
| Does Mandrill store this? I'm yet to fully check them out.
| RaiyanYahya wrote:
| This is so cool. I am going to build a command line app around
| this. Love it! All the best!
| zenorocha wrote:
| Awesome! Can you show me when you're done? I'd love to see it
| :)
| RaiyanYahya wrote:
| why would anyone downvote this ? ffs
| pxue wrote:
| Any thoughts on third party integration such as segment?
| zenorocha wrote:
| Definitely on the roadmap
| hoofhearted wrote:
| I have been looking for a basic Mailgun type transactional email
| service for my React based project, and I believe this is exactly
| what I need.
|
| I asked Adam to think about designing some reusable transactional
| email templates for Tailwind UI a few months ago. It looks like
| Resend would pair right up with Tailwind perfectly :)
|
| I added Resend to my R&D to do list, and I hope to partner up
| soon: https://github.com/elegantframework/elegant-cli
|
| Congratulations on the launch, and keep up the great work!
|
| I saw that Guillermo also to note of your work, so props on that
| too!
| zenorocha wrote:
| That's pretty cool! You should definitely try Resend if you're
| already using Next.js, React, and Tailwind.
|
| This should be a good place to start:
| https://react.email/docs/components/tailwind
| leggetter wrote:
| I had the chance to get hands-on with Resend during the private
| beta and found the Resend dashboard DX features to be really
| helpful during the development process. HTTP logging, email
| filtering, and webhooks (also with logging).
|
| Being able to create email templates in React is great, too.
|
| The very best of luck to you Zeno, and the rest of the Resend
| team.
| zenorocha wrote:
| Thanks leggetter, it means a lot coming from you.
| enono wrote:
| This is awesome! I have a project that I need to send some emails
| on so this is perfect
| zenorocha wrote:
| Cool! Let me know if you need any help with the integration
| lowercased wrote:
| No mention of PHP SDK?
|
| I see your docs mention a composer package in the PHP section.
| zenorocha wrote:
| We do have PHP [0] and Laravel SDKs [1]. It's mentioned on the
| homepage as well.
|
| [0]: https://github.com/resendlabs/resend-php [1]:
| https://github.com/resendlabs/resend-laravel
| jonas_kgomo wrote:
| It's good to note that this product has an open-source version
| https://react.email/docs/introduction
| zenorocha wrote:
| Both founders come from an open source background, so having
| some sort of open source component was very important to us.
| calmworm wrote:
| Not for nothing... your site (resend.com) is a HUGE CPU hog. I
| didn't get a chance to view or read anything on the site because
| I quickly closed the tab after my CPU rocketed up.
| zenorocha wrote:
| Would you mind sharing what computer/OS/browser you're using so
| we can try to reproduce on our end?
| hamasho wrote:
| Not 100% but it looks like using ~10% of single core on my
| macbook too (It's too much for a static landing page).
| Perhaps it's caused by the black Rubik's cube animation on
| canvas.
| usernamebias wrote:
| Just use Mailgun.
| trollied wrote:
| You state that deliverability is the problem that has been your
| pain point for years & you want to solve it.
|
| I have 1 question.
|
| How?
|
| 'cos React email templates isn't the answer to that.
| mercurialsolo wrote:
| What i would really love to see in a developer email service is
| also some workflows baked into the emails. There's a ton of times
| you would want to wire up a service and just set it for
| transactional events but also as sequences and with a default set
| of templates wired up. Think Zapier meets Sendgrid for emails and
| a set of templates maybe wired for default dev flows like Signup,
| Verification, Billing receipts.
|
| We do use SG for transactional emails and their email DX is
| frankly abysmal. Also not a big fan of html for transactional
| emails but sometimes you gotta do it.
| zenorocha wrote:
| That's great idea! Today we have some integrations
| (https://resend.com/docs/integrations) available, but it
| requires you to use a separate service.
| rolfkip wrote:
| This sounds a lot like ServiceNow to me
| filipedeschamps wrote:
| Hi Zeno! To help you have some reach in Brazil, I just posted
| this on TabNews:
| https://www.tabnews.com.br/filipedeschamps/resend-nova-plata...
| mr90210 wrote:
| Filipe, that's really nice of you! Cheers!
| zenorocha wrote:
| Ohh nice, thanks for the cross-posting there Filipe!
| pelcg wrote:
| > Why? When you look at all the biggest competitors like
| Sendgrid, Mailgun, Postmark, and SparkPost, you'll notice that
| they were all founded around 2009/2010, and they all have been
| acquired by now. Because of that, it's common to see them only
| prioritizing enterprise requirements and optimizing for sales-led
| growth.
|
| So does this mean that Resend _won 't_ get acquired? What is your
| exit strategy other than an acquisition?
| 1thrasher wrote:
| I think this misses the point: regardless of Resend's exit
| strategy, they are innovating _now_ , unlike the competition
| (allegedly), and that's the value proposition.
| pelcg wrote:
| ...Until they have an exit, and they can only have this
| because they took funding, which is my point.
|
| I remember MailChimp not taking any funding for over 20 years
| and being completely bootstrapped, innovating and useful
| until they eventually got acquired and not shutdown.
|
| Also the same for Postmark.
|
| Both are profitable and were bootstrapped for years.
|
| Sometimes it all ends the same way, the question is how long
| for Resend. Since they've taken funding as it is highly
| likely they are heading for an exit in under 10 years.
| paxys wrote:
| "All the big players in the space got acquired or had a big
| IPO. Instead of supporting them choose our scrappy VC-backed
| startup so that one day _we_ can get acquired or have a big
| IPO. "
| pelcg wrote:
| This is what I was thinking possibly an IPO.
|
| Resend would need to expand beyond their main TAM when they
| get email right.
|
| I'm wishing them the best.
| iamacyborg wrote:
| > Poor observability: Most tools keep you in the dark without
| knowing what really happened after you sent an email. Resend
| exposes all the events associated with your email via webhooks.
|
| I can't think of a single email platform I've used as an email
| marketer/crm marketer for a decade that didn't expose a full
| event stream for all emails.
| meesles wrote:
| Sendgrid doesn't log sent email bodies, as a simple example.
| Think harder!
| roflyear wrote:
| Their webhook doesn't send the full body? I'm sure you at
| least get the data if not the exact data sent...
| goenning wrote:
| I don't think any email provider sends the body via
| webhook. AWS SES certainly doesn't, which I think Resend is
| built on
| kevinob11 wrote:
| Mailgun does
| bhandziuk wrote:
| If SendGrid fails to send an email it won't tell you why or
| that you even attempted to send an email.
| [deleted]
| tifani wrote:
| SendGrid exposes it for like 14 days I believe. I tried like
| hell to get data from before that and support told me you're
| required to store that yourself. So not super helpful until you
| realize you needed it in the first place.
| iamacyborg wrote:
| This is very true, but I can understand why a transactional
| provider probably doesn't want to sit on masses of old data
| like that. Marketing ESP's all usually store the data
| indefinitely.
| pascal07 wrote:
| Postmark shows the body for 45 days by default, and it can be
| extended to up to a year. https://postmarkapp.com/email-
| analytics
| xyst wrote:
| > Poor observability: Most tools keep you in the dark without
| knowing what really happened after you sent an email. Resend
| exposes all the events associated with your email via webhooks.
|
| Isn't this what DMARC is for? I have this setup (along with SPF)
| with my domain with a strict "reject" policy and a dedicated
| inbox to receive delivery reports.
|
| I do like that you are tracking whether the recipient opened the
| email or not. But most email clients are no longer loading images
| (including the "tracking pixel") by default so this nice
| feature/metric can be misleading.
|
| > More recently, as a VP of Developer Experience at WorkOS, I
| once again had to deal with emails landing in the spam folder
|
| This usually means DMARC is configured incorrectly or just too
| many of your recipients are marking the emails as spam.
|
| Besides the ability to write templates using react syntax, I
| don't see why developers would use yet another centralized
| service in production.
| jabart wrote:
| The changes to tracking pixel is a bit complex. Yes some email
| clients do not load any images. Other email clients load the
| image through a proxy to hide the user IP (google/yahoo).
| Apple's Mail Privacy Protection (MPP) loads all images at the
| time it was delivered to a device. That metric is still very
| useful because you know the device received it and it's an
| active email address. Versus the alternative is to send an
| email and wait for an click if they have images turned off.
| LeonM wrote:
| DMARC is an anti-impersonation standard, not anti-spam.
|
| DMARC alignment is trivial to set up, so even spammers can do
| that. That, amongst other reasons, is why all major spam
| filters are based on content, not DMARC alignment. This is why
| you can have 100% DMARC alignment and still end up in spam.
|
| Failing to meet DMARC alignment will result in your email being
| marked as suspicious (with a big fat warning), or flat-out
| rejected (not delivered), but it typically won't be marked as
| spam (unless content is flagged as spam, of course). What
| exactly happens on DMARC unalignment somewhat depends on your
| DMARC policy, but mostly on the policies/implementation of the
| receiving provider. Each provider handles DMARC unalignment
| different.
|
| One thing that is consistent, is that none of the email
| providers will reflect in any way if your email is flagged as
| spam or not. Otherwise spammers could trivially figure out
| which content trigger spam filters, and which content won't. A
| DMARC report will not tell you if your email is flagged as spam
| or not. This is also why most email providers will always fetch
| and cache tracking pixels, again to not expose to a potential
| spammer if their content made it into an inbox or not. This
| behavior makes it look like every receiver has opened the
| email, even though it never happened. This makes tracking
| pixels useless.
|
| So, Resend's claim to show you 'all the events' means they can
| display how many mails were send, how many have bounced (due to
| various reasons, except spam), and how many tracking pixels
| were loaded. But as explained, the number of pixels loaded does
| not, in any reliable way, reflect the number of emails actually
| making it to the recipient's inbox.
|
| Reliably sending email is an insanely hard, you can never
| guarantee delivery with email anyway. If the 'React' email
| template editor is the novelty in Resend, I'd suggest them
| using something like SES to actually send the email. Don't try
| this yourself, until you verified your product-market-fit and
| have the scale to invest (heavily) in your own delivery
| network.
| lucasfcosta wrote:
| Congratulations Zeno! What an awesome launch, really excited for
| you and the team at Resend.
|
| Once we go for an email provider here, Resend will definitely be
| the first option.
| zenorocha wrote:
| Thanks a lot lucasfcosta! Let me know when you start
| integrating, I would love to hear your feedback.
| [deleted]
| isnhp wrote:
| Congrats Zeno. Have tried today and falling in love with Resend.
| Currently installed it with my sites. Easy to setup and looks
| stable. Would you plan to announce another plan in the middle of
| Free and Pro? I think 20 monthly and 50k emails sometimes
| overusing. 10 monthly and 20k emails or something.
| davidnordhausen wrote:
| Looks great Zeno! Does the "Dedicated IP" increase the volume I
| can send through a specific domain?
| HappyCathode wrote:
| That looks promising, I'm currently looking at Sendgrid and
| Mailgun.
|
| 2 points I would bring :
|
| - You need a cheaper plan. Mailgun have their flex plan that's 0$
| for 1000 emails per month, and then 1$ for any extra 1000. It
| would cost more to send 50k emails, but I'm not there yet, I need
| a cheap starter plan with a lot less emails. My total infra cost
| is going to be around 30$, so I'm not going to drop an extra 66%
| to send maybe 1000 emails per month.
|
| - If I reach my plan limits, you need to still deliver my emails
| and I' ll happily pay for them. Your FAQ says : If you exceed
| your plan limits, you will be notified and given the option to
| upgrade to a higher plan. If you don't upgrade and repeatedly
| exceed your plan, your account may be temporarily deactivated.
|
| My platform relies on emails to register users, MFA backup and
| transactions invoices. So if my email provider doesn't send my
| emails, my platform is broken. Yes, I could "just" keep an eye on
| my usage, look at it multiple times per day. I could also take
| some of my time to put some monitoring in place to wake me up at
| 3AM if there's a spike in traffic and I need to upgrade my plan.
|
| Or, I can do none of that and register to a Mailgun Flex plan, or
| a 20$ Sendgrid plan, and not spend my time babysitting my email
| provider. Both Mailgun and Sendgrid allow going over plan quota
| and just charge you a premium. Don't not deliver emails, you're
| an email provider, that's disruptive.
| mediumdeviation wrote:
| Do not use Mailgun. Their support is extraordinarily poor if
| you use it for something mission critical. We've had our
| grandfathered in account downgraded twice now resulting in
| outages, and their support took _days_ to respond.
|
| They were bought out by Private Equity a while ago so it looks
| like they are in the stage where the company's value is being
| extracted.
| KomoD wrote:
| > They were bought out by Private Equity a while ago so it
| looks like they are in the stage where the company's value is
| being extracted.
|
| Same is probably going to happen to this.
| moffkalast wrote:
| > Email API for Developers Using React
|
| But what if I'm just a regular developer who doesn't use react?
| /s
| zenorocha wrote:
| That's totally fine, you can still send emails using HTML or
| Plain Text.
| perpil wrote:
| Watch your free tier very closely. An unfortunate part of being
| in the email business is that spammers and phishers are always
| looking for free ways to send their emails on ips with a good
| reputation. It quickly becomes a game of cat and mouse which
| detracts from the business, so make sure you have a effective
| strategy to prevent misuse when allowing customizable emails with
| a generous free tier.
| zenorocha wrote:
| Thanks a lot for the advice here. That's definitely an area
| where we spend a lot of time and one of the reasons why we've
| been under a private beta for the last six months.
| kylegalbraith wrote:
| We use Resend for our transactional email at https://depot.dev
| after migrating away from Postmark following their acquisition.
| It's been awesome so far and because our app is Remix underneath
| the hood, it was delightfully easy to get our emails exactly how
| we wanted them.
|
| The visibility into what emails have been sent, to who, and what
| the content was is also incredibly helpful when we are talking
| about transactional emails. Double bonus for being able to share
| that email as well.
| snow_mac wrote:
| How long have you been doing this startup for?
| zenorocha wrote:
| We officially started in January
| santialbo wrote:
| I built something using react-mjml and storybook (storybook-
| server). It takes a bit of plumbing but the devx is very nice.
| zenorocha wrote:
| That's why we built react.email, you should check these
| examples: https://demo.react.email/preview/airbnb-review
| _Bruno42 wrote:
| Just FYI, https://www.resend.com should have a 301 to
| https://resend.com
| zenorocha wrote:
| Totally, adding that 301 redirect now
| swyx wrote:
| this really ought to be a vercel default. idk why so many
| platforms (like netlify too) require/default to www
| subdomains. defeats the purpose of acquiring a short domain
| revskill wrote:
| How do people actually use Sendgrid, Mailgund,... and any crappy
| email services outhere ? Day by day, i got upset and stressful
| working with "enterprisey offerings".
|
| Resend innovates at simplicity, no crappy dashboard, clean API
| design.
|
| Thanks you.
| cusx wrote:
| Why limit it to 100 emails a day for the free plan? Makes the
| 3000 limit feel like a false advertisement unless you have 100
| users signing up every day.
| KomoD wrote:
| > false advertisement
|
| No, very clear, quite literally right below
|
| "
|
| Up to 3,000 emails / mo
|
| 100 emails / day
|
| "
| gokulkrishh09 wrote:
| [dead]
| swyx wrote:
| this is the most gorgeous dev tool design/website i have seen in
| a long time. and you JUST graduated from YC? amazing
|
| my real question is - how do you ship so fast _and_ well? what do
| you trade off to be able to do this?
|
| for email - my main wish is that it be integrated well with an
| auth and analytics system. the emails i send out should be aware
| of what the user has done, and if you've given me your email i
| should already have created an account for you, etc. seems all
| like one and the same - have a total representation of the user.
|
| i am guessing i'm far from the first to talk about this. so the
| smaller, second idea, is just a good/gorgeous "contact center"
| like experience with multiple channels and levels of email
| engagement that people can opt in/out of. so eg you can choose to
| get emails from me every day/week/month/quarter/year, or based on
| specific topics. one can of course build this with resend, but it
| wouldnt be GREAT. people/developers/startups need help making
| this usually overlooked experience GREAT.
| zenorocha wrote:
| Thanks for the kind words!
|
| Shipping software, to me, is like a heartbeat.
|
| You need to ship small improvements in a steady rhythm, but you
| also need the big spikes which represent the major releases. If
| you only ship minor things every week, people won't care. If
| you only ship one thing every year, people will forget. It's
| important to find a balance between both.
|
| When it comes to quality, it's a matter of asking ourselves:
| "Are we proud of this?" There were two occasions when we
| discussed shipping this website sooner, but we decided to
| postpone it because it simply wasn't quite there yet. Sweating
| the details is more important than people think.
| zenorocha wrote:
| About your email wishlist - I agree entirely.
|
| The more integrated it is with auth and analytics systems, the
| better and easier it will be to get started.
|
| The whole unsubscribe flow is overlooked by most companies, and
| having a built-in drop solution for this would be awesome.
| benatkin wrote:
| > We need to stop developing emails like it's 2010 and rethink
| how email can be done in 2023 and beyond.
|
| Do you have any awareness of how tacky this sounds?
| geekrax wrote:
| Not sure if you are actually developing the emails or not, but
| from a front-end developer's perspective, I hate to touch my
| email templates codebase because it _has to be_ coded in
| certain way that works with the email provider.
|
| I cannot see what the end result is going to look like until I
| actually send out a test email and see it in my email clients.
| This DX indeed feels like 2010 if you compare it with today's
| DX for developing websites.
| benatkin wrote:
| Yes, I am.
|
| So this is like Litmus?
| aziaziazi wrote:
| > they were all funded [...] they all have been acquired by now
| [...] nobody is trying to innovate
|
| > rethink how email can be done in 2023 and beyond to innovation
|
| 1. Is your plan to follow your competitors path from innovation
| to acquisition to status quo and be the BestPlatform for the next
| 10 years, waiting for the next innovating startup to take over?
|
| 2. Or do you consider keep on innovating, following the JS or DX
| trend or whatever clever innovation? If so what's your plan to
| keep on innovating after acquisition whereas others failed ?
|
| Thanks for the post and good luck.
| damianricobelli wrote:
| We are using Resend for our new products at GuruHotel (YC19) and
| the experience is really impressive. It has never been so easy to
| create email templates. The Resend dashboard is simple and clear,
| we love it.
|
| Best of luck Zeno, keep it up
| zenorocha wrote:
| Thanks damianricobelli! We spent a lot of time making sure that
| dashboard was simple and clear, I'm glad you noticed it :)
| lbriner wrote:
| We have built out some of the things you said were missing for
| our email system at SmartSurvey. The biggest annoyance is random
| blacklisting from email providers. Mimecast almost always
| greylists us, which is annoying because it creates an artificial
| baclog on our mail servers, others work fine and then all of a
| sudden they block you - sometimes you can contact them, sometimes
| you can't.
|
| We also have a big problem with automated tools like mimecast or
| Office365 because customers don't receive emails that were
| blocked by some rule or heuristic or other but they just contact
| us because they can't see what their receiving system has done.
| Even when we show them the logs.
|
| Our sysem sends out about 50 different types of email and some
| are easy to handle when they bounce, others are not so easy so it
| will be interesting to see whether your use of webhooks will make
| things that much better than e.g. MailJet (who we use for some
| emails) since all of email failures arrive via webhook.
|
| Other problem is to do with IP ranges of the sending servers.
| Using SES probably mitigates some of that (I assume most
| providers whitelist SES) but if you ever wanted to move to your
| own hosts, without a /16 subnet, you can easily get blacklisted
| (again for unknown reasons) and without enough servers to move
| to, your deliverability suffers.
|
| I think the one thing that would help us if we were using a
| third-party system would be failure messages with specific links
| to solutions that could be displayed to the end user. e.g.
| MimeCast 5.7.2 could link to an article about giving permissions
| to access a Mimecast mailing list. That would save a lot of
| explaining since we would just show that message to the customer.
| presentation wrote:
| Reading through the docs, some thoughts:
|
| - RE Observability, the lack of APIs to tag emails and retrieve
| them by tags makes this worse from that perspective to me because
| I've used Mailgun's APIs before to pull down all emails we've
| sent in a burst to allow reconciling it against external data. No
| way to export data programmatically means that I can't really do
| that type of reconciliation.
|
| - some weird things in the docs like in the NextJS example it
| provides both raw HTML and react bodies for the email; not sure
| what this means. Also not clear why you don't use JSX to render
| the email templates which seems not that idiomatic.
|
| - as mentioned in a separate comment, GDPR/SOC2 stance would be
| good to know.
|
| But looks promising, been burned by incumbents just generally
| having bad support, so looking forward to variety here.
| stevoski wrote:
| You mention that you have a Java SDK but I can't find it on your
| website.
|
| Can you please share a direct link to the Java SDK?
| xyst wrote:
| Not the OP. It's not listed in the "quick start" section of the
| docs but their SDKs are available on GH. This is their Java SDK
|
| https://github.com/resendlabs/resend-java
| martinald wrote:
| I don't really see as most of these features being particularly
| new or different, there are loads of SDKs and packages around for
| rendering emails and sending them with various providers. It's
| really a non-issue.
|
| Deliverability is the #1 problem all developers actually face
| with this imo. We have perpetual issues with extremely high
| importance, but extremely low volume transactional email from
| admin panels alerting various (usually non technical) people to
| things. For example; an important extremely high value custom
| order has been requested and requires senior signoff in a
| platform. As far as I can tell nothing really suits this, it's
| too low volume (<1k emails a month - maybe even a few emails a
| month) for it to work well with dedicated IPs and shared IPs
| constantly get spam blocked on the major MSPs.
|
| In the the end we tend to use SMS or slack/teams webhooks for
| this.
| birdman3131 wrote:
| I have had good luck with MXRoute for this. They have a fairly
| strong antispam stance on their platform.
| martinald wrote:
| Oh, great shout. Thanks.
| nik736 wrote:
| Your competitors have been acquired but you are funded by YC...
| so there is a high chance this will happen to you as well.
|
| There isn't much innovation happening since email is stable. I
| don't want to design my emails in React, but I am probably not
| the target group since I am still running my own mail servers.
|
| Edit: What I meant by "email is stable" is basically the way
| email is being sent and not email itself and the experience
| around it.
| robertlagrant wrote:
| I disagree. Those companies were all made long after email was
| stable, but having used SendGrid I can say it's definitely not
| the best DX, and it is indeed tailored to marketing.
| SkyPuncher wrote:
| I absolutely want to design my emails in React.
|
| I loath building email templates. It brings me back to the old
| days of terrible HTML tables.
| zenorocha wrote:
| That's a valid point.
|
| The web is also pretty stable, but when you look at the past
| 10-15 years, there's been so much evolution around it.
|
| Doing things like rounded borders or dark mode is still very
| difficult, especially when you take into consideration all the
| different email clients like Gmail, Outlook, Yahoo Mail,
| Superhuman, and HEY.
|
| The web evolved, and now we don't hear too many complaints
| about having to design your website to look the same across all
| browsers as before. Unfortunately with email, this is still an
| open problem.
| Alex3917 wrote:
| > There isn't much innovation happening since email is stable
|
| There are probably more Show HN launches involving email than
| any other product category.
| devjab wrote:
| Having worked with a few of them, currently with SendGrid I
| think the market is ripe for disruption. It's a terrible,
| terrible, experience to work with these systems when you need
| e-mail visibility to play into a larger setup. We're doing
| simple stuff, like giving our sales personal an information
| stream to track that links into their HubSpot and a few other
| systems, and it's frankly so bad that one of our developers
| wrote as much of the business logic as was possible outside of
| SendGrid. I'm sure it works well for the IT services part of
| our operations, but for development and automation purposes
| when you need to put some gaffatape on all those 300 systems
| that your business bought. Then it's not very good.
|
| As far as being YC funded, well, that's the purpose of HN isn't
| it? I'm not personally convinced that you can't maintain a good
| product after you getting acquired. I haven't used these
| services enough to say, but maybe they fit into the market of
| their time, and has then failed to innovate or keep "great" in
| the decades that followed? If you ask our IT operations they
| will tell you that SendGrid is great.
| axiak wrote:
| Out of curiosity, if you are spending a lot of effort to
| track the data in HubSpot, why not try to send emails
| directly in HubSpot?
| devjab wrote:
| Because that would make sense.
|
| Or the slightly longer version of how HubSpot is sort of
| our CRM system but also a front end for our on-prem
| Sharepoint and our Microsoft CRM and a couple of other
| things. It can send some emails, but not all emails, and
| when it does send emails someone wants them tracked not
| just by HubSpot but also by SendGrid because that's how we
| track mails in parts of the business. Why do we have both
| HubSpot and Microsoft CRM you ask, well you are, one
| department really likes one of them and another department
| really likes the other.
| axiak wrote:
| Thanks for the insightful reply! :D
| fluffyspork wrote:
| I've been dealing with email deliverability for the past 4 days
| as part of a new project.
|
| The requirements are to send login codes when the user provides
| the email for a likely small site (maybe 100 active users a
| month). Eventually maybe send 1 email per day per user for
| notification reminders or something. Everything is transactional,
| no marketing. (Are notifications marketing or transactional?)
|
| I'm directly implementing the http call. Most services don't have
| that different of request JSON so it's pretty straightforward.
| I'm likely not going to use the API for anything else. A curl
| example will typical show everything I need to know.
|
| The emails I want to send are basically SMS style messages. No
| HTML or other noise. I would prefer no body logging. I assume
| such short messages may be an issue for spam filters?
|
| subject: login code body: login code: abcd
|
| (I did have the login code in the subject too, but those show up
| in some console pages and I suppose are more likely to be logged)
|
| SendGrid
|
| I initial used SendGrid since we used it at my prior job.
| Generally fine when using gmail addresses, but every non-gmail
| mta was rejecting the emails due to the IP being in multiple
| blacklists. So as a new SendGrid account we were placed in a
| shared IP pool with blacklisted IPs.
|
| A support request reply included a link to an April 6, 2023 blog
| post discussing their "shared IP address pool improvements"
| (https://sendgrid.com/blog/shared-ip-address-pool-
| improvement...). Since I won't be sending a lot of emails, don't
| want to track users, and users don't even have to open the email
| to see login codes it sounded like we would never get a better IP
| pool.
|
| IDK if our usage would ever require more than the free tier max
| emails. However, to get out of shared IP pools, $80/mon ($960/yr,
| maybe theirs a deal but doesn't matter because it's a small site)
| is required. OK, but their support docs also say that it's up to
| the user to initial monitor the IP in spam blacklists, etc.
|
| The entire thing I want to pay for is NOT having to deal with any
| of that and have my transactional emails delivered. Yes, some of
| that is on the user not spamming, but I would also be fine if
| they were scanning emails and notifying me of spammy behavior
| proactively.
|
| So I moved on.
|
| Postmark
|
| Seemed promising. Said all the right things on the website.
| Created an account, verfied an email, got a server token, and
| started implementing. For unknown reasons, the use a custom
| header instead of standard oauth2 bearer authorization header. I
| could modify my code to send the custom header, but I don't like
| that idea. Additionally, it seems like a potential security issue
| as general proxies or other things that log http requests would
| like not log authorization headers, but would log unknown
| headers. Probably small.
|
| Maybe unreasonable to abandon for such a "small" reason, but does
| this imply anything about their other design decisions? I didn't
| have a lot to lose so moved on.
|
| Mailgun
|
| This time checked the API first. Uses the http user for the
| token. Pass
|
| smtp.com
|
| Didn't seem like they had a free tier, seemed more oriented
| towards marketing. Didn't care for their website so moved on.
|
| Amazon Simple Email Service
|
| I don't use AWS. Terrible docs. I just need one endpoint to send
| an email. Not immediately obvious how to authenticate. Doesn't
| sound like it provides else but sending. Searches indicated maybe
| blacklist type problems, IDK.
|
| SES doesn't have a standalone email company type of home page
| with a curl example or anything. It's just some service down in
| the bowels nobody cares about until it breaks. That's fine
| though.
|
| MailerSend
|
| Through Google I found MailerSend. Curl example on homepage.
| Signup was realitively easy except I messed up the domain
| verification. I'm using Google Domains with Google Workspace
| which creates its own SPF record. It's not immediately obvious
| that exists in Google Domains and then requires deleting the
| entire Google Workspace sythetic record. That's not MailerSend's
| fault though as they did have a useful error message that I
| didn't read.
|
| They require filling out a form to approve everyone before
| sending email outside your domain. Seems like humans are actual
| doing the approval. My initial submission was denied, but
| resubmitting with more detailed info about company/site (more
| than 6 words) was approved.
|
| MailerSend's domain verification success email went to my gmail
| spam. So that wasn't a good start.
|
| The IP isn't in a blacklist and my test users that were having
| problems are at least receiving login codes now. At least 1 went
| to spam.
|
| I can't say if MailerSend will turn out to be any good long term,
| but ok so far.
|
| Conclusion
|
| A recurring problem with all of these services is that my usage
| will likely only fall into the free tier with paid tiers being
| excessively expensive for a small site. If they aren't making
| money off me, they likely aren't going to care if I have
| problems. A $20/yr plan would probably be fine or up front buy a
| bunch of email sends or something.
|
| It feels like any company that starts out targeting transactional
| only eventually is either bought by a marketing company or adds
| marketing emails. You certainly can't grow revenue off small
| sites using free tiers and likely can't if VC backed either.
|
| Since it's a low volume of emails, it seems like as long as my
| server IP isn't already blacklisted and I setup SPF/DKIM I could
| probably send the SMTP directly and skip the middleman. Maybe
| when I get time.
|
| Sorry that's so long. Maybe some of its useful. Did anyone
| actually read to the end?
|
| EDIT: I don't care at all about email templates
| zenorocha wrote:
| That's definitely useful. Thanks for sharing the entire
| journey.
|
| There's a lot to unpack here, so maybe it's better to chat
| directly. Let me know if you ever want to give Resend a chance.
| paxys wrote:
| 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?
| zenorocha wrote:
| 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 wrote:
| 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...
| cobertos wrote:
| 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 wrote:
| > 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?
| solardev wrote:
| 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 wrote:
| 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 wrote:
| 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/intro
| duction#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...)
|
| ----
|
| 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.
| mbesto wrote:
| > 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.
| solardev wrote:
| Ah, I see what you're saying now! Sorry I misunderstood,
| and thanks for explaining.
|
| That does sound like something better dealt with on the
| backend at sufficient scale. The Resend API rate limit
| appears to be 10/sec.
| douglaswlance wrote:
| Emails are rendered like websites with a reduced
| featureset.
| winphone1974 wrote:
| This isn't really true. More like static pages targeting
| a million different rendering engines with unbalanced
| feature support
| avree wrote:
| 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...)
| mbesto wrote:
| 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 wrote:
| 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
| mbesto wrote:
| 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 wrote:
| 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?
| winphone1974 wrote:
| But the code populating and sending the email is rarely
| (ever?) Front end code
| fastball wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| But why use React to do that when you can achieve the
| same thing on the backend?
|
| https://mjml.io/
| mattwad wrote:
| 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 wrote:
| Unfortunately, the react-mjml library is no longer
| maintained: https://github.com/wix-incubator/mjml-
| react#notice-this-proj...
| DylanSp wrote:
| The selling point is that this allows leveraging existing
| React knowledge, as per the founder's comment upthread.
| mediumdeviation wrote:
| 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.
| theallan wrote:
| 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).
| wbobeirne wrote:
| 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.
| kiliancs wrote:
| 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.
| whstl wrote:
| _" 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.
|
| HTML emails are no fun.
|
| [1] https://mjml.io/
| iamacyborg wrote:
| > Most people doing anything of medium complexity is already
| using some abstraction layer, such as MJML
|
| Citation needed.
|
| I'm an admin for the largest email community online
| (emailgeeks) and when folks talk about code, everyone is
| talking about writing this stuff by hand.
| nathansherburn wrote:
| This seems wild to me. Can you share examples of the
| complexity of the emails people are coding by hand?
|
| This sounds like a pretty amazing art form if people are
| building cross-client compatible, rich, modern email
| designs with tables and inline styling.
| iamacyborg wrote:
| Check out this talk from Mark Robbins from 2018, he's
| been leading the industry with interactive email for a
| long time now.
|
| https://www.youtube.com/watch?v=l7i7YDPcAcM
| fkyoureadthedoc wrote:
| I don't think this supports your point of "everyone"
| talking about doing this by hand. If anything this guy is
| an outlier.
| iamacyborg wrote:
| My point is backed up by what I can see posted every day
| in a community of 18,000 email marketers.
| Nazzareno wrote:
| 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...
| iamacyborg wrote:
| A lot of those template systems you just mentioned
| require an email dev to create brand appropriate modules.
|
| Once that's done it does drastically improve the speed of
| email creation though.
| toddmorey wrote:
| 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.
| csomar wrote:
| 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?
| k3liutZu wrote:
| 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.
| whstl wrote:
| 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.
| winphone1974 wrote:
| 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?
| Aeolun wrote:
| 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.
| stnmtn wrote:
| Absolutely, but show what this will look like to the
| marketing team and they will, probably rightly, tell you
| that times have changed.
|
| For a major brand, CSS and pretty design is a requirement
| for all branded emails.
| geoffeg wrote:
| 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.
| thex10 wrote:
| It sadly no longer shocks me, I've seen many "front-end"
| engineers rely on React as a sort of crutch for building UIs.
| Even for non-interactive UI. :(
| onion2k wrote:
| _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.
| ssijak wrote:
| you can make a static site with NextJS too
|
| 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
| geoffeg wrote:
| Oh, I'm sure they're right, but it was wild to me, someone
| who starts any new web-based project with a static html
| page.
| satvikpendem wrote:
| 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._
| winphone1974 wrote:
| Maybe, but spaghetti jsx really sucks too.
| satvikpendem wrote:
| Sure, if you write everything in one file, but that's why
| componentization exists in React.
| mattwad wrote:
| This isn't an argument. Spaghetti templates are even
| worse
| Levitz wrote:
| 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.
| klysm wrote:
| React is a really good template language and allows you to stay
| consistent with branding across multiple products with minimal
| investment
| zenorocha wrote:
| Exactly. High consistency + low investment, that's the
| perfect combo
| [deleted]
| arek_nawo wrote:
| 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.
| addandsubtract wrote:
| 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.
|
| [0] https://github.com/vadimdemedes/ink
| zenorocha wrote:
| That's a great analogy, big fan of Vadim's ink project btw.
| iLoveOncall wrote:
| What is the advantage over something like SES? It seems you need
| to do basically the exact same code for the same result.
| simplezeal wrote:
| Microsoft Azure offering
|
| https://learn.microsoft.com/en-us/azure/communication-servic...
| mightytravels wrote:
| Assuming that each email is about 10 KB in size, sending
| 1,000,000 emails with Azure would cost:
|
| * $0.00025 x 1,000,000 = $250 for sending emails
|
| * $0.00012 x 10 KB x 1,000,000 = $1.2 for transferring data
|
| * Total cost = $251.2
| zenorocha wrote:
| Are you currently using it? I would love to hear what you like
| most about it.
| iamflimflam1 wrote:
| How does the react email templating work in non javascript
| backends? For example Rails?
| zenorocha wrote:
| We render the React components on the server side.
| kevsim wrote:
| Meaning your server?
| satvikpendem wrote:
| They use (and are makers of) https://react.email which
| works on client side or server side, through NodeJS. So you
| could spin up a NodeJS server, send your React components
| through and compile to HTML, then use whatever email
| service you want, but I believe Resend does all of this
| natively via their servers. I personally use react.email
| with Sendgrid.
| codersfocus wrote:
| I think if you're targeting developers, SES is your biggest
| competitor. Their very cheap pay as you go pricing is more
| attractive than your monthly pricing. If email templates with
| react is your usp, I think I've seen libraries that offer that
| already.
| ignoramous wrote:
| > _I think if you're targeting developers, SES is your biggest
| competitor._
|
| Cloudflare via _MailChannels_ is virtually free:
| https://blog.cloudflare.com/sending-email-from-workers-with-...
|
| It lacks tooling / observability that a marketer would want
| though.
| ttul wrote:
| Watch this space.
| mightytravels wrote:
| Are there any unpublished limits for this? Asking for a
| friend :)
| ttul wrote:
| There are no unpublished limits. I'm the CEO. We don't
| specifically limit Cloudflare traffic.
| KomoD wrote:
| How does this work if we don't need to validate domain?
| btown wrote:
| Does SES still have a reputation for being flagged as spam more
| often than other senders?
| mightytravels wrote:
| SES reputation is medium at best. But they allow everyone to
| send emails so you get what you pay for...
| YetAnotherNick wrote:
| Which competitor has the best reputation for transactional
| mails?
| Manouchehri wrote:
| SES has a terrible developer experience.
|
| We use it and don't plan on switching for a few reasons, but I
| would not recommend it to most folks.
| andris9 wrote:
| Resend seems to be a UI layer on top of SES, so it is probably
| not a competitor. People could use SES directly, but if the
| target group for Resend is a "modern front-end dev" then they
| probably do not want to, or do not know how to, and thus need
| that UI layer.
|
| For example, I maintain a popular email sending library
| (Nodemailer) and if I could get a penny any time some user
| files an issue with something that is clearly basic for anyone
| who has ever even touched email, I would be quite wealthy. All
| these people are good match for a service like Resend, they
| just want to send mail for a reasonable price and do not care
| the slightest of what is going on under the hood.
| rozenmd wrote:
| Going against the cheapest in the market in a race to the
| bottom is a fool's errand
| joao wrote:
| Resend is, or at least at launch was, using SES as their email
| provider.
| thesimon wrote:
| Sucks because SES reliability is a mixed bag and more
| competition would be good.
| [deleted]
| mightytravels wrote:
| Is there something that's cheaper than SES and similar in
| reliability? Do Oracle, Google/ Microsoft Cloud offer something
| similar (pricing and endpoints)?
| new_to_hn_1 wrote:
| doesnt resend use SES themselves to send emails? domain dns
| settings in their dashboard appears to hint at this IIRC
| cnity wrote:
| I think this is a fair criticism, however it's clear that there
| is a market for "polished, dev-x first, react focused cloud
| platforms". Just look at next.js and Remix, both of which solve
| problems which are already solved by combining normal cloud
| providers and open source libraries, but crucially with a lot
| more head-desking and glue code.
| isnhp wrote:
| I tried Resend and Custom Email feature reveals SES. I think it
| good when Resend build on top of SES
| miki123211 wrote:
| > What issues have you had with email sending?
|
| Most email services assume that you are a big, US based company
| and care about following US anti spam laws, which require you to
| disclose your address in each email you send. As an Eu-based
| hobbyist running their services without registering an official
| business, I have no address that I can safely disclose and no
| willingness to deal with the legal system of a country that I
| have no interest in. What are your policies on this?
| rattray wrote:
| I have to say I'm impressed at the breadth of their SDK support
| (even Elixir) and how idiomatic they seem at first glance in each
| language (though too bad there's no python types yet).
|
| Really nice to see all the examples too.
|
| Pretty wild that in comparison, "Twilio Sendgrid" doesn't even
| have a single code snippet on their homepage, and once a Rubyist
| clicks "Least more" and scrolls they're greeted with this:
| `sg.client.mail._('send').post(request_body: mail.to_json)`
| geuis wrote:
| 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.
| ctas wrote:
| Looks like they're using AWS SES. From personal experience,
| none of them (SES, Mailgun, Sengrid) are suited for critical,
| transactional emails. I'm working in the same space and we're
| running our own backend.
| aj462 wrote:
| @ctas since you're running your own backend, how did you
| solve the reputation problem to ensure good deliverability? I
| would have thought that using a dedicated IP on an existing
| provider like Sendgrid would be the best solution for
| critical transactional email.
| ctas wrote:
| There's no one-size-fits-all-solution to ensuring good
| deliverability. Dedicated IPs are often (not always) a sign
| of weakness as they indicate that the shared IP pool lacks
| good reputation.
|
| We run an exclusive transactional email service, meaning
| customers go through an approval process before they can
| send live emails. Transactional emails by definition are
| sent as a reaction to a users' action and _should_
| therefore have a low spam-rate and fast time-to-open. If
| you can ensure that your customers are good email citizens
| and actually send only transactional emails, you don't even
| need to upsell dedicated IPs to your customers, as the
| deliverability of a high-quality, shared IP pool is better
| than that of an isolated IP address.
|
| Email is in my bio, if you have other questions.
| dazbradbury wrote:
| I suspect most serious customers will want dedicated IPs, and
| then they can send using their own servers. Relying on shared
| IPs is always going to cause problems, especially for high
| volume users that can sustain enough traffic for their own
| clean IP sets.
| simonbarker87 wrote:
| Congrats on the launch but I can't see why I would go to this
| over Postmark. It's so easy to get up and running, templates are
| solid, they have Zapier integration and the monthly fee starts at
| free for 100 emails and then $15 a month for over 1,000 a month.
|
| What am I missing?
| rasmus1610 wrote:
| Well for one you can send 1000 emails for free with resend
| instead of 100 with postmark.
| zenorocha wrote:
| It's actually 3,000 emails for free with Resend
| joshmanders wrote:
| Please for the love of god do not decide for me where I want to
| be.
|
| I signed up, confirmed my email, opened the app and was browsing
| through it and was on settings tab when I got a phone call.
| During that call I had to look up something so I opened a new
| tab. After the call I went back to resend's UI to watch it blink
| and all of the sudden I'm on the dashboard again.
|
| So I tested it, I went to the settings page again, switch to a
| different tab and then back to Resend again just to watch it
| switch back.
|
| There is absolutely ZERO reason for this functionality. It is not
| a better UX, it's an annoying UX you do not know what I am doing
| or where I want to be on your website.
| confoundcofound wrote:
| Could you not find a million other ways to provide this
| feedback less abrasively? People like you unnecessarily
| exacerbate the stress of launching a new endeavor.
| joshmanders wrote:
| I'm sorry was I not asked to give feedback on a launch post?
| Did you not see this line:
|
| > I would love to hear your ideas, experiences, and feedback
| on any and all of the above.
| goodoldneon wrote:
| Criticism phrasing is important. Just because someone asks
| for feedback doesn't mean they're OK with an abrasive tone.
| Bugs happen -- I'm sure they didn't intend for the
| experience to be that way
| satvikpendem wrote:
| There's a difference between giving feedback and giving
| feedback with tact, no need to be so harsh even if you are
| right.
| [deleted]
| swyx wrote:
| (deleted thx to dang)
| dang wrote:
| Please don't bring in personal details (even public ones)
| from elsewhere as ammunition in an argument. I understand
| the impulse and I'm not saying the information is
| irrelevant. It's just not worth the cost/benefit of what
| it does to the threads. It only makes them meaner and
| more personal. Better to resist the temptation.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false
| &so...
| satvikpendem wrote:
| Wow, looks like almost all of their tweets/comments are
| exhausting.
| zenorocha wrote:
| That's pretty bad, looks like some UI bug. We're investigating
| it right now.
| jacobobryant wrote:
| FYI, the site is returning a 500 error currently.
|
| Anyway, re: the substance of your post--I've used a few email
| services for the handful of small web apps I develop. I'm
| currently on Postmark and I really like it. You state "Nobody is
| building an exceptional developer experience" and "There isn't a
| single developer-first email platform in the market today", and I
| have to disagree. Postmark has great developer experience. And
| the specific points you raise aren't much of a rebuttal:
|
| - Templates: your own react.email project already has a Postmark
| integration. More generally, templating solutions don't need to
| be tied to the email service. I prefer to use separate libraries
| for rendering and then pass off the html output to the email
| service anyway.
|
| - Slow performance: Postmark has excellent delivery speed.[1]
|
| - Poor observability: Postmark (and every other service I've
| used) provides events.[2]
|
| - Designed for marketers only: Postmark is clearly designed for
| developers, as are several other services.
|
| I am rooting for you! But I'd also like to say that before you
| trash talk competitors, please be sure you have substance to back
| it up, because some of us actually like those competitors :).
|
| [1] https://postmarkapp.com/email-delivery
|
| [2] https://postmarkapp.com/email-analytics
| zztop44 wrote:
| I'm also a happy Postmark customer and also bristled a bit when
| I read the allegation that they don't have a good developer
| experience. Their developer experience is pretty good,
| actually.
|
| BUT their JS library has been a shitshow for years now. Like,
| it works. But the readme links to outdated documentation and
| 404s. And in the library documentation you can get into an
| infinite loop of "click here for more info" taking you to back
| to the page you're on.
|
| It's still usable. I can just find the page I need with a bit
| of googling, and actually I stopped using the JS library and
| just interact with their API directly with HTTP these days. But
| it's definitely a sign that they're not paying attention to
| _that_ side of the business and developer experience anymore.
|
| Which is, like, fine. Postmark is a great product. It does what
| it needs to and it does it well. But it's fair to say they're
| not hungry anymore and haven't been for a while. And although I
| don't totally understand Resend's value prop, the market's
| definitely big enough to support someone new and hungry so good
| luck to them.
|
| PS: Zeno, I saw in a sibling comment that you guys had a
| upstream outage during your Launch HN. Damn, such bad timing
| haha!! At least it's back up now :)
| zenorocha wrote:
| There's an outage with our upstream provider (AWS Lambda):
| https://health.aws.amazon.com/health/status
|
| This issue is only affecting the Marketing Website and
| Dashboard.
|
| The Email API is up and running normally.
|
| More updates here: https://resend-status.com
| zenorocha wrote:
| The Marketing Website and Dashboard are back to normal now.
| laurels-marts wrote:
| Any plans to allow Svelte components as well?
| dazbradbury wrote:
| As soon as you support inbound email handling we'll definitely
| give it a go. Mailgun have some critical blockers (and potential
| security vulnerabilities) that have meant we're looking for an
| alternative to switch to ASAP.
|
| Ideally by then you'll have migration guides from every big
| provider and so it will be even easier! Thanks for innovating in
| this space - it's much needed!
| zenorocha wrote:
| Roger that.
|
| Adding support for inbound emails is definitely on our roadmap.
|
| Great idea on the migration guides!
| hevalon wrote:
| How long does it take to have my domain whitelisted? and should I
| be able to send emails under one domain? Do you support react-
| native? Can I send it from the backend (eg next.js server-side
| backend)? Is it for only transactional emails?
|
| Thanks!
| zenorocha wrote:
| How long does it take to have my domain whitelisted? - It
| usually takes only a few minutes depending on the DNS
| propagation
|
| Should I be able to send emails under one domain? - Yes, you
| can add as many domains as you want in case you wanna send from
| multiple domains
|
| Do you support react-native? - Resend is designed to be used in
| the backend, so you'll have to call an API from react-native
|
| Can I send it from the backend (eg next.js server-side
| backend)? - Yes, here's a Next.js example:
| https://resend.com/docs/send-with-nextjs
|
| Is it for only transactional emails? - It's designed around
| transactional emails, but you can use it for other use cases
| userforcomment wrote:
| I am using MJML but custom components aren't great, happy to see
| this one. Also would be great if you take a look into adding
| email action buttons, calendar integration and other modern
| features.
| zenorocha wrote:
| Ohhh I love this suggestion. Great idea!
| scrollaway wrote:
| I dunno if this is interesting to anyone but a while back I built
| a mjml email manager.
|
| 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.
| presentation wrote:
| Congrats on the launch! What's your stance on GDPR and SOC2? I'm
| making a B2B SaaS and we need to vet our vendors, would be
| helpful to know. Thanks!
| pelcg wrote:
| Zeno, is Resend planning to have a CLI (linked to my account),
| since your product is a developer first email platform.
|
| Your thoughts on this would be most welcome.
| zenorocha wrote:
| Yeah, that would be great. Out of curiosity, what's your use
| case for sending emails via CLI?
| pelcg wrote:
| For me it is the following:
|
| Generating Boilerplate Projects
|
| Rapid Testing (Think CIs)
|
| Manage Environments and API Keys in Resend
|
| Listing Domains and Email Sending Health
|
| A way to 'Watch' email events in realtime for debugging.
| throwaway85858 wrote:
| Looks cool, i would agree the space needs a shakeup.
|
| But I see you don't have an inbound offering, I'm looking for
| something similar to what sendgrid and mailgun offer in that i
| can receive a POST request to my API everytime someone sends an
| email to test@mydomain.com. Ideally with the following features:
|
| 1. Solid email MIME data parsing into JSON or XML
|
| 2. retry handling
|
| 3. included in the free tier (mailgun excludes this)
|
| 4. inbound routing based on parsed data
| swyx wrote:
| this too! and throw in OCR of any pdf/image that i send you and
| you really have a stew going
| kieranhunt wrote:
| Zeno! Since no one else has said it on this thread, thank you for
| your work on Dracula.
___________________________________________________________________
(page generated 2023-06-13 23:01 UTC)