What is your email framework of choice?
So far I've tried Foundation Email & MJML. Both have their pros and cons but they are not perfect and I've noticed some rendering issues and bugs on both, so right now I'm using both frameworks depending on the type of marketing email sent.
I wanted to know what are your preferred email framework(s) or template(s) to use? What I'm looking for is something that is:
- Rendering on all major clients (https://emailclientmarketshare.com/)
- Easy to build (I like the templating tags used in MJML & Foundation)
- Flexible in mobile and desktop layouts/rednering (I found Foundation to be best at this so far).
- Reduced file size (Foundation can get quite large and starts to truncate in Gmail).
Thank you for your suggestions!
BLUF: It's down to personal preferences. But I personally enjoy MJML because it's mobile-first and forward thinking, the syntax is nicer, and the support community is astounding.
I've been a fan of Foundation since v1. It's easy to use and has tons of utility built right in. I used it in several production projects and shaved hours off my dev time and greatly increased my ability to target emails cross-platform - it was wonderful. Getting used to writing "Inky" HTML was a tiny bit of a challenge but once I got the hang of it I was coding at full speed. And when Zurb announced that they were cooking up V2 I waited impatiently for months until the day it was released...but by then I had found MJML...
MJML started as a project internally to MailJet and from my understanding grew pretty rapidly to become a real value-adding project that they decided to release into the wild. I actually came across it one day in a Litmus newsletter that mentioned exciting Community posts. Intrigued by the post I quickly visited the website and downloaded through NPM and started combing through the online docs. I was immediately impressed.
The MJML syntax is EXTREMELY simple and if you've got absolutely no HTML experience you can start coding up really good emails in I would say maybe an hour or two (once you get used to dealing with the command line). If you do have HTML experience and, more specifically HTML email experience of course, then it'd take you about 5 minutes to put together a great if not basic email. I really enjoy the experience of typing up straight MJML code especially for prototypes. Then when you want to get a little more serious you can throw in your own HTML/CSS at will and MJML will spit out a beautiful email (providing the design itself is beautiful 😜) that's pretty much ready to go into testing and deployment.
Now all that said, about a month or two after I started using MJML then Foundation for Emails 2 (using v2. Of their Inky language) was released. I was exactly as excited as I had been all along. As good as MJML 1.0 was I knew that Foundation 2 would dominate. Now I would write straight Inky code rather than using "Inky HTML" (the difference is that originally you'd write HTML with some Inky thrown in but now you write in Inky with HTML thrown in. This is the same method you use when writing MJML). But the truth is I wasn't exactly blown away.
Foundation 2 is an excellent framework. It's very robust, has support for partials, and using SASS in email development was a dream come true (email developers, as it turns out, dream nerdy dreams). But there were a few things that I didn't really enjoy First it was the project file itself: when you create a new project (which is to say, one email) you do so on the command line and you end up creating a +~200MB folder. Now this folder is for development only, once you're ready to test and deploy you have a single HTML file. But it's still huge and has over 2,000 files. Compare that to an MJML project which is exactly one .mjml file and you can see how that can be a little jarring.
Getting over the huge size of the project folder, though, I dove into the new Inky syntax which, as expected, is a pleasure to use. This is of course where I started comparing and contrasting the two frameworks to see which I'd enjoy using best.
MJML is a mobile-first framework. So when you create a table, for example, it's going to be 100% width (with some padding) and then use media queries and other CSS goodness to display properly on desktop clients. Foundation, on the other hand, is desktop-first and makes use of media queries to display properly on mobile. Each method has its pros and cons of course, but I prefer the mobile-centric approach from MJML. This is just a preference, of course but I mention it here because it becomes important to the differences in syntax of the languages.
Both Inky and and MJML live inside of container structures which are, overall, pretty similar in function. Where you have:
<mjml><mj-body><mj-container>...</...>in MJML you have
Clearly from the outset Inky is a bit more simple to write than is MJML, but that starts getting a little dicey when we start to consider responsiveness.
Both MJML and Inky use some form of column to differentiate horizontal sections of content within a row. MJML uses
<mj-column>where Inky uses
<columns>and while they do basically the same thing, there's some underlying complexity with each. For example, Inky columns make use of attributes large="X" and small="X" to differentiate the width of a column on desktop and mobile views. Obviously this is a good way to control how mobile content renders and can be useful when attempting to create multi-column mobile layouts. MJML, on the other hand, defaults all mobile columns to 100% width. This means that to create multi-column mobile layouts you employ another MJML component -
<mj-group>. MJ-group allows you to fine-tune how your columns will collapse, expand, and stack on mobile views while not affecting the display on the desktop.
Personally, I like the way MJML handles this better. It's rare that I need to worry about having multiple columns on mobile view anyway, and if I do I like being able to group elements together in a container. In that way, to me, the code is more readable. To achieve the same result in Inky you would use the
small="X"on each of your columns. The resulting markup for each would be like so:
The output of these two pieces of code is wildly different and I invite everyone to view it on their own (get ready for Inky's automatic inlining which is nice) but the display is the same. You get two side-by-side columns across devices and clients. Though in particular you do get a bit better support using Inky with a little funkiness happening on some Outlook clients with the MJML output. This will likely be addressed by a later update.
There are some other syntax differences here and there but, overall, you can expect Inky to be somewhat more terse and MJML to be somewhat more verbose. I like the expressiveness of MJML when I'm writing the code but I can just as easily see how someone would like Inky.
Next I'll move over to what I perceive to be the philosophy of the two frameworks. This will be focusing on out of the box functionality, not adding in enhancement after the fact.
To me it seems that Foundation is focused mainly on what I'd call simple stability. This means it's great at making your email look exactly the same across as many clients as possible. You can be very certain that your code will produce rock-solid desktop experiences with relatively good mobile experiences. Of course, being desktop-first that means that sometimes your mobile experience will suffer. For this I'd say the decision is made by the numbers. Do you have more people viewing your emails in older clients? Do you have a lot of customers using Lotus Notes? Foundation, in other words, works from the point of view of graceful degradation. Anywhere that fancy techniques can be used, it's encouraged. You're not going to be using as much cutting-edge technique out of the box, but you can always add that in later yourself.
MJML on the other hand is focused on producing great-looking emails that render excessively well on mobile AND on the desktop and web clients, while providing a fall-back for anyone who's using a less than capable client such as Outlook.com. Because the design is mobile-first then you can easily visualize how your layout will look without the benefit of media queries. You can also be sure that you're going to get great results across the gamut of mobile devices (which is extremely important for me). Also, MJML has slightly more forward-looking elements built in such as hamburger menus and using background images in the
mj-herocomponent. So we're talking about progressive enhancement here. Make sure that your content looks as good as possible, and then make it look even better where you have the option to do so.
I think the two philosophies can be summed up by saying that Foundation is layout focused where as MJML is content focussed.
Finally I'll talk about support which is really, really important when using a framework to do the heavy lifting and trusting it.
Foundation has a community online. There are several very knowledgeable users who've been using it since V1 and have since made the transition to V2. Most of your questions will receive attention pretty quickly and you'll often get some helpful tips about where to look. They also have their documentation posted which makes it easy and fast to look up components or refresh yourself on syntax. However, the online community is mixed with the Websites and Apps communities which makes it difficult to search and the documentation is, to me, not as comprehensive nor as easy to follow as that provided for MJML which is simple to follow and has examples along with their live try it online editor. This makes taking MJML example code and trying it out, modifying it, or just exploring it really simple and actually fun. That, combined with an extremely active and highly engaged support community makes finding answers to questions rapid and as pain-free as HTML email questions can be. It also seems that MJML is evolving more quickly than Foundation. This may simply be because I'm not as active with Foundation's Github but I see new fixes and features happening more quickly with MJML.
So, I hope that helps someone and I apologize for the long post. And feel free to ask any questions you've got and I'll try to answer them as best as possible.
Have you looked into creating your own framework?
While I've not tried any of these frameworks, I've usually created bespoke frameworks for specific clients/companies. I've found that this has been the easiest way to get everything I need for the emails to work where I need them to work. And patching the frameworks, when email clients goal posts invariable change, is an easy thing for me to do.
Big thumbs up for this comment! Far too often I come across devs who are lost without their frameworks and libraries. Not only do you gain an incredible amount of knowledge and experience by creating your own, but you also develop an efficient framework that is tailored to your coding style.
Now by no means am I advocating solving bugs that have already been solved by the open source community. In those cases, just drop in the patches into your framework.
Hey Jaina, how would you go about creating your own framework. Do you have any horror stores when creating one or anything to look out for in particular?
The first steps in creating your own framework is looking at the design of your emails and seeing how you can modularise it—parts of the email that you're likely to repeat. Looking at the design patterns in your current emails would be a good place to start.
No horror stories that I can think of. But I think it's all about being very methodical and thorough in your approach to building a framework. And test! Test, test, test—you never know when email clients will go and change things.
Thanks for the advice.
We've talked a lot about frameworks on recent episode of The Email Design Podcast:
Hope that helps!
Loved the podcasts! Thanks for bringing these particular ones to my attention.
Check out Cerberus (http://tedgoas.github.io/Cerberus/) ...great framework and very consistent.
I don't use any frameworks. I feel like they're unnecessary. Coding an email from scratch gives you more flexibility.
All emails I build work great (and look mostly the same) across the majority of email clients/platforms. All you need to know is the quirks of each email client and how to fix them :)
Writing the CSS from scratch too?
Yes, writing the CSS from scratch too. Sorry, I replied initially from work's account :)
I have tried MJML but not foundation yet but I think Foundation doesn't show Mobile view in Gmail app which is needed for my emails.
Putting in my 2 cents a little later than others but I have to agree with @Jaina. Creating your own framework is one of the best ways i have found. I have been using a slim piece of CSS for all my emails and it has been holding up for the last 6 years. Of course i have been adding in new fixes as it came long. I have preset CSS for all clients set as universal CSS then i have preset code in media query. If i need to target a bigger screensize (for issues or client request to cater for a device) then i add in a new media query as i go along. I have set up a snippet in Dreamweaver's snippet manager so all i do is open a document, remove contents and add in my snippet and i am ready to code.
Hope that helped
UPDATE: Maizzle is a standalone framework now, it no longer uses Jigsaw. It has been rewritten in Node.js and relaunched April 1st, 2019 - find it on NPM.
Many things have changed since I posted here 2 years ago, so I thought I should update my answer.
In August 2018, I launched the Maizzle Email Framework, and this is what I have been using since.
It's powered by the Tailwind CSS framework and the Jigsaw static site generator. It has many features, most of which are either things I wish existed in an email framework, or that have been suggested by others in the community. It's quite a long list, so I'm not going to add it here - just check the website linked above.
I guess the biggest difference when compared to the two most established options is that there's no custom markup/tags that you need to learn - you do need to write your own HTML.
On the flip side, this approach means you're in full control, as there's no code hidden behind custom tags; so you can choose to code one email hybrid, and another responsive - totally up to you. It's also faster to pick-up, since it's just HTML that you already know.
Perhaps the feature that I am most fond of is that you can use Tailwind CSS as a design system for your emails, and not have to write CSS for most of the time. Coupled with the BrowserSync live preview, you can prototype emails really, really fast (I've been lately doing redesign experiments with Maizzle on popular brands' emails, and it usually takes me under one hour for a layout).
Maizzle is open source on GitHub - if you have feedback, issues, or would like to contribute and make it better, I would love to hear from you 😊
Using Foundation, I quickly came to realise there's a trade-off between the wonderful build-system they have, and the final output. Looking at other frameworks, it's the same: you trade off development conveniences for code bloat and less control over your final code.
So I took what I liked in other frameworks, and made my own.
It's simple (no build system), 12 columns, solid (tested and well documented), and easy to use. I've also added some useful things like hamburger menus (no inputs), reverse column stacking for mobile, Outlook bg image support, and mobile column widths and offsets.
If you want to give it a spin and/or give feedback/contribute: https://github.com/ThemeMountain/tm-pine
I like the idea of a lighter-weight email framework that does just what I need. I also really like the idea of incorporating centering a column in a row and reverse column stacking. I've been using Foundation for Email 2 and those were two things that seemed more annoying to implement than they should have been. I'm moving away from email dev as much as I can :) but if I find myself back in the thick of it I'll definitely check out Pine.
Since I built Pine, I worked on some projects that needed something even more simple. I originally went for a 12 column grid, because most people can relate to it coming from other frameworks, and because it divides nicely. However, with emails, you rarely go beyond 6 columns.
So I forked Pine and made a simpler, 6 column grid. The rest is the same, only total width (now 640px), column widths, and mobile width/offset classes are different.
If you're liking Pine, check out the Slim version, too:
None. I believe in boilerplates, not frameworks, for emails. You're making something that's going to be in an inbox, not a website.
I find it handy. Especially when churning out hundreds of emails a month. If it were only a handful, then sure, use a web based email design utility.
I agree :-) This is what I do. I have a boilerplate which I made with generic css etc in - I just add to it if I need new classes for that particular email. Every table I build is from scratch though :)
I think at times people need perspective. This is an email. It's not a website. Why would you use Foundation for Email? It's got it's own proprietary markup language and compiler. If you're gonna do that, go use Campaign Monitor or Mailchimp's WYSIWYG builder. You're doing the same thing.
I'm also against Foundation for websites, but for that, you'd need to see my web framework. getshipwright.com
H Jay, You should check some by your own, since everyone will suggest you their preference! I have tried some like ZURB, MJML with some other framework as well, the sources are on the web and you could give a try one by one.