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.
Oldest comments (134)
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 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 ... :)
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 ... :/
Angular + Standards and then blaming React... I may lost something in the road but in React I use standard things except for the JSX while in Angular not even the templates are standard.
To drive a React project you don't even need people that "knows" React, people that knows HTML, CSS and JS is enough, understanding hooks (which are just HoF) and a couple of concepts of FP is enough to go ahead properly.
Can you please clarify?
Also I'd like to know where in this comparison Next, Vue and Svelte will sit in your opinion.
thank you
The general principle is that the fewer decisions you have to make, the better it is.
Less is more because the paradox of choice makes you les productive and happy when you have too much of it.
If you have n binary decisions to take, that's a 2^n combinatory explosion.
Frameworks that have made by default a reasonable choice on most common topics are exponentially better than frameworks that gives you infinite flexibility.
For example git can do everything but following the GitHub programming workflow is much more efficient.
Can't speak about the specifics of JavaScript frameworks, not my field.
Bingo! Thank you. No further questions ... ^_^
Yup! So true. And others have "different standards" - Check out Jean-Michel's comment for further clarification ...
As a general rule of thumb, the less choice the better ...
@jmfayard is not a matter of coice because you like one thing more than the other.
We usually use a minimal approach with that.
Start a project with the less you need
i.e.
React, ReactDOM, Styled-Components (for styling) and Jest (for testing).
Then add things JUST when you need them, because you can't predict every need you'll face on the major part of projects, this way you avoid adding a bunch of things that you may or may not use.
Furthermore when you face a specific need you can choose the right lib (or custom implementation) that better suits this specific need and/or use-case.
There are 61702 packages tagged with "Angular" in NPM so I guess you'll need to bring this kind of decisions in Angular projects as well. It can be less amount of them or the same depending on the specific project and it will happen whenever Angular core API doesn't provide the exact tool to suit your needs.
To clarify, are you saying that my principle doesn't apply in React vs Angular (possible, no opinion from my side) or are do you disagree with my principle (and why?).
I'm saying that to some extent you'll need to take decisions either be one or the other and that a minimalistic approach adds less burden to the project overall.
The decisions about which dependencies we should add to the project are made -in our case- by the TL (which is me in this case) regarding the technical nuances of the project, the environment, current needs, future roadmap and lib's dependencies while checking for security concerns (known bugs/security issues...).
Also we'll do a PoC with that hypothetical lib to ensure full compatibility and to define how it should be used to avoid weird implementations (which I saw whatever the language and tools are used).
Angular is not agnostic to this kind of issues ( first example I found ) thus my PoV is that it isn't that "good" and/or it doesn't release you much of this "burden".
Angular is (obviously!) not "perfect". Every time I need to upgrade something, I cringe from fear of breaking something. In comparison, NuGet (.Net) is a breeze compared to npm. However, you have to make a lot fewer choices when using Angular than React. Which is Jean-Michel's primary argument here, and also mine too, since fewer choices equals higher amount of standardisation, leading to more easy recognisability for others, etc, etc, etc - Basically a good spiral upwards ...
Yes it is like that in most cases, agree with that
My question though goes through a different path: Does fewer choices compensate the lack of being able to choose the right tool for each job?
I've worked on a couple of projects with Angular and it was fine but speaking of frameworks I do like Next more from the dev point of view (flexibility, fine-grain the results regarding the needs...).
In most companies we standarize some sort of libs to use and when something is more convenient to a project we simply add them as option, so you'll end up with few options (or just one) whenever you want to fill a need. On the other hand, JS core API is quite good for quickly overcoming needs without the need of libs.
This requires iterative checking and it's some burden but it's mostly decoupled of the devs day to day job (devs can suggest whatever they like, then everything is checked, including the license of course and added or not whether it's convenient).
By the way the "current" situation is a lack of available human resources aligned with a high demand and React is known by much more people (and is way easier to learn), which makes it a good choice.
On the other hand Google did deprecate AngularJS once ... vad vibes đ it was a good decision for several reasons back those days of Angular2 but the big G has a big graveyard of projects and I wouldnât risk my neck for they not doing it again.
TLDR; tech decisions are not made only from the tech point of view.
Wrong question, it's like asking if your car is married. The correct question is; "Does fewer choices leads to higher quality, better performance, and less resource requirements?" - At the end of the day, the only thing the companies I am referring to in the article care about is quality, time2market, and resource requirements.
Correct, and once realising that, what the individual developers "feels is better", and or "wants to use" becomes irrelevant. Standardisations will force itself unto us, one way or another, and as it does, less power to the individual developer, and more power to the business decisions makers are a natural consequence. The only reason why business even cares about what devs "wants" is because they're terrified of devs quitting. That is a "local evolutionary optimum" destined to end, sooner and not later - Like it or not ...
Hmm nice PoV, I've not enough data to answer this, would need to check whether Angular projects have more quality than React ones through different metrics.
On performance and resource requirements I'm confident saying NO, Angular produces heavier applications due to the many features of this framework, that can burden projects, translating into a heavier application with slower performance. I've tested it a couple of times; I prefer the minimal approach I explained before just for that reason.
I definitely need to check the quality thingy, I'll come back if I get an answer on that.
If the app spend 0.4 seconds or 0.8 seconds to initially load is irrelevant. When I speak about resource requirements, I am talking about manpower required to maintain the project, not CPU and RAM. The latter is (for the most parts) no longer of much interest due to Moore's law ...
Quality is erronously perceived here I presume. "Quality" from a business perspective is rarely the same as quality from a software developer's perspective.
Quality from a business perspective might for instance imply;
Etc ...
My bad but still the answer is no, in my experience, the amount of devs you need depends on what the client wants, at what speed and with the budget.
Of course the answer is usually "Everything", "Now" and "as low as possible" respectivelly but I mean after a refinement and viewing it from a realistic point of view đ
But if you want X and it requires 3 people in average it will be the same in Angular, React or whatever. The amount of people is mainly due to parallelization of tasks, on the other hand if we talk about delivery speed, developing in React is faster than using Angular (according to my experience as dev and as TL).
Those seem design factors to me and not related with the tech stack used.
If you design a bad application it will be crap either be Angular, React, Vanilla JS, Java, PHP, C or whatever đ
I was thinking more on "how many bugs appear into production", "time to solve them" and so on.
I suspect that's a highly subjective observation. I would say the exact opposite. However, the point is that Angular projects have less differences, implying moving people around from one project to another, and/or hiring new devs is by the very definition of the term easier ...
Not correct. All Angular apps (assuming they're using Material) ends up more or less the same. For enterprise back office administration apps that is a good thing ...
True ... :)
That's undoubtedly true.
The only showstopper is the popularity of the framework. From my closest friends 5 are able to work in React but only 1 coded with Angular, counting me that's (+1 on each) 6 vs 2 and more or less the same can be observed in new hires. For each 10 frontend devs, ~2 have used angular.
To some extent it also has been recently (since the beginning of the pandemic) influenced on juniors due to the rise of several tens of codecamps teaching MERN stack around the world (see the increase in npmtrends).
My bad, I meant the product design.
If you decide to have a button here or there, to have a 4 step process to reach some functionality instead on optimizing it to 2 (if possible), how many features it will have, how they interact between each other, which are the user journeys... and this kind of things.
On the other hand if you use Material and don't put a hard work on editing/overriding Material components it will look pretty much "stock" (Using a pre-built theme). Changing the colors for the corporate ones in the config neither make it an application designed for the purpose so you end up using Sass API to style as much as you can and then Overriding styles (bad yada yada) because it wasn't enough.
Contrary to that if your app is meant to be used in-house (corporate) which is the target of every single Angular App I worked in, using Material is a straightforward way to deliver considerably faster and lowering the maintenance (if you are able to say "that's not possible" when the designers want something that's out of Material's capabilities).
Earlier I forgot to mention that
This is not applicable to public web apps. It has been well proved that lowering load and response times increases conversion rates. After checking, @angular/core alone weights 76.2 kB kb (minified and GZIPed) which is ~2 times React's entire weight (~40k).
Worth mention, If you need SEO I'd rather use Next JS (79.46 kB) for the SSR and SSG thingy and/or if I need to code a monolith so I've Node and React in the same place, lightweight and smooth (a good option for PWAs as well).
Is this true? I know React is more popular, but I suspect the above is slightly inflated ...
Of course not, my bad, I should have specified back office apps ...
Well It was said by a colleague that usually handles tech interviews, I don't know if he was exaggerating or not and
if yes, to what extent đ
The last figures I saw was that React was 1.5 times as popular as Angular. These numbers are a bit old, and I know React has a lot of momentum though, so things might have changed since then ...
Thank you :)
Speaking more seriously with the same guy that's what I can extract:
People inexperienced in driving large scale product implementations may not realise the point made here. For large enterprises software is a tool to derive profit. Angular definitely knocks out a lot of contentious issues. React is like core Java. Spoilt for choices. For enterprises what matters is what gets the job done. It doesnât matter if itâs the best breed as long as itâs above average.
Word!
Exactly
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.
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!
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 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 ... ;)
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 :)
""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 ...
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!
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 ...
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 ... :)
Yea you just totally missed my point, it's not logically valid to compare two things that do not directly relate, especially when the better comparison exists (i.e. comparing to specific React frameworks). So no, you can't answer which is best if you are just comparing to "React" the library. Comparing React to Angular is like comparing MacOS to the Linux kernel. A high-level OS (Angular) just doesn't compare to a small, subcomponent piece like the kernel (React library) because they intentionally are designed to be different solutions to different problems (even though they are definitely in the same realm of related concepts). We compare MacOS to Windows because that's a more fair comparison as their purpose/use-cases directly align.
I am saying developers/people who just say "choose between React/Angular" are incorrect to ask that in the first place as it's a framing fallacy. That is not the right question to ask yourself when choosing a framework. I think the better way of phrasing this is "should we choose between Angular/NextJS/Remix/CRA."
I guess the main gripe is the lack of qualifiers and the overgeneralizations you make when referring to React. Like "React ecosystem" maybe more accurate to what you're trying to get at, and even then I think you're straw manning React because you are not specific about what particular area of the React ecosystem you're referring to (which is why I just recommend comparing to other React frameworks).
(read other comment first)
Let's take your points as example of why I think you're overgeneralizing:
What? Absolutely not! Just use
fetch(), you don't need other dependencies or components. Want a Date picker? Style it yourself. Want an out-of-the-box styled date picker, yea sure, install MaterialUI as a dep, if you want to look like Google (not everyone wants to their website to look like Material Design btw, I don't see that as a plus for Angular if you aren't adopting Material, and if you're overriding it, that's just the same amount of effort you'd have when overriding custom theming of a component library in React, thereby being no different).Honestly besides having a single UI component library (that Angular Material is comparable to), I don't see most projects installing tons of different components. In fact, within a particular framework, I extremely frequently see the exact same libraries being used, and even if there are different ones being used (i.e. state management libraries), they all share the same fundamentals these days (i.e. hooks and unidirectional data flow patterns). And I have seen two Angular projects with wildly different state management usages and practices! I disagree than Angular is somehow immune from different projects doing things differently, I see it all the time. The framework doesn't prevent people from writing different, non-standard, or custom code or installing different libraries.
This is just not the case for the React frameworks. NextJS and and Remix, for example, are pretty prescriptive on how you organize the projects. But even granting your point, that is the whole point and difference of opinion (i.e. there is no right or wrong answer) to how you should structure your particular front-end project. Not all web apps have reason to look identical, there are wildly different scopes and scales of projects out there, and some do not need to overhead of strict organization than Angular may recommend.
Yea I'm not even sure what HTTP libraries you're referring to - like besides built in
fetch()and something like Axios, what do you mean everyone has their favorite HTTP library and how does that relate and actually a downside of React?Yea, people have different favorite UI/design component libraries because people have different taste in design. Not everyone wants their website to look like Google. Just like CSS, there's tons of ways of doing the same thing differently, what's wrong with that?
Again, what's wrong with this? Can people not have opinions on dependencies they like to use? Why is it a problem that that people do styling differently, that they use different state management libraries, and that they like to install different helper libraries to do things. Like what's wrong with people having their own preferences? Lack of consistency -- ok choose a more prescriptive React framework like Blitz. Also, just adding "favorite 'whatever' library" to your list of problems you have with React is not helpful because what do you mean "whatever"? Be specific! It almost sounds like you haven't ever been in a modern React project when you're not specific in what you don't like about React and you don't show evidence.
Within the same React framework, you absolutely, 100% find React codebases that look the same. That's my whole point. Just compare Angular to React frameworks in the first place and then we can discuss. You point is moot to just say "React isn't consistent" when that's an obvious statement because different React frameworks are different just like they are different when compared to Angular.
And I think you are only considering folder structure or file structure or something, because 90% of React is very similar everywhere I have looked. JSX is in all the projects. Components are the UI building blocks. Hooks are the data-building blocks. Contexts/providers are used for state management (the state management libraries use the same feature under the hood feature, they just may differ slightly in how they are consumed and how they scale, which is totally fine, because different projects have different needs for scale and complexity so there is no one right answer). Uni-directional data-flow and event/call-back driven data models are always the same. Composition patterns are consistent. Prop passing patterns are similar and transferrable. Yea I quite frankly don't know what evidence you have to suggest that React projects are all wildly different in some of these fundamental building block elements. Yea structure changes between frameworks, but most of modern React is totally transferrable between projects (I know this because I've experienced 5 different production grade React projects).
Not true within the context of a particular React framework.
This must be anecdotal experience (which is not an argument/confirmation bias), because the Angular projects I have seen do NOT all look the same at all. I definitely believe that they look the same within your company and the companies you've worked for, but I also have worked for these standard/non-tech companies with low priority on development, and yea, I see Angular projects that are not consistent. Angular is not immune to that at all.
Getting mixed messages from these statements -- are you actually making a value judgement claim about Angular or not? I also agree the technical performance aspect of the two is very irrelevant for comparing. And I also agree React frameworks nor Angular as a framework are objectively better than the other, yea. That's exactly what I have concluded about the tens if not hundreds of web frameworks out there - they all are unique, different, and none of them are objectively better than the others at this level of generalization. Only with specific constraints and circumstances can you make such bold claims when comparing frameworks.
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 ...
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 :)
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.
Thank you đ
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.
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.
Clickbait. Didn't read anything below title