Which framework should we use? None. We should be using jQuery.
Now, jokes aside. There is no such thing as one being better than the others without taking into account all (including non-tech) aspects. They all solve similar but not the same problems and it’s never a simple choice to make. We can never tell which one is better just based on a set of features and syntax.
Know the market
You cannot develop independently from the market. I.e. you cannot make a great product if there are no specialists in the chosen technology. When considering which framework to use on a project you should keep in mind how many developers (good developers with production experience) are out there, because if you chose a tech A and there are no people who know how to apply it — you won’t succeed, furthermore you will struggle even to maintain it as developers will eventually stop working on the project and you will need a replacement.
And this might be also a reason to migrate from one framework to another even if it was great in the good ol’ days. We need to face the reality, be aware of how many specialists are on the market, how well it’s supported etc. It’s natural that most of the frameworks will eventually die, so we have to foresee it and start migration in time. Micro-frontends might help with that by leveraging the ability to upgrade piece by piece and not in one big jump where you might (and probably will) break the leg.
Know the problem you are solving
Naturally, we don’t make apps just to make them. We solve a problem with our product. Therefore we need to clearly understand what’s there to look for to better choose the solution. If you bluntly pick a framework just because you know/love it you might end up in a situation where you constantly struggle against its nature, because you are trying to solve the problem with the wrong instrument. So, to make a well-weighted decision you should have a good understanding of what each of the frameworks can suggest to you and what the tradeoffs are. Ideally, you should have some level of experience in building apps and solving different problems with them to have more reliable information proven by experience and real life.
Community
The days when developers did everything by themselves exclusively are long gone. Nowadays, we have a lot of libraries which solve common problems. As you might have guessed not every framework has the same libraries available. Hence it’s worth checking if there are any ready libraries for the framework you are willing to choose for the product you are going to develop.
Maintenance and reliability
You need to know how well maintained a framework is and how stable and reliable its APIs. If it has low maintenance or frequent breaking changes which you have to fix yourself to migrate to a newer version — these are the red flags that should make you more reluctant to choose that framework. You don’t want to spend a lot of time fixing those incompatible upgrades every now and then or migrate to another framework just because the current one turned out to be out of support.
Keep in mind the team
While it’s tempting to choose a technology by bare specs we should also account for the team we already have. If they don’t know how to work with that and don’t want to learn it you will have to find new developers. This comes at a cost of time and more money you (the business) need to spend.
Tech stacks
If compared React to Angular, they come with different capabilities out of the box. Consequently, in Angular you have more “stable” projects (most of the projects have the same tech stack and not many extra libraries added). This makes transfers between projects a breeze as developers don’t need to learn the new file structure, new libraries etc. everything is almost identical from project to project, only the business logic differs. This makes it much easier for the teams to keep in sync without strict supervision as most of the choices are already made for you. However, sometimes these restrictions might become limiting and therefore harmful to the business.
React does give you a ton of flexibility, but this comes at a cost of making too many choices and a higher need for supervision over inexperienced developers. It’s not a disadvantage, but a tradeoff you need to be aware of. Everything comes at a cost and you be better aware of those costs.
The conclusion
In my opinion, you can’t compare the frameworks/libraries just by their specs, but also have to give a lot of thinking about other aspects of using any tech. This is not limited to choosing between React/Angular/Vue or just to the front-end. It can be applied to any decision you need to make. The point is to think not only about what tech will come with the choice, but also what possible consequences are.
Top comments (0)