Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Sendune – open-source HTML email designer
429 points by samdung 4 months ago | hide | past | favorite | 90 comments
Demo: https://designer.sendune.com/ Code: https://github.com/SendWithSES/Drag-and-Drop-Email-Designer

HTML for email is probably the hardest code to write. Even a teeny-tiny deviation from the rules will break the email in untold combination of os/desktop/mobile clients.

It's mid 2024. Almost 50 years since email was invented and 35 years since HTML was born. A 'basic-open-source-HTML-email-designer' must be a solved problem, right? We thought so too.

Sadly, that's not the case.

There are a few decent open source email designers but they carry dependencies that make them cumbersome to embed within your app. That's why we decided to open source our HTML Email Designer.

The SENDUNE email designer focuses on simplicity and ease of use. It is light-weight. It does pure HTML - no intermediate code wranglers like mjml. There is no lock-in of any kind. Save HTML output as a template and use with ANY email service provider.

Feel free to fork the repository, make improvements, and submit pull requests.

AMA: hello at sendune dot com




No MJML feels like a mistake. I design emails and that is literally the most important feature to me.


Because someone keeps commenting and immediately deleting their comments in reply to this: MJML is a tool to essentially “fix” email, which essentially has to work around out-of-date clients and incomplete HTML specs.

If it feels out of date, it’s because HTML email itself is out of date.


Oh! I wasn’t expecting this. I’ll be here a couple of hours to answer any questions.


Looks very nice. I'm curious about "no mjml" -- I've worked with authoring tools in related domains and found that separating the serialization format from the output format has some benefits. It manifested in needing to store editing concerns like "this element is locked" in the HTML when it had no business being in the HTML output.


Oh wow, nice, thanks for the MIT License!


How did you reliably determine what works and what doesn’t in “untold combination of os/desktop/mobile clients“? Is there a description of that somewhere?


There is site for that https://www.caniemail.com/ . I don’t use it, even if I work on email marketing software, but I guess it might be useful sometimes.


No malicious intent here but the post says it was submitted by you.

What exactly were you "not expecting"?


wasn't expecting to hit the front page so soon given all the attention towards crowdstrike.


not expecting to be on the front page maybe


the upvotes?


Very nice work and very well deserved the front page #2 spot! Thank you!


Anyone who has touched HTML emails knows the devilry involved. Kudos for developing and open sourcing this! Excited to try it out for my newsletter.


> knows the devilry involved

You're being too kind if anything. Whilst trying to bash HTML emails into something acceptable I questioned if my life wouldn't better have been spent as a monk in Tibet.


This work looks very promising. "HTML for email" is indeed hard to design and hard to implement. Especially editing on mobile, tablet devices, or asian (two+ bytes japanese, chinese) languages input nightmare.

I do lot of email templating for B2B CRM use cases and decided to opt out for a bit different approach based on slatejs/platejs editor

https://docs.slatejs.org/

https://github.com/ianstormtaylor/slate

https://github.com/udecode/plate

The internal representation of email template with variables in slatejs/platejs json format can look like:

{ "type": "h1", "children": [ { "text": " Blocks {{template_value}} {{$timenow}}}" } ], "id": "1" }

Can be easily stored in Postgres jsonb. Very easy to add Reacjs base widgets like mentioning, media, diagrams, etc inside of slatejs/platejs editor.

The drawback is that you can't design the exactly the same pixel perfect template.

The better abstraction is probably MJML - https://mjml.io/ ... and yet with slatejs/platejs json format you can copy&paste your editings across various assets in CRM, knowledge base, etc

Storing data in MJML is not a great choise for me

<mj-text align="left" color="#55575d" font-family="Arial, sans-serif" font-size="13px" line-height="22px" padding-bottom="0px" padding-top="0px" padding="10px 25px"> ...

Was thinking about using something similar to /SendWithSES/Drag-and-Drop-Email-Designer as the last final step ... but couldn't settle it my brain and most end-users dont care anyway.

Any thoughts on data representations and "Postgres <> Editor > Email HTML > Send button" dataflow is greatly appreciated. Very few people have serious thoughts on the subject.


You can set an <mj-class> at the top of the file for a given design format to simplify your code. So in your example, if you did:

<mj-class name="typebox" padding-bottom="0px" padding-top="0px" padding="10px 25px">

<mj-class name="paragraph" color="#55575d" align="left" font-family="Arial, sans-serif" font-size="13px" line-height="22px">

That would allow you to simplify your callbacks to

<mj-text mj-class="paragraph typebox">

You can also set CSS classes as well if you need something outside the MJML spec for some reason (which would potentially cover some of your cross-platform concerns).

MJML also integrates well with other languages. For example, I use a Craft CMS integration to pull data in via Twig to build complete templates directly from my CMS; there’s also an integration with Eleventy.


The drag and drop part is not working for me, Firefox, macOS. I can click on the elements on the left and they will pop up, but I am not able to drag them onto the email.


although the name says 'drag and drop', it's not truly that. you click on any column in the designer and then select the component (heading, text, image, etc) in the left panel. you can then move components up and down using the arrows.

we found this approach simpler than drag and drop, especially when designing long emails.

let me know if drag and drop is something thats an absolute for you. we can bring it back.


UI-wise then I wonder if it would work better to have a "+" button inside each column, clicking that then gives a popover of available components right where you’re adding them.


Cool that you open sourced this. As you say there's nothing open quite like this.

Not using MJML as a design decision. Foes that simplify deployment a lot, or just keep things lighter? In turn, do you have to strangle a lot of compatibility issues yourself? etc. Thanks.


I think it's distinctly uncool that this was published as open source. OP should charge money from all the swines that will use the software, including people like me.


go ahead and feel free to use it. that is what we intended it for.


I'm super down voted by open source enthusiasts who want free stuff, but I really think you should charge for this software. It's only going to be used by businesses, so they should pay for it. You wouldn't go to your local McDonald's and offer to work for free for them all day, would you?


Totally understand your point of view. HN community is largely well intentioned and net-net the software world is the better for it. The designer we have open sourced is part of our much larger communication platform (https://sendune.com).


View -> Message Body As -> Plain Text

Not your fault, but please always provide fall back text.


got it. plain text fall back is on our todo list.


Really great thanks! Is it possible to add responsive styles? Such as converting columns into rows on smaller device screens?


OP should have used the patterns from Cerberus: https://github.com/emailmonday/Cerberus


we did indeed use some design patterns from Cerebrus along with a few others. our documentation in fact credits Ted Goas, Nicole Merlin, and Mark Robbins

https://github.com/SendWithSES/Drag-and-Drop-Email-Designer


Yes, this designer does that. please test it out.


Is there some documentation on how to integrate it into a different web app? I would really like to open a template that is stored in the database and handle sending the mail, "exporting" (rename it to "save"), etc.

Is that possible?


You can visit the following page for documentation on how to integrate it into your angular web app. https://www.npmjs.com/package/@send-with-ses/ng-email-design...

You can integrate your api call in the exportHtml() method to save it to your database. And you can load the same template into the component by providing it to [template].

ex: <lib-email-designer [type]="selectedTemplateType" [template]="selectedTemplate" #emailEditor></lib-email-designer>


This looks great, nice job!

Does anyone here use Foundation for Emails? - I found it to be pretty good (circa 2020) but the code it produced still needed some tweaks to display images correctly in Outlook for Windows.


Looking for a simple email designer which will give us compatibility in all email clients. Surely will test this in this weekend.


I was just briefly searching for something like this the other day; will check it out. Thanks!


Same, I was even surprised because I didn’t find anything.


Absolutely amazing. Really makes so much sense to have a solid mail editor as OSS!


This is a very useful thing, I will definitely test it


Looks awesome. Is there a way to load saved templates?


there's an export HTML functionality. you can use this to save templates once you embed this in your project.


I appreciate the response, but that's not what I was asking. I'll rephrase as a workflow question: After I make a design in your editor, I'll want to reuse that for future emails. Is there a way to load a saved design back in (that I previously made in your editor) so I don't have to redesign every email from scratch?


got it. that is an implementation you will have to do when you embed it in app. it's basically exporting the HTML, giving it a name and storing it a database. this functionality is beyond the scope of the demo. but we have it at https://sendune.com/


Wow love it, great work on this! I think you've tapped into a nice market, trying to reproduce marketing dept. designs into HTML templates are always a pain.

I'm looking forward to seeing the product grow!


How does this compare to something like resend?


Is this a genuine question? I dont want to be rude but I dont understand how are you asking this?

Just in case it is a genuine question:

- This is a tool for designing/creating emails - they say in the title of this post "Open source HTML email designer"

- Resend is a tool for sending emails: "Deliver transactional and marketing emails at scale" this is from the hero of resend homepage

I dont know any of them, just opened the Resend website and read the hero and read the description of the post you are commenting.


Do your research before responding to me next time. They're both email design tools - Resend is based around building your emails in React.


It looks great, I will have to try it!


wow. this should help to design invoices, what do you think? html to pdf is not a problem anyway so....


you can design absolutely anything with the HTML editor - invoices included.


Love it see it, I think most "designers" like this tools are behind paywalls and subscription email platforms. This looks great thank you for sharing.


I really like this idea!


I have the personal impression that it would be a net positive if all emails were written as text.

Ok, in some cases I see why html would make some sense. In those cases, my opinion is: send text and invite the person to view markup content in their browser.

The e-mail context is not suitable for markup, styling, and all this stuff.


I would love first class support for some limited subset of markdown (same for browsers actually).


That's why I am using aerc so that even HTML mails are presented as text in my terminal.

Another problem are mails that don't have the TXT part and *only* HTML.


You're being nice.

I plain cringed when I saw the headline. This sounded like a tool designed by some evil entity to bring destruction upon the World.


Yeah, the headline alone made me angry. I'm glad I'm not the only one.


So plain text, not even links with <a>?


I intentionally disable html on my email programms and block all internet access for my mail program to the internet (except for the smtp, imap hosts of course)


Yes. Links can be automatically marked up in the client.

The problem is there is no practical way of getting back to plain text, or even to a different type of markup.


Talking to non-tech people means you're going to be copy-pasting screenshots and replying in blue text next to their bullet points that was written in black text.

To say nothing of legitimate marketing emails (which many people rely on to get coupons and deals) that has to feature pictures and the like.


> Talking to non-tech people means you're going to be copy-pasting screenshots and replying in blue text next to their bullet points that was written in black text.

None of that requires HTML. Using ">" to denote previous conversation quotes is the standard and they normally get highlighted different than reply text. And images just need a decent 'drag-to-add-attachment' flow.

Marketing emails don't matter as they are an abuse of the platform.


The entire reason email (and the internet) took off is because there are many ways to use it, for many purposes.

Handing down diktats about the correct use cases and workflows for a flexible thing that is currently being used by billions of people in billions of ways - like email - will either reduce your personal relevance to them, or, if you succeed in pushing your vision onto the popular thing, drive people away from it.


> legitimate marketing emails

I don't think there is such a thing.


I receive many such emails that I signed up for and am happy to get.

The senders of those emails are happy to send them.

Unless you - an unrelated third party - think you have the right to insert yourself into this business relationship, it's completely legitimate.


I was writing them email templates 15 years ago... oh... look we are still using tables. How has email markup not evolved?


We still have to use outdated layout / css techniques because some email clients (cough outlook) only support a limited set of HTML/CSS features, and they seem to have no plans to want to make things easier for those who send html emails.

See https://www.caniemail.com/scoreboard/ and take note of what's at the bottom of that list.


> and they seem to have no plans to want to make things easier for those who send html emails.

We just need so called "Kobold letters" to catch on so that all the inconsistencies become an actual threat. I'm only partially joking.


it has not evolved much. and i believe that's a good thing. this is the reason why emails from 20 years ago look the same even if you open them today. given the short life of everything on the internet, email is a wonderful thing.


Yes, I have no idea why UI practices need to constantly "evolve". As far as I am concerned a lot of UI is getting worse over time so the less evolution the better.


There is some need to evolve as contexts change. Screen sizes and capabilities, computing speed, available bandwitdth etc.

Also humans seem to need fashion as a mechanism to show belonging and distinction. (Differentiate form parents generation, show affiliation to some sub culture, ...)

And then there is the hope to make the production more efficient. (Which may not work out)


There are periodic items on here from people having trouble with self-hosted email, but nonetheless I think it's also not suffered the same closed-systems/walled-garden effect as much as other protocols like IM.


I've long wished for something like Markdown for email, but something that can actually be standardised and doesn't suffer so much under HTML's influence.

I guess Google tries/tried with AMP but it's not that and I doubt they have the resilience to keep the effort up for decades for it to catch on.


You can use MJML - https://mjml.io/ - which abstracts away a lot of the ugliness and Outlook hacks.


The argument for this I always get is security. Since email is so critical reducing the surface area of html/css supported somehow makes it secure. I...don't really buy it.


It’s hard to imagine “full CSS support” being a selling point for an email client. Even for a free email client, funded by advertising, compatibility with other email clients is necessary for the advertisers.


Email clients and servers have not evolved


though Exchange certainly did mutate like stillbirths at Chernobyl.


Did there is any history about the name ? Keep reading "Send nude". Sorry.


Gosh, my first job was writing HTML emails. Those heady days of lamenting the fact that some companies STILL use Lotus Notes not dead, I see.


[flagged]


I would wager that the vast majority of people consume email via Gmail, Outlook, or Mail (Apple). You might have the holdovers like my parents who still use Thunderbird (because in early 2000's that was ideal of POP3 accounts, and they're used to it, and that's just how it will remain). All of those clients display HTML by default, and all marketing / account-related / branded emails are HTML emails. Every single reason cited in your link for choosing plaintext are irrelevant for the overwhelming majority of internet users worldwide. We could definitely productively debate the ethics surrounding marketing initiatives and data privacy, but at the end of the day, to me, plaintext destroys most of the functionality that makes email so useful.


This is not a good Show HN comment. There's nothing these people can do with this feedback, and it's litigating a tired internet trope. It's 2024, people overwhelmingly use HTML email, and this is not a thread intended to investigate whether that's a good thing or not.


>people overwhelmingly use HTML email

If that is true, it is only true because email providers are making a choice on behalf of consumers, namely, the user writes plain-text emails (at, e.g., gmail.com) then the provider converts it to HTML.


You can use HTML with plain text fallback. That's still the vast majority of marketing/form emails.

HTML works fine, and adds important features like formatting text and links. HTML without images is ideal, as images are often blocked (as you mention).

I prefer plaintext too, but for a marketing email (ie, "confirm your account") consumers will think it feels "off" or unpolished given what they are used to. It will likely lead to churn. Clients can opt to view plaintext if they prefer.

Edit: also it's a bit funny the page you link, useplaintext.email, uses lots of HTML formatting.


My sentiments are totally with this comment, however as others have pointed out you can deliver both via plaintext fallback

And in defense of html emails: for marketing missions there's nothing like a nice piece of visual design -- layout, color, possibly some type design, but not necessarily images since folks like me turn them off because of tracking -- to get attention and drive interest. Also, html can allow for column layout that could keep email content shorter than plain text version


Literally everyone that sends marketing emails uses HTML (from political campaigns to video games, to movies, to shopping). You'd be putting yourself at a serious competitive disadvantage if you started sending plaintext (not to mention that it would look spammy, if anything).


I work in this space with hundreds of clients and tens of thousands of email templates and literally zero use plaintext as the primary templating option for marketing emails. None of them.


The entire premise is absurd.

I will grant that many people want rich text, formatted emails with images and logos. I don't want that but understand the wants and needs are different for others.

For gods sake why HTML? A fairly simple markup language (Markdown, orgmode, etc) would have sufficed, would have eliminated the need for separate plain and html versions of every email, been far more accessible to screen-readers and other assistive devices, been far less privacy-invading, and been far less vulerable to security problems.

But no, the answer was "let's put a full-blown web browser in every email client"

I know the horses have left the gate.


I just want one thread about HTML email to not be a re-litigation of this point. It’s been around for a quarter-century at this point. It’s well-established. It has plenty of warts, but it’s not going away.

There are better ways to push the ball forward than this recurrent frustration over something that is so broadly used. A key one would be to improve support for making divs display properly in HTML emails, so the format could be more accessible, for example, as well as to look into ways to push corporations away from outdated email clients. Finally, a way to sandbox emails to help minimize concerns around risky designs would be ideal.

AMP is a dirty word around these parts, but Google’s AMP for Email did some of these things.

I don’t know what that would look like, but there has to be a better way to expel our energy than just being frustrated about something that’s unlikely to change.


There was an attempt to standardise what looks like an HTML-subset for formatted emails: https://en.wikipedia.org/wiki/Enriched_text

But unfortunately it wasn't very popular.


Because at the time web browsers were taking off and web based mail services (Hotmail yahoo etc) were taking off. Back in that time the alternative to html was Tex.

Why do we still boot to 16-bit protected mode to launch any OS on x64? shrug but you are welcome to move that mountain :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: