Email HTMHell – A Journey into HTML Email Development

A custom newsletter template for the company I’m working for was the starting point for some research into HTML email development. Although I’ve worked on the web for more than 20 years, I’d never had to deal with this niche area — and, in hindsight, thankfully so.

It’s no secret that HTML email is hard. Just take a look at Hristiyan Dodov’s hilarious post, which sums it up perfectly.

Thankfully, there are a few frameworks that help ease the pain. MJML is usually the first one you stumble upon, and for good reason. By abstracting raw HTML, it offers a range of predefined, battle-tested components that let you build layouts quickly and with confidence.

In this context, I can highly recommend Josh W. Comeau’s insightful article on his very own HTML email workflow.

MJML has become something of a de facto standard for authoring HTML emails, and many providers have adopted it. For most use cases it works perfectly fine. One of the things I miss is native dark mode support — although you can work around that with media queries and a bit of CSS.

There’s also Maizzle. Since it uses Tailwind CSS for styling, it initially looked like an ideal candidate for my workflow. It allows for much more fine-grained control over layouts, and its PostHTML and PostCSS pipeline makes a lot of sense when targeting cross-client compatibility. However, the lack of a higher-level abstraction layer is also its biggest drawback. You still end up writing a lot of table-based markup for fairly basic layouts, which quickly becomes hard to read and maintain. If you heavily rely on components or need to fetch data dynamically via an API, it can still be a good choice.

I haven’t looked deeply into other modern frameworks like react.email, which could be a viable alternative to MJML if you’re already working in that ecosystem.

An Ideal Email Editing Workflow

Drew Wilson’s tweet back in 2020 addressed this problem years ago.

Crafting a static template is one thing. Using it effectively inside your newsletter tool is another. I didn’t find any of the common newsletter SaaS tools ideal when it comes to managing a larger set of templates over time.

The main problem: once you drag a component into a template, the connection to its source is lost. Any subsequent changes to that component are no longer applied elsewhere.

This “copy-on-drop” model exists for safety and simplicity. Emails must be fully self-contained, and users need to edit freely without the risk of breaking other templates. But the trade-off is fragmentation — once a module is inserted, it’s disconnected forever.

That means no global updates, no shared design tokens, and no single source of truth. Each newsletter slowly drifts away from the base layout. It’s a workflow optimized for instant WYSIWYG results, not for developers who crave DRY, component-based systems.

Loops.so is the first tool I’ve seen that meaningfully improves this situation. It allows components to stay in sync and offers a back-syncing mechanism for pushing changes to other instances. On top of that, it supports themes that can be applied across emails and remain editable and consistent over time. That’s a big step toward treating email templates as part of a real design system.

Closing Thoughts

The hard part of HTML email isn’t writing it — it’s maintaining it.

As long as newsletter tools rely on copy-and-paste modules, templates will drift and design systems will fall apart. Approaches that keep components, themes, and templates in sync point toward a healthier future for email workflows.

HTML email may be stuck in the past, but the way we manage it doesn’t have to be.

P.S.: I’ve borrowed the term HTMHell from Manuel Matuzovic’s great collection of bad practices in HTML. He said it’s ok ☺

P.P.S.: I gave a short talk about this topic at the Frontend Graz meetup, also organized by Manuel.