Picking MJML as the output format instead of raw HTML is the move. That's the layer where the cross-client pain has already been solved by people more patient than any of us.
Two questions:
1. How extensible is the block system? Can consumers define their own block types with custom MJML output, or are you limited to the built-ins?
2. Any plans for a headless render path (JSON → MJML → HTML on a server) for transactional emails generated from templates at send time?
Either way, bookmarking. Been waiting for someone to do this without the SaaS tax.
Thanks — yes on both, and both already exist today.
1. Custom block extensibility: full. You define a custom block as a schema — typed fields displayed in the editor (text, textarea, image, color, number, select, boolean, repeatable that contains basic fields) plus a Liquid template that emits HTML using those field values. The editor auto-renders the form for marketers to fill in, then runs the Liquid against those values to show a live preview on the canvas — so consumers don't write a Vue component themselves. The renderer wraps that HTML in <mj-text>, so it still goes through MJML's table layer for cross-client rendering. Optional dataSource.onFetch lets the block hit your API at render time, so use user can fetch custom block contents from existing data source — instead of having to manually type values into every field. Check out the docs and playground for custom blocks usage.
2. Headless render path: that's exactly what @templatical/renderer is. Separate package, zero UI dependency, pure JSON -> MJML conversion. You store the JSON tree in your storage; on the backend you pass it to renderToMjml() and get MJML back. Since MJML has compiler libraries in almost every language, you compile MJML to HTML yourself whenever. Currently the renderer is TypeScript-only (browser + Node.js); porting to other languages as first-party packages is on the roadmap.
The whole shape — store JSON in your DB, render at send time on your server, send via your own provider — is the transactional flow you described.
I looked for this in the past. This is the main reason we bothered with mailchimp/hubspot -- simply the ability for nontechnical marketing people to put together nice emails, and the trust that we won't need an engineer to troubleshoot email formatting on their behalf. I remember trying some OSS tools at the time (8 years ago?) and there were some templates we used but then when we wanted to modify them, the broken-ness of email html/css standards made it really hard to test.
I know the standards and practice around this are a moving target, though, so I hope you can find a model to sustain and expand this, without charging for delivery/contact list numbers like MailChimp or other incumbents.
Thanks — this is exactly the audience I built it for.
The cross-client rendering thing is why Templatical outputs MJML instead of raw HTML. MJML was built to abstract all the
table-based, Outlook-2007-quirks, Gmail-strips-style nonsense — you write semantic blocks, MJML compiles to table HTML
that works across every major email client. So when your marketing person moves a block or changes a button color, it
doesn't silently break in Outlook two weeks later.
On sustainability — same concern. Even while I was building it, multiple times I caught myself asking "is this even worth theeffort? Maybe not with all the functionalities I've built, but someone could vibe-code a lightweight version of it in a day." But at the same time, I see and personally used SaaS products with the same or fewer features selling for $2,500/mo, which seems ridiculous.
I'm currently working on a subscription-based Cloud version, but only for things that actually need an infrastructure and backend: AI chat/rewrite, image-to-template conversion, MCP integration, hosted media gallery, saved modules, commenting, real-time collab, email testing, version history, etc. Sending stays your own provider — no per-contact, per-email, or per-delivery charges.
Even when using mjml you must do render tests of your templates using litmus or a similar service. Mjml is WAY better than hand rolling templates but there are foot guns to be found and the docs won’t mention most of them https://github.com/mjmlio/mjml/issues/2927#issuecomment-2539....
Totally agree on edge case quirks of MJML - or more like weird behaviors in Outlook. With so many email services and clients around, nothing can provide 100% bulletproof solution but I think MJML is as close as it gets to works-for-majority. I‘m sure MJML maintainers also aim for this.
Also, yes! Microsoft should kill Outlook with fire! :)
As someone who built a similar open source project (grapesjs), this looks really good
Even with LLMs, generating raw HTML emails that render correctly across major email clients is still surprisingly hard, so great choice going with MJML.
Holy shit, it's you! Thank you, that genuinely means a lot coming from you!
GrapesJS is the forever OG that proved this whole space could be an embeddable SDK rather than a paywalled SaaS. It also standardized the palette/canvas/inspector layout that every serious visual builder now ships by default — including Templatical. I took direct inspiration from a few other patterns too: the block-as-first-class-citizen model, and the trait system, which maps almost 1:1 to how Templatical's custom blocks expose typed fields into the inspector.
And yeah — agreed on MJML. Building email layouts that work for most clients is notoriously hard. I think the people who built MJML absorbed an enormous amount of pain so the rest of us don't have to.
Hi looks nice. I am in the process of building a email management system for a client with a small coaching base, and decided to go with Maily to integrate with the React and resend stack.
I hadn't heard of beefree or unlayer before this post. What would you say are the reasons we would want to use Templatical over our current integration or Beefree/unlayer?
Thanks. Honestly, I hadn't heard of Maily until your comment :) Just spent a few minutes with it. Looks like a clean React-first editor.
I can't directly compare it with Maily, but what I see from first glance is that it is a minimalist email template editor that gets the job done. Please correct me if I'm wrong.
Beefree and Unlayer are paid services that offer powerful features like custom blocks, merge tags, display conditions, theming. The catch is most of those features sit behind enterprise tiers, and you're tied to their cloud render API to get HTML out.
Templatical aims for that same feature set, open-sourced and self-hostable. No vendor render API — output is MJML, which is battle-tested across the major email clients.
Check out the playground — it has
templates showcasing different features. See if it suits your use case.
This is awesome! I've always had trouble designing my emails in Figma first and then coding the HTML. For some reason, I just can't wrap my head around it any other way (I might not be the best at coding, tbh). Thanks for putting this together—I'm definitely going to give it a shot!
Believe me, writing HTML for email that works for most clients is notoriously hard, no amount of code experience can help with that :)
This was exactly the reason I went with MJML. Consumer should focus on designing the email, Templatical takes care of converting the design to MJML and rest with MJML is already battle-proven.
This looks great! So glad the output is MJML. I will have to see how I can embed it in the project I am working on as I have been wanting to add the feature for clients to build out their own emails or customize some of the standard templates. It will at least be a big help in my own admin UI to start.
If you ship your app with it, send a link — happy to feature it on the showcase page. Also, if you have existing HTML-based templates, try the @templatical/import-html package to convert them to Templatical JSON true — should get you a reasonably close starting point.
This is really awesome. I'm showing this to my marketing team - we were looking for something similar in the past too. I've had the pleasure of attempting to build fancy marketing emails and a signature and I never wanna look at a Word Table in my life again.
People who know how painful email HTML is are the exact audience here. I believe MJML is the best thing that happened to emails — eliminates almost all the cross-client compatibility quirks.
If your team gives it a spin, I'd genuinely love their feedback.
I was considering IntroJS, but Claude Code generated a simpler version in ~120 lines — just @vueuse/core helpers (useLocalStorage, useIntervalFn) and focus-trap, no tour library.
Looks good! Do you have an MCP or API in your roadmap? The reason: managing a lot of templates and their placeholders can get out of hand pretty quickly and agents can be a good way to deal with the complexity.
I'd love to try this with sendops.dev although I'm not sure how it's going to work with the git backed templating it has.
No — built from scratch on Vue 3 + TipTap, no React anywhere. Output is MJML, not the React-component-to-HTML approach React Email takes.
Adjacent category but no shared foundation: React Mail is a code-first library for devs to write emails as components; Templatical is an embedded visual editor for marketers to build them without touching code.
No — and this is actually one of the real architectural differences from the closed-source competitors like Beefree and Unlayer.
The SDK is fully client-side — it runs in your app, the JSON templates go wherever you decide to store them (your DB, S3, anything). Nothing touches my infrastructure. SDK also has zero telemetry.
The Cloud tier on the roadmap (AI rewrite, real-time collab, MCP, saved modules, media library, comments) is opt-in — you only hit it if you actively sign up.
No — built from scratch on Vue 3 + TipTap. Different data model entirely: Templatical stores templates as a typed JSON tree of blocks and renders them as MJML; GrapesJS is a generic HTML/CSS page-builder retrofitted for email via an MJML plugin.
Yeah, I get what you mean about UI. But honestly that similarity is also a selling point — people are used to how visual editors look and work. Shipping a drastically different UI is a hard sell.
GrapesJS — the OG embeddable visual builder. Yes, I like it. I haven't used it recently, but I built production landing-page builders on top of it a while back.
I saw they also have an email builder now and checked it just now. Looks and works fine, but you can tell it's a retrofitted approach from a landing-page builder. With Templatical I wanted to build something from the ground up, email-only.
Picking MJML as the output format instead of raw HTML is the move. That's the layer where the cross-client pain has already been solved by people more patient than any of us.
Two questions:
1. How extensible is the block system? Can consumers define their own block types with custom MJML output, or are you limited to the built-ins?
2. Any plans for a headless render path (JSON → MJML → HTML on a server) for transactional emails generated from templates at send time?
Either way, bookmarking. Been waiting for someone to do this without the SaaS tax.
Thanks — yes on both, and both already exist today.
1. Custom block extensibility: full. You define a custom block as a schema — typed fields displayed in the editor (text, textarea, image, color, number, select, boolean, repeatable that contains basic fields) plus a Liquid template that emits HTML using those field values. The editor auto-renders the form for marketers to fill in, then runs the Liquid against those values to show a live preview on the canvas — so consumers don't write a Vue component themselves. The renderer wraps that HTML in <mj-text>, so it still goes through MJML's table layer for cross-client rendering. Optional dataSource.onFetch lets the block hit your API at render time, so use user can fetch custom block contents from existing data source — instead of having to manually type values into every field. Check out the docs and playground for custom blocks usage.
2. Headless render path: that's exactly what @templatical/renderer is. Separate package, zero UI dependency, pure JSON -> MJML conversion. You store the JSON tree in your storage; on the backend you pass it to renderToMjml() and get MJML back. Since MJML has compiler libraries in almost every language, you compile MJML to HTML yourself whenever. Currently the renderer is TypeScript-only (browser + Node.js); porting to other languages as first-party packages is on the roadmap.
The whole shape — store JSON in your DB, render at send time on your server, send via your own provider — is the transactional flow you described.
Great idea. I starred this on GitHub, where by the way for those are interested, your star will be statistically significant (only about 100 now).
https://github.com/templatical/sdk
Thanks for the star :)
And yeah — at this stage every star is statistically significant, so anyone reading: appreciated.
This is cool!
I looked for this in the past. This is the main reason we bothered with mailchimp/hubspot -- simply the ability for nontechnical marketing people to put together nice emails, and the trust that we won't need an engineer to troubleshoot email formatting on their behalf. I remember trying some OSS tools at the time (8 years ago?) and there were some templates we used but then when we wanted to modify them, the broken-ness of email html/css standards made it really hard to test.
I know the standards and practice around this are a moving target, though, so I hope you can find a model to sustain and expand this, without charging for delivery/contact list numbers like MailChimp or other incumbents.
Thanks — this is exactly the audience I built it for.
The cross-client rendering thing is why Templatical outputs MJML instead of raw HTML. MJML was built to abstract all the table-based, Outlook-2007-quirks, Gmail-strips-style nonsense — you write semantic blocks, MJML compiles to table HTML that works across every major email client. So when your marketing person moves a block or changes a button color, it doesn't silently break in Outlook two weeks later.
On sustainability — same concern. Even while I was building it, multiple times I caught myself asking "is this even worth theeffort? Maybe not with all the functionalities I've built, but someone could vibe-code a lightweight version of it in a day." But at the same time, I see and personally used SaaS products with the same or fewer features selling for $2,500/mo, which seems ridiculous.
I'm currently working on a subscription-based Cloud version, but only for things that actually need an infrastructure and backend: AI chat/rewrite, image-to-template conversion, MCP integration, hosted media gallery, saved modules, commenting, real-time collab, email testing, version history, etc. Sending stays your own provider — no per-contact, per-email, or per-delivery charges.
Even when using mjml you must do render tests of your templates using litmus or a similar service. Mjml is WAY better than hand rolling templates but there are foot guns to be found and the docs won’t mention most of them https://github.com/mjmlio/mjml/issues/2927#issuecomment-2539....
Totally agree on edge case quirks of MJML - or more like weird behaviors in Outlook. With so many email services and clients around, nothing can provide 100% bulletproof solution but I think MJML is as close as it gets to works-for-majority. I‘m sure MJML maintainers also aim for this.
Also, yes! Microsoft should kill Outlook with fire! :)
I remember doing a MailChimp "clone" in Laravel some 12 years ago and implementing an email builder using their templates
As someone who built a similar open source project (grapesjs), this looks really good
Even with LLMs, generating raw HTML emails that render correctly across major email clients is still surprisingly hard, so great choice going with MJML.
Holy shit, it's you! Thank you, that genuinely means a lot coming from you!
GrapesJS is the forever OG that proved this whole space could be an embeddable SDK rather than a paywalled SaaS. It also standardized the palette/canvas/inspector layout that every serious visual builder now ships by default — including Templatical. I took direct inspiration from a few other patterns too: the block-as-first-class-citizen model, and the trait system, which maps almost 1:1 to how Templatical's custom blocks expose typed fields into the inspector.
And yeah — agreed on MJML. Building email layouts that work for most clients is notoriously hard. I think the people who built MJML absorbed an enormous amount of pain so the rest of us don't have to.
Huge respect for what you built.
Honestly, I didn’t invent anything particularly new, but I deeply appreciate your words. Thank you.
Really happy to see people building great things in this space and pushing it forward. Wishing you and Templatical the best!
Hi looks nice. I am in the process of building a email management system for a client with a small coaching base, and decided to go with Maily to integrate with the React and resend stack.
I hadn't heard of beefree or unlayer before this post. What would you say are the reasons we would want to use Templatical over our current integration or Beefree/unlayer?
Thanks.
Thanks. Honestly, I hadn't heard of Maily until your comment :) Just spent a few minutes with it. Looks like a clean React-first editor.
I can't directly compare it with Maily, but what I see from first glance is that it is a minimalist email template editor that gets the job done. Please correct me if I'm wrong.
Beefree and Unlayer are paid services that offer powerful features like custom blocks, merge tags, display conditions, theming. The catch is most of those features sit behind enterprise tiers, and you're tied to their cloud render API to get HTML out.
Templatical aims for that same feature set, open-sourced and self-hostable. No vendor render API — output is MJML, which is battle-tested across the major email clients.
Check out the playground — it has templates showcasing different features. See if it suits your use case.
This is awesome! I've always had trouble designing my emails in Figma first and then coding the HTML. For some reason, I just can't wrap my head around it any other way (I might not be the best at coding, tbh). Thanks for putting this together—I'm definitely going to give it a shot!
Believe me, writing HTML for email that works for most clients is notoriously hard, no amount of code experience can help with that :)
This was exactly the reason I went with MJML. Consumer should focus on designing the email, Templatical takes care of converting the design to MJML and rest with MJML is already battle-proven.
The migration page is so good. Being stuck in Unlayer is a real thing, and seeing a clear path out makes this much more tempting to adopt.
Happy to hear you found it useful. :)
I'd love to hear your feedback on what worked and what didn't. Feel free to open an issue or start a discussion on GitHub.
I got you a gold star ;) Excited to use this, as I've been frustrated by vendor lock-in for this exact use case.
This looks great! So glad the output is MJML. I will have to see how I can embed it in the project I am working on as I have been wanting to add the feature for clients to build out their own emails or customize some of the standard templates. It will at least be a big help in my own admin UI to start.
Amazing to hear :)
If you ship your app with it, send a link — happy to feature it on the showcase page. Also, if you have existing HTML-based templates, try the @templatical/import-html package to convert them to Templatical JSON true — should get you a reasonably close starting point.
This is really awesome. I'm showing this to my marketing team - we were looking for something similar in the past too. I've had the pleasure of attempting to build fancy marketing emails and a signature and I never wanna look at a Word Table in my life again.
People who know how painful email HTML is are the exact audience here. I believe MJML is the best thing that happened to emails — eliminates almost all the cross-client compatibility quirks.
If your team gives it a spin, I'd genuinely love their feedback.
This is great, i've been wanting someone to do this for a while, and was tempted to myself
I was thinking this is so nice but too bad I can't use it because I'm so deep into Unlayer. Then I see the the migration page :)
Yes! If you attempt the migration, I'd love to hear your feedback on what worked and what didn't. GitHub Issues / Discussions both open.
What do you use for the onboarding guide?
Hand-rolled in Vue 3 using Claude Code :)
I was considering IntroJS, but Claude Code generated a simpler version in ~120 lines — just @vueuse/core helpers (useLocalStorage, useIntervalFn) and focus-trap, no tour library.
Not hand-rolled, since you used AI: https://news.ycombinator.com/item?id=48061257
YES! This is so needed. Also very happy to see it's Vue + TipTap. Great choices.
Thanks :)
I know each framework has its pros/cons, opinionated in a certain way. Vue is my favorite.
TipTap was the easy half. It's basically the go-to option when a good WYSIWYG editor is needed.
Looks good! Do you have an MCP or API in your roadmap? The reason: managing a lot of templates and their placeholders can get out of hand pretty quickly and agents can be a good way to deal with the complexity.
I'd love to try this with sendops.dev although I'm not sure how it's going to work with the git backed templating it has.
Really cool work. Quick question: is this built on top of React Email?
Thanks.
No — built from scratch on Vue 3 + TipTap, no React anywhere. Output is MJML, not the React-component-to-HTML approach React Email takes.
Adjacent category but no shared foundation: React Mail is a code-first library for devs to write emails as components; Templatical is an embedded visual editor for marketers to build them without touching code.
Very nice job! That project have a lot potential!
Thank you!
This is really nice, thanks for building. I will use that heavily :)
This is great a great idea !! I starred it on github.
Thanks for the star!
does it store our data persistently on your server/system
No — and this is actually one of the real architectural differences from the closed-source competitors like Beefree and Unlayer.
The SDK is fully client-side — it runs in your app, the JSON templates go wherever you decide to store them (your DB, S3, anything). Nothing touches my infrastructure. SDK also has zero telemetry.
The Cloud tier on the roadmap (AI rewrite, real-time collab, MCP, saved modules, media library, comments) is opt-in — you only hit it if you actively sign up.
This is superb work!!
Thank you!
Looks like a grapes fork?
No — built from scratch on Vue 3 + TipTap. Different data model entirely: Templatical stores templates as a typed JSON tree of blocks and renders them as MJML; GrapesJS is a generic HTML/CSS page-builder retrofitted for email via an MJML plugin.
Thanks for the response, I will have a closer look! Maybe it's just the current UI Trends that look similar to me. Do you like grapes in general?
Yeah, I get what you mean about UI. But honestly that similarity is also a selling point — people are used to how visual editors look and work. Shipping a drastically different UI is a hard sell.
GrapesJS — the OG embeddable visual builder. Yes, I like it. I haven't used it recently, but I built production landing-page builders on top of it a while back.
I saw they also have an email builder now and checked it just now. Looks and works fine, but you can tell it's a retrofitted approach from a landing-page builder. With Templatical I wanted to build something from the ground up, email-only.
did you build it yourself or by AI?