41–50 of 60 posts
> Which of these two codes can you understand faster? To me, the first one, but I’m not convinced JSX is a good idea anywhere and I’ve been writing HTML for 30 years.
Just use MJML ( https://github.com/mjmlio/mjml ) or mrml ( https://github.com/jdrouet/mrml ). It solves the real problems with building emails without introducing useless abstractions like JSX.
I once worked with a guy who kept looking over my shoulder and saying 'just use binary'. Nice guy, but they had to let him go.
Just use MJML ( https://github.com/mjmlio/mjml ) or mrml ( https://github.com/jdrouet/mrml ). It solves the real problems with building emails without introducing useless abstractions like JSX.
I'm using mjml-react which gives me: - proper i18n with any react i18n library - js to create complicated emails - nicer component reuse story. - syntax highlighting and completion when used with Typescript - can be integrated with other nice js tools like Storybook for seeing all emails in one place and play with their props. How is that useless?
The discourse would be much less boring.
> Which of these two codes can you understand faster? To me, the first one, but I’m not convinced JSX is a good idea anywhere and I’ve been writing HTML for 30 years.
It probably targets developers that learned web development while learning React. It is at least a good idea for them. I think jsx-email wants to be the jsx version of mjml.
Just don't forget the plaintext version! Even Gmail/Outlook/Yahoo users may disable js and/or HTML when reading mail.
I'm assuming this precompiles the HTML before sending it, given the render() call.
Generating a plaintext message dynamically isn’t much of a pain point but html emails can be.
Just use MJML ( https://github.com/mjmlio/mjml ) or mrml ( https://github.com/jdrouet/mrml ). It solves the real problems with building emails without introducing useless abstractions like JSX.
Just use MJML ( https://github.com/mjmlio/mjml ) or mrml ( https://github.com/jdrouet/mrml ). It solves the real problems with building emails without introducing useless abstractions like JSX.
Agreed that MJML is great, but I wouldn't call JSX a useless abstraction. Using JSX as a templating language for MJML has real benefits, like being able to use javascript directly in templates instead of having to remember handlebars/mustache/nunjucks/etc templating syntax. And libraries like mjml-react make it really easy. https://github.com/wix-incubator/mjml-react/
Just use MJML ( https://github.com/mjmlio/mjml ) or mrml ( https://github.com/jdrouet/mrml ). It solves the real problems with building emails without introducing useless abstractions like JSX.
Just use MJML ( https://github.com/mjmlio/mjml ) or mrml ( https://github.com/jdrouet/mrml ). It solves the real problems with building emails without introducing useless abstractions like JSX.
Agreed that MJML is great, but I wouldn't call JSX a useless abstraction. Using JSX as a templating language for MJML has real benefits, like being able to use javascript directly in templates instead of having to remember handlebars/mustache/nunjucks/etc templating syntax. And libraries like mjml-react make it really easy. https://github.com/wix-incubator/mjml-react/
Just use MJML ( https://github.com/mjmlio/mjml ) or mrml ( https://github.com/jdrouet/mrml ). It solves the real problems with building emails without introducing useless abstractions like JSX.
I'm using mjml-react which gives me: - proper i18n with any react i18n library - js to create complicated emails - nicer component reuse story. - syntax highlighting and completion when used with Typescript - can be integrated with other nice js tools like Storybook for seeing all emails in one place and play with their props. How is that useless?