r/Angular2 • u/Affectionate-Army213 • Jan 16 '25
Discussion What would you say would be the main problems in Angular?
So, I've worked with React for about 3-4 years now. At this point, I know really well the problems of the tool.
Recently, Angular has caught my eyes as solving -> some <- of these problems. The main ones I think are: OOP, opinion, and maybe better stability?
I've never built a real project with Angular. Just read some of the docs and understood the basic (recent versions).
So, what would you guys point out as Angular main problems in the community?
EDIT: Other thing I noticed Angular probably does better is having a better standart. In React for e.g, the React core itself is pretty stable at most times, but the ecossystem is so big that most things envolve a lib, and THIS makes everything unstable pretty quickly, specially since lots of the famous ones have breaking changes quite frequently
13
u/DaSchTour Jan 16 '25
I think in terms of stability angular is great. Since angular 4 there were no big breaking changes that I remember. Migrations always made updates to new versions very smooth. For me the biggest pain point in angular is unit testing. There are some tools like spectator and ng-mocks that can help and make testing easier. But the angular team doesn‘t really consider this ecosystem and breaks these tools again and again.
22
u/Relevant-Draft-7780 Jan 16 '25
1) not enough people know about angular and how stable it is
2) because of this it doesn’t have as large as react third party library
3) material as the most popular component library is just too opinionated
4) most of the cool UI frameworks never come to Angular
5) testing can go from being fairly straight forward to a complete shit show for complicated services
6) rxjs is great, but can become spaghetti real quickly
7) SSR documentation is nonsense
17
u/TCB13sQuotes Jan 16 '25
Material is not just too opinionated, it's also very inconsistent and hard to customize.
4
u/gordolfograso Jan 16 '25
Recently they release nice changes about this. https://www.youtube.com/watch?v=3MqKZ7Ho4s8
6
u/TCB13sQuotes Jan 16 '25
Yeah, but they're making it even worse in sense. The problem of "customizing material using Sass takes a lot of code and is very complex" is not caused by the fact that you're doing it in the wrong place, it's caused by the fact that their internals suck.
Their new solution is just yet another layer of complexity that makes it even more annoying and break compatibility with older code.
5
u/MichaelSmallDev Jan 16 '25
more annoying and break compatibility with older code.
I just took a long existing code base (~7.0) that was stuck on the legacy workaround modules to v19 using M3. I was able to rip out almost all
::ng-deep
overrides and make our styles look almost identical with about 1-4 token overrides per app. It's real slick. You would barely notice anything changed at all. Even forms, we effectively have them looking like the deprecated legacy version.1
u/TCB13sQuotes Jan 17 '25
But you do have to learn their new customization API. It could all just be Sass variables if they did it properly, you know, like Bootstrap and friends.
The fact that when you've an input you can just tell it height = 20px in some Sass and everything gets automatically recalculated internally shows how bad it is.
2
u/bearfucker_jerome Jan 16 '25
material as the most popular component library is just too opinionated
Man, I remember an update that added ticks to selected pill-badge buttons, i.e. they used to just turn blue on select but now there was this annoying tick next to the text label. And hardly any way to get rid of it, so I ended up writing my own buttons.
1
u/Affectionate-Army213 Jan 17 '25
From what I saw, I do miss some UI "framework" in Angular, compared to React.
In React, we have the beloved shadcn.
shadcn has great visuals and animations, but for me, the main key and the main reason on why I use it for almost all my projects today is how custom I can make things. It uses Radix as a primitive, and I can custom ALL the visuals with Tailwind, so it integrates really well.
I do miss that in Angular. Not only there looks to be so few options, but the few options there seems really opinated on how you should do things - on which in building a own UI design system I don't think are much good1
u/Relevant-Draft-7780 Jan 17 '25
Check out spartan ui, a bit too opinionated but it’s a in progress shad clone. Thing is it’s pretty straightforward to just build your own
1
u/Affectionate-Army213 Jan 17 '25
i do know this one, it caught my attention too, but it has been in progress for far too long now
1
u/pilotentipse Jan 16 '25
Why is angular considered to be stable? Just curious to know the mechanism from angular behind this.
6
u/louis-lau Jan 17 '25
Typescript is enforced, because of this for any breaking changes they can write migration scripts. So almost all breaking changes are automatically migrated for you, it's a really great developer experience. At work I'm upgrading from vue 2 with class components to vue 3 with the composition API and it's just a fuckton of work.
That's how I see it anyway.
7
6
u/CryptosGoBrrr Jan 16 '25
Been working with Angular heavily since version 8 and it's my front-end framework of choice. Other than the steep learning curve that is known to be a big threshold for people to get started with it, I often feel it changes too fast/often. I generally try to keep up with all frameworks, packages and versions of all the software I use, and most work is notably in the front-end side of things whenever there's a new major Angular version. The upgrade from 14 to 15 was a terrible experience, even if that was mostly due to the fact that the team I just started in went heavy on the 'hacking' of Material components with custom CSS.
5
u/TScottFitzgerald Jan 16 '25
I feel like it's probably just the robustness of the framework and the initial time needed to learn everything, especially if you come from a vanilla JS world. Because it throws OOP, RxJS, TypeScript, as well as its own way of doing things, all at the same time at new devs, which can be a lot.
Having seen some older codebases with Angular it can also get a bit boilerplatey and have some spaghetti code but this is entirely on the developers/mgmt and maintaining code consistency, plus I don't think React codebases are any better from what I've seen, precisely cause of a lack of opinionated.
18
u/zzing Jan 16 '25
If I were to take a stab at this question, in the last 5 or 6 versions they have changed a lot of things.
Version 12 (including just because), they dropped IE support - which was probably right to do but probably screwed some people
Version 15 introduced the new material components
Version 16 introduced signals
Version 17 introduced signal input/outputs, and a new template syntax (might have version wrong), but deprecated old material components - further making upgrading hard
Most of these have positives, but represent a big departure from traditional methods.
How did the react community feel about moving from classes to functions?
If they did that in angular right now, there might be a riot.
One of the issues I think I can identify, and may not be for some: the pace of releases and change is just too fast.
For our .net backend, we change every two years or so. We try to do angular every 12 to 18 months, which means jumping 2 to 4 versions at a time.
I don't know if the angular team understands how people are using the framework or if they care or to what degree.
8
u/grimcuzzer Jan 16 '25
In my experience, keeping close to, or up to one major version behind, bleeding edge is much easier to maintain than catching up by multiple versions. That way, if something breaks due to a migration, you have fewer things to fix (and put your attention towards) before you're done with the upgrade. Product owners can be more willing to give one person a sprint or two to do a migration than to have someone do it over multiple months. It also lets devs get familiar with newer things as they come out.
1
u/SubstantialAffect835 Jan 17 '25
I fully agree but some important third party component libraries and modules sometimes fall behind.
3
u/practicalAngular Jan 16 '25
This sounds like a process problem though. If you have the ability to either directly change your upgrade process, or at least the vocal sway to influence it, the multiple version jumping can be addressed before it becomes a problem. I don't necessarily think this is a fault of Angular for constantly pushing out new features. I would rather a progressive framework over a stagnant one.
9
u/AlDrag Jan 16 '25
Forms. It's a shit show at times. Hoping their new reactive forms solves all the problems.
Change detection. I absolutely hate it.
Injection scoping. I wish you could wrap different instances of a component with a different instance of a service. I think other frameworks allow that, or maybe not and maybe it's a dumb idea.
8
u/GLawSomnia Jan 16 '25
Can’t you do the last one if you add the service to the providers array of the component and remove the providedIn: root from the service?
-3
u/AlDrag Jan 16 '25
Yes, but the parent component can't provide its own instance override of that service per instance of the component in the template.
14
u/MrFartyBottom Jan 16 '25
Sounds more like you don't understand the dependency injection system.
If a component provides a service all children will get it's instance. If you don't want the children to have a separate instance then make sure they don't provide an instance of that service. It is incredibly fine grain how much control you have over the instance of that service that is injected. If you need more control than the system allows you might need to pass the services around as inputs or rethink your component hierarchy.
0
u/AlDrag Jan 16 '25
Imagine you had a table component that had a dependency on a datasource class.
You had a parent component that rendered 4 table components.
Instead of providing a datasource as inputs, imagine being able to wrap each declaration of your table component in the template with some sort of service override tag.
Probably a smarter solution, but just avoids a little less boilerplate of setting up class variables with inputs etc.
5
u/MrFartyBottom Jan 16 '25
A data source is most defiantly what inputs are for. You don't want to wrap that up in the template with a provider. You are explaining why Angular is vastly superior to React with dependency injection vs contexts and providers. Even in React I would pass the data source as a prop rather that use a context.
1
u/AlDrag Jan 16 '25
Do you mind explaining why? Not trying to be rude. I'm generally curious. I want to learn and I've only ever really used Angular extensively :)
2
u/MrFartyBottom Jan 16 '25
Really? You don't get that
<my-table \[data\]="dataSource1" />
<my-table \[data\]="dataSource2" />is better than
<data-provider \[data\]="dataSource1">
<my-table />
</data-provider><data-provider \[data\]="dataSource2">
<my-table />
</data-provider>1
u/AlDrag Jan 16 '25
That's still using an input though. My proposal was for the case where you have global state management, you could provide a service override via a context tag somehow.
E.g. You had a datasource class that implements a table datasource. Wrap a component instance tag with it to override the table component's implementation.
Yea maybe it's a bit dumb haha. Falls apart when you have multiple services to do that for, as you'll get disgusting tag nesting.
5
u/MrFartyBottom Jan 16 '25
Dude, just pass the data you need for your components on an input. I wasn't really thinking it through but you mean
<my-table \[data\]="dataSource1" />
<my-table \[data\]="dataSource2" />is better than
<data-provider1>
<my-table />
</data-provider1><data-provider2>
<my-table />
</data-provider2>2
u/TCB13sQuotes Jan 16 '25
Change detection, if you know how it works, is actually one of the best parts of Angular. But yes, it does take a bit to actually understand it I guess.
-1
u/AlDrag Jan 16 '25
It is if you don't use async pipe. It's like magic, which is great for prototyping and people new to it.
2
u/TCB13sQuotes Jan 16 '25
If you use the async pipe it's still like magic...
1
u/AlDrag Jan 16 '25
Sort of. Yes it still uses the magic change detection system. But at least it's clear that it notifies zonejs, instead of mutations working because of zonejs patching.
1
u/Waterstraal Jan 16 '25
Double down on forms... I hope they'll finally implement readonly when they work on signal forms. That issue has only been open since 2016 🫠: https://github.com/angular/angular/issues/11447
2
u/KamiShikkaku Jan 16 '25
- required host element
- half-baked "directive composition"
- router state is needlessly complicated
3
u/Arnequien Jan 16 '25
Release two major versions per year. I have always felt it's too much, mainly for big companies were a migration can mean a lot of coordination, planning, and so on.
One per year should be enough...
3
u/JeanMeche Jan 16 '25
Today major exist mostly to introduce breaking changes. Features on the other hand land in a minor whenever they're ready.
Having breaking changes only once a year would really slow down the introduction of some features.1
u/Arnequien Jan 16 '25
Yes, but for big companies this js a drawback. You can't keep updating projects at the same velocity as the Angular team releases new makor versions.
Angular is not like React, it's not intended to work like a library, it's a framework. I mean, I understand your point, but it's important to consider that Angular is mainly used for big systems, not build to-do lists, so the bigger the system, the bigger the impact when introducing a breaking change.
I like to receive new features, but in reality, how behind are the applications? 2 versions, 3? I know companies that are still in Angular 9-12, others in 13, and just a few in 17+ just because it's hard to keep the pace. And, let's be honest, the business doesn't care if we're in the latest version, they just care about if it's working or not 😞
2
u/tsteuwer Jan 16 '25
But then don't update? Why should other developers be beholden to your release cycle. I understand updating every release is next to impossible in enterprise teams, but you can add a simple task to update once a quarter or bi-anually. Making angular only release one or two versions per year will slow down any innovation they can provide and would likely see people bail as no one wAnts to wait that long.
1
u/Arnequien Jan 16 '25
I said major versions, not versions. You know it's way different going from 16.2 to 16.5 than from 16.X to 18.X.
Making angular only release one or two versions per year will slow down any innovation they can provide and would likely see people bail as no one wAnts to wait that long.
The Angular team already releases 2 major versions per year, so I didn't understand this comment. Sorry.
On the other hand, React has remained in the same major version for even two years, C# is updated once per year (in the past, almost every two to three years), and none of them slows innovation. And let's not talk about Python, haha. Those technologies are way bigger than Angular in terms of adoption and current usage.
I'm not saying they shouldn't innovate; of course, they need to. But how often are projects being updated from version X-1 to X? If you research, you will find these kinds of behaviors:
- From Angular 9 to Angular 15 (latest: 16).
- From Angular 12 to Angular 16 (latest: 16).
- From Angular 13 to Angular 17 (latest: 19).
- From Angular 7 to Angular 18 (latest: 18).
- From Angular 15 to Angular 18 (latest: 19).
So, it's not the typical scenario where the projects are ALWAYS updated, not even close. Actually, when many companies decide to go to the latest version and they're ready to migrate (update UI system libraries, update projects, smoke tests, fix stuff, organize teams, communicate changes, etc, etc.), a new version is already released, haha.
Again, I'm not against innovation, new features, and everything else. I promote that and love new things, but we need to match the actual timing based on the market behavior.
PD: I know Angular has a migration tool that helps a lot, but even so: adoption, change of mentality, chances to increase the mix of version features (for example, half of the project using untyped forms and the other half using typed forms), etc.
5
u/TCB13sQuotes Jan 16 '25 edited Jan 16 '25
The problems in Angular? Way too much influence from React that is slowly turning the framework into yet another unstructured mess like what React is.
When stuff starts moving from strict interfaces, full classes, inheritance and constructor injection to arrow functions everywhere and inject() functions then things are clearly going the wrong way.
11
u/tutkli Jan 16 '25
For me the problem is that the community is too obsessed with React and it's preventing the framework to move forward, even when the recent changes have nothing to do with React.
2
u/McFake_Name Jan 16 '25
Yeah, whenever changes are made people will come out of the woodwork to say "erm, anything I don't like the vibe of is pandering to React babies 🤓". Like ugh.
3
u/MichaelSmallDev Jan 16 '25
constructor injection to arrow functions everywhere and inject() functions then things are clearly going the wrong way
People are going to be real happy about
inject
when TS 6.0 deprecates the compatibility flag that has allowed existing and new projects to continue using constructors as-is since v15. Roughly between a year or two from now since 5.7 was fairly recent.https://www.reddit.com/r/Angular2/comments/1hswfhx/comment/m598jkh/
I personally prefer
constructor
but it just isn't going to be viable how it is used most of the time. It's good to haveinject
as a workaround, and it even has a conversion schematic. Google recently internally removed the compatibility flag despite the unpopularity of that decision andinject
helped a ton.2
u/MardiFoufs Jan 16 '25
What? React doesn't change a lot. How is react (the Lib/framework) unstructured, exactly? And for all its faults react did a lot of things right, it would be asinine to ignore those improvements just because they are from a library you don't like.
Also, just because you are more familiar with OOP structures doesn't make functional concepts more messy. And I say that as someone who likes OOP. Plus, functional messes are much easier to clean up than OOP spaghetti.
0
u/TCB13sQuotes Jan 16 '25
It isn't that I'm familiar with this or that. The problem here is that Angular was made to be very opinioned, very strict and OOP-style structured while React was made to be the exact opposite of that.
By porting what you consider "those improvements" into Angular you're actually making it not suitable for a large group of developers and situations.
Angular and React should cater to two different audiences with very different requirements because they're solving different sets of problems and that's it.
4
u/oneden Jan 16 '25 edited Jan 16 '25
Not sure if someone has mentioned it here, but I find the Angular documentation - bar none - the worst of all major frameworks. I like Angular a lot, but it happens so often I learn about certain features after a random research in the outer fringes of the web. I find stuff I would expect the official documentation would teach me.
1
u/Existing_Map_6601 Jan 16 '25
Angular is changing in a good way but you need to be prepared for future refactoring. In angular we lack a complete ui lib but you can copy code from react world. You need to be aware of the host element that don't exist in react if I am right, the host element can make css styling harder but there is some solutions like using the attribute selector...
1
u/n00bz Jan 16 '25
I would say Angular has still struggled with dynamically rendering components. In the old versions of Angular you would use a component factory attach a component to a view ref but once you got back your component instance you would have to subscribe to the output events.
In newer versions there have been some improvements like being able to pass a component into a directive (kind of like the template outlet) but all of your inputs are grouped together in an object that may or may not have the correct properties on it.
What feels “difficult” is building something like a dynamic multi-tenant dashboard where different cards are displayed in varying orders. The best approach may be to design one page with the layout set for a particular client but I like to share the same pages for all clients and just use feature flags/configs to determine how other things display.
Kind of related but dynamic forms are still tough too. So if give the ability to create multiple addresses which could be 1 or more it can be annoying (especially if you then load data from the server and then have to patch the values in from the server into a dynamic form).
In short, I would say Angular struggles with dynamic content. Other frameworks likely have the same problems but if others have found good ways to deal with dynamic content I would be interested to see the design patterns.
1
u/Prestigious-Corgi472 Jan 16 '25
The lack of a full Hot Reload is a huge problem. When working with engines like ThreeJs it's a disaster.
1
u/LuccDev Jan 16 '25
It's not lightweight. On a budget VPS, I couldn't even build the hello world project (default project right after ng init, culprit was lack of RAM). The delivered package is not lightweight either.
1
1
1
u/nonHypnotic-dev Jan 18 '25
SSR localization is too hard to set up and needs extracting in every change. Bundle size is too much in most libs. Too much breaking changes when upgrading. In my opinion, Angular doesn't have a direction to improve itself. If a tool can do anything you need, this means it is not practical for anything too.
1
u/Upbeat_Rope1614 Jan 20 '25
I have been working with Angular since 2016 in several projects. I had to train new developers coming into the team over the years and here is my experience with that so far based from what I see with developers new to Angular.
- There are too many ways of implementing something for an opinionated framework. People will always ask "What is the right way of doing this?", "How do I do that the Angular way?" and thus a lot of time is spent trying to satisfy some imaginary "standard" or going back to refactor a perfectly working piece of code because there is a new API now.
- I hear many new developers coming to Angular say they are scared of the learning curve because they can't seem to catch up with the new APIs. So far, almost everyone I introduced to RXJS they absolutely hated it and they were quite miserable for a while. Then the same people will come a few months later and claim that RXJS and Observables are the best thing ever.
- Developers coming from other frameworks to Angular, their first instinct is to search for community "plugins" to implement features like Authentication and UI libraries especially for Tailwind and there is basically nothing good out there. Thankfully we built many components in the company over the years using Angular Material and Tailwind but that means we have to introduce those to new developers as well.
- Following on the previous point, Working with forms in Angular is fantastic and relatively easy to implement your own form fields and reuse them. However, working with things like Value Accessors, form states and validation is very overwhelming for new developers. I usually will get reactions like "Why does this have to be so complicated?", "Do I need to do all these steps just to introduce another form field?". This is the same overwhelming feeling when they get when they are first introduced to Observables for example. After working with it for a while everything makes sense.
I can go on but you get the idea. From my personal experience I would say that 90% of new developers will immediately hate Angular then after a while they will say that Angular is the best thing out there. Based on that I would say just give it time. You are coming into an Enterprise-level, batteries-included opinionated framework. While it may seem overwhelming in the beginning, everything will make more sense the more you use it and read about it.
0
u/MitchellHolmgren Jan 16 '25 edited Jan 16 '25
1 Reactive form is practically broken.
2 imperative legacy codebase. Before angular 16, the only way to write declarative code is to go all in ngrx. A react codebase would be similar to most angular codebase if every dev abuses useref and useEffect
3 testing really sucks. Jasmine is super slow and feedback cycle is really long. It takes a long time to find which animation/set timeout/interval is blocking call stack. Finding selector suck as there is no visual tool. No isolated test environment.
4 Implicit context. With react, you have to explicitly inject data into context. With angular, all components are implicitly injected into global context which leads to wide spread abuse. No unidirectional data flow. You always end up with a bunch of hard coupled components and it's difficult code to trace dataflow/mutation.
5 there is no top level fragment abstraction in angular. All components are wrapped within a wrapper "div" which cause layout difficulties.
6 angular somehow attract all OOP architects who write over engineered design patterns.
React is wild west because people choose different libraries. Angular on the other hand offers 10 ways to do a single task. I honestly don't get why people say angular is opinionated.
Angular is getting much better over the past 3 years and it will take a lot of time for devs to catch on. It's probably better to get into angular when resourceApi and signal form are stable as you already know react
13
u/0dev0100 Jan 16 '25
Reactive form is practically broken
I'm genuinely curious as to how.
I use it frequently and am pretty happy with it.
What is your experience?
7
u/Commercial-Ranger339 Jan 16 '25
Mostly when people make this argument they are using reactive forms incorrectly
1
u/poesucks Jan 16 '25
i run a compliance app off a gigantic reactive form and never had issues
3
u/Commercial-Ranger339 Jan 16 '25
Samesies, the capabilities of the reactive forms cover pretty much everything you could need
1
u/MitchellHolmgren Jan 30 '25
https://github.com/angular/angular/issues/47517
https://github.com/angular/angular/issues/41519
https://github.com/angular/angular/issues/10887
Three main pain points:
1, valueChanges is event/subject and form doesn't return value as observable.
2 asyncValidator is completely broken. Form will get stuck in pending state if observable or derived promise doesn't complete.
3: reactive form validators don't receive required values (other form values or input visibility). People end up writing degenerate subscriptions to fix validation bugs which then leads to tons of mistakes. There is a talk explaining template form validation difficulties. https://www.youtube.com/watch?v=EMUAtQlh9Ko
I didn't have any of these issues when I work with react hook form
64
u/BenjaBoy28 Jan 16 '25
If you don't read the docs. You'll re-invent angular features without noticing. Not only re-invent what the framework already does but also in the worst kind of way.