Potentially unpopular opinion: we don’t like using publicly available email frameworks at Litmus.
Yes, there are upsides to leveraging pre-existing email components that someone else is in charge of updating. Many email developers, like Nicole Hickman, a Direct Marketing Developer at Fishawack Health, use and enjoy publicly available email frameworks daily. They’re an excellent option for plenty of teams.
But we at Litmus don’t think they’re the right option for every email team–and we’ve got reasons to back it up!
Here are some of the benefits and drawbacks we think every email team should consider when it comes to the pros and cons associated with email frameworks–so you can make the best decision for your organization.
What is an email framework?
An email framework is a collection of pre-made HTML and CSS components that email developers use to build emails.
Two kinds of email frameworks:
- Publically available frameworks that use pre-processors to help make coding easier by automating part of the coding process (like Maizzle or MJML).
- Pre-built blocks of HTML code that you create (like an email design system).
Rather than writing each line of code from scratch for every email, a framework has the building blocks you need to speed up development without sacrificing quality. Any developer can use a publicly-available email framework—or create their own email framework and form it into an email design system.
Benefits of using publicly available email frameworks
Frameworks have one main goal—to make email development easier. Here are three reasons open source email frameworks are so compelling to some developers.
1. Faster build time
Imagine you’re an email team of one, and you just got word that you need to send a sales promotion tomorrow. (Oh, and you’re already knee-deep in developing another campaign.) You need to build quickly–and an email framework can help.
Instead of building each component from scratch, you can plug and play with the framework’s code. Hickman points out that you typically have to write less code for an email framework than jumping straight into HTML
“As we all know, due to Outlook for Windows not playing nicely with divs, ghost tables are required for emails to work as expected in Windows Outlook. MJML creates the ghost tables for you, so it saves a ton of coding/typing time.”And it’s true. Frameworks could help teams who are short on time. They’re a great way to create emails fast. Then, you can throw them into your email testing platform like Litmus and fix whatever bugs show up.
2. No updates required
Third-party frameworks also continuously update code to deal with ISP changes or that one tricky element for that one frustrating email client. The people who are keeping up the framework are the ones that are in charge of making sure everything works.
You don’t have to go back and fix any code that no longer works or keep documentation up to date. Don’t completely let your guard down, though. You should test every email you send.
If you do run into an issue with an email framework, you can turn to your community. The MJML Slack, like the Email Geeks Community, is a place for email developers to connect, learn, troubleshoot, and support one another.
3. Works alongside HTML
While you typically have to use a framework-specific coding language, you can add HTML where needed.
“If there’s a coding scenario that requires coding that is outside of MJML’s default scenarios using MJML tags, it’s easily enough accomplished to ‘code your own’ so to speak. The <mj-text> tag is highly robust and accepts all types of custom HTML code,” explains Hickman.
She also points out that there isn’t much you can’t do with MJML; the misconception that those who use MJML are only doing very basic, simple email layouts is false.
“I’ve produced emails with Dark Mode styles, used the ‘faux absolute positioning’ technique written up by Mark Robbins and Stephen Sayo, an interactive email inbox survey, and a whole lot more, all from within MJML. It does require a strong working knowledge of HTML to pull off these techniques from within MJML, and a strong working knowledge of MJML as well–but they’re all completely doable within the framework,” says Hickman.
Drawbacks of publicly available email frameworks
While there are plenty of email developers who use and enjoy publically available frameworks, they do have some drawbacks, including:
1. Framework-specific language
Email frameworks have a learning curve, since you typically have to learn a framework-specific language before getting started.
This might raise the question: “Why am I learning another language to do what I already know?” If you’re confident in your HTML skills or don’t want to take the time to learn new tags, you may not like email frameworks. Since some elements require both HTML and MJML language knowledge if you use a framework, you’ll have to manage two languages to use a framework to its full potential.
2. Loss of code control
One of the most prominent downsides of email frameworks is your loss of complete insight and control of the code.
This is one of the largest reasons I’m not a fan of publicly available frameworks. Yes, they help you code easier. But especially if you’re using a framework that you didn’t create, you’re putting your code into someone else’s hands.
While you don’t completely give up control of your code (since you can modify the email with HTML after it processes), that can raise other issues. For example, if you don’t control the bulk of your code, you don’t know what’s gone into it, what might conflict, or its quality. You’ll also be left scrambling if something happens to the framework and you can’t access or use it anymore.
3. Bloated code
Adding custom HTML to an email framework gives you more control than relying solely on the framework, but it also creates extra work.
“If a layout for desktop has, for example, three columns that need to stack into two (3×2>2×3), then HTML coding is required to accomplish this. Otherwise, <mj-column> defaults to single column stacking (3×2>1×6),” says Hickman.
Creating something you know you’ll have to update immediately could be a frustrating extra step you don’t need.
Since frameworks are building blocks for any team to use in any combination, you might also experience code bloat. For example, if you combine multiple components that happen to have some shared code, your emails may take longer to load, without you realizing it.
Bloated code can also make it hard to figure out exactly what part is causing a rendering issue that you might be seeing. Creating your own email framework gives you the control to make changes and catch any issues right away.
How to create your own email framework as an email design system
Plenty of people use publicly available email frameworks, and they do have value. At Litmus, we use our own email framework and have incorporated it into an email design system instead.
We think more email teams should consider it. In fact, experts at companies like Zillow and Stack Overflow also leverage email design systems.
What is an email design system?
An email design system is a collection of reusable components guided by standards that teams use to create on-brand emails more consistently and efficiently. In essence, it’s an email framework that is specific to your brand’s styles. In addition to visual guidelines like colors, our email design system has two critical email development components: partials and snippets.
As things change in our workflow, we have to adapt and evolve. That’s a lot easier to do with an email design system than relying on an outside framework.
Creating a custom email framework is a lot like creating an email design system. I created our email framework while creating our email design system. In fact, I consider our email design system’s micro blocks our email framework. They’re small and flexible enough to use anywhere.
Example of Litmus’ Design Library used as an email design system/email framework
How to build an email design system
Instead of relying on a third-party email framework, you can build out your email design system and create an email framework– all at the same time. Here are five tips to make the transition.
1. Build slowly and test as you go
Creating an entire email design system is daunting. And now you have to create an email framework too? Yikes! You don’t have to overhaul your email workflow overnight, though.
Start by adding your most-used elements or common pain points to your framework. If there’s a common bug that you’re fixing a lot, create a snippet for just that one piece. Then, you won’t have to keep fixing it over and over again.
After you create a few snippets, test the framework and start using the snippets. When you put them to use, you’ll probably find mistakes, or that some things don’t fit together the way you expected. If you create everything at once, you might end up with lots of mistakes. Don’t wait to get started.
2. Use past emails as a basis
Using past emails saves time in creating your email design system and your framework. If you’ve been coding your emails for a while, you can go into past emails and take code to create email framework snippets from that. Use larger, more designed chunks for design system blocks (like an article block) and smaller blocks (like a paragraph tag) to create email framework blocks.
3. Create a system to track issues
As you use and develop your email design system, you must set up a process to track and resolve issues. I use a simple form to enter issues I come across, and place them in a spreadsheet so the team can collaborate.
I, or someone else on the team, can fill it out with the form when we discover an issue. Then, I can fix errors all at once. If there’s an emergency– like an ESP stops supporting styles in the head section– I’ll change it immediately. If it’s a minor issue–like an image alt text isn’t styled correctly–I’ll take care of it at the end of the month.
4. Keep everything in one place with Litmus
Litmus’ Design Library gives you a centralized place to store, use, and collaborate on your email design system. Instead of starting from scratch for each message, you can use a template or add partials and snippets. After building your email, you can automatically test it within Litmus and sync it to your ESP.
About the Author
