Choosing a (JavaScript) Framework

With the sea of frameworks/libraries out there, it can be difficult to make an informed decision about what to use. Here are things I look at when trying to find new technology for production use.


Clear documentation and access to the source are the best ways I have found to determine if the project feels open. For closed source frameworks, I look for extensive documentation and a good support community.

If a project is closed source or if it doesn’t have adequate documentation, I could get stuck with a problem I can’t solve without ripping out the framework. The point of looking for openness is to make sure I don’t end up between a blackbox and a hard place.


The next thing I look for is if the framework is going to be reliable. Does it operate as expected, both intuitively and in the documentation? Is the project being actively developed?

In the case of GitHub projects, I usually look for these things first: number of contributors, number of commits, and last release. A low number of contributors may indicate the project is not mature.

I also look for unit tests. While I don’t think unit tests always make sense in the short term for internal projects, for 3rd party frameworks, it is what prevents a contributor from inadvertently introducing breaking changes to their API.


Knowing if a framework is scalable can be difficult. A good indicator of scalability is if other large projects exist using the technology. I look at what the pains are at scale.

Depending on the type of project, scalability may not ever be an issue. In those cases, I try to figure out if it would be easy to replace in the future if I can.


Productivity is more important than exactness for my day to day projects. If I worked at NASA where a single bug could end a person’s life, I would value exactness more.

There is a really easy way to tell if a framework makes you productive: build a simple project. Part of the reason I started is to get a feel for different JavaScript frameworks in as little time as possible. I would recommend taking this approach when vetting new technologies: just build something.


Being critical of frameworks is a healthy thing. It prevents me from making costly mistakes when choosing new technology. I have made that mistake more than a few times, and use these ideas to make better decisions.