Do you want to skip the article and want to know what’s my top preference for beginners to start with? The simplest answer is React.
But if you are curious to know why I preferred to react, grab a cup of coffee and sit around to read the article.
When working with JavaScript you’ve got a lot of solid options in frameworks to choose from and oftentimes, it gets confusing to choose a one and get started.
Here, I’ll introduce you to the two most popular frameworks of JavaScript i.e. Angular and React.
We will find the best fit for your situation and will discover why react is gaining huge popularity.
By the end of this article, you will be on your way to start working with one of these frameworks/libraries.
Introduction
In this article, I’ll be talking about Angular 2 and not about Angular.js.
Angular 2 is a general term used to refer to all versions of Angular after Angular.js.
One thing to be mentioned in this article I’ll be using Frameworks and Library very often inter-exchangeable, for ease of readability.
But this doesn’t mean that both the words have the same meaning.
Library and Frameworks both share very different properties and in fact, it is one of the core differences between React and Angular.
React is a Library whereas, Angular is a fully-fledged Framework.
Before disclosing the reasons for the popularity of React.
Let’s understand more about these two Frameworks with the help of few points.
Brief overview
React
React is a JavaScript library for building User Interfaces.
It’s a component-based library and makes it super easy for developers to create User Interfaces.
It was managed and created by Facebook and a group of open source developers and was introduced in May 2013.
Angular
Angular is a JavaScript framework for web and mobile development.
It is a typescript-based language, managed by Google’s Developer community and was launched in 2016.
It is one of the most important factors that work in favour of Angular that it is built and updated by some of the most credible persons on earth.
Learning curve
React Possess a low learning curve when compared with Angular.
However, react itself is not complete and you generally have to use some state management libraries like Redux and Flux for managing states in a complex React application.
We can combine react with any other framework out there and start working on it, even we can combine react with Angular.
Angular is quite opposite of React and possesses a high learning curve as it is a very large framework.
Performance
Performance could be the turning point for most developers to change their minds from Angular to React.
React uses Virtual Dom, whereas Angular uses a traditional Dom.
Now, In traditional Dom, if you want to update specific information of your user, Angular will rewrite the whole structure of the Html Tree.
Whereas, React Virtual Dom allows you to update the changes without rewriting the entire HTML.
In short, React Virtual Dom is faster than the Angular Traditional Dom.
But angular has something called change detection which updates the DOM whenever data is changed.
Due to this angular DOM performed as effectively as virtual dom.
React Uni-directional data flow ensures that the state change takes place meticulously even in complex projects.
Data flow control is very simple in react even for large projects.
Opposite to React Uni-directional nature Angular Bi-directional data flow makes it even complex for large applications to deal with data quickly.
However, Bi-Directional binding is easier to work with.
Uses
Here is the list of companies that uses Angular and React to give you an idea of their Market Value.
Angular
React
Reasons why React is winning?
React is declarative in nature:
This means that when you write a component in react you just need to tell the react what do you want your component to look like.
You need not worry about its different states and the other elements on the web page.
React will handle that for you.
React is easy to learn:
React is pretty much simple JavaScript with some extra functions and therefore.
It’s much simpler to understand React in comparison to Angular where you have to learn a full framework.
Although, it’s come with the cost of learning several external libraries.
React is very minimal:
React is a very minimal language that does not focus on too many things and just focuses on one simple thing building user interfaces.
Remember this statement works in both ways.
It can be used in favour of React as well as against react.
React has been a top choice for developers to work with and even in a
stackoverflow survey done by 90,000 developers in 2020.
React is still one of their top preference with 68.9 percent of developers voting for react.
Conclusion
While JavaScript is already a complex programming language I think its ease of readability and working can be increased by using a framework or library.
React has an easier learning curve whereas Angular has many built-in functionalities to work with.
React is used pretty much everywhere whereas Angular is mostly used by Enterprises.
I think while React is my choice of preference to get started with there is no harm in learning Angular as well.
If you want to know more about these two frameworks you can always head to their official documentation for a more detailed comparison.
Also, tell me below which framework are you using or going to use.
If you find my work interesting and enjoyed reading you can appreciate me on Twitter and LinkedIn.
Cover by - Anna Shagova on Dribbble.
Top comments (34)
I find it ridiculous when people say React has a smaller learning curve. Which flavor of react are you referring to? Which router? Which build system? Which cli tooling? Every react project is different because it's wild west.
I feel like this is a pointless thing to note and a bad faith argument. If you just compare "@angular/core" to "react" the stuff inside them is pretty comparable. So what does React make easier? Templating. You have to learn JavaScript with sugar, rather than a custom templating language. Modules. With React you have to learn ES6 import statements and you're done, but with Angular your have to learn that plus the convoluted and messy NgModule system. And not to mention Reacts patterns don't force you to learn DI out of the gate. I'm not going to say DI is bad, but I'm going to say the concept is weird for beginners and that above all, in a client, it's very rarely got a purpose. 99% of folks Angular service @Injectables are just one instance.
Good point.
Personally I liked the nudge to learn typescript. I've been using it since it's was in Angular RC candidates so at the time the browsers didn't even support const and let or the class keyword so in those times it was letting you use next gen js features w/o babel.
That has become much less of a point nowadays though.
I'm general I feel like it promotes learning of good software architecture patterns rather than proprietary syntax.
Kind of feels like you're suggesting it's a bad thing for developers to learn how the concept of dependency injection works, or how strong programing patterns help.
I don't see it as a drawback to basically teach developers SOLID design principles as they learn a framework at the same time.
Tempered and experienced developers will latch to a project template or simply use eslint, prettier, commitlint, husky, etc to standardize the workflow and code style. It also helps to standardize on the technologies used.
Zustand, unstated-next, material-ui, react-query/swr, emotion/styled, axios, etc. If you choose what technologies have been trustworthy in your past and have proved their value, then you can guarantee the same experience across projects.
I agree with you! There are so many things you might not have heard of but are used in jobs. Atleast, angular gives us a bunch of things so that we know we are not missing anything major. But still, React is my favourite framework(just cuz I don't know any other JS frameworks lol)
HAhaha .. laughed so hard at this comment
Totally agree. I tought React was simple, but after seeing a project at a new job I was shocked how different it was there. All logic INSIDE the jsx... Man glad I've ran away from that.
What do you use right now?
Use Nextjs then... and why should everything be opinionated react is just the view layer.
React is purposely built this way. It's unopinionated, so you can add anything you want to it. Routers, build systems, CLI tools - these are all extraneous packages and NOT React!
Angular has Uni-directional data flow also. Bi-directional flow is optional.
You are wrong about angular re-writing the whole component tree. Angular uses incremental DOM. It can detect exactly where change was made. React is the one that actually has to rebuild components everytime something changed because it uses virtual DOM.
Both frameworks will fail in performance if you do not properly maintain state, which will cause renders when you don't want to. It just so happens that keeping track of all that is easier for developers in React than in Angular. Too many async operations in Angular cause a "what just happened" moment more times than I can count, whereas I never ask that question when writing React code.
Angular uses bidirectional data binding by default. They convolute and give the unidirectional binding system. React doesn't try to hide how it works out of the gate. I've been an Angular dev for 4 years and I can promise you that the magic of Angular seems awesome to new devs but it's got bad performance repercussions and fixing it late is incredibly dramatic.
And they both have a comparable shadow DOM concept that intelligently figures out what needs to be rebound.
There is a saying : "Use right tool for the Job".
Which means
Reactis not the right tool for every Job. Sometimes the right tool for your project can beAngular, React, Java, Node.Js, .NETetc...Before 10 years it was
PHP, NowAngular, Reactetc , Who knows what will be in future ?Hope you understand the point. 😄
Having worked in Web Components for years (since 2018 when Firefox adopted the spec), and ALSO having years in React and both flavors of Angular, this comment intrigued me.
To be honest, the compiler approach that Svelte, Stencil, Catalyst and others of the new generation of frontend tools have taken has really been a breath of fresh air after a decade of overly-complicated framework madness (this includes React). All of them have at least the option to compile to Web Components, and two are WC native
I would never say those are always the right choice, the same way I would never pick a frontend or backend framework for every project, but I will say I don't see any similarities between Web Components and Angular.
I'm interested in what experience or reading brought you to this conclusion! The only pitfalls I would warn my clients about are that they don't have the same level of third party library support... But since they are native to the browser (as part of the spec) that's a lot less concerning than a custom run-time that you have to download into the client to interpret your code.
It's really more of a tradeoff, where you need more custom third party libraries written for React and Angular as custom run-times vs being able to use vanilla js tooling with WC, but the most popular framework-specific libraries won't be available unless you introduce the framework as a wrapper/controller/router to contain your WCs. It's really all about what you need to accomplish, and I just didn't understand where you're coming from. Thanks!
Yeah, that post is one I normally point to when I'm trying to introduce modern Web Component compilers to folks. Here's a comment I left for someone wondering about using Svelte with a web component compile target. I largely disagree with Rich's post, but I like to give him his due. He's written some great tools, I just think he's got some weak points in his stance on WCs. It's something I'd rather debate over coffee and not in little chat boxes!
I was an early polymer adopter back in 2016 or so too. It wasn't ready then, and it was still running off of the old pre-approval v0 spec, which needed significant retooling. I didn't return to WC's until 2018 or so because of the initial issues with it.
It is important to highlight some of the arguments against WC's like Rich's, because it's an architectural choice. Like I said, not every problem is a nail, and WC's definitely aren't a silver bullet. I find myself defending them often (generally due to unfortunate early implementations from 5 or 6 years ago), but keep in mind my defense is that they are a viable and legitimate approach... not necessarily the one I would always take!
Accessibility and styles being busted is also a common misunderstanding. There are longer breakdowns out there, but my favorite is in LogRocket's "React vs Web Components" article (Check out the accessibility section). I don't suggest ANYONE try and do large application development on base web-components without a compiler (too much boilerplate), but especially if you're extending an HTML element, there's no issue with accessibility. If you're creating a purely custom element, the "role" attribute is there to help, even if the "is" attribute isn't supported in... Internet Explorer and Safari?
Shadow DOM has never presented me with an accessibility problem above and beyond what I might expect in any other JavaScript context like React and Angular, but I'm open to any current links (IE: Within the last year or two), as I'm not an accessibility consultant, so there may be a problem I've missed :) It's really been testing tools which haven't adopted support for it that find me using "open" Shadow DOM more than anything else.
Most of the popular compilers have a SSR solution (I Linked Stencil's SSG capability which has a link to their SSR solution at the bottom), and especially when using a framework like Ionic's stencil, GitHub's Catalyst, or even Svelte's Custom Element API (Which Rich Harris still supports, even if he doesn't love Web Components), prop/attribute confusion tends not to be an issue. Not a lit-element fan (mostly because I haven't played with it enough), but I feel like it deserves a shout-out here too :)
Finally, I can't ignore all of the enterprise adoption that's been happening on the WC front. SalesForce has been using them since 2016, and released their component builder in 2019, GitHub uses the aforementioned catalyst in production, Apple has used them, RedHat has used them in their Design system PatternFly to create PatternFly Elements... the list goes on, so it seems that WC's are starting to gain some good traction...
All that said, I see WC's and the compiler pattern as a path out of the overly-complicated framework wars that have engulfed the front-end ecosystem for the last decade+, but again, they can be complementary to the frameworks as well as replacements for. No silver bullets here!
I guess working in a natively supported browser technology rather than the custom runtimes we've all gotten used to has me remembering that there's an easier way. A lot of the WC FUD I tend to see feels a lot like when we were all jQuery developers circa 2009 and were convinced you couldn't download ALL the JS for a framework, and the SPA pattern felt like madness haha.
Thanks for responding to me!
Nice article.
You have something wrong here, Microsoft is using React as well. I know Angular was the election in the past but, now, it is using React as the main library for Office 365 developments. This links as an example docs.microsoft.com/en-us/sharepoin....
Maybe, you have to add one more reason in your article to start or move to React ;)
Sure! I'll check it out later on.
The reason to use React is... Microsoft is using it?
In a small scale project i agree that React has a smaller learning curve than Angular. When you build a website for personnal use, React gives a simple way to build it. But, today i think many people overused React itself. They use CRA for every project without thinking React has a lot of pitfall.
When you use CRA for enterprise website and it used by thousand of people you need to care a lot of things for example size. Of course a project built on React has a size relatively large if you don't aware how you manage your component. You need to use technique like dynamic import or use someone package (which actually also increases the size of your app and bloated your brain), choose common package like http client, state management, etc.
Because in enterprise website we focus on how to solve the problem and serve it to user as soon as possiple and should void spend to much time for thing like i mentioned above. And that's why Angular comes for. To tackle those trap.
I'am a big fan of React and used it over two years in my personnal and office project. I did a lot of experiments which let me know how to use React more effectively and of course i can't write it here because it's too long 😂.
For the short summary React is a library that focus ONLY handle your UI not the ENTIRE app. React don't care how you authenticate user and how you do http request to your server. It's common, but React ignore it and Angular saves your work with its modules.
I think React is quite hard to master. Yes.. You can get started pretty quickly in plain js. But you can get your project into trouble very quickly if you set it up in the wrong way. Also it requires more knowledge of how everything behind the scenes works in Javascript, which is IMO pretty valuable.
Both are viable options. Which one you choose should depend on what paradigm you are most comfortable with:
There's no winning or losing, just a choice depending on preference. Even more choice if you count in Vue and svelte, which too are interesting alternatives.
I stop reading after "super easy, building beautiful...". You do favor to React before start talking about differences between them. This is not neutral opinion from the begging
The best way to write apps is lit-element wonder when it will overtake react.
Nice writeup. thank you. Can you provide/share your ressources/benchmarks for the following statement In short, React Virtual Dom is faster than the Angular Traditional Dom. and maybe also how the approch to benchmark is choosen?
tahnk you again and ch33rs
If you ask me about which one has the best engineering behind I would say Svelte probably. If you add a team like Google's Angular or Facebook's React for developing Svelte it would probably be the king.
Apart from that opinionated comment that (almost) nothing has to do with the post you may need to take a deep learning about how the things work on both react and angular to state a comparison like that. It can be an entire paper from my point of view.
I've just said that there are much differences but at high level (i.e. if a self-taught dev which has no knowledge about how the things work under the hood uses one or another) he'll find almost no differences apart from the obvious (syntax and workflow).
Framework is a detail, web is detail, database is detail, ... think clean architecture 🤐
ASP.NET Core - Blazor WebAssembly
S2