Creating e-mails with Maizzle

Cauê Almeida
3 min readJun 15, 2021

--

We just can't bind over and over all integration again…

https://maizzle.com/
https://maizzle.com/

At the company I work for, our team has to, sometimes, build e-mails based on custom layouts, and we were always using some boilerplates we'd found on the internet.

And that worked for a while, but as projects get bigger and bigger we lack of creating a pattern for the whole team so everyone would understand how it was built, quickly.

Before entering the solution, I'm gonna tell you some of the things we'd struggled with — until now.

Limitations

If you have already built some e-mail marketing you should know that you can't expect to write some CSS in a file and import it on your HTML, as we're used to doing on the web. That's because e-mail renderers have limitations and they expect your styles inline.

Well, we can find a way of creating CSS within classes and use something to get those transformed into the tags, but we can't do it whenever working with other teams, especially when those other teams will get your template and make it work with their backend platforms.

With that said, imagine if you have to update your template after another team has written some other code in it: how would you know what you could change or not?!

Working with other teams

So, I know in some companies the frontend team will build the e-mails and the backend team will get your e-mails and make it work with their backend, i.e.: when a user register on your website they're going to receive a welcome e-mail, and for that, your code will change from:

This:

<h1>Welcome Bruno</h1>

To this:

<h1>Welcome {{ user.name }}</h1>

But what if — after this — your manager or the design team comes with a new requirement that will make you have to change some of this code, you'll have to test again and after that make the backend team do what they've had already done? Two kinds of files/directories for each team?

This process starts to get more complicated than it should.

Maizzle to the rescue

Maizzle is a framework that helps you quickly build HTML emails with
Tailwind CSS and advanced, email-specific post-processing.

So, instead of all teams write code in different files/directories, everyone is going to write code in the same files.

Real Use Case

Given the welcome.html file where we wrote our code, added new styles, making it look nice and etc., we make the other teams use the same files, and it doesn't matter how they're gonna use it, the only thing we have to change — for them — is the default location where the build let the files.

Some of our backend teams work with Laravel, and for them, it's nice to let the e-mail files within the resources/views/emails folder, and for this, we update the config.production.js file to:

module.exports = {
build: {
templates: {
destination: {
path: '../views/emails',
extension: 'blade.php',

},
assets: {
destination: '../../../public/images/emails',
},
},
},
inlineCSS: true,
removeUnusedCSS: true,
}

Our Maizzle project directory is located at resources/emails.

From that, they're gonna use the following command to replicate every file change to the files:

maizzle serve production

And if we have to change something after that, it's ok, because we can either use the normal serve command or this one as well. In the end, this makes everyone's lives easier.

And last but not least, Maizzle works with Tailwind, so you can expect great things such as flexibility when stylizing your pages.

Final thoughts

We're still testing this new process with everyone and I'll let you know if something goes wrong.

What about you? How do you do on your projects?

Have any feedback? I’ll be happy if you help me to improve in any way.

Find me at cauealmeida.com.

--

--

Cauê Almeida
Cauê Almeida

Written by Cauê Almeida

Tech enthusiast. Also, dev, skateboarder and musician.

No responses yet