How NOT to Choose a JS Framework
There are a ton of articles out there on how to choose a JavaScript framework.
This article is not one of them.
Instead, I’ve written this article to provide some guidance that should help you NOT choose a particular JS framework.
Often, the correct choice is no JS framework at all. If you are just building a simple backend admin website, avoid JS as much as possible. Use plain ASP.NET MVC and you’ll be happy. Only use a JS framework if you really need one.
You’ll thank me later.
Can I use just a little JS?
If you are dead-set on using any JS framework, start by asking yourself how much of the application actually needs JS.
When does an application need JS? It usually comes down to the user experience you want to provide. Maybe you need it for a more dynamic data table or for some more complex user interactions. Maybe it is for a pair of eyes that follow a cursor around (true story: I once worked on a project where a dev did that – it greatly hurts the performance of the page).
If you need JS, ask yourself if you can use just a little JS. Isolating the parts of a site that need JS and keeping everything else raw MVC will make delivering a website a more pain-free experience. If you need JS for just a few screens or interactions, look for a framework that can be used on just those pages. Don’t choose a framework that wants to control everything you’re doing. Pick something with a narrow set of features. If all you need is data binding, pick something that only solves data binding.
Sometimes you have to build a true single-page application where you have data binding, routing, and messaging between components. In that case, use of a proven single-page application framework is just fine.
What about this fancy new JS framework?
Don’t be tempted to pick the latest and greatest framework. JS frameworks are basically here today, gone tomorrow. You are better off choosing a framework that solves your specific problem and has been well-used by a number of developers. Don’t pick a framework that is someone’s pet project; pick something that has a lot of documentation.
What if the team and I know a particular framework really well?
Don’t undersell the value of existing knowledge. If you have a team of framework X experts, leverage it. Already having experience with a proven framework is a huge advantage; don’t throw away that investment.
Conclusion
In the end, I’m not saying that there are no use cases for JS frameworks – there really are. But I’ve seen many developers get into trouble when they lean on frameworks to do too much or get seduced by the promise of a “shiny and new” framework that ends up making their application tough to troubleshoot or perform poorly for the end user.
Taking a limited approach to implementing JS frameworks and sticking with frameworks proven by many other developers or that are well known by you or your team will make for a much happier experience.
