To understand the above sentence you'll have to read the whole article, and in fact you need to understand how most developers are working too. First of all, "most developers" are working for companies having software development as a secondary function. Some examples here are insurance companies, banks, hotels, hospitals, etc. These are companies who fundamentally don't care about software, but need software to optimise their processes and fulfil their primary objectives.
These companies typically have large turn over, and the average employee rarely works at the same company for more than 2 years. This implies that once every 6 to 12 months, a new developer starts working for the company, and need to understand the existing code base to become productive. In addition, 80% of these company's software projects are back office administration apps, not visible for customers. Examples are CRM systems, ERP systems, etc. With that in mind, let's go through how React and Angular is typically used at these companies.
How Angular is used
When you start out a new Angular project, the process is fairly straight forward. You make sure you've got the latest version of Angular, you install Material, and you start implementing your design. Each individual project therefor has a similar structure and largely uses the same components. This implies that every project becomes similar in structure, have similar components, and typically very similar markup and code - Assuming the Angular developer knows what he or she is doing. Maybe you'll need a handful of custom components for your project, but in general if you've seen one Angular project, you've seen "all" Angular projects.
How React is used
If you did the same exercise with React, you'd need to install dozens of components before you can even create a simple HTTP request and show a freakin' date picker. Every single time you install a new component, you have a myriad of choices, resulting in that you'd rarely find two different React projects using the same set of components and plugins. The structure of the project is much more left up to you as an individual developer in regards to how you want your code and project to be organised.
The problem
The above differences implies that for the most parts you can replace any Angular developer with any other Angular developer, and after an investigation phase of maybe half a week, your replacement is equally productive as the person who worked on the codebase originally. This results in an "agile organisation", able to easily move resources around between projects, without needing a longer learning period as resources are moved between projects.
With React the above is simply not true, because each React developer has his own favourite HTTP client, he's got his own favourite widget library, he's got his own favourite "whatever" library, resulting in that you'd rarely find two codebases with similarities at all.
So regardless of whether or not React is objectively "better" than Angular, it's already lost at this point, since resource management at a "React company" becomes much more rigid, and you're much more dependent upon individual resources, whom are more difficult to move around and replace if needed. You have created an unnecessary "dependency" from a business perspective, where you're much more dependent upon individual contributors, and you've got less flexibility as a company.
In addition to the above, most Angular projects ends up looking similar. For a company having dozens of in-house developed back office administration applications, this is an advantage, since back office workers used to one app, can easily understand all apps. With React this is simply not the case.
So really, which of these two frontend libraries/frameworks are better technically, is at this point completely irrelevant. As long as Angular performs at least somewhat "close" to React, the technology behind, and its ability to perform, is no longer important for you as a company.
NOW you can comment and disagree with me ... ;)
Edit - This is why we're exclusively using Angular at Aista.
Top comments (137)
I disagree :D
A software project is not only about managing dependencies.
Furthermore, with current versions of React and vanilla es2021 you don't really need anything else. For xhr, fetch is sufficient. Let's say a CSS framework (as when you add angular material) if your company does't maintain one. Let's add a router and that's all !
And after you've done what you propose, your project probably ends up with a unique structure, implying there's a cognitively larger and steeper learning curve to understand it, then if you had chosen "the standard Angular solution". Henry Ford, arguably "the father" of automation was so obsessed with standardisation and time2market that he refused to paint his cars in any other colours then black. His argument was that black would dry in half the time as any other colours. If you need to spend only 30% additional time to maintain a React project than an Angular project, you're a "dead stick in the water" in the context I presume in the article's main text.
For a company with software development as a secondary function, technology is irrelevant. What is relevant though, is ease of use, and cost of maintenance. Angular wins hands down on both these two parameters ...
However, you're of course allowed to disagree ... :)
Angular + Standards and then blaming React... I may lost something in the road but in React I use standard things except for the JSX while in Angular not even the templates are standard.
To drive a React project you don't even need people that "knows" React, people that knows HTML, CSS and JS is enough, understanding hooks (which are just HoF) and a couple of concepts of FP is enough to go ahead properly.
Can you please clarify?
Also I'd like to know where in this comparison Next, Vue and Svelte will sit in your opinion.
thank you
The general principle is that the fewer decisions you have to make, the better it is.
Less is more because the paradox of choice makes you les productive and happy when you have too much of it.
If you have n binary decisions to take, that's a 2^n combinatory explosion.
Frameworks that have made by default a reasonable choice on most common topics are exponentially better than frameworks that gives you infinite flexibility.
For example git can do everything but following the GitHub programming workflow is much more efficient.
Can't speak about the specifics of JavaScript frameworks, not my field.
Yup! So true. And others have "different standards" - Check out Jean-Michel's comment for further clarification ...
As a general rule of thumb, the less choice the better ...
@jmfayard is not a matter of coice because you like one thing more than the other.
We usually use a minimal approach with that.
Start a project with the less you need
i.e.
React, ReactDOM, Styled-Components (for styling) and Jest (for testing).
Then add things JUST when you need them, because you can't predict every need you'll face on the major part of projects, this way you avoid adding a bunch of things that you may or may not use.
Furthermore when you face a specific need you can choose the right lib (or custom implementation) that better suits this specific need and/or use-case.
There are 61702 packages tagged with "Angular" in NPM so I guess you'll need to bring this kind of decisions in Angular projects as well. It can be less amount of them or the same depending on the specific project and it will happen whenever Angular core API doesn't provide the exact tool to suit your needs.
To clarify, are you saying that my principle doesn't apply in React vs Angular (possible, no opinion from my side) or are do you disagree with my principle (and why?).
I'm saying that to some extent you'll need to take decisions either be one or the other and that a minimalistic approach adds less burden to the project overall.
The decisions about which dependencies we should add to the project are made -in our case- by the TL (which is me in this case) regarding the technical nuances of the project, the environment, current needs, future roadmap and lib's dependencies while checking for security concerns (known bugs/security issues...).
Also we'll do a PoC with that hypothetical lib to ensure full compatibility and to define how it should be used to avoid weird implementations (which I saw whatever the language and tools are used).
Angular is not agnostic to this kind of issues ( first example I found ) thus my PoV is that it isn't that "good" and/or it doesn't release you much of this "burden".
Angular is (obviously!) not "perfect". Every time I need to upgrade something, I cringe from fear of breaking something. In comparison, NuGet (.Net) is a breeze compared to npm. However, you have to make a lot fewer choices when using Angular than React. Which is Jean-Michel's primary argument here, and also mine too, since fewer choices equals higher amount of standardisation, leading to more easy recognisability for others, etc, etc, etc - Basically a good spiral upwards ...
Yes it is like that in most cases, agree with that
My question though goes through a different path: Does fewer choices compensate the lack of being able to choose the right tool for each job?
I've worked on a couple of projects with Angular and it was fine but speaking of frameworks I do like Next more from the dev point of view (flexibility, fine-grain the results regarding the needs...).
In most companies we standarize some sort of libs to use and when something is more convenient to a project we simply add them as option, so you'll end up with few options (or just one) whenever you want to fill a need. On the other hand, JS core API is quite good for quickly overcoming needs without the need of libs.
This requires iterative checking and it's some burden but it's mostly decoupled of the devs day to day job (devs can suggest whatever they like, then everything is checked, including the license of course and added or not whether it's convenient).
By the way the "current" situation is a lack of available human resources aligned with a high demand and React is known by much more people (and is way easier to learn), which makes it a good choice.
On the other hand Google did deprecate AngularJS once ... vad vibes 😆 it was a good decision for several reasons back those days of Angular2 but the big G has a big graveyard of projects and I wouldn’t risk my neck for they not doing it again.
TLDR; tech decisions are not made only from the tech point of view.
Wrong question, it's like asking if your car is married. The correct question is; "Does fewer choices leads to higher quality, better performance, and less resource requirements?" - At the end of the day, the only thing the companies I am referring to in the article care about is quality, time2market, and resource requirements.
Correct, and once realising that, what the individual developers "feels is better", and or "wants to use" becomes irrelevant. Standardisations will force itself unto us, one way or another, and as it does, less power to the individual developer, and more power to the business decisions makers are a natural consequence. The only reason why business even cares about what devs "wants" is because they're terrified of devs quitting. That is a "local evolutionary optimum" destined to end, sooner and not later - Like it or not ...
Hmm nice PoV, I've not enough data to answer this, would need to check whether Angular projects have more quality than React ones through different metrics.
On performance and resource requirements I'm confident saying NO, Angular produces heavier applications due to the many features of this framework, that can burden projects, translating into a heavier application with slower performance. I've tested it a couple of times; I prefer the minimal approach I explained before just for that reason.
I definitely need to check the quality thingy, I'll come back if I get an answer on that.
If the app spend 0.4 seconds or 0.8 seconds to initially load is irrelevant. When I speak about resource requirements, I am talking about manpower required to maintain the project, not CPU and RAM. The latter is (for the most parts) no longer of much interest due to Moore's law ...
Quality is erronously perceived here I presume. "Quality" from a business perspective is rarely the same as quality from a software developer's perspective.
Quality from a business perspective might for instance imply;
Etc ...
My bad but still the answer is no, in my experience, the amount of devs you need depends on what the client wants, at what speed and with the budget.
Of course the answer is usually "Everything", "Now" and "as low as possible" respectivelly but I mean after a refinement and viewing it from a realistic point of view 😂
But if you want X and it requires 3 people in average it will be the same in Angular, React or whatever. The amount of people is mainly due to parallelization of tasks, on the other hand if we talk about delivery speed, developing in React is faster than using Angular (according to my experience as dev and as TL).
Those seem design factors to me and not related with the tech stack used.
If you design a bad application it will be crap either be Angular, React, Vanilla JS, Java, PHP, C or whatever 😅
I was thinking more on "how many bugs appear into production", "time to solve them" and so on.
I suspect that's a highly subjective observation. I would say the exact opposite. However, the point is that Angular projects have less differences, implying moving people around from one project to another, and/or hiring new devs is by the very definition of the term easier ...
Not correct. All Angular apps (assuming they're using Material) ends up more or less the same. For enterprise back office administration apps that is a good thing ...
True ... :)
That's undoubtedly true.
The only showstopper is the popularity of the framework. From my closest friends 5 are able to work in React but only 1 coded with Angular, counting me that's (+1 on each) 6 vs 2 and more or less the same can be observed in new hires. For each 10 frontend devs, ~2 have used angular.
To some extent it also has been recently (since the beginning of the pandemic) influenced on juniors due to the rise of several tens of codecamps teaching MERN stack around the world (see the increase in npmtrends).
My bad, I meant the product design.
If you decide to have a button here or there, to have a 4 step process to reach some functionality instead on optimizing it to 2 (if possible), how many features it will have, how they interact between each other, which are the user journeys... and this kind of things.
On the other hand if you use Material and don't put a hard work on editing/overriding Material components it will look pretty much "stock" (Using a pre-built theme). Changing the colors for the corporate ones in the config neither make it an application designed for the purpose so you end up using Sass API to style as much as you can and then Overriding styles (bad yada yada) because it wasn't enough.
Contrary to that if your app is meant to be used in-house (corporate) which is the target of every single Angular App I worked in, using Material is a straightforward way to deliver considerably faster and lowering the maintenance (if you are able to say "that's not possible" when the designers want something that's out of Material's capabilities).
Earlier I forgot to mention that
This is not applicable to public web apps. It has been well proved that lowering load and response times increases conversion rates. After checking, @angular/core alone weights 76.2 kB kb (minified and GZIPed) which is ~2 times React's entire weight (~40k).
Worth mention, If you need SEO I'd rather use Next JS (79.46 kB) for the SSR and SSG thingy and/or if I need to code a monolith so I've Node and React in the same place, lightweight and smooth (a good option for PWAs as well).
Is this true? I know React is more popular, but I suspect the above is slightly inflated ...
Of course not, my bad, I should have specified back office apps ...
Well It was said by a colleague that usually handles tech interviews, I don't know if he was exaggerating or not and
if yes, to what extent 😂
The last figures I saw was that React was 1.5 times as popular as Angular. These numbers are a bit old, and I know React has a lot of momentum though, so things might have changed since then ...
Thank you :)
Speaking more seriously with the same guy that's what I can extract:
Bingo! Thank you. No further questions ... ^_^
People inexperienced in driving large scale product implementations may not realise the point made here. For large enterprises software is a tool to derive profit. Angular definitely knocks out a lot of contentious issues. React is like core Java. Spoilt for choices. For enterprises what matters is what gets the job done. It doesn’t matter if it’s the best breed as long as it’s above average.
Word!
Well i'm not that sure... Angular is highly verbose, so you'll have to maintain a larger codebase. Besides, the heaviness of angular come with a cost when you have to update your dependencies every 6 months (even if it's adds consistent in dependency management). And have you include the cost of migrating from AngularJS to Angular2 when Google guys decided to break compatibility?
That would be an argument for legacy code bases, not for decisions related to starting out a new project - However, yes, that was a nightmare ... :/
I clicked "like" but what you say isn't true ... well for a hobbyist it might be, but the author of the article talked about professional development at enterprises.
So, most serious apps need state management, so we'll probably add Redux (please don't get me started about cobbling together your own "poor man's Redux" with Context and Hooks). Then you find out that
fetchis rather limited, so you add Axios. Once you find out that you keep repeating yourself writing Ajax calls and managing that, you'll add React Query and the like. And so on, and so forth.The problem is really that React is not a framework, but a "library". But, something like Next.js is a framework (well more so than React is), so that would be an option.
So why did you like if you disagree ? 😅
Next.js does not reduce that much the number of dependencies, excepts for routing.
In my experience, you don't need redux in 95% of projets. Axios and React Query as well (the only missing feature in fetch would be interceptors, but it's easily overcome). But the main point is even if core angular dependencies are consistent in term of versionning, you still need to add them (@angular/router, rxjs, @angular/material)... So is there so much difference ?
Well I can see that you made an effort to formulate a coherent argument, so that's why I put a like, not because I completely agree :)
I don't know what kind of projects you have in mind, but in 95% of serious apps you do need some sort of "global" state management for the whole app, i.e. above the component level. Whether you do that with Redux or in another way is a different discussion (don't tell me that you don't need Redux coz you'll do it with Context and Hooks, lol) - the point is you'll need some sort of state management other than component level "setState".
Axios, yes okay, you can emulate all of its features with
fetch, so if you want to be super minimal on bundle size you can skip Axios.But state management, in my experience you'll need it not in 5% of the cases but in 95% of the cases. No idea where the Redux hate comes from, TBH.
But what exactly was the debate about again?
ROFLMAO :D
I was just joking don't worry.
Global state is kind of a antipattern in React, excepts for user preferences or authorization it should be use with extreme care. I saw many projects starting with redux for no specific reasons which involve overengineering and maintenance issues.
Not sure what was the debate 😅
That's good, I like jokes as well :)
I agree that you shouldn't start with Redux per se, but if you do some prior analysis then in most cases it's simple to find out whether or not your project will benefit from global state management.
But, what's funny about us having this debate is that we're lending credibility to the author's narrative that Angular is "better" - because, apparently, in the Angular world they don't need to have these kind of debates :)
Sure, damn angular users 😁
I'm a fun of React but the fact that you take theese decisions is a confirmation of what said in the article. To change this fact an official voice should collect all standards "the-facto" and promove an official way of how to do apps with React. For example Next.js It moves in this direction.
Exactly
I think you made a very convincing argument for the limited and specialized use case that you're describing (building internal apps at a company/enterprise) - as soon as this company is building a public facing app, then the discussion already changes.
P.S. the whole point is that Angular is a framework, React is a library, so you could say it's bit of an apples-to-oranges - comparison - a more apples-to-apples comparison would probably be Angular versus Next.js?
Yes, bit it's the by far most common use case I have seen in my life. And 80% of the world's software developers are in similar positions as me, so instead of claiming it's the "special use case", I'd say it's the "general rule of thumb".
That's true. I'm not entirely convinced the argument changes enough to justify React, but here I'm on slightly more shaky grounds I admit ...
As to apples versus oranges? Devs typically choose between two things when they start out new projects; React and Angular. Even though Angular is a framework and React a library, I don't really agree here. These are two different competing technologies where users choose one of them when starting out new projects.
You made a (very) convincing argument for the use case that you state, however the title of your post ("Angular is almost always better than React") is of course a little bit click bait, lol ... it should have read "Angular is almost always better than React for building internal enterprise apps", but well that's not going to generate the clicks & views and comments that it generated right now, so I don't blame you haha ;)
What has bugged me about React for a long time (so I'll give you that as well, no doubts there) is that React is definitely NOT "batteries included", and that everyone seems to be endlessly reinventing the wheel.
Case in point: we have Redux as a mature state management solution, but no, we get dozens of articles how it's "better" to build your own Redux using Context and Hooks (hint: false claim, it isn't "better" at all).
That's very telling when it comes to a certain mindset, and at some point it induced huge "React fatigue" in me. I'm now back to being interested again in React, now that it has matured and there's a bit more of "de facto" standards, but please React people, can we stop reinventing the friggin' wheel? It's a waste of time.
P.S. something like Next.js might be a candidate for the 'framework' that we need - another good option is to use Redux Toolkit - I think if you combine these parts then you have a pretty complete and mature solution which could compete with Angular:
Just declare it "the React standard" and get it over with, lol. You need SSR then choose Next.js, and again done & dusted.
Shhh ... ;)
Sure, the header could have been more correct, but it's not incorrect either ...
I suspect that train has left the station, but I might be wrong ...
This article is pretty much an exact summary of why I chose angular as the platform of choice for the company I work for. People always bring up the fact that other platforms provide better performance than angular. In many cases this is true. But companies that use software in support of their main business, don't always need the increased performance. Human resources are usually more expensive than losing out on other performance increases.
Thank you Shmuly :)
This is the exact reason why we choose Angular as our primary goto tool ourselves, and also produces Angular code in our data grid generator ...
The question that is nagging away at me is are you measuring the right human resources? In internal applications, the cost of the human resources of the developers is (hopefully) dwarfed by the cost of the human resources of the users. So if the application is markedly slower in use, or clunkier because a component had to be written in house, rather than taken from a pre-written library, in a way that absorbs more of the users time, that could work out far more important.
I've never coded in either React or Angular, so have no horse in the race, and don't know whether there is significant difference in the proportion of the application that would typically have to be written in house.
Actually, many of these enterprise in-house applications are typically used by a handful of people, so the word "dwarfed" is probably slightly exaggerating, but obviously yes, that's a valid point, and I touch upon that in other comments here, where I say that "the fact that all Angular apps typically ends up similarly in UI and UX is an advantage since once the user has learned one app, the user has effectively learned all apps, and the context switch requirements between different apps created in Angular is hence smaller than the context switch requirements if these apps were created in React" (roughly ...)
I suspect this is a problem that's not more frequently happening in Angular than React.
I worked in Angular for four years before moving over to React. What I found was a breath of fresh air. React is not perfect, but Angular is an inherently hazardous architecture to lean into.
The main feature of Angular that you lean into is standardized ecosystems. I have no qualms with standardized ecosystems, but it's everything else about Angular that make it a bad technology and that nullify the advantages of standardized ecosystems.
The core problem is that Angular requires so much boiler plate code to maintain it's standardized model that sending a seasoned Angular developer out to understand a code base just takes more time than sending out a seasoned React developer to a modern React code base.
First reason: simple use cases require obtuse tooling that average Angular developers aren't familiar with. In general the component API has several different flows for getting and managing data and events. If you told an Angular developer to make you a button component, 9/10 times your developer would make you a standard @Component which forwards an onClick event from the template directly. This means it inherently fails to scale. Rather than creating a button selector like
my-button, they were supposed to create a selectorbutton[my-button]as is done in Angular Material. But why use that, when @Directives exist? Because you can't add style sheets and templates to a @Directive. Then why use @Directives at all? Oh because you can't put more than one type of this @Component selector on an element. So if your team wants a standardized button component that wraps the @Angular/material button... well that's not really something you can do in a scalable way.React doesn't have these arbitrary rules and different types of APIs. A fully featured and scalable button component uses the same component API because props (React's version of @Input/@Output) are just an object, so you can just use JavaScript spread (...) syntax. Angular hides this complexity from developers, behind rarely used APIs of the framework.
Second reason: performance. React performance is nothing to write home about. In fact, if performance is a primary requirement for you then I recommend you look to other options like SolidJS. But what I can say for React is that state updates in React are intentional and puts the developer in control. When you need to update a piece of state you run some kind of setState update. Angular on the other hand is an absolute mess of automated internal event handlers and proxies. The ZoneJS library is itself a nightmare, not even to mention NgZone that maps it to Angular. I've never worked on an Angular application that didn't scale to the point of having to have it's change detection turned off. And you'll notice this happens with every major library. This is indicative of the authors of Angular knowing it's bad and having to write special use cases to make Angular work at scale. This is not standardization, it is the opposite of standardization.
I can talk all day about why Angular is bad but I will leave it at this third reason: Google knows Angular is bad. Google has made two other frameworks which follow Reacts patterns exactly: Flutter follows the same patterns as pre-React@16 class components where you have a render method on each class that returns an object tree and rerenders are managed by a state update method. And then there's Jetpack Compose which is so outright similar to modern React that here's a 1:1 mapping of almost all React patterns as they are implemented in Compose. Google could have leaned into a technology like Angular + NativeScript for mobile development, but they made a choice not to do that.
React has 11m installs this time last year on NPM, now 16m, 45% growth. Vue 2.4m to 3.3m, 37% growth. Svelte 170k to 340k, 100% growth. SolidJS 15k to 37k, 146% growth. Angular 2.5m to 2.9m, 16% growth. In no way should popularity dictate tech decisions but looking at popularity is indicative of looking at overall tech decisions made in the industry. It's obvious that the tech industry is choosing Angular less often year over year and it's worth considering the reasons behind that.
Great points. One detail though; JavaScript is the by far worst programming language in the world, still the by far most popular language. If popularity was a measure of quality, we’d still be coding VB6 using WinForms … 😉
One more detail; If you’re creating your own button in Angular, you’re probably doing something wrong … 😉
Not a front end dev or a project manager but I completely agree.
Less is more and people should Google "the paradox of choice".
I once heard a scientist more or less explain why Americans are 60% over weight, which is because as you go to SafeWay, you get 176 choices of salat dressing ... ;)
You could become fat easily when each time you go for a salad, the waiter forces you to order an entree, a dessert, some cheese and a glass of wine
(Just trolling, you got my point 😁)
Hahaha :LD
Drinking red wine is good for your health.
Ok, this has been debunked on the scientific level,
on the ground that the main factor is that France has universal healthcare and the US doesn't.
But I choose to belive it anyway :)
ROFLMAO :D
Me too ...!! ^_^
Agreed - so choose a React framework that makes more prescriptive choices for you!
Anyone who disagrees here has never maintained a big project written in React by someone else, and on which, over time, several developers have succeeded.
Word! I'd like to repeat myself here ...
As someone who is more of a React dev but also has some experience with Angular and others I agree with your point. Lack of standards and flexibility is a double-edged sword for react apps.
It gets even worse when instead of using some popular library for some common problem they go with “we will make our own solution”. And this “solution” at least in most cases I’ve seen after a couple years later turns into “there is some shitty, undocumented piece of code some guys that don’t work here anymore wrote and we can’t just refactor it because all of the project is dependent on it and if we change something in there, many unforeseen bugs may come up”. So new functionality is being piled up on that as they go making it even worse.
Now that being said I’ve also seen similar situations in Angular projects I worked on (which aren’t that many) where the devs have just completely missed the point of some pattern and butchered it in such a way it’s just unbelievable. But of course I’m sure there are good Angular projects and developers.
My experience in all Angular or AngularJs projects: developers didn't know the standards + didn't "have time for search for the patterns of Angular". Outcome: crazy custom convoluted patterns and solutions doing what Angular already does (with their standards), so they ended up under using Angular. With workarounds including creation of handful useless files, like empty services, providers, views, controllers or whatever Angular likes to call them.
My feeling: Angular is a crap that forces devs to create 25 files for a "hello new page with i18n and infinite scroller and a custom layout".
But of course, that was my experience with lousy Angular developers. Because they were not Angular developers but "full stack developers" with PHP or .Net background (No JS background, of course... so you can expect a lot of "class" objects). Angular is as bad as the developers implementing it.
The difference with React, in my opinion, is that React is a library that extends JS with HTML (JSX) and extends JS with CSSinJS (Styled-Components). So at the end of the day I become a better JS developer (with functional programming approach, btw, because JS is not good for OOP and "this" and "class"), which will improve my coding skills.
Angular on the other hand, extends HTML with logic tricks (ng-for) which do "black magic behind the scenes" and devs can get better in Angular, but not necessarily better JS programmers (or Engineers).
I honestly prefer to become a good JavaScript developer, which will also help me to be a better programmer in any language (FE or BE), than being a good Angular developer.
Thank you 😊
Angular is a superior option. The React option started with resistance on the part of facebook and continues to tear down and recreate the code approach. Artificial inclusion of state management, reducers and premature browser rendering all part of problems with React. Add to the recent rewrite in React Hooks which forces you to throw away entire code bases and start over. React is a hot mess.
Thank you, I didn't know about these problems, I'm just another Angular dev tired of hearing "React is much better than Angular" ... :/
Angular has state managemnet too. What are you saying here?
Optional feature. I've built production grade eCommerce complicated apps that never once touched a reducer and it scaled very well.
Hmm, sounds just like AngularJS. I agree it's bad, and yet it's a problem all of web technology experiences, most importantly Angular itself.
Now I agree with this on some level. But it is worth to mention that React is not a framework. It is a library. Sooo, you know. You can't really compare these two.
Your argument is basically comparison of x custom react based self-made 'frameworks' against angular framework.
Where I agree - every React based project will be different out there in the wild. None of these are same. Thus initial burden to get into development is for juniors higher and you consume more manpower to watch their steps. It is usually not so steep learning curve as with whole framework.
Initial investment to Angular (or different framework, it doesn't matter) is initially higher - but it will make you more productive for the long run --> given that there is already decided flow in majority of the projects
Nevertheless - it is worth to know multiple approaches and technologies. So in the end it really is about how you enjoy your work and how much you are paid.
And a Scania Trailer Truck is better than a Mercedes-Benz CLA 220.
It has more horsepower, much higher load capacity, the cabin should be more comfortable, you've more visibility while driving... but is slower.
React and Angular are joining in a single need which is building user interfaces.
Angular provides a huge toolkit to tackle other needs while React doesn't.
If you need anything that's not covered by Angular API (mostly any middle to big project) then you need to come up with something custom which will allegedly differ from any other angular project. 🤷🏼♂️
I get your point though, the complexity is the same it's just that in an Angular project it's already defined how to deal with a good part of it through the framework API while in react it needs to be defined each time. That also opens the door to a more fine-grained result regarding the project needs on the other hand.
This article was written for project managers, and developers just starting out learning software development. And as the title says; "Angular is almost always better than React" - Which I still stand by, given the context the article describes ...
Notice the word "always" and the article's context ... ;)
Edit - However, when that's said, a Volvo is almost always better than a Ferrari (for the same reasons) ...