Navigating the landscape of JavaScript frameworks can be a little daunting. There is a lot to choose from and a lot to take into consideration when choosing a framework for a project. Everyone seems to have an opinion on this topic as they are entitled to have, but today I will share my opinion for what it is worth. Please note I am well aware that the universe has too many of these types of blog posts, articles, and podcasts already. For some reason, I felt like throwing one more out there wouldn't hurt.

The Big 3

If you have been developing in JavaScript for any significant amount of time, then you know that the main three frameworks people talk about are React, Angular, & Vue. They are all fantastic frameworks with large feature sets written by incredibly intelligent people that make your development process faster and easier. They all also have one main problem; fanboys/fangirls/fan-people. If you read blogs, listen to podcasts, or even just socialize with other developers, you are destined to hear a bunch of enthusiastic, heavily opinionated chatter about each of these.

There are other fantastic frameworks out there which you should not ignore. Ember, for example, has a respectable user base and enthusiastic community surrounding it. For the sake of brevity and addressing the masses, I will stick to talking about the "big 3" in this post. I am also really only familiar enough with these three to speak somewhat intelligently about them. Again, that doesn’t mean you should ignore the other options that exist as you never know which one will become the next big thing and they have a lot to offer.

A Little Preemptive House Cleaning

• I know that many people consider React a library and not a framework and I understand why. For the sake of this post, I will refer to it as a framework and I hope you understand why in return!
• I have been using Angular in both a professional and personal setting for 5 years now so my knowledge of Angular goes deep and I am admittedly a little biased.
• I have the least amount of experience with React, but I feel I understand the problem it solves and the power it possesses.

Frameworks Should Speed Development, Not Hinder It

Let’s start off by getting this out of the way; REGARDLESS of what I say here, you should ALWAYS consider your own comfort level with a framework when making your decision on which to use. If you are contributing to a project that is already under development or integrating with another, you should also consider which framework is already being used and what kind of mess it would make to use another. Just because you are “Team React” doesn’t mean it makes sense to add React to an Angular or Vue project, etc. Frameworks are supposed to be a tool you reach for to speed up the development process and allow for additions of certain features with minimal time spent writing code. Don’t disrupt the flow and bundle size of a project because you like one framework over another!

You should also consider your comfort level with a framework and the comfort level of any other contributors before you select it for a project. Maybe you REALLY want to learn Vue, but the project has a somewhat tight deadline and you haven’t familiarized yourself with Vue yet. If this is the case, then don’t choose Vue! Choose something you are familiar with so you make your deadline. If you are starting a personal project or working on something with no real deadline, then THIS is the time to experiment with something new or base your decision off of other variables. We as developers have a tendency to lose sight of what the priority is and, instead, think about are own preferences and curiosities. Don’t do this!

At a Glance, One is Not Better Than Another

Without a specific criterion to judge the main three JavaScript frameworks against, not a single one of them is really any better than any other. All three have large, extensive feature sets that include:

• easy ways to accomplish server-side rendering
• easy building of single-page applications
• routing
• state management
• simple and utilitarian templating
• CLI tools
• large communities for support and community-driven plugins
• good documentation
• performance optimization
  
  

Sure, you will find blog posts with graphics talking about how one framework out-performs another. I believe that any actual performance difference is negligible and the factor that will have the greatest impact is the implementation by the developer using the framework. You will find communities of users singing the praises of one while they bash another. Ignore them! I believe that humans have a tendency to defend their choice and lash out at the other options to validate their own feelings or decisions. A great example of this is how, before I became a video game collector, I bashed Xbox and sang the praises of the PlayStation. I owned each PlayStation, so I was ignorantly and blindly lashing out at Microsoft’s offerings. Once I deemed myself a collector and acquired the three models of Xbox, I quickly learned that they are great consoles too and I was missing out. That said, now that I am familiar with the differences between the Xbox and PlayStation, I feel that they have small differences that make them a better choice in certain people or situations. The same goes for the “big 3” frameworks and I will elaborate.

Caution: Opinions About React, Angular, & Vue Ahead!

Angular: Pros

I’ll start with Angular since I’ve admitted being the most familiar with it. Angular gives you everything you need right out of the box. There’s no reason to stop and think “which routing solution should I use” or “how will I handle asynchronous operations”. I’ll tell you how; you’ll use the router built into Angular and RXJS since it comes included. This is why people say Angular is opinionated. It is, but that isn’t a bad thing. Having some of these decisions made for you not only saves you the time and trouble of choosing, but it also means that these features and dependencies are tightly integrated with the rest of the framework which means you get maximum performance and compatibility. Sometimes freedom of choice can be more of an inconvenience than a good thing. At my day job, I work in a very large code base using Angular. We built our own monorepo setup where our applications, component libraries, and service libraries exist together allowing for the simplest way to develop cross-project. We even have Storybook setup so we can not only see examples of implementing our components, but we can show them to our UX designers allowing for another level of collaboration. Working in a code base this large in Angular is nice, and that is what I believe to be one of Angular’s strengths. It is my opinion that for large applications, Angular is a better choice than the other two. The fact that Angular is so opinionated also means that there is never really a question where to find a file because we follow the standard protocol for organizing and naming files in Angular. There’s also minimal disagreement between team members on what dependencies we should use because so many of those decisions are made already.

To finish singing the praises of Angular, I’ll add that while we can now use Typescript with any of the “big 3” frameworks, it is the standard in Angular and I feel like it adds value. The type checking doesn’t catch bugs for me often, but I believe some of that has to do with the fact that when I am writing in Typescript, I am naturally more conscious of the types so I don’t incorrectly try to pass the wrong types of variables to a method. While RXJS is included with Angular, you can also use it by itself or with any other framework. Still, I’m not sure I would have forced myself to learn RXJS if it wasn’t included and I’m glad I did. I believe that, at the time of this writing, RXJS is the best and most powerful approach to asynchronous programming. I won’t dare to say that Angular, Typescript, and RXJS are at all easy to learn, but I believe they are worth the effort.

Angular: Cons

Speaking of the time and effort it takes to learn Angular, Typescript, and RXJS, I feel that is the biggest con to learning Angular. It is a steep learning curve. Basically, you have to learn an object-oriented framework, a new programming language, and a library that gives you a new data type: the observable. This is no small task. Thankfully, I feel like Typescript makes a lot of sense because it is a superset of JavaScript and, if you’ve ever written in another statically typed language, the additions made to JavaScript will seem familiar. Still, it can feel overwhelming at first.

Another drawback is the base size of an Angular project. This isn’t a situation where you write a small config file and start creating files for your components. Basically, you need to generate your project using the Angular-CLI and it will create A LOT of files. This is also another area where the learning curve can become an issue as, if you want to tweak parts of your build process or TS config, you have to know where and how to do these things. Once you trigger a build process, your end result will be small and performant. The number of files you will carry around in the repo will be daunting though.

Vue: Pros

I love Vue! I am rooting for Vue to become the next big thing and I use it almost exclusively the past few months for personal projects. In fact, I built this website using Vue and Nuxt. I feel like Vue took all the best features from the other frameworks and rolled them all into one while learning from their mistakes as well.

Vue is easy to learn. The basic idea is to create a single file component with standard HTML, JavaScript, and CSS or the CSS preprocessor of your choice using the following tags to separate them: template, script, and style. Inside the script tags you simply export a JavaScript object and the keys of that object are the Vue specific keys you have to learn, but they make perfect sense. Your life-cycle hooks exist as functions on the root of the returned object so simply adding created() {} or mounted() {} gives you a place to add functionality to those hooks. The data passed from the parent component go into your child component through the “props” array which, again, is just a key on the root object. It continues this way which makes Vue very easy to pick up.

Vue also has a large community for support and the creation of plugins. Want to make your site a PWA with minimal setup? Someone made a plugin for that. Want to quickly add a scroll-to-top button or social sharing buttons. There are plugins for that too. Have a question about something very Vue specific? If you can‘t find the answer in the official documentation for some reason, there are a plethora of Stack Overflow answers and small communities of people that have your back!

Vue also has Vuex for state management. I feel that, while Vuex shares a lot a similarities with Redux, it is easier to learn and just as powerful.

Vue also allows you to use the libraries of your choice if that is your thing. You can simply run npm install axios -S then use an ES6 import at the top of your script tag in a component to include axios. You can do this with just about anything. If this is the flexibility you crave, then Vue is a good choice.

Vue: Cons

Many people cite that Vue has no major corporate backer as a bad thing. I can definitely see where that raises concern over the potential longevity of the project. Personally, this doesn‘t bother me, but I understand the concern.

Vue is also very young comparatively, so it hasn’t had the time to gain the trust of many developers. It also means that, while there are lots of community-driven Vue plugins, there still isn’t the laundry list of options you might find with either of the other two major frameworks. While you won’t find a Vue specific data visualization library for charts just yet, you can still use a regular JavaScript library solution, but you will have extra work ahead of you to make everything play nicely.

React: Pros

I’ll do my best to talk about React, but I really don’t have a lot of experience with it YET.

React has been the “flavor of the month” for a few years. If you are front end developer in 2019, it is assumed that you are using React. This means that there is no question you cannot find the answer to and no need for a library that hasn‘t already been met. Want a static site generator for React? Try Gatsby. Needs some charts? You have options including Recharts and CanvasJS.

Currently, I am exploring what other opportunities are out there and I have noticed that I am constantly asked what kind of React experience I have. Employers want React experience because so many of their dev teams are using it. A few years ago I was a pro with AngularJS and it was the hot framework of the day so I felt like the world was my oyster. Now, you need to know React to have that feeling.

React is not difficult to learn if you already know JavaScript well. If you have ever thought to yourself “I wish there was a way to create web pages and applications only using JavaScript” then React is what you have been looking for this whole time. The layout, style, and functionality is all handled via JS.

While perhaps mobile applications are no longer needed for most situations with the rise of PWAs, React has React Native to allow you to generate native mobile applications from a single code base. For those companies that are offering something outside the range of what they can accomplish with a PWA, this is a huge benefit. Sure, you can accomplish the same thing with Ionic and Angular, but React Native is built specifically for React which makes the compiled result a little less likely to contain strange, unpredictable bugs and a little more likely to perform well.

React: Cons

I’ll lead this off by stating that this is very much MY opinion. While I cited the lack of corporate backers as a con for Vue, I’ll say the fact that Facebook is the corporate backer/creator of React is why I avoided it initially. I don’t trust the company at all and they validated my concerns early on with the whole React license fiasco.

I’ll also say while React is arguably easier to learn than Angular, it is harder to learn than Vue. If you need state management, then you will end up reaching for Redux which will take that learning curve barrier to the next level.

Another area that proves divisive is the freedom of choice you have when using React. Some prefer this freedom and some consider it a curse. Since React is not overly opinionated you can pull in pretty much any JavaScript library to solve any problem you are facing. I consider this a con as it is easy to become overwhelmed with options, but you might see this as a pro. Again, this is an opinionated post.

Are We There Yet?

Yes, kids, we’re there! You’ve made it through yet another highly opinionated blog post about modern JavaScript frameworks. If you completely disagree with my pros and cons list for each of the “big 3” frameworks, I hope the takeaway is that they all have their place and you can’t really definitely say one is better than another. You can definitely have a preference, but that is all it is. I feel like the main thing to consider when choosing which to use is how their strengths and weaknesses align with your project and which one(s) you already have a high level of familiarity and comfort with.

I urge everyone to learn all three frameworks before they make too many judgments. It is unreasonable to say you should become an expert in all three, but at least build a couple of things using each before you become too much of a fanboy/fangirl for one in particular. There’s no reason you can't like them all!