# Cómo integrar MJML en un workflow frontend moderno > Aprende cómo integrar MJML con Vite, React y Node.js en un workflow frontend moderno para crear emails responsive más mantenibles. - URL canónica: https://www.martagonzalez.dev/blog/como-integrar-mjml-workflow-frontend-moderno/ - Fecha de publicación: 2026-07-22T07:19:00 - Última actualización: 2026-06-11T20:31:49 --- ![Imagen del artículo](https://martagonzalez.dev/wp/wp-content/uploads/2026/07/integrar-mjml-workflow-frontend-moderno-1024x683.avif) Integrar MJML en un workflow frontend moderno no consiste únicamente en instalar una dependencia, crear un archivo .mjml y compilarlo a HTML. La integración real empieza cuando las plantillas de email dejan de ser piezas aisladas y pasan a formar parte de un sistema de trabajo más ordenado: control de versiones, componentes reutilizables, scripts de automatización, revisión visual, validación y despliegue. En desarrollo frontend estamos acostumbradas a trabajar con herramientas como Vite, React, Node.js, TypeScript, sistemas de diseño, linters, pipelines y entornos de desarrollo rápidos. Sin embargo, cuando entramos en el terreno del email development, muchas de esas comodidades desaparecen o deben adaptarse. Un email no se comporta como una página web. Gmail, Outlook, Apple Mail, Yahoo y otros clientes de correo pueden interpretar el HTML y el CSS de manera diferente. Por eso MJML resulta tan interesante. No elimina por completo la complejidad del email, pero sí ofrece una capa de abstracción mucho más amable para crear emails responsive sin tener que escribir manualmente estructuras interminables basadas en tablas HTML. Si vienes del desarrollo web y quieres entender mejor ese salto de mentalidad, también puede ayudarte leer esta comparativa sobre [las diferencias entre diseñar una web y diseñar un email](/blog/diferencias-entre-disenar-una-web-y-disenar-un-email/). En este artículo vamos a ver cómo integrar MJML con Vite , MJML con React y MJML con Node.js dentro de un flujo frontend actual, evitando que el proyecto se convierta en una colección caótica de scripts, archivos duplicados y plantillas difíciles de mantener. ## Por qué MJML encaja tan bien en un workflow frontend moderno MJML nació para resolver un problema muy concreto: crear emails responsive compatibles con múltiples clientes de correo sin tener que pelear constantemente con el HTML tradicional para email. En lugar de escribir directamente tablas, estilos inline y estructuras repetitivas, MJML permite trabajar con una sintaxis más legible mediante etiquetas como , , o . Por ejemplo, una sección sencilla de bienvenida podría escribirse así: Bienvenida a la newsletter Gracias por suscribirte. Aquí empieza tu recorrido. El resultado final será un HTML mucho más complejo, adaptado a las necesidades reales del email. Pero como desarrolladora, no tienes que escribir toda esa estructura manualmente. MJML se encarga de generar buena parte del marcado necesario para conseguir una base responsive más fiable. Si estás empezando con esta herramienta, puedes profundizar primero en [qué es MJML y por qué facilita la maquetación de emails responsive](/blog/que-es-mjml-y-por-que-facilita-la-maquetacion-de-emails-responsive/). Ese punto de partida ayuda a entender por qué MJML no debe verse solo como una librería más, sino como una forma de trabajar mejor con un canal técnicamente limitado. ### Usar MJML no es lo mismo que integrarlo bien Usar MJML puede ser tan simple como abrir un editor online, escribir una plantilla y exportar el HTML. Para una prueba rápida, está perfecto. Pero cuando hablamos de integrarlo dentro de un workflow frontend moderno, el objetivo es otro. Una integración sólida debería permitirte: - Organizar plantillas y bloques reutilizables. - Compilar emails desde scripts del proyecto. - Validar errores antes de enviar. - Compartir ciertos criterios visuales con la web. - Versionar cambios en Git. - Automatizar el build de los emails. - Conectar el HTML final con una plataforma de envío. Es decir, no se trata solo de “hacer emails con MJML”, sino de crear un sistema sostenible para mantenerlos en el tiempo. ## MJML y Node.js: la base para automatizar plantillas de email Si quieres integrar MJML en un entorno frontend actual, Node.js suele ser el punto de partida más natural . La razón es sencilla: la mayoría de proyectos frontend modernos ya funcionan sobre npm, scripts de package.json , dependencias gestionadas y procesos de build. La instalación básica sería: npm install mjml A partir de ahí, puedes trabajar de dos formas: usando la CLI de MJML o utilizando MJML desde un script de Node.js. ### Compilar MJML desde la línea de comandos La forma más directa de compilar una plantilla es mediante la línea de comandos: npx mjml src/emails/newsletter.mjml -o dist/emails/newsletter.html Este comando toma un archivo MJML de entrada y genera un HTML final en la carpeta de salida. En un proyecto real, lo más cómodo es añadir scripts al package.json : { "scripts": { "email:build": "mjml src/emails/templates -o dist/emails", "email:watch": "mjml -w src/emails/templates -o dist/emails" } } Así puedes compilar todos los emails con: npm run email:build O trabajar en modo observación con: npm run email:watch Este pequeño paso ya mejora mucho el proceso. La compilación deja de depender de acciones manuales y queda documentada dentro del propio proyecto. ### Compilar MJML desde un script de Node.js La CLI es suficiente para muchos casos, pero si necesitas más control, conviene usar MJML desde Node.js. Esto resulta especialmente útil cuando quieres procesar varias plantillas, inyectar datos, generar versiones por idioma o bloquear el build si hay errores. import mjml2html from "mjml"; import { readFile, writeFile, mkdir } from "node:fs/promises"; import path from "node:path"; const inputPath = "src/emails/templates/bienvenida.mjml"; const outputPath = "dist/emails/bienvenida.html"; async function buildEmail() { const mjml = await readFile(inputPath, "utf8"); const result = mjml2html(mjml, { validationLevel: "strict", minify: true }); if (result.errors.length > 0) { console.error(result.errors); process.exit(1); } await mkdir(path.dirname(outputPath), { recursive: true }); await writeFile(outputPath, result.html); console.log("Email compilado correctamente."); } buildEmail(); Este enfoque te permite convertir MJML en una parte más del sistema de build. Si quieres ampliar esta parte, puedes enlazarlo con una estrategia más completa como la que se explica en [cómo automatizar plantillas de email con MJML y Node.js](/blog/como-automatizar-plantillas-de-email-con-mjml-y-node-js/). #### Cuándo merece la pena usar Node.js Usar Node.js tiene sentido cuando el proyecto empieza a crecer. Por ejemplo, si tienes varias plantillas de email, contenidos dinámicos, diferentes idiomas o una integración con una herramienta externa de envío. En cambio, para una newsletter puntual o una plantilla muy sencilla, la CLI puede ser más que suficiente. La clave está en no complicar el workflow antes de tiempo. Un buen sistema debe crecer al ritmo de las necesidades reales del proyecto. ## MJML y Vite: cómo hacer que convivan sin mezclar responsabilidades Cuando hablamos de MJML y Vite , conviene aclarar algo importante: Vite está pensado para aplicaciones frontend web, no para compilar emails como objetivo principal. Su fortaleza está en ofrecer un entorno de desarrollo rápido, un servidor local cómodo y un sistema de build optimizado para aplicaciones modernas. Eso no significa que MJML y Vite no puedan convivir. De hecho, pueden hacerlo muy bien si mantenemos una separación clara de responsabilidades. Vite puede encargarse de la aplicación web, mientras MJML se encarga de las plantillas de email. ### Una estructura de carpetas clara Una estructura práctica podría ser esta: project/ ├─ src/ │ ├─ app/ │ │ ├─ main.tsx │ │ └─ components/ │ ├─ emails/ │ │ ├─ templates/ │ │ │ ├─ bienvenida.mjml │ │ │ └─ newsletter.mjml │ │ ├─ partials/ │ │ │ ├─ header.mjml │ │ │ └─ footer.mjml │ │ └─ data/ │ │ └─ newsletter.json ├─ scripts/ │ └─ build-emails.mjs ├─ dist/ │ ├─ app/ │ └─ emails/ ├─ package.json └─ vite.config.ts Esta organización evita un error bastante común: tratar los emails como si fueran páginas web pequeñas. Aunque ambos canales compartan una identidad visual, no comparten las mismas reglas técnicas. En web puedes trabajar con CSS moderno, Grid, Flexbox, animaciones, componentes interactivos y frameworks visuales. En email, en cambio, debes ser mucho más prudente. Si quieres profundizar en esta diferencia, puede resultarte útil este artículo sobre [qué partes de CSS funcionan realmente en email marketing](/blog/que-partes-de-css-funcionan-realmente-en-email-marketing/). ### Scripts combinados para trabajar con Vite y MJML En un proyecto con Vite, podrías tener scripts como estos: { "scripts": { "dev": "vite", "build": "vite build", "email:build": "node scripts/build-emails.mjs", "email:watch": "mjml -w src/emails/templates -o dist/emails", "dev:all": "concurrently \"npm run dev\" \"npm run email:watch\"" } } Con esta configuración, Vite se ocupa del desarrollo web y MJML observa las plantillas de email. Si usas una herramienta como concurrently , puedes levantar ambos procesos a la vez. El resultado es cómodo y ordenado: trabajas desde el mismo repositorio, pero cada herramienta cumple su función. #### Compartir diseño no significa compartir implementación Un workflow frontend moderno debería facilitar la coherencia visual entre la web y los emails. Pero coherencia no significa copiar y pegar el mismo CSS. Puedes compartir tokens de diseño como colores, nombres de fuentes, espaciados base o criterios de marca. Por ejemplo: export const brand = { colors: { primary: "#CC2B5E", secondary: "#F8E0EA", accent: "#753A88", text: "#020101", background: "#FFFFFF" } }; Estos valores pueden servir como referencia para la web y para los emails. Sin embargo, la implementación debe adaptarse a cada canal. El CSS que funciona perfectamente en una landing page puede no funcionar en Outlook o Gmail. ## MJML y React: cuándo tiene sentido trabajar con componentes La integración de MJML con React suele interesar a equipos que ya trabajan con componentes y quieren trasladar esa lógica al mundo del email. La idea es atractiva: si ya usamos React para construir interfaces, ¿por qué no usarlo también para componer plantillas? La respuesta corta es: depende. React puede ser muy útil para sistemas de emails complejos, pero no siempre es necesario. ### Cuándo usar MJML directamente Para newsletters editoriales, emails sencillos o plantillas con poca variación, escribir MJML directamente suele ser más simple. El archivo es fácil de leer, fácil de revisar y no introduce una capa adicional de abstracción. Por ejemplo, si estás creando tu primera newsletter, probablemente te convenga empezar con una estructura MJML directa. Puedes verlo con más detalle en esta guía sobre [cómo crear tu primera newsletter responsive con MJML](/blog/como-crear-tu-primera-newsletter-responsive-con-mjml/). ### Cuándo usar React para generar emails React empieza a tener sentido cuando aparecen necesidades más avanzadas: - Muchas variantes de una misma plantilla. - Datos dinámicos complejos. - Emails transaccionales personalizados. - Reutilización intensiva de componentes. - Tipado con TypeScript. - Integración con lógica existente de una aplicación. Un ejemplo conceptual de componente podría ser: import { Mjml, MjmlBody, MjmlSection, MjmlColumn, MjmlText, MjmlButton } from "@faire/mjml-react"; export function WelcomeEmail({ name }) { return ( Hola, {name} Gracias por unirte. Hemos preparado algunos recursos para empezar. Ver recursos ); } Este enfoque permite trabajar con props, composición y lógica de componentes. Pero también añade complejidad. Por eso, antes de elegirlo, conviene hacerse una pregunta muy práctica: ¿React simplifica realmente este sistema de emails o solo lo hace más sofisticado? #### La regla práctica para decidir Si tus emails son pocos, estáticos o editoriales, usa MJML directo. Si tu sistema de emails es dinámico, reutilizable y necesita muchas variantes, React puede aportar orden. La sofisticación técnica solo merece la pena cuando mejora la mantenibilidad. Si no, es mejor optar por una solución más simple. ## Cómo diseñar un workflow completo con MJML, Vite, React y Node.js Un workflow completo no tiene por qué ser complicado. Lo importante es que cada pieza tenga una función clara y que el proceso sea fácil de entender para cualquier persona que entre al proyecto. ### Primera capa: plantillas Las plantillas son la base del sistema. Pueden estar escritas directamente en MJML: src/emails/templates/ ├─ bienvenida.mjml ├─ reset-password.mjml └─ newsletter-mensual.mjml O generarse desde componentes React: src/emails/react/ ├─ WelcomeEmail.tsx ├─ ResetPasswordEmail.tsx └─ NewsletterEmail.tsx En ambos casos, lo importante es que las plantillas estén localizadas, versionadas y documentadas. ### Segunda capa: bloques reutilizables Un buen sistema de emails no debería repetir el mismo header, footer o CTA en cada archivo. Para evitar duplicación, puedes crear parciales o componentes reutilizables. En MJML directo: src/emails/partials/ ├─ header.mjml ├─ footer.mjml └─ cta.mjml En React: src/emails/components/ ├─ EmailHeader.tsx ├─ EmailFooter.tsx └─ EmailButton.tsx Si quieres ordenar esta parte con más profundidad, puedes apoyarte en esta guía sobre [cómo organizar componentes reutilizables en MJML](/blog/como-organizar-componentes-reutilizables-en-mjml/). ### Tercera capa: compilación y validación La compilación transforma el MJML en HTML final. En este punto es recomendable incluir validación para detectar errores antes de que una plantilla llegue a producción. Por ejemplo: { "scripts": { "email:build": "node scripts/build-emails.mjs", "email:watch": "mjml -w src/emails/templates -o dist/emails", "check": "npm run email:build && npm run build" } } El script check permite comprobar tanto los emails como la aplicación web. Esta clase de automatización es especialmente útil si el proyecto se despliega desde un pipeline o si varias personas trabajan en el mismo repositorio. ### Cuarta capa: revisión visual Una vez generado el HTML, hay que revisarlo. Abrirlo en el navegador puede servir para una primera comprobación, pero no debe ser la única prueba. El navegador no renderiza como Gmail, Outlook o Apple Mail. En email development, probar en clientes reales sigue siendo fundamental. MJML ayuda mucho, pero no convierte el email en una página web convencional. Si quieres entender mejor esta limitación, puedes complementar este artículo con [MJML vs HTML tradicional para emails: ventajas y limitaciones](/blog/mjml-vs-html-tradicional-para-emails-ventajas-y-limitaciones/). ### Quinta capa: integración con la plataforma de envío El último paso consiste en llevar el HTML final a la herramienta que enviará los emails. Puede ser una plataforma de email marketing, un CRM, una API transaccional o un sistema propio. En este punto conviene tener cuidado con las variables dinámicas. Muchas plataformas usan su propia sintaxis para personalizar nombres, enlaces, condiciones o bloques repetibles. Por eso, el HTML generado debe adaptarse al sistema de destino. Un buen workflow no termina en la compilación. Termina cuando la plantilla se puede enviar con confianza. ## Buenas prácticas para mantener el workflow limpio Integrar MJML en un proyecto moderno puede mejorar mucho el proceso, pero también puede complicarlo si no se establecen límites claros. ### No trates el email como si fuera una mini web Este es uno de los errores más frecuentes. Un email puede compartir identidad visual con una web, pero sus reglas técnicas son diferentes. No conviene abusar de CSS moderno, animaciones, interacciones o estructuras demasiado ambiciosas. Si quieres construir emails responsive sin depender tanto de tablas manuales, puedes leer también [cómo hacer emails responsive sin volverte loca con tablas HTML](/blog/como-hacer-emails-responsive-sin-volverte-loca-con-tablas-html/). Es una buena continuación para entender hasta dónde puede ayudarte MJML y dónde siguen apareciendo las limitaciones del canal. ### Documenta el proceso Una carpeta de emails debería tener un pequeño README con información básica: - Dónde están las plantillas. - Cómo se compilan. - Dónde se guarda el HTML final. - Cómo se prueban los emails. - Qué convenciones deben respetarse. Esto es especialmente importante si el proyecto crece o si otras personas van a tocar las plantillas más adelante. ### Evita la abstracción excesiva Reutilizar componentes está bien. Convertir cada pequeño bloque en una abstracción difícil de rastrear, no tanto. En email development, cuando algo falla, necesitas poder localizar el problema rápido. Un sistema demasiado abstracto puede ser elegante desde el punto de vista técnico, pero incómodo para depurar. La prioridad debe ser la mantenibilidad. ### Controla el peso del email Un email demasiado pesado puede cargar lento, truncarse o empeorar la experiencia. Conviene optimizar imágenes, evitar bloques innecesarios y revisar el HTML final. La integración con MJML no debería hacerte olvidar lo esencial: claridad, rendimiento, accesibilidad y compatibilidad. ## Ejemplo de workflow práctico para un proyecto con Vite, React y MJML Imaginemos un proyecto frontend con Vite, React y TypeScript que necesita generar emails de bienvenida, recuperación de contraseña y newsletters. Una configuración sencilla podría ser esta: { "scripts": { "dev": "vite", "build": "vite build", "email:build": "node scripts/build-emails.mjs", "email:watch": "mjml -w src/emails/templates -o dist/emails", "dev:emails": "npm run email:watch", "check": "npm run email:build && npm run build" } } Con esta estructura, el equipo puede trabajar de forma clara: - La aplicación web se desarrolla con Vite. - Los emails se escriben en MJML. - Node.js automatiza la compilación. - React solo se usa si aporta valor real en plantillas dinámicas. - El HTML final queda listo para revisar y enviar. Este enfoque permite mantener un equilibrio sano entre automatización y claridad. No se trata de crear el sistema más complejo posible, sino de construir un flujo que pueda mantenerse en el tiempo. ## Errores comunes al integrar MJML en un workflow frontend ### Depender solo de la vista en navegador El navegador es útil para una revisión rápida, pero no representa el comportamiento real de todos los clientes de correo. Un email debe probarse en contextos reales antes de enviarse. ### Duplicar plantillas sin control Crear una plantilla nueva para cada pequeña variación puede parecer rápido al principio, pero genera mantenimiento duplicado. Es mejor trabajar con estructuras base y bloques reutilizables. ### Meter demasiada lógica en el email La plantilla no debería convertirse en el lugar donde se resuelve toda la lógica del negocio. Siempre que sea posible, prepara los datos antes y deja que la plantilla se centre en presentar el contenido. ### No validar antes de producción Un error de estructura en MJML puede generar un HTML defectuoso. Por eso conviene validar durante el build y bloquear el proceso si hay errores importantes. ### No pensar en accesibilidad Un email también debe ser claro, legible y accesible. La jerarquía, el contraste, los textos alternativos y los enlaces comprensibles siguen siendo importantes. MJML ayuda con la estructura, pero el criterio de diseño y contenido sigue siendo responsabilidad del equipo. ## Preguntas frecuentes sobre MJML en workflows frontend modernos ### ¿Puedo usar MJML directamente con Vite? Sí, puedes tener MJML dentro de un proyecto con Vite, pero lo recomendable es separar responsabilidades. Vite puede encargarse de la aplicación web y MJML puede compilarse mediante scripts propios. No necesitas convertir las plantillas de email en componentes de la app para que formen parte del mismo workflow. ### ¿Es mejor usar MJML con React o escribir MJML directamente? Depende del proyecto. Para emails sencillos, newsletters editoriales o plantillas con poca variación, MJML directo suele ser suficiente. Para sistemas con muchas variantes, datos dinámicos y reutilización intensiva, React puede aportar más orden. La clave está en elegir la opción que haga el sistema más mantenible, no necesariamente la más sofisticada. ### ¿MJML sirve tanto para newsletters como para emails transaccionales? Sí. MJML puede utilizarse para newsletters, emails de bienvenida, recuperación de contraseña, confirmaciones, notificaciones o campañas promocionales. La diferencia está en el workflow. Las newsletters suelen tener un enfoque más editorial, mientras que los emails transaccionales suelen requerir más integración con datos dinámicos y sistemas backend. ## Integrar MJML sin complicar el workflow Integrar MJML en un workflow frontend moderno no significa añadir complejidad por añadirla. Significa crear un proceso más claro, más repetible y más fácil de mantener. MJML resuelve una parte importante del problema: la creación de emails responsive compatibles con diferentes clientes de correo. Node.js permite automatizar la compilación y trabajar con datos. Vite organiza el entorno frontend. React puede aportar componentes cuando el sistema realmente lo necesita. Pero ninguna herramienta sustituye el criterio. Un buen email sigue necesitando una estructura clara, una jerarquía visual bien pensada, textos comprensibles, accesibilidad, pruebas reales y atención a las limitaciones del canal. La mejor integración no es la más compleja, sino la que permite que una plantilla se entienda, se compile, se revise, se versionee y se envíe con confianza. Ahí es donde MJML deja de ser solo una herramienta para maquetar emails y se convierte en una pieza sólida dentro de un sistema frontend profesional.