Build static output in HTML with EJS template scripts.Ideally leverage React and TypeScript, which our other web tech stacks are built on.We had some important qualities going into our prototype: The goal: Create a new build pipeline for email templates Initial proof-of-concept We wanted components, we wanted TypeScript, and importantly we wanted a drop-in replacement so we could seamlessly move from the legacy system without a hitch. Each template was basically it’s own unique file, with poor reusability. We had a simple template build system that handled some things like i18n and A/B tests, but all of our emails were barebones HTML with no tooling to help developers build out each email. This will enable us to remove any dependency between components.Our existing approach to building email templates was lacking from a technical standpoint too. For example, we’ll state the relation dependencies such as parent and children tags between components in a separate configuration files, instead of stating it in the components itself. To make MJML always more configurable and cleaner, we’re doing a few organisational changes. While it is a great library, using htmlparser2 (on which cheerio is based) directly enable us to have more control over the way we parse MJML. We’re having a few issues with the parser we use at the moment, cheerio. Introducing a parser better suited to our needs We’re taking advantage of this breaking (internal) change to concentrate on structural issues that were introduced since the origins of MJML. A good opportunity to solve deep issues at the core of MJML ? Switching to plain JavaScript, which is much more widely known, makes it more straightforward to understand how components work. This change will also improve the performances of the MJML API which are directly tied to MJML’s ability to scale.Įxample: using a postRender on mj-divider to add conditional comments for Outlook Requiring to know React to create components wasn’t the most inclusiveĪs much as we love React, it added an obscure veil to anyone not familiar with it when it comes to creating components. This is a really huge change, especially when you integrate MJML in your app. While adding a few hundred milliseconds load time is totally ok for website and interfaces, it can quickly add up when rendering a lot of and/or long MJML emails.įrom our early tests (MJML 4 is a work in progress), by rewriting MJML in plain JavaScript, we’re making the rendering of MJML emails up to 35 times faster.
However, React was also initially built for another purpose and is not the best for our needs. The Facebook library enabled us to prototype and build MJML very fast, and we’re thankful for that. React is a really powerful library, we love it and still use it in a lot of our other projects. Now you’re wondering… “Why would you do that?!”.
What will change is mostly the internals of MJML, especially as we won’t use React anymore. Templates created with MJML v3.x will be fully compatible with MJML v4, you’ll still be able to render MJML emails like you are today, and we won’t break the look and feel of your emails from a version to another. Announcing MJML v4 ?Īfter a little more than a year, an increasing number of downloads (20,000 in February!) and an always more active community, we decided that it was time to take a fresh start.įirst, don’t freak out. We’re entirely rebuilding MJML from scratch”.