React Email ou Maizzle : comparer deux frameworks d’e-mails

Réponse courte pour une équipe SaaS

React Email est adapté lorsque le produit est déjà construit en React et que les développeurs veulent traiter chaque message comme un composant. Les props portent les données d’une commande, d’une facture ou d’une alerte, tandis que la prévisualisation locale reste proche du code applicatif. Maizzle convient aux équipes qui préfèrent lire directement la structure HTML et appliquer Tailwind CSS avant une étape de build qui place les styles dans le document. Les deux frameworks produisent un résultat à transmettre à un service d’envoi ; aucun ne constitue à lui seul une API de livraison.

La différence se voit dans les frontières du projet. React Email rapproche les templates du frontend, avec les mêmes conventions de modules, de types et de revue de code. Maizzle rend la pipeline d’e-mail plus explicite : une source, des transformations, puis un dossier de sortie. Avant de décider, prenez une notification réelle et suivez-la de la variable métier jusqu’au HTML final. Cette petite expérience révèle le coût de maintenance mieux qu’une liste de fonctions.

React Email : des e-mails comme composants

Avec React Email, un gabarit expose une fonction de composant. Un message de bienvenue peut recevoir un prénom, une URL d’activation et une locale ; une facture peut recevoir une liste de lignes et un total. Les primitives de la bibliothèque décrivent le document, le corps, le conteneur, le texte ou le bouton. Le développeur garde ainsi une séparation nette entre les données du SaaS et le balisage de l’e-mail.

Cette approche est confortable si le dépôt utilise déjà TypeScript, les imports et des composants partagés. Un en-tête, un pied de page et un bouton peuvent suivre la même convention que le reste de l’interface, tout en restant limités aux contraintes du HTML d’e-mail. La contrepartie est une dépendance à la connaissance de React et du JSX. Une personne qui modifie rarement du code devra comprendre les props, les fragments et le rendu avant de changer une phrase.

Le rendu doit être une étape visible de la livraison. Décidez si le serveur produit le HTML au moment de l’envoi ou si la CI publie des artefacts. Conservez les variables non résolues de façon intentionnelle et journalisez la version du template. Cette discipline évite qu’une modification de composant change plusieurs messages sans que l’équipe sache quel artefact a été envoyé.

Maizzle : HTML, Tailwind et pipeline dédiée

Maizzle part d’un document HTML et de classes Tailwind CSS. Les layouts et les blocs permettent de garder une ossature commune pour une confirmation, un rappel ou une notification de sécurité. Pendant le build, les règles CSS sont intégrées au HTML et les transformations prévues par la configuration s’appliquent. Le résultat est un fichier autonome que l’API d’envoi peut recevoir.

Pour une équipe qui pense d’abord en tableaux, cellules et attributs de messagerie, cette visibilité est utile. Les classes Tailwind accélèrent la mise en forme, mais elles ne rendent pas tous les styles sûrs par magie : le gabarit doit rester compatible avec les clients ciblés. Les responsables du code doivent également documenter les extensions de configuration, les layouts disponibles et le dossier de sortie.

Le serveur de développement de Maizzle donne un endroit clair pour modifier une source et regarder le résultat. Il ne remplace pas la vérification du HTML produit ni la décision sur le moment où l’API envoie le message. La pipeline peut vivre dans le même dépôt que le produit ou dans un paquet séparé ; dans les deux cas, nommez les versions et les variables de façon stable.

Templates en code, réutilisation et i18n

Les deux modèles permettent de partager des parties, mais les unités de partage ne sont pas identiques. React Email partage des composants et leurs props. Vous pouvez créer un composant de prix, un bloc d’adresse ou un encart d’action, puis passer la traduction et les valeurs au même endroit. Des types stricts aident à repérer une variable manquante avant le build.

Maizzle partage des layouts, des includes et des conventions de classes. Les données de build peuvent alimenter des placeholders dans un gabarit HTML. Cette organisation fonctionne bien lorsque les auteurs veulent voir le document et quand les règles de design sont exprimées en tokens Tailwind. Elle demande de limiter les variables implicites : chaque bloc doit préciser les champs dont il dépend.

Pour l’internationalisation, gardez un catalogue hors du markup et imposez une liste de locales. Dans React Email, le composant reçoit une locale et choisit les textes dans une couche dédiée ; dans Maizzle, un contexte de build peut sélectionner les données et le fichier de gabarit. Dans les deux cas, prévoyez les textes plus longs, les formats de date et les liens propres à chaque marché. Une traduction manquante doit faire échouer le rendu ou être signalée avant l’envoi.

Prévisualiser et vérifier le HTML

Une prévisualisation locale répond à la question « que produit mon changement ? ». Elle ne décide pas de la politique de test de votre équipe. Après le rendu, inspectez les tableaux, les liens, les textes alternatifs, les en-têtes et les variables. Faites passer le HTML par votre processus de vérification des clients de messagerie et gardez les cas représentatifs dans le dépôt. React Email et Maizzle s’insèrent tous deux dans ce flux, avec des commandes et des artefacts différents.

Reliez ensuite le fichier final à votre service d’envoi. Une API transactionnelle reçoit généralement un destinataire, un sujet, un HTML et des données de suivi. Si votre application envoie directement le composant React, définissez une frontière claire entre rendu et appel réseau. Avec Maizzle, le service applicatif peut charger un fichier construit ou l’intégrer à un paquet. Dans les deux cas, les secrets d’API restent hors des templates.

Coûts : frameworks gratuits, envoi facturé séparément

React Email et Maizzle sont des outils gratuits et open source. Le poste concret arrive avec le fournisseur qui remet les messages. Resend Free inclut 3 000 e-mails par mois et le plan Pro coûte 20 $ par mois pour 50 000 e-mails. Resend propose aussi un palier Pro à 35 $ par mois pour 100 000 e-mails. Ces montants sont mensuels et portent sur des e-mails envoyés.

Postmark Free autorise 100 e-mails par mois sans dépassement. Son plan Basic commence à 15 $ par mois pour 10 000 e-mails ; au palier de 50 000 e-mails, Basic est à 55 $ par mois. Postmark sépare donc clairement la construction des messages et le volume remis par son service.

Mailgun Free comprend 100 e-mails par jour. Mailgun Basic commence à 15 $ par mois pour 10 000 e-mails mensuels. Foundation coûte 35 $ par mois après le premier mois pour 50 000 e-mails mensuels, et Scale coûte 90 $ par mois après le premier mois pour 100 000 e-mails. Pour comparer correctement, notez le volume, la période de facturation et les éventuels dépassements dans votre budget.

Ces prix n’achètent ni React Email ni Maizzle. Ils paient la remise, les journaux et les fonctions du service d’envoi choisi. Un volume irrégulier peut favoriser un plan avec un petit palier de départ ; un produit SaaS qui envoie des notifications constantes doit comparer le quota inclus et le tarif des e-mails supplémentaires. Ajoutez les frais d’un outil de prévisualisation uniquement si votre processus en a besoin.

Migration de React Email vers Maizzle

Commencez par dresser l’inventaire des templates, des données, des langues et des points d’appel. Choisissez une notification avec un layout commun, une liste et un bouton. Exportez son HTML actuel, notez les styles indispensables et reproduisez la structure dans un layout Maizzle. Traduisez ensuite les composants récurrents en includes ou en blocs HTML, sans changer le contrat de données au même moment.

Construisez les deux versions dans une branche de migration. Comparez les liens, les valeurs, les textes et le résultat après inlining CSS. Branchez l’API sur une sélection contrôlée, puis retirez l’ancien rendu lorsque la nouvelle pipeline est comprise par les personnes qui la maintiendront. La migration est plus sûre si chaque étape produit un artefact nommé et traçable.

Migration de Maizzle vers React Email

Dans l’autre direction, séparez d’abord les données du HTML. Transformez chaque layout en composant React, remplacez les includes par des composants et regroupez les tokens visuels dans une petite couche de styles. Les classes Tailwind ne se transposent pas toutes directement : gardez une liste de règles approuvées et rendez les styles adaptés à l’e-mail.

Ajoutez une locale et un jeu de données de démonstration à chaque composant. Faites produire le HTML dans la même étape que les autres notifications React, puis conservez le chemin d’envoi identique tant que le rendu n’est pas accepté. Cette méthode permet de changer la source sans déplacer simultanément les secrets, les files ou les règles de livraison.

Tableau de décision pratique

Ce tableau décrit des chemins de travail, pas un classement. Faites le choix avec la personne qui écrira les templates, celle qui opérera le build et celle qui maintiendra l’intégration d’envoi. Une convention claire vaut mieux qu’un mélange de deux syntaxes pour un même message.