If you’re strapped for time, here are the most important points from this article:
The big three JS frameworks are: React, Vue, and Angular.
If you’re wondering which framework to choose for your project, it’s covered in the next section of this article: “How to make the right decisions regarding JS frameworks.”
This section is an overview of the JS framework ecosystem.
Created and maintained by Facebook and a large open-source community, React was first released in 2013 and has since become indispensable for many of the top applications in the world. React Native was released in 2015 and it’s a framework that simplifies building mobile application interfaces.
React itself is not a framework, it’s a library. Frameworks make a lot of technical decisions for you, and libraries essentially give you building blocks and leave decisions to you.
But developers use React like a framework. Using React as the foundation, programmers turn it into a framework by adding packages with different functionalities they need. They’re building their own React-based frameworks.
Because React doesn’t make a lot of decisions for you, you need to make those decisions yourself. React doesn’t impose rules, which can be an advantage, as well as a disadvantage. There’s no main convention, so React projects can be quite different from each other.
If you don’t want to choose custom packages, there are ready-made frameworks for React like Next.js, which solve this problem for you. Next.js provides all of the things that React doesn’t have, like server-side rendering and routing. It enables a faster start for React projects, but can also be limiting because it imposes certain technological choices.
(There’s no relation between Next.js and STX Next, by the way. Though we have used it to build software products for some of our clients.)
Use React in your project if you want maximum customizability, don’t mind using a lot of third-party packages, and want to benefit from code reusability. Add Next.js if you don’t have the time to choose additional packages yourself.
First released in 2014, Vue.js is an open-source framework created by a former Google developer who wanted to build a lighter alternative to Angular.
Vue is quite similar to React, but it comes with more functionalities out-of-the-box. It’s more opinionated than React, making more decisions for you. This enables a quicker start, but makes it slightly less customizable.
Like with React, developers can add the Nuxt.js framework for a complete toolset to kickstart a project quickly, or choose their own packages to build around Vue.
For simpler projects, developers can just use Vue. It’s very similar to React with Next, since Nuxt.js becomes necessary when you need server-side rendering, or your project is a bit too complex than pure Vue can handle.
Use Vue.js in your project if you want to start quickly, your app isn’t a complex behemoth, and you want a tried-and-tested solution that speeds up development time.
There are two Angulars. Both are open-source frameworks created by Google.
The first is the “old” AngularJS, first released in 2010. It’s still maintained only because there’s a large number of projects that haven’t switched to another framework (switching frameworks in mature projects is often impossible, as you’ll see later in this article).
The second is the “new” Angular, sometimes referred to as Angular 2+, first released in 2016. It’s a complete rewrite of the old AngularJS.
Angular is an absolute beast. It has all you need to build frontends, and it leaves developers with very few decisions to make. They just need to learn how to build things the Angular way. It’s the most opinionated framework, with very clear rules about everything.
Building huge applications is the easiest with Angular, mostly because it’s very easy to draw the lines between what different teams are building and avoid getting in each other’s way. Angular projects are nicely compartmentalized and organized.
All of the big three frameworks can be good for complex enterprise solutions, Angular is simply the most popular choice. It’s heavy, so it requires a lot of optimization and skillful craftsmanship to make the interface fast. But it comes with everything developers might need to build web and mobile frontends.
Use Angular in your project if your developers already know it, you want to minimize the use of third-party packages in your frontend, and you want your project to be neatly divided into several distinct parts.
Svelte was released in 2016, the first popular framework not associated with any of the tech giants. It’s now at version 3, and has been undergoing a surge in popularity since early 2020.
Svelte is a new approach to frameworks, because it’s a compiler, which makes it a framework without a framework. What does it mean? If React, Vue, and Angular make the browser (essentially meaning the user’s computer or mobile device) work to generate the interface you see, Svelte does all of its magic a step before the browser.
Because of this novel approach, Svelte is very light and makes for extremely fast applications.
Use Svelte in your project if you care greatly about speed and aren’t afraid of using a revolutionary technology that’s less than 5 years old.
Node.js is often listed among JS frameworks, which is a simple mistake. Node.js is a runtime environment.
React’s Next.js, Vue’s Nuxt.js, and Angular’s Angular Universal are used to start the frontend from the server side. It might be due to this functionality that some people group Node together with frameworks. But they’re not like Node; they’re just a bridge between Node (or another server-side technology like Python) and the frontend.
(If you’re curious when it’s better to use Node.js on the backend and when you should go for Python, we have a full Python vs. Node.js guide for you!)
The new major frameworks were created because it was difficult to decide when and which HTML to present, as well as what data to put into that HTML and how to do it. Using vanilla JS, you need to design all of this yourself.
Frameworks make these decisions easier. But the JS ecosystem is constantly changing and JS is getting more powerful. We have Web Components, or frameworks like Svelte, which are small additions to vanilla JS, and they’re starting to do the same things that frameworks do.
To help you make the right technological decisions, here are some of the most important things to consider before you choose a framework.
The first key aspect of choosing a framework is developer preference. In a lot of cases, whichever framework your developers like and know the most is the one that will be right for your project.
Looking at the big three—React, Vue, and Angular—they are largely interchangeable. They will meet all of your frontend requirements, big or small, simple or complex, but they require slightly different design and development approaches.
Beyond the big three, there are multiple frameworks for specific use cases, like LitElement or Svelte for tiny applications that need to work on low-end devices. You can still use these frameworks across the board, but the low-size, high-speed situation is where they generate the most value.
Keep in mind that if the project calls for a specific framework, but nobody on your team has used it yet, it doesn’t immediately mean that you should choose another framework.
For example, if you don’t have very short deadlines, and your analysis shows that a specific framework will work best, senior developers should be able to learn that framework within a reasonable amount of time.
But in another case, if you have 5 senior JS developers that have never used Angular, this is a valid reason to avoid Angular, because it’s a vast framework and will take a long time to master.
As always, the right call comes down to knowing your unique context and deciding appropriately.
Say your backend team is working in Java. It’s a strict, strongly typed programming language, with very clear rules for how to write code.
Angular has a very similar approach, with clear rules for how to use it. So if your backend developers use Java, Angular can be a good fit for your frontend.
This is especially important if your backend developers are also doing your frontend. But even if you have separate teams, pairing technologies this way will make it easier to cooperate. It means both your teams will have a similar programming philosophy, minimizing the risk of miscommunication.
Frameworks are usually heavy tools and weight translates to performance. Of all the frameworks in this article, Angular is the heaviest. React is smaller, Vue is even smaller than that, and then you have super tiny frameworks like LitElement.
The general rule is to use the smallest possible framework that meets your needs without adding a lot of unnecessary weight.
In some cases, you might not need a framework at all and just use vanilla JS to build simple functionalities. Or you can use a very small framework, like LitElement, which is a small addition to vanilla JS and enables you to do similar stuff to React or Angular.
If you’re creating a Progressive Web App (PWA, essentially a mobile app), the lighter and faster, the better. Again, LitElement would be good, or Preact, which is a React clone with a lot of stuff cut out, so it’s faster, but with fewer functionalities.
Note that in most cases, if your app is reasonably complicated, it will be hard to get a performance boost from using only vanilla JS. Your team will have to spend a lot more time designing things and working out bugs. As things are in the JS ecosystem today, you’re better off using a framework for everything except very simple web apps.
Let’s say you’re building a web application that will have thousands of subpages with various content, functionalities, and logic. Different subpages will have forms, games, blogs, videos, shop functionalities, and so on.
Here, Angular could be a good choice, since it’s built to handle complex frontends. Then again, you could use React, Vue, or Svelte and achieve similar results; the development process would just be a bit different.
What if all you need is to build a simple proof-of-concept app, just to see if your idea is viable? React is famously awesome for building MVPs.
If you’re building a very simple website—a basic online business card with no dynamic elements and very basic interactions—then it doesn’t even require a lot of work. You can use a sprinkle of vanilla JS to move the HTML from the backend to the browser.
It’s difficult to give a clear answer, because it depends. If you have a junior JS developer who doesn’t know a framework, they’ll need more time to learn it compared to a senior JS developer.
Learning the basics of a framework isn’t difficult. If a senior developer gets to know the construction, proper setup, tool selection, then using the framework should be relatively easy. To do basic things, it would take a day. For more complex usage, it should take a week or two.
At least for React, Vue, or Svelte. When it comes to Angular, there is significantly more to learn before a developer can code proficiently; it has the highest point of entry. Even a senior developer will need at least a month of training.
But again, it’s hard to say for sure. It depends on every developer’s personal experience and ability to learn new tools, as well as the size of the framework.
All software has security issues, so you need to update things. Nowadays, there are cool tools that detect if there are any security issues with the tools you’re using. You get instantly notified and know what needs updating.
Upgrading is usually easy, as long as everything is up to date. With React, there are no issues with upgrading to new versions. With Vue, it was a bit more difficult to upgrade from version 2 to 3 because of how many things changed. With Angular, it depends. Some versions were easy to upgrade to, while other versions—with a huge codebase of upgrades—required a lot of time and dedication. But every new version introduced something to make future upgrades easier.
For example, if you’re at Angular 4 and want to update to 9, you’ve missed 5 versions in between. This will be a big problem. That’s why it’s important to keep everything updated.
There’s a caveat with React. While it’s easy to upgrade React itself, you also have to upgrade all other packages that you’ve added to your React build, which can add difficulty to the process. Same goes for other frameworks and the extra packages you add to them.
In order to avoid technical debt, make sure your developers are using the latest versions of tools, libraries, and frameworks, and keep updating them. Sometimes, there are valid reasons not to do this, but often it just happens because it’s easy to forget about.
It’s complicated. If you have a mature project in framework A and you want to change it to framework B, you basically need to rewrite everything from scratch. It’s very difficult to switch frameworks.
But developers have come up with different ideas for doing it. For example, you can run two different applications—one in framework A, the other in framework B—and slowly rewrite all features into framework B. It makes performance worse, but it’s doable.
There’s also a concept called microfrontends. It enables developers to effectively use several frameworks in one application. But it also requires a special strategy and a unique implementation process. It demands a lot of work to make it viable.
Short answer? No.
The ways you code in vanilla JS and in a framework are mutually exclusive to a certain extent. Frameworks impose a different type of coding. If you build an MVP with one or the other, it’s likely that you’ll have to grow it in the same way.
Building a prototype is easier with a framework. Frameworks also make it easier to grow your MVP if it shows promise as a viable business.
But it has to be the right framework. A heavy and strongly opinionated framework like Angular is usually not a great choice for MVPs.
This is a moot point. It all depends on the experience of your developers. All of the big three frameworks make it very hard for you to mess things up. Developers would have to go out of their way to add blatant security flaws.
All major frameworks go through growing pains, but they quickly reach a point where they’re very secure. And they all have global communities of open-source developers polishing every part to be as stable and secure as possible.
The most bug-prone and dangerous way is using vanilla JS. Of course, you’ll find many developers who say otherwise. But in a business situation with tight deadlines and junior/mid-level developers, it’ll be much harder for them to make mistakes in a framework.
Frameworks are everywhere these days, so it’s important to use them wisely. Make sure you choose frameworks that your team knows and likes. If you need a framework that your team doesn’t know, they should be able to learn it, but it will slow down development.
Use heavier frameworks only when your project is complex enough to really need them. Otherwise, you’re needlessly sacrificing performance.
Avoid technical debt by using the latest versions of frameworks and make sure they’re regularly updated throughout the project’s lifetime.
Frameworks are proof that collaboration is the driving force of software development. They’re the result of a beautifully concerted effort between smart developers, industry-leading companies, and global communities of open-source engineers—all with a common goal to create better software.
If you want to learn more about frameworks, check out these articles:
P.S. If you need help choosing the right framework for your product and building your app, contact us, we’re always eager to take on new projects.