Of course, there is no right or wrong answer to this. However, the human psyche is always hungry for debates and conflicts, and this is why the internet is full of articles and texts that either try to prove framework A’s superiority, or rant against using framework B. Of course, the available options are more than two.
The truth is that all frameworks (at least the major and most known) have something valuable to offer, and thus it all boils down to pros and cons, and how these in particular affect your team, your project, and your product both in the short and the long run.
The options are numerous. You just have to study them in a pragmatic way, assessing the value that they will add to your workflow, without though neglecting the burden that they may induce.
The key points that I would research regarding each framework, before moving on with picking one, are the following (note that they do not appear in order of priority, as that would depend on the nature of each project/team/etc):
Of course, the whole “let’s use a framework” thing exists in order to grow your software in a more efficient way, enabling the constant addition of new features while keeping regression bugs (and engineer headaches) to a minimum. Take a look at sample projects built with the frameworks under question, and try to judge how much the architecture that they propose is beneficial to YOUR app. Not all apps are the same, and what is useful for a simple ToDo app may not be for your enterprise scale product.
Adding to the previous, the longevity of an ever-growing app demands that the code is easy to test. Sadly, as engineering teams grow in number of people, ensuring that test coverage stays above the accepted minimum is like committing to going to the gym; it will only be accomplished if there are no obstacles in your way, and the route from your home to the gym is a smooth, quick and easy ride. What I mean with this metaphor, is that the whole setup should make it easy for engineers to test their code, and empower them to do so. This covers a wide spectrum, including clean architecture with loose coupling, quick building and efficient test running and of course good and helpful tooling that enables running tests easily.
Stability — Backwards compatibility
Talent availability — location adaptation
Now this again applies to long-running or relatively larger projects. How easy is it to hire engineers that are proficient in using a specific framework? Are you hiring remotely? If yes, it might be easier to find the needed talent. If not, you might want to do a quick search for the existence of local meet-ups regarding the use of each framework, and also take a look at the job market in general at your specific location.
Directly relating to the previous point, if this project is going to be built by existing members of your team and they are not proficient in it, it is worth paying attention to the learning curve. Steeper learning curve means more time to delivery, but it also means that bigger effort is needed in order for one to master it. It is worth noting, as well, that our first try in building something with a new framework is always (and without no exceptions) imperfect. Thus it is vital that enough time is given upfront in order for the team to familiarize themselves with the framework, and perhaps use it first on a pet project so that their cognitive skills in using it are more mature when they start building the big app that matters.
Of course, the aspect of performance could not be neglected. Frameworks affect performance in multiple ways, from downloading time, to parsing time (which is more of an issue than you’d expect) and memory footprint. This is always a hot topic, advocating that one framework is lightweight or fast, while the other one is less performant or heavier. In my opinion, as long as best practices are followed and careful engineering is done, performance is only an issue when you are either dealing with a mobile-only web app (or some piece of code that will only run in mobile devices), or your frontend code does some heavy and really frequent rendering. Apart from those specific cases, most frameworks will work smoothly on the majority of your users’ computers (again, as long as you follow best practices and proposed guidelines while building the app). And adding to that, clean code and maintainability are far more important than premature optimization.
If you have thought of anything that may be missing from this list, or, any comments in general, I’d like to read them. Comment away!