Skip to content

Aquent | DEV6

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Choosing a Frontend JavaScript Framework

Written by: Chad Upton

This is the second post in a series about Front-end JavaScript Frameworks. If you want to read the previous post, which looks at why to use a framework, click this link: Don’t Burn Yourself, Use a Framework. If you’re convinced that you should use a framework, continue reading this post for a process that will help you choose the right framework for you and your project.

I liken this process to choosing the right car for you and your family because there are so many similarities. A framework is the vehicle that helps take your project from start to finish the same way a car takes your family from point A to point B.

In both cases there are plenty of options that will work and while that process may sound daunting, I’ve tried to simplify the approach of selecting the right framework for you, your project and your development team. For what it’s worth, I think you could also apply this approach to selecting your next car.

1. Narrow down the frameworks that meet your application’s needs

This is where you have to define your needs and separate real needs from wants. In other words, your application or project has certain functionality or requirements that need to be in the finale product and therefore you have to select a framework that won’t get in the way and can ideally help deliver those application features.

For example, if your application needs to support multiple languages then you probably want to choose a framework that supports internationalization (aka “i18n”), or have a plan to make it work without that feature built in.

In other words, if you need localization then the framework you choose has to support it or be compatible with something else that does. Of course, you could always roll your own Multilanguage implementation, although I suggest reading the previous post in this series to see if that’s right for you.

For a number of reasons, I usually like to minimize the number of frameworks and libraries I bring into a project and for that reason I try to find a framework that will satisfy as many of my requirements as possible. So, I’m likely going to choose a framework that supports localization if I need it. Although there are many reasons to do this, there is a better chance of compatibility down the road if one framework is handling most of my needs rather than piecing together many smaller libraries to get the job done.

There is a table at the end of this post that shows which of the major frameworks have some of these “need to have” features:

  • Reusable Components
  • Templates
  • Localization
  • Internationalization

Keep in mind that requiring an add-on to get some functionality isn’t necessarily a negative since omitting unnecessary functionality could potentially make your application smaller and load faster. You’ll probably want to look at the frameworks that contain the closest mix of features you need since you may not want something with too much (or too little) functionality built-in — there are downsides to having too much bloat or needing to patch a lot of dependencies together.

Some people may say that React is not a true framework or that Backbone is more of a library than a framework, but I added those in since they are popular and I thought they would be important inclusions for people to compare how far they can get with them.

Additionally, keep in mind that the comparison table at the end of this blog post is not exhaustive and there may be additional features you want or need that aren’t covered here and some frameworks or libraries that don’t check as many boxes here may fare better when compared with other feature sets that were not included here.

2. Filter that list down to the frameworks that satisfy your preferences

Once you have a list of frameworks that meet most of your needs, you can highlight the frameworks that also tick off the things on your list of preferences. I wouldn’t completely throw away the rest of the list quite yet, but keep it aside in case you want to take another look if you’re not happy with anything on the list at the end of this exercise.

Here you’re looking for framework features that won’t make or break the success of your application but simply make the journey more convenient and enjoyable.

If you’re shopping for a car, these are your “nice to haves”. For example, as much as I use and think I need heated seats, I live in Los Angeles now and I could definitely live without them (it still gets cold here though sometimes, ok). But I have to keep in mind that my luxuries are another person’s necessity – some people wouldn’t buy a car without heated seats.

In the scope of frameworks, you might not need two way data-binding. In fact, the folks at Backbone really don’t believe it’s a necessary feature, but gosh it sure is nice to have and that feature may very well save a lot of time in development and debugging, and that feature is available as an add-on for backbone.js.

There is a table at the end of this post that shows which major frameworks have some of these “nice to have” features:

  • 2 Way Data-Binding
  • Dependency Injection
  • Charting
  • Mobile Touch Events
  • Animations

3. Prune away the frameworks that don’t match your style

The popular frameworks have very similar core functionality and this often leaves people confused about how to make the right choice. This is completely normal and is the same for choosing a car. You’d probably be fine with any of your top choices, so if they all have the features you need then you just have to go with the one that matches your personality and style — the one that embodies your values.

For example, some people are purists and believe strongly that code doesn’t have a place in the presentation layer. That argument will surely live on forever but regardless of which side you’re on you must recognize that hugely successful, robust and maintainable applications have been built with (and without) code inside the presentation layer. So, this is really just a style preference and no matter how passionate or nauseous it (or its absence) makes you feel, nobody is right or wrong about it.

Which framework you actually choose is up to you, this is just a guide to help you work through the decision. Some other useful information might be the popularity of the frameworks. In searches alone, Angular.js wins by a significant margin:

JavaScript Framework Comparison

That said, React is quickly gaining traction and a lot of very large companies have built their latest user interfaces with it. At the end of the day popularity might not be too important in itself, however it does indicate the relative size of the community that comes along with it.

I suppose you could say this post is a framework for choosing frameworks, and the humor of that is not lost on me; but if you like things well structured then I hope you appreciate that.

When you’re deciding on a framework as a team then you may want to better understand why you like your choice of framework and give your teammates a way to come to a similar conclusion or at least have a catalyst for a productive discussion.

For reference, here is a comparison of some of the most popular features in some of the most popular frameworks:

 Angular.js 2 (beta)React.jsBackbone.jsEmber.js
 Reusable Components
 2 Way Data-Binding(add-on)(add-on)
 Dependency Injection(add-on)
 Mobile Touch Events(add-on)

Remember, your framework needs come from your project’s requirements. Your wants are someone else’s needs and style is a personal choice, not a requirement.