React is a library and Angular is a framework, so the comparison is not fair
Correct, and that's the whole point. As to fair, it's irrelevant, the question I am trying to answer is which is "best". 80% of the cases I illustrate in the article, Angular wins, hands down.
React the library is very purposely unopinionated, and it, as a library, was never meant to compete with a fully fledged framework like Angular
Incorrect. React is a library, Angular is a framework - However, it's not like as if we're comparing apples and oranges, since once a new project is initiated, the developers are often choosing between React and Angular - Maybe Vue and some others, but it is often a choice between React and Angular.
The problem is that your choices aren't really between React versus Angular, they're more as follows.
Angular + Material
React + a bajillion different options for x, y and z
Choice one leads to a standardised codebase, easily moved around between devs, with high recognisability. Choice two leads to purple cows, with unicorn horns, eagle wings, and elephant legs - As in never having two similar types of projects unless done by same dev, resulting in a maintenance nightmare for the company as resources quits, and/or are moved around.
As to the rest of your comment, I mostly agree, and thank you for clarifying ... :)
As to fair, it's irrelevant, the question I am trying to answer is which is "best".
Yea you just totally missed my point, it's not logically valid to compare two things that do not directly relate, especially when the better comparison exists (i.e. comparing to specific React frameworks). So no, you can't answer which is best if you are just comparing to "React" the library. Comparing React to Angular is like comparing MacOS to the Linux kernel. A high-level OS (Angular) just doesn't compare to a small, subcomponent piece like the kernel (React library) because they intentionally are designed to be different solutions to different problems (even though they are definitely in the same realm of related concepts). We compare MacOS to Windows because that's a more fair comparison as their purpose/use-cases directly align.
However, it's not like as if we're comparing apples and oranges, since once a new project is initiated, the developers are often choosing between React and Angular - Maybe Vue and some others, but it is often a choice between React and Angular.
I am saying developers/people who just say "choose between React/Angular" are incorrect to ask that in the first place as it's a framing fallacy. That is not the right question to ask yourself when choosing a framework. I think the better way of phrasing this is "should we choose between Angular/NextJS/Remix/CRA."
I guess the main gripe is the lack of qualifiers and the overgeneralizations you make when referring to React. Like "React ecosystem" maybe more accurate to what you're trying to get at, and even then I think you're straw manning React because you are not specific about what particular area of the React ecosystem you're referring to (which is why I just recommend comparing to other React frameworks).
(read other comment first)
Let's take your points as example of why I think you're overgeneralizing:
you'd need to install dozens of components before you can even create a simple HTTP request and show a freakin' date picker
What? Absolutely not! Just use fetch(), you don't need other dependencies or components. Want a Date picker? Style it yourself. Want an out-of-the-box styled date picker, yea sure, install MaterialUI as a dep, if you want to look like Google (not everyone wants to their website to look like Material Design btw, I don't see that as a plus for Angular if you aren't adopting Material, and if you're overriding it, that's just the same amount of effort you'd have when overriding custom theming of a component library in React, thereby being no different).
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
Honestly besides having a single UI component library (that Angular Material is comparable to), I don't see most projects installing tons of different components. In fact, within a particular framework, I extremely frequently see the exact same libraries being used, and even if there are different ones being used (i.e. state management libraries), they all share the same fundamentals these days (i.e. hooks and unidirectional data flow patterns). And I have seen two Angular projects with wildly different state management usages and practices! I disagree than Angular is somehow immune from different projects doing things differently, I see it all the time. The framework doesn't prevent people from writing different, non-standard, or custom code or installing different libraries.
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 organized
This is just not the case for the React frameworks. NextJS and and Remix, for example, are pretty prescriptive on how you organize the projects. But even granting your point, that is the whole point and difference of opinion (i.e. there is no right or wrong answer) to how you should structure your particular front-end project. Not all web apps have reason to look identical, there are wildly different scopes and scales of projects out there, and some do not need to overhead of strict organization than Angular may recommend.
each React developer has his own favorite HTTP client
Yea I'm not even sure what HTTP libraries you're referring to - like besides built in fetch() and something like Axios, what do you mean everyone has their favorite HTTP library and how does that relate and actually a downside of React?
he's got his own favorite widget library
Yea, people have different favorite UI/design component libraries because people have different taste in design. Not everyone wants their website to look like Google. Just like CSS, there's tons of ways of doing the same thing differently, what's wrong with that?
he's got his own favorite "whatever" library
Again, what's wrong with this? Can people not have opinions on dependencies they like to use? Why is it a problem that that people do styling differently, that they use different state management libraries, and that they like to install different helper libraries to do things. Like what's wrong with people having their own preferences? Lack of consistency -- ok choose a more prescriptive React framework like Blitz. Also, just adding "favorite 'whatever' library" to your list of problems you have with React is not helpful because what do you mean "whatever"? Be specific! It almost sounds like you haven't ever been in a modern React project when you're not specific in what you don't like about React and you don't show evidence.
you'd rarely find two codebases with similarities at all
Within the same React framework, you absolutely, 100% find React codebases that look the same. That's my whole point. Just compare Angular to React frameworks in the first place and then we can discuss. You point is moot to just say "React isn't consistent" when that's an obvious statement because different React frameworks are different just like they are different when compared to Angular.
And I think you are only considering folder structure or file structure or something, because 90% of React is very similar everywhere I have looked. JSX is in all the projects. Components are the UI building blocks. Hooks are the data-building blocks. Contexts/providers are used for state management (the state management libraries use the same feature under the hood feature, they just may differ slightly in how they are consumed and how they scale, which is totally fine, because different projects have different needs for scale and complexity so there is no one right answer). Uni-directional data-flow and event/call-back driven data models are always the same. Composition patterns are consistent. Prop passing patterns are similar and transferrable. Yea I quite frankly don't know what evidence you have to suggest that React projects are all wildly different in some of these fundamental building block elements. Yea structure changes between frameworks, but most of modern React is totally transferrable between projects (I know this because I've experienced 5 different production grade React projects).
resource management at a "React company" becomes much more rigid
Not true within the context of a particular React framework.
most Angular projects ends up looking similar
This must be anecdotal experience (which is not an argument/confirmation bias), because the Angular projects I have seen do NOT all look the same at all. I definitely believe that they look the same within your company and the companies you've worked for, but I also have worked for these standard/non-tech companies with low priority on development, and yea, I see Angular projects that are not consistent. Angular is not immune to that at all.
regardless of whether or not React is objectively "better" than Angular
which of these two frontend libraries/frameworks are better technically, is at this point completely irrelevant
Getting mixed messages from these statements -- are you actually making a value judgement claim about Angular or not? I also agree the technical performance aspect of the two is very irrelevant for comparing. And I also agree React frameworks nor Angular as a framework are objectively better than the other, yea. That's exactly what I have concluded about the tens if not hundreds of web frameworks out there - they all are unique, different, and none of them are objectively better than the others at this level of generalization. Only with specific constraints and circumstances can you make such bold claims when comparing frameworks.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Correct, and that's the whole point. As to fair, it's irrelevant, the question I am trying to answer is which is "best". 80% of the cases I illustrate in the article, Angular wins, hands down.
Incorrect. React is a library, Angular is a framework - However, it's not like as if we're comparing apples and oranges, since once a new project is initiated, the developers are often choosing between React and Angular - Maybe Vue and some others, but it is often a choice between React and Angular.
The problem is that your choices aren't really between React versus Angular, they're more as follows.
Choice one leads to a standardised codebase, easily moved around between devs, with high recognisability. Choice two leads to purple cows, with unicorn horns, eagle wings, and elephant legs - As in never having two similar types of projects unless done by same dev, resulting in a maintenance nightmare for the company as resources quits, and/or are moved around.
As to the rest of your comment, I mostly agree, and thank you for clarifying ... :)
Yea you just totally missed my point, it's not logically valid to compare two things that do not directly relate, especially when the better comparison exists (i.e. comparing to specific React frameworks). So no, you can't answer which is best if you are just comparing to "React" the library. Comparing React to Angular is like comparing MacOS to the Linux kernel. A high-level OS (Angular) just doesn't compare to a small, subcomponent piece like the kernel (React library) because they intentionally are designed to be different solutions to different problems (even though they are definitely in the same realm of related concepts). We compare MacOS to Windows because that's a more fair comparison as their purpose/use-cases directly align.
I am saying developers/people who just say "choose between React/Angular" are incorrect to ask that in the first place as it's a framing fallacy. That is not the right question to ask yourself when choosing a framework. I think the better way of phrasing this is "should we choose between Angular/NextJS/Remix/CRA."
I guess the main gripe is the lack of qualifiers and the overgeneralizations you make when referring to React. Like "React ecosystem" maybe more accurate to what you're trying to get at, and even then I think you're straw manning React because you are not specific about what particular area of the React ecosystem you're referring to (which is why I just recommend comparing to other React frameworks).
(read other comment first)
Let's take your points as example of why I think you're overgeneralizing:
What? Absolutely not! Just use
fetch(), you don't need other dependencies or components. Want a Date picker? Style it yourself. Want an out-of-the-box styled date picker, yea sure, install MaterialUI as a dep, if you want to look like Google (not everyone wants to their website to look like Material Design btw, I don't see that as a plus for Angular if you aren't adopting Material, and if you're overriding it, that's just the same amount of effort you'd have when overriding custom theming of a component library in React, thereby being no different).Honestly besides having a single UI component library (that Angular Material is comparable to), I don't see most projects installing tons of different components. In fact, within a particular framework, I extremely frequently see the exact same libraries being used, and even if there are different ones being used (i.e. state management libraries), they all share the same fundamentals these days (i.e. hooks and unidirectional data flow patterns). And I have seen two Angular projects with wildly different state management usages and practices! I disagree than Angular is somehow immune from different projects doing things differently, I see it all the time. The framework doesn't prevent people from writing different, non-standard, or custom code or installing different libraries.
This is just not the case for the React frameworks. NextJS and and Remix, for example, are pretty prescriptive on how you organize the projects. But even granting your point, that is the whole point and difference of opinion (i.e. there is no right or wrong answer) to how you should structure your particular front-end project. Not all web apps have reason to look identical, there are wildly different scopes and scales of projects out there, and some do not need to overhead of strict organization than Angular may recommend.
Yea I'm not even sure what HTTP libraries you're referring to - like besides built in
fetch()and something like Axios, what do you mean everyone has their favorite HTTP library and how does that relate and actually a downside of React?Yea, people have different favorite UI/design component libraries because people have different taste in design. Not everyone wants their website to look like Google. Just like CSS, there's tons of ways of doing the same thing differently, what's wrong with that?
Again, what's wrong with this? Can people not have opinions on dependencies they like to use? Why is it a problem that that people do styling differently, that they use different state management libraries, and that they like to install different helper libraries to do things. Like what's wrong with people having their own preferences? Lack of consistency -- ok choose a more prescriptive React framework like Blitz. Also, just adding "favorite 'whatever' library" to your list of problems you have with React is not helpful because what do you mean "whatever"? Be specific! It almost sounds like you haven't ever been in a modern React project when you're not specific in what you don't like about React and you don't show evidence.
Within the same React framework, you absolutely, 100% find React codebases that look the same. That's my whole point. Just compare Angular to React frameworks in the first place and then we can discuss. You point is moot to just say "React isn't consistent" when that's an obvious statement because different React frameworks are different just like they are different when compared to Angular.
And I think you are only considering folder structure or file structure or something, because 90% of React is very similar everywhere I have looked. JSX is in all the projects. Components are the UI building blocks. Hooks are the data-building blocks. Contexts/providers are used for state management (the state management libraries use the same feature under the hood feature, they just may differ slightly in how they are consumed and how they scale, which is totally fine, because different projects have different needs for scale and complexity so there is no one right answer). Uni-directional data-flow and event/call-back driven data models are always the same. Composition patterns are consistent. Prop passing patterns are similar and transferrable. Yea I quite frankly don't know what evidence you have to suggest that React projects are all wildly different in some of these fundamental building block elements. Yea structure changes between frameworks, but most of modern React is totally transferrable between projects (I know this because I've experienced 5 different production grade React projects).
Not true within the context of a particular React framework.
This must be anecdotal experience (which is not an argument/confirmation bias), because the Angular projects I have seen do NOT all look the same at all. I definitely believe that they look the same within your company and the companies you've worked for, but I also have worked for these standard/non-tech companies with low priority on development, and yea, I see Angular projects that are not consistent. Angular is not immune to that at all.
Getting mixed messages from these statements -- are you actually making a value judgement claim about Angular or not? I also agree the technical performance aspect of the two is very irrelevant for comparing. And I also agree React frameworks nor Angular as a framework are objectively better than the other, yea. That's exactly what I have concluded about the tens if not hundreds of web frameworks out there - they all are unique, different, and none of them are objectively better than the others at this level of generalization. Only with specific constraints and circumstances can you make such bold claims when comparing frameworks.