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 a...
For further actions, you may consider blocking this person and/or reporting abuse
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!
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.
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?
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!
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).
Well, this article is biased towards react as the author has minuscule experience in Angular framework. React isn't even a framework, react is very chaotic while working on huge projects, there are many libraries and are not standardized.
I have worked on React and Angular myself, I felt angular more traditional and robust. The verbosity Angular offers is great. It is easy to work on multiple Angular projects for multiple clients, everything seems so familiar and structured.
Framework is a detail, web is detail, database is detail, ... think clean architecture 🤐
ASP.NET Core - Blazor WebAssembly
S2
React it's not "winning", they are just different.
If you check the FE framework usage for web agency's I'm pretty sure that angular is inexistent...
Things changes if you compare framework's on large companies, angular it's a giant player here.
Please stop evaluating the success of a project by the number of stars/download's, they are not the real world.
Wait until you know Svelte...
Angular is harder to learn. For big apps I think angular shines tho
Keep sharing!!
React does have a state management built-in and you don't necessarily have to use an extra state management library :)
NIce article, but I don't understand the point of such articles. There are so many such posts and in my opinion, there's no point repeating the same thing.