You may not want to use [hip_js_framework]

Angular 2 is around the corner (I can’t tell how many times I’ve said this before but this time is for real, I promise) and I’m already reading a lot of Angular-2-vs-React type articles popping all over the place. And it’s gonna get worse.

The problem with this is that most comparisons are not going to be fair, mainly because these tools were initially created to solve very specific problems that were bounded to a certain context. Then, over time, they evolved into fully fledged frameworks/libraries but a part of that initial motivation remained. Eventually, when a lot of people started using them, they became hip and hot, and everyone started trying to solve every problem out there with these tools just because everyone else was doing the same thing.

Please, stop.

For me, there are two things that people tend to forget and make most (if not all) framework-a-vs-framework-b comparisons biased and not as relevant as you might think: programming paradigms and developer mindsets.

Programming paradigms

These are merely a way to classify programming languages based on the programming style and some key features that defines each style. Each paradigm will allow developers to solve specific problems in a more efficient way than others so we could say that they not only classify programming languages but also problem domains.

Programming languages are just tools that allow programmers to solve problems in a very systematic way while following a set of principles and adhering to a predefined style.

Developers have different backgrounds and, as a consequence of that, we will choose a programming language, framework or library that matches it, and this won’t necessarily be the best choice in a lot of cases. But because this is what we know and trust, we end up using it for every situation, just to discover that it may not work as well as expected.

And then we start blaming that piece of software for our own mistakes and misunderstandings, or even worse, we attack the people who built it.

Developer mindset

Every developer has his/her own set of “beliefs”, and these are usually driven by their background but also by a lot of external factors such as the issues they’ve faced using certain technology or tool, the way they think or even the things other developers they admire believe.

Look at Kent C. Dodds, for example:

Sometimes, it just doesn’t click

I’ve been there, we’ve all been there. And, when you compare two different frameworks or libraries your mindset plays a big role in your final decision. For some people it might be easier to use react while others may find angular more appealing. There are other individuals that will not settle with neither and start building their own solution from scratch.

This is good, that’s a big part of what makes this career exciting: you have a lot of options, and even if you don’t like any of those you can always create your own way to solve a problem.

I don’t wanna read a post featuring a showdown between Angular and React features, that’s what documentation is for; instead, let’s write more articles about how Angular, Cycle, React, Ember, Knockout, Vue, Mithrill, Choo et al are solving specific problems, and how good are they proving to be for that problem domain.

Just remember: the fact that certain tool doesn’t fit your specific needs or your mindset doesn’t necessarily mean that it’s a bad software piece. Of course, there are terrible pieces of software out there and some libraries/frameworks will perform better than others under certain circumstances, but you should take enough time to analyze the implications of implementing a project with them. Don’t blame software for your (or others’) poorly informed decisions.

Disclaimer: I’m not a native English speaker, so feel free to point out grammatical and/or syntactical errors. Every respectful comment is deeply appreciated.