Frameworks for Email?!

What the &#^$ is this $#!^!

I have 10 years of experience in the web development industry.  A good portion of this time was spent developing emails.  I was there the day Outlook 2007 first rolled out and the first musings of using CSS in email were thrown on its ear before it even took hold.  I was one of the original beta users of Litmus’s excellent Builder tool.  I’ve been a longtime contributor to Campaign Monitor’s community with several tips submitted to their blog.

Overall, it’s safe to say, I know a thing or two about email development.  So imagine my surprise when I found out that frameworks have been created for email development.  Wait, what’s that?  Frameworks?!?  For Email?   So I researched further.

The Frameworks In Question.

Foundation for Email is the first one I really looked at.  Foundation promises SASS in email, a responsive grid, it’s own unique markup language, and many many more features.  MHML promises yet another markup language, a responsive grid, and many other features.  There’s also been several attempts to create a Bootstrap for Emails too.   The biggest problem I have with this is the concept of a framework for emails is inherently flawed.

Want to Learn Latin?  Ok, First Learn French.

Just as I detailed in my earlier post about pre-processors, browsers function by reading HTML, CSS, and Javascript.  Email clients don’t really read javascript, and, due to standards present from Outlook, we have to use very little to no CSS, thus most times emails are coded in tables, with inlined styles.  Because of preview panes, most emails will be designed to be between 500 and 600 pixels wide, well under the width of even the most narrow tablets.  The limited nature of CSS support in emails means that any mobile layout would, naturally, default to a single column look most likely.

There’s much more to making emails; bulletproof buttons, bulletproof backgrounds, webfonts, Outlook hacks, webmail hacks, etc., that going over everything would be more in place at Litmus’s wonderful community.  The point remains that, on a whole, most emails should not have that much code in them, if you can help it.  Afterall, we are talking about a piece of code that is sent via email.  Honestly, emails should rarely be over 30kb in file size, or over 1,000 lines of code.  Tables, archaic as they are for forming layouts in HTML, are still valid HTML code, even in an HTML5/CSS3 world.

These newer, ‘easier’ formats for writing emails provided by Foundation and MHML create the exact same issues I wrote about in my pre-processor post.  This is the creation of a similar, but not exact language used for software to later interpret into valid code.  And, once more, the existence of Foundation’s INK(what they call their markup language), an MHML’s markup language, plus what I can imagine is many others out there, is creating various competing standards of language when, again, in the end, the browser can still only understand HTML.

This is like saying to a language student Hey, want to learn Latin?  Ok, first learn French.  

No to Frameworks, Yes to Boilerplates

While I don’t believe in frameworks, I do believe in starting all emails on a basic email boilerplate.  Something that has 90% of what I always use in every email.  It’s small; compact, and has no grid system, no SASS, and no unique markup language.   It’s a boilerplate.

It’s a Friggin’ Email

I really really want to emphasize this.  This is a piece of HTML/CSS that you’re writing that will most likely be less than 30kb.  It’s something that, with practice, you should be able to write in just under 2-3 hours.  This is an email.  This is not a landing page, a website, web-app, or anything else that would require a code-base that would honestly eclipse the size of the email itself.  This is like having to build a sandbox in your backyard and renting a backhoe.