Because you get 2 levels of indirection instead of 1.
If 1 does the job equally well, you should choose 1.
In fact, MJML can be used with any templating solution, so if your system already uses JSX, JSX doesn't add indirection, and you should use it.
But if your system is not, adding JSX on top has just prevents you from hacking a shell scripts that generates the email in a few lines, generating the email from whatever backend you use, or just writing the template in a free form file without anything to install.
I'm not sure what you mean by indirection in this instance. How does JSX use 2 levels?
> MJML can be used with any templating solution
Wouldn't that add complexity where JSX has less? Why use 2 systems (MJML + [templating]) when you can get away with 1 (JSX)?
> adding JSX on top has just prevents you from hacking a shell scripts
As far as I understand both are npm libraries so I can't see how one allows this where the other doesn't? Surely their application is the same usage pattern?
BiteCode_dev|3 years ago
If 1 does the job equally well, you should choose 1.
In fact, MJML can be used with any templating solution, so if your system already uses JSX, JSX doesn't add indirection, and you should use it.
But if your system is not, adding JSX on top has just prevents you from hacking a shell scripts that generates the email in a few lines, generating the email from whatever backend you use, or just writing the template in a free form file without anything to install.
You gain complexity, you loose flexibility.
lucideer|3 years ago
> MJML can be used with any templating solution
Wouldn't that add complexity where JSX has less? Why use 2 systems (MJML + [templating]) when you can get away with 1 (JSX)?
> adding JSX on top has just prevents you from hacking a shell scripts
As far as I understand both are npm libraries so I can't see how one allows this where the other doesn't? Surely their application is the same usage pattern?
unknown|3 years ago
[deleted]