Things to have in mind before picking a framework

Image for post
Image for post

few days ago, while talking with a friend about a new project his team is about to start, he asked me my opinion about which JavaScript framework to use.

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):

Code Maintainability

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.


Speaking about tooling, since we are living in the age of Open Source Software, and most (if not all) JavaScript frameworks are open source, the only way to ensure the existence of appropriate tooling is the presence of a rich ecosystem around a framework. As more people worldwide are engaged with a specific framework, more and more supporting tools and libraries will emerge for it. But the ecosystem’s vital contribution does not stop there. It will also result in easier access to documentation, online help from forums or boards (ahem StackOverflow), meet-ups and conferences, helping the engineers solve problems and advancing them at the same time.

Stability — Backwards compatibility

When starting a long-running project, selecting a framework to use means committing to it for at least a few years. Having committed to a specific framework, though, does not mean that you want to commit to a specific version of it. One of the benefits of the fast-evolving nature of the JavaScript community is the option of having upgraded versions of frameworks and libraries every once in a while. That is why, in such a case, you should not pick a framework that does not have “backwards compatibility” in its upgrade plans. No matter how fancy or awesome it is. Rewriting an app from scratch should only be done because the team has chosen so, and not because the used framework has forced you to.

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.

Learning curve

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.

Runtime performance

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.

Talent retention

In the fast evolving cosmos of software engineering in general (and even more in JavaScript), it is good for one’s career to be up to speed with the latest advances and to use as much of the state-of-the-art patterns and practices as he/she can. Being part of a team that uses ages old tech (in our case, “ages old” may mean 4–5 years!) is surely something that may be interpreted as taking a step back in one’s career, thus making them think of switching jobs. For example, a framework like Backbone is sweet and practical and may be a puzzle fit for the needs of my app, but if my engineers’ churn rate rises because of it being relatively obsolete (or not trendy — this seems to be equally effective) nowadays, then I surely wouldn’t pick it.

Summing Up

Having these key points in mind will help you feel less unsure about which framework to pick, and hopefully guide you towards the right direction. Fortunately, the JavaScript ecosystem is so vibrant that there is an abundance of articles online offering such information. And if you feel like you are starting to get frustrated, don’t forget; You never marry a framework. While growing your app, you can always use new frameworks in new features and experiment in general with other options in small tasks in order to keep the risk to a minimum (if it doesn’t suit your team or product, you can roll it back). Either way, the rate at which the software engineering ecosystem is advancing will force you on its own to try new things on the way, too!

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!

Happy coding!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store