To understand the above sentence you'll have to read the whole article, and in fact you need to understand how most developers are working too. First of all, "most developers" are working for companies having software development as a secondary function. Some examples here are insurance companies, banks, hotels, hospitals, etc. These are companies who fundamentally don't care about software, but need software to optimise their processes and fulfil their primary objectives.
These companies typically have large turn over, and the average employee rarely works at the same company for more than 2 years. This implies that once every 6 to 12 months, a new developer starts working for the company, and need to understand the existing code base to become productive. In addition, 80% of these company's software projects are back office administration apps, not visible for customers. Examples are CRM systems, ERP systems, etc. With that in mind, let's go through how React and Angular is typically used at these companies.
How Angular is used
When you start out a new Angular project, the process is fairly straight forward. You make sure you've got the latest version of Angular, you install Material, and you start implementing your design. Each individual project therefor has a similar structure and largely uses the same components. This implies that every project becomes similar in structure, have similar components, and typically very similar markup and code - Assuming the Angular developer knows what he or she is doing. Maybe you'll need a handful of custom components for your project, but in general if you've seen one Angular project, you've seen "all" Angular projects.
How React is used
If you did the same exercise with React, you'd need to install dozens of components before you can even create a simple HTTP request and show a freakin' date picker. Every single time you install a new component, you have a myriad of choices, resulting in that you'd rarely find two different React projects using the same set of components and plugins. The structure of the project is much more left up to you as an individual developer in regards to how you want your code and project to be organised.
The problem
The above differences implies that for the most parts you can replace any Angular developer with any other Angular developer, and after an investigation phase of maybe half a week, your replacement is equally productive as the person who worked on the codebase originally. This results in an "agile organisation", able to easily move resources around between projects, without needing a longer learning period as resources are moved between projects.
With React the above is simply not true, because each React developer has his own favourite HTTP client, he's got his own favourite widget library, he's got his own favourite "whatever" library, resulting in that you'd rarely find two codebases with similarities at all.
So regardless of whether or not React is objectively "better" than Angular, it's already lost at this point, since resource management at a "React company" becomes much more rigid, and you're much more dependent upon individual resources, whom are more difficult to move around and replace if needed. You have created an unnecessary "dependency" from a business perspective, where you're much more dependent upon individual contributors, and you've got less flexibility as a company.
In addition to the above, most Angular projects ends up looking similar. For a company having dozens of in-house developed back office administration applications, this is an advantage, since back office workers used to one app, can easily understand all apps. With React this is simply not the case.
So really, which of these two frontend libraries/frameworks are better technically, is at this point completely irrelevant. As long as Angular performs at least somewhat "close" to React, the technology behind, and its ability to perform, is no longer important for you as a company.
NOW you can comment and disagree with me ... ;)
Edit - This is why we're exclusively using Angular at Aista.
Latest comments (134)
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.
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 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 ...
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.
Totally disagree! Nothing else to comment
"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 ...
Ah, presenting personal opinion as fact, great writing that 🤡
Hahaha, I couldn't resist, liked your comment, because of the clown ^_^
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 :)
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.
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
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.
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 😂
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!
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 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.