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 !
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 fetch is 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.
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.
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.
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 :)
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.
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 ... :)
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
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.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
@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.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
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?).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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 ...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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.
Does fewer choices compensate the lack of being able to choose the right tool for each job?
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.
tech decisions are not made only from the tech point of view
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 ...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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.
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
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 ...
I definitely need to check the quality thingy, I'll come back if I get an answer on that
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;
How many hours will it take to train my staff for the new app?
How is the recognisability factor of the app, and what effect does it have on context switches as my back office workers are switching between apps?
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I am talking about manpower required to maintain the project, not CPU and RAM
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).
Quality from a business perspective might for instance imply;
1. How many hours will it take to train my staff for the new app?
2. How is the recognisability factor of the app, and what effect does it have on context switches as my back office workers are switching between apps?
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.
developing in React is faster than using Angular (according to my experience as dev and as TL)
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 ...
Those seem design factors to me and not related with the tech stack used
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 ...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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
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).
Not correct. All Angular apps (assuming they're using Material) ends up more or less the same...
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
If the app spend 0.4 seconds or 0.8 seconds to initially load is irrelevant.
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).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
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 ...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Speaking more seriously with the same guy that's what I can extract:
Depending on the niche you'll find more Angular than React devs.
Sometimes there's a company with projects already made with Angular so they want the same stack on following projects.
It's happening a new wave of React projects (the pandemic increase is being reflected into the market thus the amount of React projects and clients that prefer React are increasing as well).
This increase in React projects in big companies also retro-aliments the community (which makes sense).
Some of projects that require a framework are now being made with Next, which is chasing Angular.
Depending on the country you'll find more people that is used to Angular than React or vice-versa (so that's a point to check if you need new devs with Angular for any new project in Aista 😁).
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?
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.
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 !
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.
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.
Bingo! Thank you. No further questions ... ^_^
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:
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 ... :/
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!
Exactly