React vs. Vue vs. Angular

Front‑end development has a bit of a reputation for being a very fast‑moving industry. It's probably fair to even go a step further than that and say that it feels like there's an all‑new "next best thing" almost every week and that ‑ for the most part ‑ those "next best thing"s don't stick; either getting surpassed and replaced very quickly, or otherwise getting condemned into middle‑management buzzword purgatory.

As more talented front‑end developers working on the cutting‑edge start to do more and more things, the expectations of what the average front‑end developer should know and be able to do rises as well.

Whilst it is great to see the amazing things that can now be done entirely within the client side (especially if you have a lot of free time on your hands), the actual set‑up and start up of any new project can be a considerable time sink, especially when building complex functionality or web apps.

That's where frameworks come into their own.

There are plenty of front‑end frameworks and libraries, each suited to different tasks. React, Angular and Vue are three prominent options in the 2021 landscape. React is a UI library, whilst Vue and Angular describe themselves as frameworks; I use "frameworks" loosely when discussing the three here.

But which of the three made sense in 2021? I've worked extensively with all three, so I had my own personal opinions, not least shaped by the projects I chose to contribute to and their underlying technologies. The use cases below reflect the landscape at the time.

First up: React.

Where Did It Come from?

Facebook, unfortunately.

Popping up in 2011 thanks to the very talented Jordan Walke, React started out as what Walke had named FaxJS (which can still be seen on GitHub today), and which found itself being rolled out on the Facebook News Feed as its first release ‑‑ a big early‑adoption for any framework.

2012 was a big year for React as well, as it was adopted by Facebook and used in their new acquisition: Instagram. On top of that, it became an integral part of how Facebook managed their ad functionality, which put it in front of the higher‑ups within the organisation.

From there, it continued to gain ground. React.js conferences started being held over the following four years, and it began to build a name for itself even with managers and salespeople who had no idea what it really was. This was great for React but probably less‑great for the developers being asked to integrate it into places that it didn't really belong.

Big Users?

Facebook... unfortunately. I don't have the opportunity to use this same joke for a third time, so here's another link to Facebook wrongdoing. Suffice it to say: if you still use Facebook, it may well be time to consider moving on.

React's adoption gives us a large ecosystem to draw on, but a list of company logos doesn't tell a client whether it fits their project. I would put more weight on the features we need, the team's experience and the work needed to maintain the result.

Where are Its Strengths?

The Virtual DOM

React lets us describe the interface from state, then works out the DOM changes needed when that state changes. The virtual DOM is part of that model; it is not an exclusive ability to update one element, or a guarantee that those updates are faster.

If a counter ticks up each second, React can update its text without replacing the rest of the page. Direct DOM code and other frameworks can also make targeted updates. The useful difference is how we organise the state and express the interface as the application grows.

Reusability and Reliability

React is probably the most economical of the frameworks I'm discussing today. A constant and reliable data flow means that you never really get lost in confusing components and update directions, instead knowing that parent elements will always update child elements and pass data downwards to them.

Another key element to React's developer friendliness is the reusability of its components. If you build in the right way, you will be able to cut down your build time by simply using and reusing small, modular pieces in different places in your UI and with different data flowing into them.

How About Its Weaknesses?

Rendering Strategy Matters for SEO

Historically, the way that React renders hasn't worked particularly well when it comes to search engine optimisation, particularly in feeding the right content to search engine spiders. Way back in 2008, I was facing a very similar problem whilst building similar rich, interactive web applications in Adobe Flash.

That was a real concern for client‑rendered applications at the time, but React itself does not decide how a page is rendered. Client rendering can still make discovery harder when meaningful content is absent from the initial HTML; static generation and server rendering can deliver that content directly.

In 2021, tools such as Gatsby and Next.js offer ways to generate or render React pages before they reach the browser. That is an architectural choice to make for the project, rather than treating every React site as a client‑only application.

JSX and the Overlap of Languages

If you care about keeping structure and logic in separate files, JSX can feel odd at first. It is a JavaScript syntax extension with markup‑like notation, which is transformed into calls that create React elements. It is not an HTML string passed through to the browser.

Writing a <p> beside JavaScript expressions in a .js or .jsx file takes a little getting used to. For me, the useful question is whether keeping a component's rendering logic together makes that component easier to follow.

How to Sell a Client on React

With the amount of hype and non‑tech recognition React now has, for the most part, it will do the selling itself. Any client (or manager) who is vaguely in the tech space, or has worked with developers before, probably knows at least the name ‑‑ and with a quick show of the user list, it's not going to be a hard sell.

My favourite tech stack at the time used Gatsby (a static site generator), which itself uses React. I tended to explain to potential clients that this combination resulted in a very performant, SEO‑friendly, and (as far as possible) relatively future‑proof website that should serve them well for many years. With the uptake React had experienced, it was not hard to imagine it still being around even a decade later.

Up Next: Vue.

Where Does It Come from?

Vue was actually created as a bit of an offshoot of our next tech ‑ Angular ‑ in mid‑to‑late 2013; officially hitting the open‑source market in early 2014. Evan You, the developer behind Vue, says that he was working at Google when he ran into Angular. He found it helpful in a lot of ways but felt that it was heavier than it should be (and he was right).

He went on to extract the bits that he felt worked well in Angular, polish them up and put them together into a standalone framework, which he later named Vue.js. You can read a little more about his involvement with the development of Vue in this 2017 article from Between the Wires (now hosted on freeCodeCamp).

Big Users?

Vue was created independently by Evan You after his time at Google, where he had worked with AngularJS. Angular is Google‑backed; Vue did not come out of Google. Their history is related, but they are separate projects.

On top of that, high‑end fashion giant Louis Vuitton makes use of Vue for their website, and even Nintendo get into the game, utilising Vue on some of their regional sites and other parts of their online presence. I could talk to great length about these particular projects given that I worked on them both!

Strengths

Vue can give you a small starting point, particularly when you only need to enhance part of an existing page. There isn't one useful bundle‑size figure for every Vue application: the version, runtime build, compiler, dependencies and compression all affect what reaches the browser. Check the production output for your actual project.

Vue also has fantastic docs. There's nothing more frustrating than a framework, CMS, library or other technology that offers some great benefits but leaves you high and dry when it comes to quickstarts or gaining a deeper insight into how the system works, especially when things go wrong. I'm looking at you Wufoo and your sparse, decade‑old documentation!

In this area Vue really stands out with clear, fast, and easy‑to‑use documentation.

Weaknesses

In 2021, many of Vue's drawbacks related to its younger age and relative novelty. It had a strong developer base and useful resources, but its ecosystem was smaller than React's or Angular's and missed some of the benefits that came with wider adoption.

Plugins, integrations, and forum answers could therefore be harder to find, with more potential dead ends when developing something complex or off the beaten path.

How to Sell a Client on This One

If you're considering Vue, show the client how it fits the work: a small prototype, the integrations it needs and the production bundle it produces. I find that a more useful conversation than promising it will always be smaller or quicker than the alternatives.

Because of its lightweight nature, it's also pretty flexible; there might not be as wide a variety of prebuilt plugins as other frameworks, but Vue doesn't really lock itself into anything at all so if you have the skillset, you should be able to integrate anything you really need.

Last but Not Least: Angular.

Where Does It Come from?

Angular began its life as an internal tool created by Misko Hevery, a developer at Google, in 2010 ‑‑ making it the oldest of the frameworks I'm covering here today. He first put it together to speed up his development of web applications, and when he and a few others in his team realised that it was genuinely something worth taking further, Angular was released as a project for the development community to work on together, going open‑source.

Big Users?

Google's support is a useful signal when evaluating Angular, but I wouldn't choose a framework from a list of famous users alone. Its more complete tooling and conventions are the stronger argument for a team that wants that structure.

Typically, Angular will form part of a MEAN stack, incorporating MongoDB to handle the database, Angular for the front‑end, Express.js as the server hosting the web app, and Node.js for the environment that the server runs on.

Strengths

Industry Support

Angular came from Google, and Google still supports and maintains it to this day. This means that not only does Angular enjoy contributions and support from the open‑source developer community, but also benefits from the support of the developers working for one of the biggest tech companies out there. Whether you like Google or not, it is not hard to see how that is a big benefit.

The Command‑Line Interface

The Angular CLI was an impressive tool. It could add external libraries, open documentation for keywords, build, deploy, and run tests on an app (using Protractor at the time). Linting and unit‑test commands were available from the start, which made it useful for getting a project running quickly.

Weaknesses

The Ecosystem is a Bit of a Hot Mess.

Angular moved fast. Angular 13 had already been released earlier in November 2021 when this article was published, and the quick succession from versions 9 through 13 made the upgrade pace feel difficult if you were still learning the framework.

Compatibility needs checking across Angular, the Angular CLI, Node.js, TypeScript and RxJS. Angular and CLI release versions were synchronised from Angular 9, not Angular 7; that is not a blanket rule that every package must have an identical patch version. Follow the supported combinations for the release you are using. The much larger historical break is between AngularJS and Angular 2 onwards.

When Angular 2.0 came out, the Angular versions before it was renamed to "AngularJS" and every following version has been "Just Angular". This can cause some confusion, at first, but isn't a major deal any more as those versions were long ago.

TypeScript

To work with Angular, you'll have to work in TypeScript. I like TypeScript and like working with it, but if you aren't familiar with it, there is a not inconsiderable time and resource investment to get up and running. If you're looking for a quick framework to get off the ground with, this might take Angular out of the running altogether.

How to Sell a Client on This One

Angular sticks out a little bit in this list because it behaves more like a platform than a framework in a lot of ways. If you develop with Angular, you're looking at a whole project, as opposed to React and Vue which can be integrated with other tools and systems, and often needs to be (for instance, React Helmet or Redux). Angular includes more first‑party facilities than React or Vue, so it forms a more complete package, although applications still depend on external libraries and tooling where their requirements go beyond the framework.

To pitch Angular to a client or a manager, push the holistic idea of development, coupled with the frequent and impressive maintenance from Google.

Use Cases in 2021

So now that I've covered each of the three in‑depth, let's think about some use cases in which each of these frameworks stands out ‑ this might answer any of the questions you've had whilst considering which one to choose, or give you some ammunition when you're trying to guide a client who has their heart set on a particular framework.

For React:

For a complex Single Page Application, React was a strong option among these three, particularly when UI regions needed to update independently. It did not guarantee a lightning‑fast result; rendering strategy, bundle size, and application design still determined performance.

It is less suited for smaller apps, and you might find yourself churning your wheels in getting React set up, routed, and the infrastructure together rather than developing your actual website if you use it on something small.

For Vue:

Vue takes the cake in lightweight, quick prototyping. If you're looking to get a small app off the ground quickly or develop a proof‑of‑concept before fleshing it out and moving to a bigger framework, you're not going to want to invest the setup in Angular, and you're going to want as small a framework as possible.

Vue beats out Angular and React for small, quick prototyping and small, simple apps. It's also useful for integration with an existing project because it's pretty agnostic and very flexible.

For Angular:

Angular is the go‑to for a fuller, beefier project. If you need to build something that works well on mobile and desktop and can handle heavy interactivity and present data in complex layouts, Angular is probably your weapon of choice.

The initial learning investment can pay off when a team benefits from Angular's conventions and first‑party tools. It still uses external libraries, and dependencies need maintenance as the project grows. A more complete framework reduces some choices; it doesn't remove that ongoing work.

The Wrap‑up

Ultimately, the answer to the question "Should I use React, Vue, or Angular?" is "It depends, what're you trying to do?". As with so many other things in web development, the question is only answered with another question.

Hopefully, though, this look into the three big players in the front‑end framework world has helped clear some things up for you.

As a final note, I think it's important to point out that whilst getting familiar with each of these frameworks is a good look for your CV, and a potentially helpful move for your career, pushing yourself to master all three is unnecessary.

In the front‑end development world, it's very easy to feel like you're falling behind ‑‑ and to suffer from impostor syndrome because of that. Nobody needs to learn all of the frameworks and techniques available to them, and trying to do that will burn you out. Focus on one stack at a time if you can, because by the time you're done learning one, you never know what the landscape is going to look like.