{"id":56288,"date":"2022-12-06T12:00:00","date_gmt":"2022-12-06T17:00:00","guid":{"rendered":"https:\/\/www.litmus.com\/?p=56288"},"modified":"2022-12-05T16:34:25","modified_gmt":"2022-12-05T21:34:25","slug":"email-framework-pros-cons","status":"publish","type":"post","link":"https:\/\/www.litmus.com\/blog\/email-framework-pros-cons","title":{"rendered":"Love it or Leave It? Email Developers Weigh In On Email Frameworks\u00a0"},"content":{"rendered":"\n\n\t
\n
\n \t
\n \t\t
\n \t\t\t
\n \t\t\t\t

Potentially unpopular opinion: we don\u2019t like using publicly available email frameworks at Litmus.<\/p>\n

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>, a Direct Marketing Developer at Fishawack Health, use and enjoy publicly available email frameworks daily. They\u2019re an excellent option for plenty of teams.<\/p>\n

But we at Litmus don\u2019t think they\u2019re the right option for every<\/i> email team\u2013and we\u2019ve got reasons to back it up!<\/p>\n

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\u2013so you can make the best decision for your organization.<\/p>\n

What is an email framework?<\/h2>\n

An email framework is a collection of pre-made HTML and CSS components that email developers use to build emails<\/b>.<\/p>\n

Two kinds of email frameworks:<\/h3>\n
    \n
  1. Publically available frameworks <\/b>that use pre-processors to help make coding easier by automating part of the coding process (like Maizzle or MJML).<\/li>\n
  2. Pre-built blocks of HTML code <\/b>that you create (like an email design system).<\/li>\n<\/ol>\n

    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\u2014or create their own email framework and form it into an email design system<\/a>.<\/p>\n

    Benefits of using publicly available email frameworks<\/h2>\n

    Frameworks have one main goal\u2014to make email development easier<\/a>. Here are three reasons open source email frameworks are so compelling to some developers.<\/p>\n

    1. Faster build time<\/h3>\n

    Imagine you\u2019re an email team of one, and you just got word that you need to send a sales promotion tomorrow. (Oh, and you\u2019re already knee-deep in developing another campaign.) You need to build quickly\u2013and an email framework can help.<\/p>\n

    Instead of building each component from scratch, you can plug and play with the framework\u2019s code. Hickman points out that you typically have to write less code for an email framework than jumping straight into HTML<\/p>\n

    \u201cAs 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.\u201dAnd it\u2019s true. Frameworks could help teams who are short on time. They\u2019re a great way to create emails fast. Then, you can throw them into your email testing platform like Litmus<\/a> and fix whatever bugs show up.<\/p>\n

    2. No updates required<\/h3>\n

    Third-party frameworks also continuously update code to deal with ISP changes or that one tricky element for that one frustrating email client<\/a>. The people who are keeping up the framework are the ones that are in charge of making sure everything works.<\/p>\n

    You don\u2019t have to go back and fix any code that no longer works or keep documentation up to date. Don\u2019t completely let your guard down, though. You should test every email you send<\/a>.<\/p>\n

    If you do run into an issue with an email framework, you can turn to your community. The MJML Slack<\/a>, like the Email Geeks Community<\/a>, is a place for email developers to connect, learn, troubleshoot, and support one another.<\/p>\n

    3. Works alongside HTML<\/h3>\n

    While you typically have to use a framework-specific coding language, you can add HTML where needed.<\/p>\n

    \u201cIf there\u2019s a coding scenario that requires coding that is outside of MJML\u2019s default scenarios using MJML tags, it\u2019s easily enough accomplished to \u2018code your own\u2019 so to speak. The <mj-text> tag is highly robust and accepts all types of custom HTML code,\u201d explains Hickman.<\/p>\n

    She also points out that there isn\u2019t much you can\u2019t<\/i> do with MJML; the misconception that those who use MJML are only doing very basic, simple email layouts is false.<\/p>\n

    \u201cI\u2019ve produced emails with Dark Mode<\/a> styles, used the \u2018faux absolute positioning\u2019 technique<\/a> 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\u2013but they\u2019re all completely doable within the framework,\u201d says Hickman.<\/p>\n

    Drawbacks of publicly available email frameworks<\/h2>\n

    While there are plenty of email developers who use and enjoy publically available frameworks, they do have some drawbacks, including:<\/p>\n

    1. Framework-specific language<\/h3>\n

    Email frameworks have a learning curve, since you typically have to learn a framework-specific language before getting started.<\/p>\n

    This might raise the question: \u201cWhy am I learning another language to do what I already know?<\/i>\u201d If you\u2019re confident in your HTML skills or don\u2019t 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\u2019ll have to manage two languages to use a framework to its full potential.<\/p>\n

    2. Loss of code control<\/h3>\n

    One of the most prominent downsides of email frameworks is your loss of complete insight and control of the code.<\/p>\n

    This is one of the largest reasons I\u2019m 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.<\/p>\n

    While you don\u2019t 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\u2019t know what\u2019s gone into it, what might conflict, or its quality. You\u2019ll also be left scrambling if something happens to the framework and you can\u2019t access or use it anymore.<\/p>\n

    3. Bloated code<\/h3>\n

    Adding custom HTML to an email framework gives you more control than relying solely on the framework, but it also creates extra work.<\/p>\n

    \u201cIf 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),\u201d says Hickman.<\/p>\n

    Creating something you know you\u2019ll have to update immediately could be a frustrating extra step you don\u2019t need.<\/p>\n

    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<\/a>, without you realizing it.<\/p>\n

    Bloated code can also make it hard to figure out exactly what part is causing a rendering issue<\/a> that you might be seeing. Creating your own email framework gives you the control to make changes and catch any issues right away.<\/p>\n

    How to create your own email framework as an email design system<\/h2>\n

    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.<\/p>\n

    We think more email teams should consider it. In fact, experts at companies like Zillow and Stack Overflow also leverage email design systems<\/a>.<\/p>\n

    What is an email design system?<\/h2>\n

    An <\/b>email design system<\/b><\/a> is a collection of reusable components guided by standards that teams use to create on-brand emails more consistently and efficiently. <\/b>In essence, it\u2019s an email framework that is specific to your brand\u2019s styles. In addition to visual guidelines like colors, our email design system has two critical email development components: partials and snippets.<\/p>\n