DEV Community

Michael Wolf Hoffman
Michael Wolf Hoffman

Posted on • Originally published at

The Best JS Framework and How To Choose One

The Best JS Framework and How to Choose One

A popular topic among web developers is what the best modern javascript framework is.

Usually the big three (Angular, Vue, and React) get compared for things like bundle size, performance, adoption, etc. By the end of the post, the writer will give their conclusion.

I’ve used the big three extensively for the last four or so years and wanted to give an updated opinion that I don’t see too often.

State of JS

First off, the State of JS was released this week. And it shows tons of stats for dev opinions on JS, libraries, features, etc.

As far as frameworks go, React looked like the big winner there with Vue not too far behind it. It looked like Angular devs looked like they were the least happy in that survey.

It Doesn’t Matter

Honestly, It doesn’t matter. For the most part, they are all the same.

Yes, there are minimal differences that still exist today.

For example, if you want a job, maybe React is better in the US. There are more React jobs in the US so it would make sense to learn React if you are looking for a position.

But are you not going to get a job with only Angular or Vue skills? I mean there are still plenty of Backbone and Ember jobs too, so I don’t really see the issue here.

Framework Shouldn't Determine Hirability

And one of the more ridiculous things a job posting could have is something like: “Must have 3 years of React experience”.

If someone has used Angular and/or Vue for 5 years, do you really think they won’t be able to be productive in React within a few days or weeks? They could probably look at a company's existing react app and immediately write code.

If your team is hiring someone because they have experience in the one particular framework and not for their ability to solve complex problems and learn the best tool for the job, you might want to re-think your hiring policy.

It Used To Matter

It for sure used to matter.

AngularJS’s original scoping where it used dirty checking to update state was inefficient. React’s state management which eventually led to redux was significantly more efficient. I wrote a Vue/TypeScript app even just a year ago and the TS support was pretty awful. Angular 2 had great TS support, and now all three of them do.

Vue.js apps tended to have the smallest bundle sizes and was seen as an up and comer, but now neither of the big three really differ enough to have that be the straw that breaks your application’s back.

Here is another example. React came out with hooks for their functional components. Aficionados everywhere were pleased. Vue didn’t have that! Oh, but now they do. The Vue Composition API are just react hooks for vue.

It seems that these framworks have been in a state of convergent evolution. They have adapted in their environments and independently begun to portray the same traits over time.

Bundle size might be the last real difference to talk about, so let's do that.

Bundle Size... Does Size Matter?

The bundle size of your application is going to matter some, yes. This README shows the minified bundle size of each core library and some of their combinations.

Angular is the clear loser here, vue is the smallest of the big three. Preact (a lightweight React alternative) minfies down to 16kb according to that link. 3kb on their website! Eitherway it is very lightweight.

While the README does show the bundle size for React, React DOM, and Redux combined... this brings up one issue on bundle size.

It's not so much the framework's bundle size that matters but your dependence on other libraries. A Vue app with Vuex, Moment, Axios, Lodash, and more will start to add up. You might find yourself as heavy as a small React/Redux app as you add more dependencies. And if your coding practices are bad in that bloated vue app, you will see performance drawbacks.

So if bundle size is your determining factor, you'll want to work too keep that small no matter what framework you are choosing.

It Just Doesn’t Really Matter Now

It really doesn’t matter now. These frameworks have become so similar that trying to even determine the best one for a specific tasks becomes a challenge. Any of the frameworks can now build any application your team would need.

Any modern JS project is going to be bloated compared to vanilla JS.

But any modern JS project is also going to be tree shaken and minified.

Want a small bundle size? Watch your dependencies and use clean code practices like lazy loading and selective imports.

React by itself is tiny. Throw in redux, react-router, thunk, Moment, Lodash, TypeScript, and before you know it, your bundle size can’t fit in the state of Texas.

What Does Matter

User happiness is a big one. Do you like Angular and Vue directives more than JSX as far as templating goes? React might not be for you out of the box.

But if you are working with a framework you’ll have more positive experiences and you’ll use that framework more.

You'll spend more time with it, learn it's intricacies, and best practices. This is what will make your app efficient and you a productive developer.

What matters is your ability to choose a framework, stick with it through it’s drawbacks and then master that framework.

If you can do that, you can learn another framework for another project or position.

I don’t think the question really should be which framework is better. They are all perfectly fine and can do anything web application related.

The question should be how can I learn to use this framework to master any requirements thrown at me.

An Example

Let's say there is a small Vue app and it doesn't even have that many dependencies, but we have a view with nested components. In the mounted lifecycle hook of a few of those components it makes an expensive API call and blocks the page with a spinner to show that data is being fetch. Let's say some of these components in this view are nested... and a few of them have that same API call. It gets made twice or three times whe the user navigates to this specific page. Then when a user navigates away and comes back during the same session, the components don't check state for that data and make the duplicate/triplicate expensive API calls again.

Is bundle size killing you here? Too many dependencies?

No. The framework is being used incorrectly here and is your downfall.

This is an extreme example. But one or two of these mistakes in this example can occur throughout an application and affect usability and load times.


The three main frameworks have been in a state of convergent evolution. They now are pretty similar. A year ago, I wouldn't have said that. But at this point, they are about the same.

Their bundle sizes are the main difference these days, but clean coding practices will affect performance more than pure bundlesize.

For example, if you don't lazy load components and you have nested components making the same expensive API call in a mounted hook that will fire twice, things like this will kill your app. A memory leak could hurt you more in a Preact (lightweight react alternative with a 3kb bundle size) app than than Angular's bundle size. You should check state on page load instead of fetching data from a server each time, etc.

Choose a framework that you like. Stick with it and learn it's best practices, and you will have great efficient applications.

Discussion (0)