We're going to talk performance and email templates today. Why performance? Because when I was coding a feature for [Hakanai](https://hakanai.io/), I came across a problem that almost made me change my mind about my choice of hosting on [Cloudflare](https://www.cloudflare.com). We'll see how an application can become a house of cards, how that house can easily collapse, what prevented me from deploying for a day and, finally, how I solved the problem. Of course, we will use that to talk about [MJML](https://mjml.io/), a very good framework for creating responsive emails and [Monaco Editor](https://microsoft.github.io/monaco-editor/), a text editor to be integrated into a [Nuxt](https://nuxt.com/) application. ## Functionality to code [Hakanai](https://hakanai.io/) is a SAAS that enables users to trigger newsletters from their blog's RSS feed. It has the advantage of being simple to use and, above all, very practical for people with static blogs who can't manage subscriptions from simple HTML pages. All this works well, but the email sent was not editable for users, and above all, in English only. When you're doing a SAAS, you obviously know the little flaws in your application, but I prefer to wait for the request to come from a user, especially at the beginning, to really code the functionality. And the request did come: > Now, simple is better but too simple is not :) There are two things which bother me: > > - I can't change the English text in my newsletters (The site is in Romanian) > - There is no option for a daily schedule (hourly is too often, weekly is too far apart) > > Can I change them somehow? > > Thanks The objective is clear: I need to offer a multilingual version. But above all, it's an opportunity to offer fully customizable email templates. And for that, it's also an opportunity to test [MJML](https://mjml.io/). ## Creating responsive emails If you've never sent HTML e-mails, you're definitely in luck. Because the HTML used to create emails is hell. It has to meet numerous constraints, and email clients have very personal interpretations of HTML and CSS standards. (Did you know that the desktop version of Outlook still exists? But that's nothing compared to Lotus Notes...) But then, if on top of that, you want a responsive email that adapts to your recipient's screen size, it becomes a nightmare. At least for a backend developer like me. Fortunately, there are libraries to simplify your life, and MJML is one of them. Not only does MJML enable you to create valid e-mails, it also makes them responsive. If you'd like to see what it looks like, I invite you to try out their live editor: [https://mjml.io/try-it-live](https://mjml.io/try-it-live) In itself, MJML is a text format, so you only need three things to integrate it: - backend logic to store a template created with MJML - a function to transform the MJML template into HTML before sending the email - a front-end text editor for user editing I'm not going to describe the first part, because storing basic text isn't worth the trouble. For the MJML to HTML transformation, there are lots of different options. Depending on the language used, you have the option of using a library developed by the community [and listed on the official site](https://documentation.mjml.io/#community-components). These include Python, PHP, Rust, .Net and, of course, node.js. Unfortunately, I use Kotlin/Java. There are some libraries on Github but they don't have full MJML support. This is precisely the risk with unofficial libraries: a lack of format support, infrequent updates and sometimes a library that stops being maintained. However, there is an interesting alternative, MJML [offers a Rest API](https://mjml.io/api) to directly transform MJML into HTML. So that's what I used on the backend. Of course, there's a risk that this API may one day become a paid API, but for the moment it's free and I'll see later if I need to change. The conversion function is really trivial: ```kotlin @Service class MjmlClient( @Value("\${mjml.app-id}") private val appId: String, @Value("\${mjml.secret-key}") private val secretKey: String ) { fun convertMjmlToHtml(mjml: String): String { val client = WebClient.builder().build() val response = client.post() .uri("https://api.mjml.io/v1/render") .headers { it.setBasicAuth(appId, secretKey) } .bodyValue(mapOf("mjml" to mjml)) .retrieve() .bodyToMono(object : ParameterizedTypeReference>() {}) .block() if (response?.get("errors") != null && response["errors"] is List<*> && (response["errors"] as List<*>).isNotEmpty()) { throw RuntimeException("Error converting MJML to HTML: ${response["errors"]}") } return response?.get("html")?.toString() ?: "" } } ``` Now we need to offer online editing. ## Online code editor In my search for a text editor, I initially looked at somewhat classic editing solutions such as Quill, TipTap and ckeditor, but these are solutions adapted for word processing, not for editing code. What's more, they're often very complex and cumbersome, whereas what I really needed was syntax highlighting to simplify writing. My second step was to see if there were any lightweight solutions above [Prism](https://prismjs.com/), which is a standard solution for syntax highlighting. I found : - [vue-prism-editor](https://github.com/koca/vue-prism-editor) but has not been active for 4 years and is not compatible with the latest versions of vue. - [live prismjs](https://live.prismjs.com/) but still in alpha version and not recommended for production use In conclusion, I looked for a third way, and checked out the [Nuxt modules](https://nuxt.com/modules) listed on the official site. Here I found : - Monaco Editor - Code Mirror - Dragon editor This is the first one I tested, because its documentation inspired me a little more than the other two. (yes, it's basic, but that kind of impression counts for a lot) ## Monaco Editor Good news: Monaco Editor now has its own Nuxt module. And second good news, it works when you follow [the documentation](https://nuxt.com/modules/nuxt-monaco-editor). Anyway, just this line in the template (plus the module registration in nuxt.config.ts), and that's it, I had a working online editor for my MJML template: ```vue ``` which, with a little work, gave me this: ![The interface created with Monaco Editor](https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/media/1765805620425-image3.png) I was happy, everything worked locally. The preview calls the rendering api on the server side and everything seemed to be perfect. That's what I thought... ## Cloudflare goes wild ### A big mistake To deploy my SSR application, I use Cloudflare. And then I saw that it's not deploying: ![Cloudflare deployment error](https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/media/1765805620908-image2.png) And in the logs: ``` Σ Total size: 5.74 MB (1.56 MB gzip) Error: Failed to publish your Function. Got error: Your Worker exceeded the size limit of 1 MiB. Refer to the Workers documentation (https://developers.cloudflare.com/workers/observability/errors/#errors-on-worker-upload) for more details. ``` Ok. Apparently, this modification and this library have caused me to exceed the 1Mb size limit for my application, which no longer allows me to deploy. So I put out a call for help on Twitter to find a lighter alternative, removed unnecessary dependencies from my app and started looking at [Code Mirror](https://codemirror.net/) which also has [its Nuxt module](https://nuxt.com/modules/nuxt-codemirror). ### Attempt with CodeMirror This time, the documentation page doesn't help. It took a little more effort and here's the result. ```vue ``` And a little more js : ```vue ``` However, out of luck, it's no lighter: ``` Σ Total size: 6.03 MB (1.73 MB gzip) ``` So I called on a friend, a better front-end developer than me... chatGPT. Yes... ### Help from ChatGPT ChatGPT advised me, with MonacoEditor, to use it without including it in the bundle, i.e. to insert the script on the fly when necessary. And that's a good idea, as it avoids overloading the bundle. It's less practical from a dev experience point of view, but if it works, I'll take it. Anyway, I removed the dependency and used MonacoEditor, following the ChatGPT help. I added a simple div : ```html

``` And I added the script conditionally, client-side, if it wasn't already loaded ```typescript if (process.client) { if (!window.monacoLoaded) { window.monacoLoaded = new Promise((resolve) => { const script = document.createElement('script') script.src = 'https://cdnjs.cloudflare.com/ajax/libs/monaco-editor/0.51.0/min/vs/loader.js' script.onload = () => { require.config({ paths: { vs: 'https://cdnjs.cloudflare.com/ajax/libs/monaco-editor/0.51.0/min/vs' } }) require(['vs/editor/editor.main'], resolve) } document.body.appendChild(script) }) } const monaco = await window.monacoLoaded if (editorInstance) { editorInstance.dispose() // Dispose of previous editor instance if switching tabs } editorInstance = monaco.editor.create(document.querySelector('.editor-container'), { value: campaignToEdit.value.mjml, language: 'html', theme: 'vs-dark', automaticLayout: true, }) editorInstance.onDidChangeModelContent(() => { campaignToEdit.value.mjml = editorInstance.getValue() }) } ``` We agree, it's awful, but it worked. Except for a new tragedy and a slight drop in morale. ``` Σ Total size: 5.33 MB (1.5 MB gzip) Error: Failed to publish your Function. Got error: Your Worker exceeded the size limit of 1 MiB. Refer to the Workers documentation (https://developers.cloudflare.com/workers/observability/errors/#errors-on-worker-upload) for more details. ``` I'll pass on other attempts, I've deleted the images in the `images` directory and put them elsewhere, I've tried small optimizations, but nothing helped. ### Cloudflare had just changed the rules From then on, I had my doubts and went to see old deployments that had worked: ``` Σ Total size: 5.3 MB (1.49 MB gzip) ``` Actually, I was **already** over 1Mb before. But Cloudflare was tolerant of this overage and obviously the rules have changed. It was clearly a big mistake on my part not to have looked at it on the first deployment. Now I was really considering a change of hosting provider. I couldn't see how to remove 500kb (1 third!) from my application. But before that, I asked myself how I could really analyze the size of my bundle. Turns out there's a tool included with Nuxt to do just that. ## Make a TreeMap of your bundle To optimize something, it's always best to start with the numbers. There's no point in optimizing anything that only represents 0.1% of the final problem. And I've discovered that Nuxt offers a handy analysis tool. Just run the command ```bash npx nuxi analyze ``` and then go to localhost:3000 ![Nuxt bundle analysis](https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/media/1765805621186-image1.png) The result is two treemaps, one on the server side ![Server-side treemap](https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/media/1765805622018-image6.png) and another on the client side : ![Client-side treemap](https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/media/1765805622329-image5.png) Not too surprisingly, on the client side, I found echarts and a bit of prism too. But above all, there's one package that seems to come up a lot, and that's Shikijs Naively, I'd say shikijs and related libs represent almost 2/3 of TreeMap. ShikiJs, I know what it is, it's a dependency pulled by the [nuxt-mdc module](https://github.com/nuxt-modules/mdc). It's a module I used for the wrong reasons, I wanted to write [the Hakanai doc](https://docs.hakanai.io) in markdown so as not to bother. But I could do without it. So I reworked the doc and deleted nuxt-mdc (and therefore shikijs). Result: ``` Σ Total size: 2.51 MB (809 kB gzip) ``` I've almost halved the size of the bundle. And now after a hard day : ![Successful deployment](https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/media/1765805622985-image4.png) In short, I'm now using MJML and Monaco to provide additional Hakanai functionality, and I haven't given up on Cloudflare. Goal achieved. And if you're subscribed to this site's newsletter (you should be ^^), if all goes well, you should have received an email with the new template I've customized for the occasion.

Articles tagged with mjml

/2024

Nuxt and Monaco to edit MJML emails