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. Fir...
For further actions, you may consider blocking this person and/or reporting abuse
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) ...
I agree with 'less choice the better' for business. The scala language was so damn fun as a developer with so many choices but bad from a business perspective as so many choices led to every code base being unique with no patterns. As a previous founder and owner and also a developer, I see why developers choose fun but the amount of choices is a BAD thing for business and TEAM/organization speed which is more important than individual speed.
I insanely agree, and my own personal favourite programming language (C#) seems to be adding 20+ new features every single year - Which actually scares me a bit ...
I completely agree with you.Angular is a complete framework for software development. And it’s pretty straight forward.I have been using Angular from last 3 years for all of my software development projects.Frankly speeking I have never thought to replace Angular with any other framework or library(like reactjs) because what ever my requirement I can easily fullfill with the Angular.
I agree with you, I've faced similar problems with react and ended up settling on angular for exactly the same merits above. Developers naturally focus on the tools they like, how they perform etc but ultimately the bottom line is the business which needs to exist long after developer x or y has left. Less is indeed more
There's a lot that could be said about this topic. I think React is sort of ironically a victim of it's own power, if you will - in the sense that because it is considerably leaner and less opinionated than Angular you naturally end up with a lot more diverging opinions concerning the 'right' approach to take. Perhaps it's correct to say that the difference between those who are competent at React and those who aren't is a lot larger than for Angular for the same reason - my impression is that in the context of a React dev team it's more important for there to be someone competent acting as a guide than there would be for an Angular team.
That being said, the comparative freedom you get with React is both a core part of it's utility and appeal. Someone who knows how to harness it will be able to consequently achieve a lot more with it than would otherwise be possible when being forced to conform to 'the Angular way.' I speak from experience also - the company I work at has an Angular app and a modern React app doing more or less the same thing and I'm familiar with both. Building the React app has has been wildly successful, and put simply the Angular app just sucks. The React app is a dream to work in, highly stable, maintainable, fast, intuitive to understand and very polished. The Angular app is none of those things even nearly.
I can appreciate that the success of it has been in no small part down to the fact that the two devs who built it were passionate and capable, and although this is just a small anecdote - the main thing for me knowing the two well is that there is simply no way we could have built a comparable app to what we have now if we did it in Angular - not even close. The freedom that React allows has been critical for enabling this.
Reading back on what I just wrote I'm worried it may seem a little subjective and I am a bit biased in a sense. My first job was writing C# for 3 years, and Angular is pretty much a front-end version of C# MVC. And if you wanna know what I think of that then judging by your OOP article we are on the same page for all intents and purposes. I've learned my lesson, not keen to be fooled twice.
Thank you for an intelligent and correct argument. Remember my context though, which was companies having software development as a secondary function ...
I can see where you're coming from but the difference really just boils down to this: React is essentially a templating library while Angular is a full-on framework.
Saying one is better than the other is not really a comparison of their respective merits in areas they both cover, it's just arguing that one covering a lot more is an inherently good thing.
And in the right context (which this post does provide) that's a very persuasive argument. In other contexts the flexibility of choice may be preferable, and for me that's fine too.
If there is one thing we may all be able to agree on is that we as a profession tend to over-emphasise the value of flexibility and choice, while understate the value of familiarity, even when it comes at the cost of flexibility.
Thank you for the post, Thomas!
P.s.: For the record, having worked with both, I'd personally choose React any day of the week, it's so much closer to the way my mind works. Which is another factor that may be worth considering, as I've also seen people "get" Angular easily and struggle (relatively speaking) with React.
Bingo! Thx Peter :)
Totally agree, every React app is different on the architecture level, so you need weeks to get familiar with all that stuff. With Angular, you just jump into the project and start coding. But the worst part of it is keeping everything up-to-date with React, because you're way more dependant on 3rd party libraries, which need to be updated and compatible with each other.
Oh, right, and TypeScript. With React you don't have the guarantee that the project is using it.
Any serious company would set up a list of usable libraries, and probably their own component library for their projects and a set of rules and guidelines on how and where to use them. If every developer can choose their libraries, dependencies and coding style, any project in any language would be a maintenance disaster.
You may have had a bad experience, but you're generalizing way too much. In a very poorly managed software department, maybe you've got a point, but then again choosing a more generic framework will only fix so much. The real problem is elsewhere.
That's true, and the problem I am illustrating is only a symptom, but that's the subject for another article ...
I don't like either of them. React used to be great when we used classes. Now everyone has to use hooks for everything and treats functions like classes when we should have just stuck to that to begin with. Absolute mess of a framework. Angular has excellent organization but I have several gripes: file hell, too many directives, bloated bundles, and webpack is awful (wish you would migrate to vite instead). I use Vue and even that's starting to suck becase Vue 3 just wants to copy react with Composition API. If I'm gonna be writing declarative code, I might as well just use Svelte; much cleaner, very light weight and simple to use
I have never really looked at Vue or Svelte, and they might be the holy grail of SPAs for all I know. However, this article wasn't about what me and you "like", it was about the sensible decision for companies when starting out new projects.
Companies have software as a mean not an end. So they might take decisions like:
Some projects doesn't follow good software design principles in their start, which could help create a set of candidates and take out the ones that doesn't make sense. I mean more like having diagrams and extension points, rather than having all the scope at first. It should be scalable in this scenarios.
I've had the opportunity to work at a company that created its own framework, maintained it and we couldn't move forward with it. It was written in Angular with the idea of forcing common practices to ensure interns wouldn't f*** things up.
You take out all of the "dev power", and trust your designs and code to a structure too simple to do what we needed.
When you block others to use different technologies you start to dive in you own code as a company and you have to fix the framework bugs, which I can tell that it takes way more time, than redoing my simple page in React as an example.
We shouldn't put the blame of bad project design choices in technologies.
It is not fair.
They all can coexist even in a company.
It takes one good Software Engineer to do it.
Word! However, this is a different debate ...
I agree. Ive found with multiple Devs, react codebases become a mess. With angular they tend to stay nice and straight. Albeit some very large components appear sometimes. As react gives more freedom it tends to lead to differing opinions on how things are done. I agree that walking into an angular project is much easier than trying to navigate a React project
you'd need to install dozens of components before you can even create a simple HTTP requestFactually and simply incorrect. You can write almost everything yourself, and hey, with React it's a breeze. I rarely need to install a 3rd party lib.
:o)Thank you for proving my point ;)
I don't need to install dozens of components, because:
If the project is happy to be built like a lego, then Angular might be a better fit
:)As someone else wrote here, the use case for Angular and React might not be exactly the same.
As a frontend developer who has mostly worked with React and would almost always prefer it as the first choice, I largely agree. Although the simplicity and unopinionated nature of React might be a good developer experience for personal projects, setting up a quick MVP, or even at start-up product with very specific technical requirements (that can benefit from a totally customized setup), that same lack of predictability can be a administrative headache at large organisations with a decent developer churn rate, and in that regard, I do concur that Angular can be the better choice in the long run.
I was the sole developer working on a project at work, where I created some good code structuring, common utilities, and development practices. That eventually led to me being assigned to another project in parallel that wasn't as well maintained, and lo and behold, it turns out to be an entirely different beast with a radically different set of libraries used, despite it still being React. Typescript was missing too, much to my annoyance. I need to maintain two headspaces for each project. Each projects's code reviews are different due to the difference in coding practices established initially.
I know that this all can be solved by a global standardisation spec across the organisation, and the projects can be migrated to that. But that's the point, it requires deliberate effort, and that standardisation will only remain as good as the diligence and commitment of most people working on it.
Working in an organisation where code quality and development flexibility are a secondary could benefit from rigid scaffolding and standard patterns of code. I believe this is more of a managerial decision than a technical one, but in the end, you need to cut unnecessary costs to have a well-paid team of developers if you're in a in industry that operates in a sector without enormous profit margins but with a well-defined frontend application requirement at scale.
Word!
Totally agree, I even shared some of the love here dev.to/ayyash/angular-a-shift-in-p...
Luvely writeup, and I (obviously) agree :)
Ah, presenting personal opinion as fact, great writing that 🤡
Hahaha, I couldn't resist, liked your comment, because of the clown ^_^
I completely agree with you.Angular is a complete framework for software development. And it’s pretty straight forward.I have been using Angular from last 3 years for all of my software development projects.Frankly speeking I have never thought to replace Angular with any other framework or library(like reactjs) because what ever my requirements are I can easily fullfill with the Angular.
Makes sense. Goes back to the whole idea that React is a library and Angular is a framework.
I also think Elm is similar to Angular in this regard since I just started learning it.
Not fair comparsion. As a React developer it is easy to follow the application struture starting from the index file. So structure is not a big deal
Anyway what makes it unfair comparsion, if we consider the structure is one factor to choose one technology and Angular is good in that. You have also to consider performance, typescript utilization, code reusiblity, SSR for SEO, community support and third parties packages for common functionalities. In fact React is much better in these factors
That's the whole point. You say it yourself, as in; "It is easy to follow ..." - If you need to "follow" to understand things, you've added cognitive requirements that are not needed in an Angular app. In an Angular app, "following" is not required, because all apps have more or less the same structure. I love the following quote illustrating the problem ...
As to ...
In backend administration apps (the use cases referred to in the OP) this is 100% irrelevant. Except reusability, which I suspect is just as good in Angular as in React ...
Edit - As to community support. Angular's community support is amazing, although React's community support might be larger. However, if you need community support, you've already forced me to "think". I don't want to think. Maybe I've got 20+ backend administration apps I am maintaining. Spending 30 seconds context switching between different apps as I jump around my codebase is 30 seconds too much ... :/
@polterguy thanks for your clear reply. I just have some concerns about that
1- if we are speaking about admin apps only, so it should be clear in the title of the post because the title is more general for web development
2- I am not underestimate Angular and its community as I used both React and Angluar and I know both are big. But flexiblity of react and wider third patries packages can help the team to solve business requirements easier and faster.
Anyway I guess in big companies they have a guidelines for boilerplate new react projects so the structure will be the same among different projects and developers can easily swap between projects. Also I think new developers always need some kind of orientation even with Angular as you have the freedom to set a strategy of what goes as components and what goes as servies for example
Finally technologies selection has different factors depend on the requirements so I am not say I will always choose react but most probably I will
I hope that make sense. Thanks
You wish ... ;)
Thank you :)
You realise that "having a plethora of libraries" is according to my argument a bad thing ...? ;)
What you've said is correct, but it is a reality that most developers are unwilling to face—a very sad reality. If you care about human beings, that is. I'm guessing humans don't much enter into your equations except as assets or liabilities.
Put plainly, your point is this: coding for enterprise is essentially slave labor. It is factory-line assembly work. The closer your devs get to unskilled labor, the more easily they can be replaced with an identical dev. No thinking required or desired.
Isn't that awesome?
In short, the enterprise benefits financially by turning the coding process into clerical work and probably paying accordingly. The workers? Meh. Who cares about them?
It's no wonder that you're "obsessed" with low-code.
This is why I'm no longer looking for work with large enterprise. Not only is the work demeaning and soul-deadening—crushing creativity and insight—but most often it is building shit that no one really needs or wants (sans massive brainwashing) and probably just helping to create the global surveillance/carceral state. And all just so some überparasites can hoard and waste a few more billions.
Sweet! No?
I'm not sure if I agree or violently object to your argument, I guess a little bit of both, but you (obviously) struck a string here. Yes, you are correct, yes it's bad, but Low-Code is here to "save us" the way I see it. Today our jobs as enterprise developers has demands that are slightly above "trained monkeys levels". Is that a good thing? Well, in order to understand that you need to look at what it leads to, and what it leads to is fully automated processes, creating most of the code autonomously, resulting in freeing up time for the humans in the equation, resulting in (I would argue) at the end of the line a better world for all of us :)
Books and creative writing didn't disappear because we automated the process of assembling books, quite the contrary, it resulted in an explosion of new types of (creative!) jobs for the world. Low-code and no-code as similar premises if you ask me ...
Read my Gutenberg article to understand the above ...
Our jobs have really been reduced to copying and pasting bugs from StackOverflow into our own codebase. This needs to end, and low-code can potentially end it ...
Key word: potentially. I, too, would love to see low-code solutions take a lot of the drudgery, copy-and-paste, code monkey work out of development. But I suspect that It will just be used to avoid hiring smart devs.
I don't think that there is a low-code tool (or that there will be) that can do justice to an application of any complexity in the hands of a layperson. For the tools to work well, they will need to be wielded by developers, designers, architects, and UX folks. The point should not be that "anyone can make an enterprise app", but that, as you say, coders are freed of the boring drudge work.
From what I've seen so far, enterprise companies don't get it at all. Not optimistic.
But I do believe that low-code can be a boon, so I have a side project (moving very slowly, sadly) to build a low-code app that uses ontologies to describe the business domain and the desired design system and then buiids an app from scratch based on that. I'll probably never get it to beta, and if I do, no one will ever use it, but a man can dream...
One of the big, big lies of consumer capitalism is that technology will make us so productive that we'll all only need to work a few hours a week to make a living, and that the work will be life-enhancing, creative work rather than soul-deadening drudgery.
Yeah. How's that working out?
Hehe, link ...? ^_^
Well, I certainly don't work only a couple of hours per week, but both me and you have jobs that would be impossible only some few hundred years ago, at which point we'd probably end up slaving on fields picking potatoes for some noble man instead of the work we're actually doing today. So I have to disagree on this one, although you do make a couple of valid points.
You should check out our stuff - It's still in beta, but we're going GA release tomorrow in fact :)
Good & reasonable explanation. I may bias as I'm loving Angular since 2019 and recently tried to convert an "ionic angular" app to "ionic react", ended up with several dependency issues React shows 😂
So what you are saying is that there are benefits to convention over configuration.
By that logic I guess everyone should move to Laravel from any other PHP framework? Or from express to Adonis?
In all seriousness, while I do like like convention over configuration angular has lost big time. As somebody else mentioned out of 10 devs, 2 have used angular before they moved on to react, vue, svelte etc.
I've seen several claims that React is 5 times larger than Angular. I know React is larger, but I'd still like to see these numbers before I believe the number is 5x. I suspect it's more like 1.5x, but I might be wrong ...
Well I'm not sure how accurate npmtrends.com can be but the first suggested search is exactly what we're looking for: angular vs react vs vue.
Now if we just go by the ratios between different frameworks, React is in fact installed 5 times more than angular.
If we add Next.js into the mix which is just a framework built on top of React its as big as angular itself.
npmtrends
Interesting ...
i get that this series is intenionally clickbaity and full of hot takes, but I fear for a lot of devs coming here in hopes of actually making a good decision.
the arguments in "how x is used" are hilariously bad and biased. are you seriously comparing using angular with material to using react without material? you dont get a datepicker with angular either, and if you want a horrible looking materialui app you can just use material-ui for react. (which is btw much better than the angular implementation).
fetchis a browser feature, so theres nothing to install there either. you CAN choose routers, and state management but there's extremely safe defaults that see more continuous improvement than @angular/core. thanks to their independence the react community got insane new approaches to things like routing, data fetching and caching that make make you gag at your oldschoolprovideRouterspinner hell. with angular you can pray that they enviously see all the new developments in other frameworks and implement a meh copy 3 years later. (self closing tags, lol)90% of what you learn with angular is fairly useless outside that framework. and while rxjs is great for certain use cases (data fetching is not one of those use-cases), in my 4 years of working with angular7+ i've only seen a handful of angular devs that actually knew how to use it properly. ts decorators are still experimental, and nobody likes to use them.
$httpis angular specific vs react just usingfetch, a native browser feature. sandboxing, IoC magic os overly complex, and not needed in 99% of cases. "everything is a service", and ngmodule nonsense forces devs to use ridiculous patterns that dont make sense for a lot of use cases. the list goes on and on...all your "pro angular arguments" boil down to "our devs are dumb as hell so they better not decide anything". if your org only ever builds "could have been an excel sheet" apps of mediocre quality, and is filled with minimum-wage makeshift devs that only work in frontend because management forced them to, yeah angular is a safe bet and can help you get mvps out the door without much thought.
but making business-critical apps that people can depend on and actually enjoy using need a much different approach to software development than "as cheap as possible"
You managed to completely miss the point, but that's perfectly fine with me ...
I disagree, for one simple reason: React is a library and Angular is a framework, so the comparison is not fair.
React the library is very purposely unopinionated, and it, as a library, was never meant to compete with a fully fledged framework like Angular.
Now, to make the comparison actually fair, compare Angular framework to the React-backed frameworks out there: NextJS, Blitz, Remix, Gatsby, RedwoodJS, and Create React App.
We can talk about how Create React App framework being the de-facto recommended framework for years has been awful for the community because it's so unopinionated, like you describe, but I think we need to be clear that the problem lies with Create React App, not React.
I totally agree with every point you made if you are referring to Create React App (honestly I bet even the maintainers of React would agree too). The failure of React to develop opinionated frameworks when the library first came out/was being adopted was a huge problem retrospectively, but now I think that is being addressed with these frameworks. Angular ecosystem not having this problem, and React having this problem for years is +1 for Angular, but I think the React ecosystem has come a super long way and IMO definitely competes and checks all of the boxes Angular checks if you adopt these frameworks/meta frameworks.
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 ... :)
(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.
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).
I Disagree.
Let me get to the root of your problem. "you can replace any Angular developer with any other Angular developer"
Every good company has their own UI library/version of a UI library and their own coding standards. So as far as UI goes components looks the same everywhere. Same goes for all the required libraries that a developer might use. Everything is standardized, so every React project in a company looks the same as every other react project. So, In a company you can replace every React dev with every other Web developer (irrespective of their stack since learning React from scratch is way too easy). This whole article wasn't thought out at all.
Where on Earth have you been the last decades ...? :D
If the above was true, I would be inclined to partially agree, however I have never seen such a company myself :)
Microsoft, Amazon, AB Inbev, Siemens. Do you need more examples?
Not one of these companies are relevant for the article I wrote. Read it once more ... ;)
Your article is relevant to the companies which are not primarily software companies but rather use software for automating the processes. Sure leave Microsoft out of this. But last time I checked/worked at AB Inbev it was selling Alcohol and was using a port of a very famous UI library for their softwares.
OK, God bless AB then I presume. Most companies are like "we need some stuff, get some devs to implement it" - 6 months later they realise the mistake they did ... :/
So React gives you freedom for creativity, Angular tight your hands?
Lack of flexibility and strict processes is a good thing. Most of "the best" songs ever written exclusively uses the Pentatonic scale. There are 12 different notes in music. The Pentatonic scale exclusively uses 5 of these, and only occasionally adds one of the other to give the music "taste".
Picasso's best period was arguably his "blue period", when he almost only used the colour blue! I can give you a bajillion examples of how lack of flexibility leads to brilliance ...
Lack of flexibility is always a good thing!
I totally second that! Angular has always been better than React. People who say otherwise are simply assholes. The whole purpose of a framework should be to simply things...but React does the exact opposite! Yes I agree with your date picker example. Not only that, you have to write a lot of unnecessary and boilerplate code even to do a simple state management in a React application.
""most developers" are working for companies having software development as a secondary function."
So your argument and opinion is based on clues that are not software companies.
Ignore that constraint, and then what do you think about Angular vs React?
As well, even if the company isn't a software company first and foremost, there should be standards. A new developer should not be able to jump on a project and start doing whatever or adding whatever they wish.
As well, you're comparing a LIBRARY to a FRAMEWORK. Two different things.
No, my argument is based upon where 80% of us works, and hence what works best for 80% of us ...
I completely disagree, Class is syntactical sugar in js , functional programming is better in react , regarding multiple packages u can choose to download packages which u like in react , while in angular by default u have to download multiple packages.
You're providing technical arguments. My entire argument in my OP was of non technical character ... ;)
Funnily enough this is the top result I got when googling "every day Angular just becomes more and more like a worse version of React". Angular's far too opinionated and it's not a question of whether you'll get burned by the fact, but when - same problem every single framework in existence forces on top of you.
That might be fine for the "software is secondary" type company you mentioned, but once you move into "we actually care about the code we write" territory a lot of your arguments start to disappear regardless of which one you choose - in the end React apps -are- more or less the same: you'll probably use redux for state management, some wrapper around
fetchfor HTTP that, say, integrates with React's hooks (APIs might have some differences but they will be APIs you've seen a million times by now), I'll concede a point on forms cause it's still a bit of a mess in React at the end of 2023. Fast forward a few months and the project will have its own wrappers developed around common functionality.Angular would have you install a million dependencies before you're even allowed to write "hello world"; you've mentioned installing Material and being good to go - that's nice and all - but Material is hardly the only UI toolkit and the way you work with it is quite different from, say, ngx-bootstrap. Want proper REST functionality and not just an Observable wrapper around fetch? Angular doesn't ship that either. It also makes writing good code much harder/annoying - React's function components let you just easily encapsulate a section of a component in a different component, Angular would have you go through the whole rigmarole of making new classes w/ decorators and, up until recently, adding them to module definitions - hardly productive and, in practice, just leads to some components getting too much code crammed into them. Over the past few years Angular's finally started admitting that's a bad system and, thankfully, introduced standalone components which bring back some of the goodies you'd expect from React like being able to import the component you want and not have to think about which out a hundred modules it's included in, but it's still a far less convenient workflow than you'd get with React.
And now we get into the more long term operational side of things: Angular is REALLY bloody unstable. React is really just a library for handling transpiled JSX w/ some very minimal goodies on top, Angular dictates every single aspect related to your frontend from build time to deployment; as a result, its updates are way more involved; it's ok when their automatic migration scripts do the job, but, more often than not, they don't, and you're stuck having to do a lot of manual fixes in a codebase of over a thousand components. My react apps, on the other hand, tend to "just work" after a breaking version update.
Been managing a commercial Angular app for the past 7 years and a React app for 4, the latter's had much less maintenance hassle and let the team spend more of their time on writing business logic instead of fighting the tools that are meant to help them. In the end I see it as a question of whether you want a code monkey or a developer on your team - the former will have just learned that you need to type out the characters "fetch" to make an HTTP request, the latter will recognise will see that all these solutions just use the same tech underneath and not waste time thinking about it (say you learned the fetch API - if, after the fact, you still can't figure out how to request headers in Angular's HTTP client or some HTTP client for Node from your IDE's IntelliSense alone then you really didn't learn a thing). I've seen over a dozen variations of Redux by now, the one thing the all had in common is that they're still just Redux so you still know exactly how it works even if the particular implementation decides to, say, refer to actions as events, or reskin itself with Observables like Angular does with Ngrx.
...as you wish, I disagree too.
React is more flexible, but that doesn't mean a company's react projects cannot share a similar structure and style. If a team can only afford to hire a couple fresh graduates to get the job done, maybe choosing angular will guarantee a better and more up to "standard" result, I agree that's probably the case. But if your company has experienced React developers, you can certainly get to the same standard but with a great deal more flexibility and a great deal less tedious boilerplate and structural overhead compared to Angular.
I my opinion, to choose Angular over React, the only strong reason I can think of is the clear boundary between modules resulted from Angular's dependency injection system. That give developers clear idea about the responsibilities of each module and how different modules depend on each other to get the job done.
I have to admit that the "dependency injection system" part I gained my experience mostly from Nestjs instead of Angular though. :p
The problem crosses company boundaries. Devs quits and devs are hired ...
Clickbait. Didn't read anything below title
"a tractor is almost always better than a car" (when you are a farmer).
It is obvious that if you compare something made specifically for a certain situation with something made for a different purpose, it turns out that the first one is "more appropriate" for that task.
So?
Because most farmers are unfortunately not buying tractors, but rather BMWs, for all the wrong reasons. Then later, somebody like me got to come and pick up their mess and try to make sense out of it ...
You have a very shallow understanding of frontend development.
React is fundamentally based on reactive (therefore declarative) programming that results in less bugs. React embraces the idea of small, atomic component where view, state, behaviour are encapsulated in a single module or function. This is evident in the fact that they use JSX which greatly improves developer's ability to follow composition. Angular is a terrible framework because it makes it VERY hard for developers to follow the best practices. END OF STORY.
Totally disagree! Nothing else to comment
Whatever floats your boat, man... ;-)
No comparison... Both have a purpose and identity... It's all about the requirement and business use case of application.
I know it's your mentality to comparison.
Pretty weak argument. You make a fair enough point, but to say this one point alone makes Angular better, is just silly.
Standardisations and generalisations is the reason why we're living in an industrialised society, and these ideas are often attributed Henry Ford. If we want to move forward as a specie, we're dependent upon such ideas. Standards, implicitly given through frameworks or by W3C, is in such a regard the only way we know about to improve collectively as a specie, and develop ourselves further, making the world a better place ...
Still depends on what kind of project.
Much better if you stick on standardizing the code base to es6+ (Classes / OOP). Then you can port it to any framework or library.
Correct, but if you generalise projects, you'll see my argument applies for 80% of all projects in the world ...
Anyway, React!!! :D
npmtrends.com/angular-vs-react-vs-vue