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
If it feels out of date, it’s because HTML email itself is out of date.
Deleted Comment
Deleted Comment
What exactly were you "not expecting"?
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.
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.
<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.
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.
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 your fault, but please always provide fall back text.
https://github.com/SendWithSES/Drag-and-Drop-Email-Designer