If All You Have Is A Hammer…
Over the last few years in my work, I have come across situations where a particular technology has been sold as a silver bullet. This is usually by people who have seen those technologies succeed for them under a certain context, who then push for adopting the same in wider contexts.
I have seen this tendency result in a push for using an event-driven way (and use Kafka) in cases where a traditional request-response mechanism would have been simpler. I have seen folks building an in-house framework for isomorphic rendering and evangelise its adoption when common sense suggests to pick a rendering approach based on specific needs. And most recently, I have had to contend with folks pushing to use React to construct email content.
A good consequence of going through this experience repeatedly means now I am able to clearly articulate a thought process to counter such silver bullet tool/technology prescriptions. It starts with two questions:
- Does using the recommended tool/technology drastically simplify solving the problem at hand?
- Do the people on the team have the skill in (or the appetite to learn) this new tool/technology?
- If the answer to the first question is “No”, then there is not enough of a reason to adopt something new. And this becomes especially true if the answer to the second question is also a “No”.
- If the answer to the first question is “Yes”, then it is worth pushing for it a bit even if the answer to the second question is “No”. But ultimately the success of adopting the new approach will be dependent on how well the team buys in.
- Needless to say, two “Yes”-es is the ideal situation to use something new.
Let me now walk through applying this thought process for the “use React to construct email content” argument. The people recommending to use React were developers who had used it successfully to build interactive web components (and some folks who had not really used React but had drank the kool-aid).
The first question now became: “Does using React make generating HTML content for email simpler?”. My first answer is “No”. Let me elaborate…
The main difference between the general web (where React shines) and email is that the latter does not really have the concept of JavaScript executing on the client-side. React is a JavaScript library for building user interfaces (and it especially shines for its declarative nature of building interactive UI on the client). Putting these two statements together logically leads to the observation that using React is not really a first-pick for constructing email content.
But I still wanted to entertain the counter-point. I tried to think what could make the answer to “Does using React make generating HTML content for email simpler?” a “Yes”. And one situation where that can happen is if a team is already super-comfortable using React and have already built a library of components in a way that those components can be reused as is within email (Note: this is a huge leap of faith because building for email is in some cases trickier/hackier than building for the browsers). And this brought me to the second question…
“Are people in the team already familiar with React?”. The answer was a “No”. The team was mostly made of folks who were very familiar building email content using HTML (via a templating language) and CSS for years. It made no sense to suddenly make all of them learn JavaScript (and React specifically) just because some developers who built web components using the same felt we ought to give it a try.
As the answers to both questions were a “No” for our context, the decision became obvious.
Related Thought
I think with respect to learning a new technology, people can go through these phases in order:
- Reluctance to use the technology as they don’t know it
- Appetite to experiment with the technology
- Familiarity with the technology and a tendency to advocate for its use anywhere and everywhere
- Wisdom about the technology – knowledge when to use it, and more importantly when NOT to
When someone advocates for a technology, try to figure out if they are in 3 or 4. If they are in 3, beware and take what they say with a pinch of salt.