Show HN: Sendune – open-source HTML email designer
99 comments
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.
If it feels out of date, it’s because HTML email itself is out of date.
[deleted]
[deleted]
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.
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.
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.
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.
<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.
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.
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).
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
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?
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>
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.
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.
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!
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.
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.
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.
Another problem are mails that don't have the TXT part and *only* HTML.
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.
The problem is there is no practical way of getting back to plain text, or even to a different type of markup.
[deleted]
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.
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.
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.
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 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.
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.
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.
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)
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.
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.
[deleted]
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.
[deleted]
dethos(7)
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 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 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.
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 :)
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 :)
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