Anything that makes email development easier is great I guess, but have personally found MJML great for solving the issues you'd run into, and not sure I want yet another abstraction layer on top of that which makes it more limited...
They address this in the docs - it is meant to make authoring the content easier for LLMs since that is easy for them to write.
It still uses MJML for the actual templates, but it is a translation layer between markdown and the template itself.
If you need to author a lot of emails with LLM this does seem like it would be a great fit.
If you need to author a lot of emails with LLM you should be rethinking your business strategy tbh
If the goal is to write emails purely using AI, then it is trivial to attach the MJML documentation as context to your LLM using context7 MCP or something of the sort. It's not a very complex language and its documentation is not large at all.
That's assuming the crawlers haven't ingested it all already...
[dead]
This appears to be a MJML wrapper with a Markdown→HTML converter attached to it. I think generating HTML from code is easier than generating Markdown, since there are many templating tools that understand HTML escaping. And writing HTML is not that hard, especially for your typical emails, so I'm not really sure if this library would be helpful in the long run.
I like the idea of this tool, as writing Markdown for some people is probably easier than HTML. I mean, use whatever floats your boat. I like that this exists.
Also a way to use fewer standards for storage of input and created text.
Writing HTML for emails is a lot harder than you're making it sound. But MJML does a good job of simplifying it for most use cases.
I'm never seen the `::: header` or `{width="200"}` kind of syntax before. Is this custom or Frankenstein solution? Or is there some kind of md-extended pattern for defining components that has been gaining steam or smthn? Markdown tooling is always confusing, since everyone has their own standard.
Admonitions are :::, allows you do to do things like this, if you have custom parser, if not, your admonitions can fail gracefully as plain text
Yep both are widely used. I forget which markdowns extensions they originated from. The Pandoc website probably has the details.
Aye, I've seen these both in kramdown and quarto.
Markdown is the secret winner of the AI early years.
I'm not so sure. It's definitely the de facto standard, but I suspect minimal HTML is better. Just enough tags to add structure and meaning (H1-H6, p, a, em, section for structure including nesting, maybe more). LLMs were trained on a lot of HTML, they're good at processing it. HTML requires more tokens than markdown but I believe it's worth it. I'll find out in a few weeks as I experiment with both.
cries in org-mode
org-mode is amazing for humans. I, as a real human and not a robot, use it every day.
I feel you on this too.
[dead]
i never understood why the markdown mime type was not used in emailclients in webclients or desktop programs...
that would eliminate most html usage and enable longer texts than 70-85 characters per line.
It’s up to the e-mail client implementors, but I would personally prefer text/enriched, RFC 1896, instead of markdown.
I like how you aren't hiding the fact this is MJML under the hood and don't layer complex abstractions over MJML spec like similar projects (cough react email cough).
The devs maintaining MJML deserve so much credit for dealing with Gmail/Outlook's monopoly bullshit and 2007 html.
Nice idea for those who manage content in markdown. I've moved away from putting emails in my codebase, but seems great for founders moving fast.
What’s your opinion on react email?
Mostly fluff/hype. Not a value-add over just using raw MJML (which has nice VScode plugins for live previews), and in fact a long term risk to add to a codebase since react-email is just a marketing play by Resend (a startup) and will not be maintained as diligently as MJML.
Also, LLMs know MJML really well.
This is my experience as well. MJML is the older, more reliable, better documented technology. And when it comes to debugging email rendering, you really, REALLY want as much documentation as possible.
Thanks! I agree - the MJML team has laid so much groundwork and it frankly made this project possible.
Any "HTML emails" get filtered straight into the spam folder here. I think I'm not part of the target audience here.
How do you deal with things like "we sent you a one-time code to confirm your login"? Most of those are HTML-formatted today
I still can check the SPAM folder, if needed.
But most SPAMs are HTML, so you'll have a good default last-stage in-client filtering in place in case some SPAM actually makes it through the other setup on the server (greylisting, DNS based filtering lists, policy-based filtering, etc.) :)
Is that a thing? Is it safer to use plain text emails?
> Is that a thing?
There must be literally dozens of people who do this.
Very much so. While a lot of mail clients block images, they can be used to track you. Hell a lot of HTML can be used to track you if you're smart about it
At this point markdown is going to be the foundation of the entire AI web. Someone the other day showed off Markdown as a responsive frontend protocol. Now we've got email. How long until we're writing classes in markdown? We can only abstract this so far before we confuse AI more than help it.
Look up Configuration Complexity clock
I hope .md domains do not become a security hole as Markdown raises in popularity...
That's a valid concern, especially given the confusion we saw with .zip or .mov TLDs. But from a security engineering perspective, the bigger 'Markdown hole' I worry about is injection. When we render untrusted AI output into HTML for email, the sanitization pipeline becomes critical. I'd be curious to see how this library handles potential XSS vectors during the MD-to-HTML conversion.
[deleted]
This reminds me of the infamous dot zip domain and the security chaos that had followed.
Great project! And if you don't mind a little workaround and some Python scripting, you can turn a regular Obsidian folder into an automatic outbox. Write markdown, drag, drop, and ship.
[deleted]
I never actually thought about this. How are people making HTML emails so responsive? Email HTML is stuck in the IE6 era, right? So everything is just a horrible workaround with tables and ancient CSS?
I'm not exactly following as to who this is for - people are going to use email templates instead of writing Markdown emails, and agents can just as easily spit out HTML. Seems like your solution is in search of a problem.
Feels more like a content layer for LLMs than a replacement for MJML.
In my experience models tend to break HTML layouts pretty easily, while Markdown degrades more gracefully.
Very nice. I think the kind of folks attracted to this thread might have some thoughts on a workflow I'm interested in.
When I see a news article, I want to be able to click a button on my Mac or iPhone to send the text of the article in the body of the email. Bonus points for rehosting the images from the article. And using a similar font both without carrying over any of the original external dependencies.
Normally it’s good to support the journalist but I cannot in good conscience send a link to elderly folks when this is so much safer.
Use the browser reader mode, select all, right click send email. Is it something like that you want?
Thank you! Great trick that comes pretty close.
If only there was a faster way to „select all“!
(if you’re down to experiment!)
For the next three intriguing articles you see on arbitrary sites, does the select all trick produce an aesthetically pleasing email? Do external dependencies get carried over? Do you spend any time manually removing cruft? Does the formatting leave anything to be desired?
When I do this all manually I can make it look great, and now that we’ve seen we can train computers to make stuff look great, it’s going to be a point of frustration for me until I have the one-click beautiful-article-email button.
Love everything to Markdownify :) I was just wondering, is there a Neovim/Markdown email client? Potentially using something like this? I love Neomutt, or Newsboat, and other TUIs. It would be great to have something totally on Markdown. Update: I gave it a spin [1] with Go and some of my favorite CLI's.
The real pain in email HTML isn't writing it — it's maintaining it. Markdown at least gives you something a human can edit 6 months later without crying.
Nice usage of admonitions. This is a great example of how eloquent markdown can be. Still very readable while even including the markup for 'footer' and the call out code.
Would love to use this - any plans for Cloudflare Workers support? Some of the node APIs you're using block it from working on Cloudflare right now.
Added support for cloudflare workers in 0.1.2. Thanks for the tip!
Sweet, thanks!
Good idea. I'll look into this.
I am working on smth similar markdown reader for humans, not agents - https://mdview.io
This problem was solved almost 15 years ago
This plus a block-based editor like editorjs would be a great addition to any custom cms.
Which email client will stylize raw markdown itself, making the HTML step here superfluous?
Emacs ofc :) seriously it should not be too much work although org-mode syntax would be even easier, there is a markdown mode here: https://jblevins.org/projects/markdown-mode/
The email part is not something i have done myself but it has been a feature for a very long time and you can find plenty of guides online.
It would first require a standard for Markdown. After that there would be very little stopping anyone from implementing it. I guess a MIME type for standard Markdown would also be nice.
Pretty sure I've said it before, but it would be a nice middle ground between text and all the complexity HTML+CSS brings in (if you want to compete with other HTML clients).
The idea of Markdown was that it was supposed to be readable in plain text without any stylizing.
This is great! I’d love to see this supported in SendOps!
Does anyone use MJML in golang? What package are you using?
templates are cool but seems too heavy to land in primary inbox
What do you mean by "too heavy"? File size?
Or, hear me out. Just send the markdown and skip the HTML bullshit. Any mail client will render markdown fine and the ones that don't either aren't worth using or don't want HTML mail in the first place. HTML email is the worst thing to ever happen to the internet
Curious why the CLI function is `mvd` instead of `mdv`?
What CLI function?
Good luck with the adoption of markdown to email html. That's the greatest challenge.
I wish people just sent plain text.
What about images, links?
Formatted text like bold or underline?
I also prefer plain text, but in most of my emails I talk about technical stuff, or I send transactional emails that require actions, in which case showing buttons is a much better user experience than plain text.
[deleted]
I don’t want buttons in my emails.
But they are a lot easier to see and click (accessibility, larger hit area).
You could have a larger text instead of a button, but changing font size is also HTML and not plain-text anymore.
Every MUA I've used allows the reader to set a font size, so changing font sizes is 100% a feature of plain-text emails. Then they get the link the size they need to read it correctly and it's absolutely easy to read. This here comment is pain text. Is it hard to read this link:
I don't think so. I certainly didn't have to resort to HTML to make that link readable and clickable.
I don’t have problems seeing and clicking normal text, thank you very much. I don’t want buttons on my emails.
I think the OP app is meant for creating transactional emails (or bulk-send emails like newsletters).
Those templates should account for all types of people and accessibility levels (including things like ADHD, where you need a big red button to click, otherwise you get overwhelmed by a block of text).
You can just send a link, and the user's client will probably highlight it even if it is plain text.
Yea, but how will they hide all the tracking URLs and base64 encoded PII from you in the email?
Using a URL shortener obviously. But you are right, if they only send plain text, they won't be able to include those 1x1 images at the bottom to track whether you have opened the email. Any sane email client blocks images by default, but whatever.
> What about images, links? Formatted text like bold or underline?
But I have to send the same sort of information (albeit shorter) via email on a regular basis.
A lot of alerts, reporting, quotes, code snippets, short documentation or step by step instructions, etc.
I don't just send emails to say "Hey, let's meet at 5". You know the memes with "this could have been an email", it usually is this case.
Just to be clear, most of those rich emails are the automatic/transactional emails.
Yeah, I get it, I unfortunately live in the real world too. I like to keep it plain text whenever possible but it's extremely useful sometimes to have inline screenshots and stuff like that.
I didn't mean to be sarcastic but it's just that to me, philosophically, email is a plaintext technology that had HTML bolted on to it kicking and screaming, and it's always been kind of crap. People like me hate things that are fundamentally ugly and crap even if they are useful. The web was designed for HTML from the start.
I used to think this, but lately I'm getting a lot of plain text marketing emails that are clearly LLMs. Now I dislike plain text emails just as much as HTML ones.
I don't. Plain text is typically formatted for 72-78 monospace characters - even if you don't want formatting, the text will look bad on any device that doesn't match IBM's 80-character punch cards from 1928.
In theory format=flowed solves that, but the same boomers that despise HTML mail also refuse to provide that accommodation, for anyone not behind a teletype.
Yeah, the first example on that site doesn't need any formatting.
It just says your code is <code>
A picture is worth a thousand words.
Plain text? Pffft.
Human language is an unnecessary abstraction, just like images.
I wish everyone would communicate in pure Binary.
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
It uses MJML under the hood to ensure email-safe HTML is generated. That should prevent many edge cases where failures can happen - but I'm sure there are some skeletons we'll have to find / fix.
"Write markdown. Ship emails." - I see a particular group of people interested in this, but they have their tools already.
I think you should probably let that group of people speak for themselves.
I'm in this "group" and see an immediate usefulness of this over what I'm doing now.
Anything that makes email development easier is great I guess, but have personally found MJML great for solving the issues you'd run into, and not sure I want yet another abstraction layer on top of that which makes it more limited...
They address this in the docs - it is meant to make authoring the content easier for LLMs since that is easy for them to write.
It still uses MJML for the actual templates, but it is a translation layer between markdown and the template itself.
If you need to author a lot of emails with LLM this does seem like it would be a great fit.
If you need to author a lot of emails with LLM you should be rethinking your business strategy tbh
If the goal is to write emails purely using AI, then it is trivial to attach the MJML documentation as context to your LLM using context7 MCP or something of the sort. It's not a very complex language and its documentation is not large at all.
That's assuming the crawlers haven't ingested it all already...
[dead]
This appears to be a MJML wrapper with a Markdown→HTML converter attached to it. I think generating HTML from code is easier than generating Markdown, since there are many templating tools that understand HTML escaping. And writing HTML is not that hard, especially for your typical emails, so I'm not really sure if this library would be helpful in the long run.
I like the idea of this tool, as writing Markdown for some people is probably easier than HTML. I mean, use whatever floats your boat. I like that this exists.
Also a way to use fewer standards for storage of input and created text.
Writing HTML for emails is a lot harder than you're making it sound. But MJML does a good job of simplifying it for most use cases.
I'm never seen the `::: header` or `{width="200"}` kind of syntax before. Is this custom or Frankenstein solution? Or is there some kind of md-extended pattern for defining components that has been gaining steam or smthn? Markdown tooling is always confusing, since everyone has their own standard.
Admonitions are :::, allows you do to do things like this, if you have custom parser, if not, your admonitions can fail gracefully as plain text
:: gallery
  
::
https://github.com/remarkjs/remark-directive
https://talk.commonmark.org/t/generic-directives-plugins-syn...
Yep both are widely used. I forget which markdowns extensions they originated from. The Pandoc website probably has the details.
Aye, I've seen these both in kramdown and quarto.
Markdown is the secret winner of the AI early years.
I'm not so sure. It's definitely the de facto standard, but I suspect minimal HTML is better. Just enough tags to add structure and meaning (H1-H6, p, a, em, section for structure including nesting, maybe more). LLMs were trained on a lot of HTML, they're good at processing it. HTML requires more tokens than markdown but I believe it's worth it. I'll find out in a few weeks as I experiment with both.
cries in org-mode
org-mode is amazing for humans. I, as a real human and not a robot, use it every day.
I feel you on this too.
[dead]
i never understood why the markdown mime type was not used in emailclients in webclients or desktop programs...
that would eliminate most html usage and enable longer texts than 70-85 characters per line.
It’s up to the e-mail client implementors, but I would personally prefer text/enriched, RFC 1896, instead of markdown.
I like how you aren't hiding the fact this is MJML under the hood and don't layer complex abstractions over MJML spec like similar projects (cough react email cough).
The devs maintaining MJML deserve so much credit for dealing with Gmail/Outlook's monopoly bullshit and 2007 html.
Nice idea for those who manage content in markdown. I've moved away from putting emails in my codebase, but seems great for founders moving fast.
What’s your opinion on react email?
Mostly fluff/hype. Not a value-add over just using raw MJML (which has nice VScode plugins for live previews), and in fact a long term risk to add to a codebase since react-email is just a marketing play by Resend (a startup) and will not be maintained as diligently as MJML.
Also, LLMs know MJML really well.
This is my experience as well. MJML is the older, more reliable, better documented technology. And when it comes to debugging email rendering, you really, REALLY want as much documentation as possible.
Thanks! I agree - the MJML team has laid so much groundwork and it frankly made this project possible.
Any "HTML emails" get filtered straight into the spam folder here. I think I'm not part of the target audience here.
How do you deal with things like "we sent you a one-time code to confirm your login"? Most of those are HTML-formatted today
I still can check the SPAM folder, if needed.
But most SPAMs are HTML, so you'll have a good default last-stage in-client filtering in place in case some SPAM actually makes it through the other setup on the server (greylisting, DNS based filtering lists, policy-based filtering, etc.) :)
Is that a thing? Is it safer to use plain text emails?
> Is that a thing?
There must be literally dozens of people who do this.
Very much so. While a lot of mail clients block images, they can be used to track you. Hell a lot of HTML can be used to track you if you're smart about it
At this point markdown is going to be the foundation of the entire AI web. Someone the other day showed off Markdown as a responsive frontend protocol. Now we've got email. How long until we're writing classes in markdown? We can only abstract this so far before we confuse AI more than help it.
Look up Configuration Complexity clock
I hope .md domains do not become a security hole as Markdown raises in popularity...
That's a valid concern, especially given the confusion we saw with .zip or .mov TLDs. But from a security engineering perspective, the bigger 'Markdown hole' I worry about is injection. When we render untrusted AI output into HTML for email, the sanitization pipeline becomes critical. I'd be curious to see how this library handles potential XSS vectors during the MD-to-HTML conversion.
This reminds me of the infamous dot zip domain and the security chaos that had followed.
Great project! And if you don't mind a little workaround and some Python scripting, you can turn a regular Obsidian folder into an automatic outbox. Write markdown, drag, drop, and ship.
I never actually thought about this. How are people making HTML emails so responsive? Email HTML is stuck in the IE6 era, right? So everything is just a horrible workaround with tables and ancient CSS?
I'm not exactly following as to who this is for - people are going to use email templates instead of writing Markdown emails, and agents can just as easily spit out HTML. Seems like your solution is in search of a problem.
Feels more like a content layer for LLMs than a replacement for MJML.
In my experience models tend to break HTML layouts pretty easily, while Markdown degrades more gracefully.
It uses MJML under the hood.
https://mjml.io/
Very nice. I think the kind of folks attracted to this thread might have some thoughts on a workflow I'm interested in.
When I see a news article, I want to be able to click a button on my Mac or iPhone to send the text of the article in the body of the email. Bonus points for rehosting the images from the article. And using a similar font both without carrying over any of the original external dependencies.
Normally it’s good to support the journalist but I cannot in good conscience send a link to elderly folks when this is so much safer.
Use the browser reader mode, select all, right click send email. Is it something like that you want?
Thank you! Great trick that comes pretty close.
If only there was a faster way to „select all“!
(if you’re down to experiment!)
For the next three intriguing articles you see on arbitrary sites, does the select all trick produce an aesthetically pleasing email? Do external dependencies get carried over? Do you spend any time manually removing cruft? Does the formatting leave anything to be desired?
When I do this all manually I can make it look great, and now that we’ve seen we can train computers to make stuff look great, it’s going to be a point of frustration for me until I have the one-click beautiful-article-email button.
Love everything to Markdownify :) I was just wondering, is there a Neovim/Markdown email client? Potentially using something like this? I love Neomutt, or Newsboat, and other TUIs. It would be great to have something totally on Markdown. Update: I gave it a spin [1] with Go and some of my favorite CLI's.
[1] https://x.com/sspaeti/status/2036539855182627169
There's not one that I'm aware of. Maybe it's about time there is :D
I gave Claude a spin, given all my likings ;) https://github.com/ssp-data/neomd
The real pain in email HTML isn't writing it — it's maintaining it. Markdown at least gives you something a human can edit 6 months later without crying.
Nice usage of admonitions. This is a great example of how eloquent markdown can be. Still very readable while even including the markup for 'footer' and the call out code.
Would love to use this - any plans for Cloudflare Workers support? Some of the node APIs you're using block it from working on Cloudflare right now.
Added support for cloudflare workers in 0.1.2. Thanks for the tip!
Sweet, thanks!
Good idea. I'll look into this.
I am working on smth similar markdown reader for humans, not agents - https://mdview.io
This problem was solved almost 15 years ago
This plus a block-based editor like editorjs would be a great addition to any custom cms.
Which email client will stylize raw markdown itself, making the HTML step here superfluous?
Emacs ofc :) seriously it should not be too much work although org-mode syntax would be even easier, there is a markdown mode here: https://jblevins.org/projects/markdown-mode/ The email part is not something i have done myself but it has been a feature for a very long time and you can find plenty of guides online.
It would first require a standard for Markdown. After that there would be very little stopping anyone from implementing it. I guess a MIME type for standard Markdown would also be nice.
Pretty sure I've said it before, but it would be a nice middle ground between text and all the complexity HTML+CSS brings in (if you want to compete with other HTML clients).
The idea of Markdown was that it was supposed to be readable in plain text without any stylizing.
This is great! I’d love to see this supported in SendOps!
Does anyone use MJML in golang? What package are you using?
templates are cool but seems too heavy to land in primary inbox
What do you mean by "too heavy"? File size?
Or, hear me out. Just send the markdown and skip the HTML bullshit. Any mail client will render markdown fine and the ones that don't either aren't worth using or don't want HTML mail in the first place. HTML email is the worst thing to ever happen to the internet
Curious why the CLI function is `mvd` instead of `mdv`?
What CLI function?
Good luck with the adoption of markdown to email html. That's the greatest challenge.
I wish people just sent plain text.
What about images, links? Formatted text like bold or underline?
I also prefer plain text, but in most of my emails I talk about technical stuff, or I send transactional emails that require actions, in which case showing buttons is a much better user experience than plain text.
I don’t want buttons in my emails.
But they are a lot easier to see and click (accessibility, larger hit area).
You could have a larger text instead of a button, but changing font size is also HTML and not plain-text anymore.
Every MUA I've used allows the reader to set a font size, so changing font sizes is 100% a feature of plain-text emails. Then they get the link the size they need to read it correctly and it's absolutely easy to read. This here comment is pain text. Is it hard to read this link:
http://microsoft.com/
I don't think so. I certainly didn't have to resort to HTML to make that link readable and clickable.
I don’t have problems seeing and clicking normal text, thank you very much. I don’t want buttons on my emails.
I think the OP app is meant for creating transactional emails (or bulk-send emails like newsletters).
Those templates should account for all types of people and accessibility levels (including things like ADHD, where you need a big red button to click, otherwise you get overwhelmed by a block of text).
You can just send a link, and the user's client will probably highlight it even if it is plain text.
Yea, but how will they hide all the tracking URLs and base64 encoded PII from you in the email?
Using a URL shortener obviously. But you are right, if they only send plain text, they won't be able to include those 1x1 images at the bottom to track whether you have opened the email. Any sane email client blocks images by default, but whatever.
> What about images, links? Formatted text like bold or underline?
Easy. Don't.
That's the great bit. You don't have to.
https://useplaintext.email/
Why isn't this website plain text then?
Probably because it's a website and not email.
But I have to send the same sort of information (albeit shorter) via email on a regular basis.
A lot of alerts, reporting, quotes, code snippets, short documentation or step by step instructions, etc.
I don't just send emails to say "Hey, let's meet at 5". You know the memes with "this could have been an email", it usually is this case.
Just to be clear, most of those rich emails are the automatic/transactional emails.
Yeah, I get it, I unfortunately live in the real world too. I like to keep it plain text whenever possible but it's extremely useful sometimes to have inline screenshots and stuff like that.
I didn't mean to be sarcastic but it's just that to me, philosophically, email is a plaintext technology that had HTML bolted on to it kicking and screaming, and it's always been kind of crap. People like me hate things that are fundamentally ugly and crap even if they are useful. The web was designed for HTML from the start.
I used to think this, but lately I'm getting a lot of plain text marketing emails that are clearly LLMs. Now I dislike plain text emails just as much as HTML ones.
I don't. Plain text is typically formatted for 72-78 monospace characters - even if you don't want formatting, the text will look bad on any device that doesn't match IBM's 80-character punch cards from 1928.
In theory format=flowed solves that, but the same boomers that despise HTML mail also refuse to provide that accommodation, for anyone not behind a teletype.
Yeah, the first example on that site doesn't need any formatting. It just says your code is <code>
A picture is worth a thousand words.
Plain text? Pffft.
Human language is an unnecessary abstraction, just like images.
I wish everyone would communicate in pure Binary.
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
It uses MJML under the hood to ensure email-safe HTML is generated. That should prevent many edge cases where failures can happen - but I'm sure there are some skeletons we'll have to find / fix.
"Write markdown. Ship emails." - I see a particular group of people interested in this, but they have their tools already.
I think you should probably let that group of people speak for themselves.
I'm in this "group" and see an immediate usefulness of this over what I'm doing now.