Why it’s Hard to Decide on Technologies
You probably find yourself, among most developers and tech leads, searching Google for “X vs. Y” quite often. This is also the type of questions that spark endless debates in meetups and social groups, which never seem to reach any conclusion.
There are several reasons why it is so hard to feel confident about your choice, and I will list them here, hoping it will help to give guidance on which signs to follow and how to ask the right questions.
People prefer what they are used to
Every post, talk, tweet, comment etc. is written by a person, and people are biased towards what they know and love.
Try to remember your very first reaction to things that you love using today. I remember starting to code with React, thinking to myself that JSX is much worse than Angular templates, and it felt like mixing logic with markup. After using it for quite some time, it makes perfect sense that the entire rendering code is just code, with a single purpose — render the UI.
This is not something that you can really explain, as it comes from your experience with the framework.
I remember working on a project that had several mini-apps, some with TypeScript and some with JavaScript, and I was switching back and forth between them.
Every time I switched from JavaScript to TypeScript I thought — “man, TypeScript adds so much fuss and boilerplate, who needs types anyway?“
Only to switch back to JavaScript after a few days, thinking — “I don’t understand how can I work without types?! How do you know what properties are on an object?!”
So I realized that habit trumps rational arguments.
Fake news
I heard so much fake news, I can open a new article just listing all of them.
Fake news usually happens because of very uneducated interpretations of shallow facts.
People rely too often on what other people say, without having a clear idea of how true these claims are and what’s behind them. For example, MongoDB was considered to be always faster than SQL databases, only to be debunked by thorough research later on.
Don’t get me wrong, I make a lot of uneducated decisions based on recommendations from people I trust. But I don’t make critical decisions this way, and I will never re-recommend something without doing the actual research.
For example, I use Postgres as a default relational DB. But if someone asks me why is it better than MySql, I will just say that I know Postgres is very performant, compliant, heavily used and maintained and feature rich. I don’t really know how it compares with MySql, but I know that MySql is a good option as well.
When people ask me about Angular vs. React, I give them a detailed explanation, since I’m very experienced with both. Same for MobX vs. Redux.
Messaging
Although usually, the creators of the tools don’t make money out of them, they still want them to become very popular.
The messaging that they use can be misleading if you don’t thoroughly research how they compare to other alternatives. For example, Vue.js says it’s “incrementally adoptable” which you could easily say about React and other frameworks as well.
Different needs
When you ask people or search for articles, no one asks you what you need to solve, what is your prior knowledge, what kind of team do you have, what are your language preferences, coding style etc.
One organization prefers to move fast, the other prefers to have solid architecture. One team prefers an opinionated tool that makes a lot of decisions for you, and one prefers the flexibility to choose. One team loves functional programming, the other prefers OOP. Some products rely heavily on mobile apps and some on desktop apps. Some systems need to scale very fast, while others support a small number of uses.
The bottom line, an advantage to someone else might be a drawback to you, and vice versa.
TMI — Too much information
An article usually has many more reasons than what you need to choose a framework. Usually, there are 2–3 reasons that have 95% of the importance, and the rest are just too much information. These considerations are different from person to person, and that’s why it’s hard to collect the right data.
Also, since these are hot debates, there are a plethora of articles on these subjects that are click baits. Try searching for “Angular vs. React”, “Postgres vs. MySql”, “Native vs. Hybrid”, “Express vs. Hapi”, “Redux vs. MobX” etc. and you’ll see how many of them were written by content writers, that merely collect data from other articles and rephrase it.
Flocking and loud minorities
People who choose the less popular technology are the loudest. They will promote their choice in a very fierce manner, for several psychological reasons. This could be misleading because they usually give half-truths and bloat things in favor of their choice.
On the other hand, most people are conservative and tend to choose the direction that the herd is taking. This can also be misleading, as sometimes this direction doesn’t make sense to you and your needs, and might be the worse alternative.
My recipe for choosing technology
Here are my 2 cents on how to decide between competing technologies. It’s not a bullet proof method, but it will hopefully make a lot of sense for you:
- Do some unstructured and unbiased research of pure facts and verify them against different sources. Don’t make any prejudgments and don’t choose sides.
- Look at who’s writing the article and what education they have on the subject. Try to understand if it’s a technical, experienced person, or a content writer. Check out the comments as well.
- Find people that you trust and that face similar challenges, and share your view on development, and consult with them.
- Write down a list of features for each technology.
- Find the features that meet your standard in all options, and remove them from the list. For example, if all technologies are performant enough for you — no need to compare their performance.
- Decide on each feature what is a pro and what is a con for you.
- Think about the things that matter the most to you. For each technology, write down at most 3–4 pros/cons that are important for you, and ignore the rest.
- Make a PoC, to determine the barrier of entry and the quality of the documentation.
An example
Let’s say you’re choosing a UI framework. All modern UI frameworks fit your needs in terms of performance and maintainability, so these features get off the list.
Now you go over the pros/cons and get it down to:
Angular
pros: TypeScript Oriented, Complete Solution
cons: Complex
React
pros: Simple, React Native, Stable
cons: View Layer only
Vue.js
pros: Feature Rich, Good Tooling & Docs
cons: Hard to find experienced developers
These are YOUR personal interpretations. Some people will see Angular’s full solution as a pro, some will see it as a con. Some don’t really care about popularity, for others, it’s the most important requirement.
And remember — your choice will affect future developers for potentially years, so making a good research at this stage is worthwhile.
Good luck!
