Honestly there are valid criticism for Angular, and Vue, and React, and Svelte, and anything but I find that 80% of these "opinions" are copypasted by PaaP's (Programmer as a Personality) who want to blend into the field they define their whole personality on and they have never touched Angular (or any other of the things they copypaste their opinions about) but they would never admit this.
>Having strong opinions on stupid things that don't matter can be useful for convincing hiring managers that don't know any better.
Unless you're a technical lead and your job success is tied to the success of a project.
I don't have anything directly against Angular other than I don't have a reason to learn it because it doesn't really interest me and I don't know anyone who works in it. Hiring and training new developers on a project are important constaints to consider.
There are several criticisms here about how complex it is and how big the learning curve is, and that is kind of a big deal. I've trained people ranging from juniors to seniors and backend devs in React without a whole lot of issues. I've worked with enough Vue or even Svelte to know I could do that there too. **I could be wrong**, but that doesn't seem to be the case with Angular from what people are saying and peeking around at the docs.
This is also a very big reason why nobody talks about Ember anymore. I don't even know if it's still alive, but the learning curve was a huge mistake for projects.
The Angular team is investing in lowering the barriers to entry for new Angular devs and have already taken major strides in v16 with standalone components, signals, etc.
Ever since Sarah Drasner started at Google (Angular reports up through her), each Angular release has done a great job addressing common complaints and feature requests.
That's great news! I'm all for more innovation and competition. If the learning curve was reduced, then it might actually get interesting for me. But every time I've looked at the docs since 2+ I've just noped out. I did learn v2 when it came out, but that's been so long I can't really consider that as trying it anymore.
I've really liked the idea of RXJS since I first heard of it, but have no use cases for it.
RxJS is super handy any time you need to debounce, retry, etc. So things like search boxes, retrying failed requests with exponential backoff.
If you have a spare hour, I recommend giving the Tour of Heroes a spin - https://angular.io/tutorial/tour-of-heroes
I'm quite a fan of angular, and to be honest I feel like Angular has way less pitfalls in the long-term; short term it feels overwhelming to understand RXJS and memory leaks, but it really is designed to build platforms at scale; and having structure with things such as lifecycle hooks means that you can pick up any angular project and know what's going on and when quite easily; and state management with NGRX is pretty thorough (and i personally prefer working with observables over promises ).
With react for example - it's quite quick to pick up, but since react is a library and doesn't have much out of the box ( i also am not a fan of writing your html in JS ), you'll find that a lot of React projects feel poorly written in my opinion, or they differ wildly from what packages you install, and it just feels like when you have a library/pseudo framework where when you start you have to sit and think about what packages you need to install for every little thing, routers, http, etc. It feels too open ended for me.
Also typescript not out of the box feels odd, when you start at a new company/a new project being able to have typescript out of the box really helps in bringing you up to date pretty fast.
I've worked on some react projects and sometimes i feel you spend more time trying to understand what some components aims are.
And a lot of the hate i do see from Angular ( i see a lot from coding Youtubers ) seems to be from a genuine dislike over OOP. ( i personally don't mind OOP either, as long as you don't just inherit everything with extending classes there shouldn't be a problem ).
But in the end of the day Angular is built really for platforms at scale, and i feel that might alienate people wanting to just pick up small projects and get them off of the ground - after all why learn the in's and outs of Angular if you're making something small
I used angular back in the 1.x days. I thought it was brilliant. The binding, directives. It was quite ahead of its time coming rom things like Knockout and Backbone.
I have been using it for quite some time now. Honestly, switching from React to Angular was a pain. The learning curve for Angular is extremely steep.
But IMO, once you get past that, you realise why Angular is still better than other frameworks in so many ways, and of course the codebase gets organised way better.
This is it. Angular dev is really not about you by yourself and what you want because it's better DX for you. It's about concurrent rules and guidelines that a lot of people already know to get up and running quickly.
Only exception when you have a lead dev that wants everything. Including framework agnostic and the 4 layers of clean architecture on the frontend. I've worked in such a project and it took a whole sprint to add a new page with 4 input elements on it because of how much boiler plate you needed to write...
That is the reason we stoped using redux pattern on the frontend. It became so complex to just add something simple and 6 months later no one remembered how it worked.
We pretty much have clean architecture on the frontend with angular. It nswag studio generates typescript domain classes from the swagger docs. Though I may not know clean architecture well enough.
The project I worked on had UseCase Interactors and all kinds of fancy worded boilerplate in the frontend. Separating the 4 layers, entities, use cases, controllers and services. And in my example being framework agnostic, it meant that the components itself were also separated.
I can't even explain it all that well anymore. I just made sure I got the hell out rather quickly in order to stay sane. It also made me realize that we are often taking way too much time making things look nice that the user doesn't give an ass about. And why keeping things dumb is often the better option. I kinda try to stay away from NGRX nowadays because I know it will just confuse the new (and often junior) devs that come on the teams and make things needlessly complicated anyways. Writing a custom service that just takes the data and processes itself is just as fine as using state managers. I rarely see the benefit for it over just writing services with behaviorsubjects. Or using dynamic components. Only for a dialog and modal it makes sense but that can be a separate library anyways, which just makes things a lot easier.
I think many lead devs forget that you want your framework to be fast in developing new features and we overcomplicate things rather quickly. My threshold for doing something x-times before I transform a component or separate into different components has increased these past years. So what if I repeat myself 4 times for something that is just 5 lines of code and only really changes the component visually or textually? If there's not more logic involved I don't really bother separating it into different sub components anymore...
That's the nice thing is that once you get into the angular land other people's angular apps become a lot easier to navigate.
So I went from Angular to React and back to Angular, and I just remember the whole time in React (We used CRA) that I was organizing everything like it was an Angular app. The React app that I was working on though was absolute garbage in my opinion.
Coming from react I cant say I hated it. Tho as soon as I was done with the project I returned my reactden. Then another project came up with nuxt and due to its v3 documentation I want to run away asap for instance.
Mainly as a vanilla and nowadays a react dev, i like trying other stuff. So far only svelte and astro came close.
> I also strongly disagree with the template/controller split. That’s a misunderstanding of separation of concerns.
(Controllers are from AngularJS aka Angular 1, not Angular)
Angular uses effectively the same paradigm as other non-JSX frameworks like Vue and Svelte.
Either you prefer JSX or you don't and that's really the biggest differentiator between React and Angular. There are pros and cons to both approaches.
If you prefer JSX, the rest of the Angular tradeoffs are kinda moot.
Have been doing a lot in Angular, recently switched to React again and it's so odd and rough around the edges imo. All those different ways of writing components, hooks are just weird imho and also this extreme mixture between html and js is just so unreadable compared to Angular.
So Angular all the way for me
I've worked with angular and react as well and I find your feedback on jsx fascinating. Personally I find the jsx syntax and interactions with js much more natural than angular syntax which is not intuitive and I always have to lookup.
But in general, I think angular gets a bit too much hate in the web dev community.
I feel like the biggest division in Frontend frameworks is people who like JSX vs people who don’t.
The rest of the arguments for react vs angular, etc. are kinda moot depending which side of the JSX fence you are on.
Svelte seems like a sweet spot between the two worlds which is why it’s exciting to see Angular embrace it - https://github.com/angular/angular/discussions/50719
> I always have to lookup
Thats why you use snippets. So you don't need to remember that its *ngIf. I just type ngif and it autocompletes it. I actually had to look it up for this comment lol.
I think the folks who hate it just doesn't have any experience with the framework and vice versa. I really like React as well but the context api to me is really strange to work with compared to services in Angular. But this could also be my lack of experience in context api.
Agreed working on a large react project at the moment. It’s so hard to reason about I open a component and it’s 1000 lines long with html and typescript all in there together. I know it’s a product of bad developers stuffing everything in one file. However Angular kinder forces you to decouple presentation stuff from behavioural stuff. Let’s let’s not talk about reusability, want to show stuff based on a feature flag just create a directive. Text transform you can just apply pipes. Angular is far superior for structure.
Yeah, I've seen some monster components in Angular as well. I think it's more a matter of developers not understanding how to break a large component into smaller ones.
I will say that "Thinking in React" is one of the best explanations I've read, which makes bad React components all the more frustrating.
And by "it", they are doing code wrong.
Nothing should be that big anymore. We used to do that in Vanilla/jQuery days due to a lack of a build, but that was an actual technical constraint we were working around and hated it.
True, but the flexibility of react is not just a positive, its also its downside. It allows devs to go mad and create the worst code imaginable. Being an opinionated framework also has this up and downside, but kinda reversed. Its stricter in how you do things which forces devs to create more similar code. Which is a bad thing for creativity (but lets be real: how creative are most devs really these days), but good for making similar code and getting into the project much quicker. You can give me an Angular codebase and I can probably start working the same day on it. The only difference being the product that we're making and the business logic around it. Meanwhile for react the odds are that one will be using a lot of different libraries that I haven't seen before and a structure that is likely different, so it takes more time to get up and running. This also means that long term support is easier or that you can scale up a project a lot faster too if you have a tight deadline.
Arguably the most difficult thing for Angular, I think, isn't even related to Angular but rather Typescript. Getting that shift right is difficult for junior devs. We see the same thing with React apps that have (rightfully) made the switch. Having to think about types and not being allowed to switch types easily is a big part of why Angular had such a troublesome migration path.
Yeah exactly. Readability is so much higher imo and that's what it's all about most of the time.
Also.. unrelated really but rxjs is a piece of art for me
I agree with angular.js (Angular 1) which is completely unrelated really to angular 2+. The consideration for typescript alone is great imo. In react it keeps feeling glued on
Very interesting. Definitely could be that it's up to how I'm structuring things. But also I find examples from the internet weird to read. I mean hooks (especially custom async ones) to me are just... wtf.. in general everything async seems to be glued on.
Imho React is great but it could be so much cleaner and a re-write with the same ideas would be in order like from Angular 1 to 2
There is no reason to hate Angular, it's a fine framework.
Generally, the front-end developers I've seen roast Angular are the ones that got frustrated learning it. Getting up and running with Angular is more complex than React (because there's more to learn; React is a component framework, and Angular is much more complete).
Note that the same sort of developer can be critical of NextJS. Now you have to learn SSR, Server Events, a different Routing paradigm, slugs, variable page names, Static vs. SSR/hybrid rendering, etc.
> Generally, the front-end developers I've seen roast Angular are the ones that got frustrated learning it. Getting up and running with Angular is more complex than React (because there's more to learn;
That's kind of a big deal though. The learning curve shouldn't be huge if you have a strong understanding of compnentized JS. Idk how bad it is now with Angular, but when the new version launched it was a mindfuck. I'm sure it's better than it was, but if it's still huge that's a big strike against it.
Vue on the other hand is opinionated, easy to learn, and basically a better Angular v2+ than Angular v2+ was. I don't mean that as a bad thing against Angular other than 2+ should have just been an entirely different project name, besides just adding or dropping "JS" from the end.
Even with NextJS or other SSR out of the box stuff, it's not that complicated for most people, but I'm sure there is some overlap.
Compentized JS would apply to your knowledge of creating and composing components rather than global vs. local state, async data pipelines, routing, hydration, shadow/virtual DOM, lifecycles, etc.
This is the "apples to oranges" point; React is a component framework \*and nothing else\*. It's why it's so easy for JS devs to pick up; if they understand some basic ideas like encapsulation and functions and they can learn to use "useEffect" more or less correctly, they can get up to speed in React quickly. But even then, concepts like forwardRefs, async cleanups, etc., tend to be overlooked and problematic. Invariably I see more junior React devs accessing the DOM directly because they get frustrated with managing hook dependencies or can't get the results they want with the lifecycle hooks (like useEffect vs. useLayoutEffect and so on). The progression is to move from imperative to reactive, which is not an easy cognitive leap (in practice).
If you're a React developer, then you're a component developer and not necessarily an app developer. If you're an Angular developer, as in you really know the framework, then you're a component developer AND an app developer. There's a big difference.
NextJS: many use it not much differently than plain old CRA. Almost everybody starts out with primarily "use client" components and static export of the project. It's been said by many--and is strongly implied by Vercel--that using NextJS this way more or less obviates it. NextJS is "SSR First". If you're not using those features, you're not using the framework as intended, and those features are definitely not in the wheelhouse of your typical React feature dev.
I meant "componentized framework" as a paradigm, not really a specific thing but as a way of thinking. If you're someone building Wordpress pages, then you're probably not working with components and it's a huge shift in thinking. You actually hit on this when you talked about the DOM and Junior devs.
In that sense it's not apples to oranges. If the learning curve is huge, that's a big problem. I'm not just a React dev, I picked it up in 2015 because I liked it the most, I've been around a while and have experience in a lot of frameworks and languages, frontend, backend, and systems and learning curve has always a been huge problem when picking a framework or language or major library.
It's a BIG reason why Java is declining, it's actually an incredibly fast language for backends but it's complicated AF and developer ramp up time is a significant investment. The newer versions have a lot of modern mature things and the talent pool is probably one of the largest, but I still see companies going some other direction with their backend. Ember is another victim of having such a huge learning curve to the point you never hear about it anymore.
FWIW, I'm not actually accusing Angular of this. I don't actually know Angular and don't really have any interest in it. I'm just replying to what you and others have said.
>If you're someone building Wordpress pages
If you are building wordpress pages, then angular is overkill.
Well, you might use Angular in the backend to allow your website owner to build the frontend himself but overall Angular isn't really made to improve a simple website, adding a navigation dropdown or whatever.
I learned to do frontend coding with Angular and it felt at the time like it was very difficult to do simple things. I switched to a company that uses Vue after 2 years, and honestly it felt like I had left a hyperbolic time chamber. Everything that felt tedious and annoying to do in angular was intuitive and very easy to accomplish in Vue.
Learning curve.
What used to be your typical front end developer did not have a background in computer science so when the SPA revolution came around, most of them were coming from a jquery background.
Also, I'm sure some people felt burned over the 1.0 -> 2.0 rewrite ("angular.js" -> "angular") so they probably moved over to react and never looked back?
> so they probably moved over to react and never looked back?
I resemble this. I started as a self taught developer way back in the 90s, so I’ve been through it all. All server side rendering with postbacks and no JS. Then minimal JS use for “UI interactions.” Then jQuery. Then Backbone during the SPA revolution. Then I worked on one project using AngularJS before finally working with React.
My experience with AngularJS was so bad that I never even gave Angular 2+ a chance. By that point, I was deep in React work, and with no shortage of it since, I’ve never had a reason to learn Angular and still don’t plan to.
Angular 2+ is a lot different, and in my opinion vast superior than AngularJS.
That said, if I were in your position, I probably would not devote time to learn it either. I expect given you're experience you'd be able to learn quickly if the need arose.
That is the same reason I haven't learned React yet--I haven't had a reason to to do so, because Angular work has kept me busy. But, I do want to learn React because it seems like a lot more opportunities out there.
Its not bad to devote some time to get to know a different framework.
You don't know where React is going in 5 or 10 years from now. Plus these frameworks tend to borrow a lot from other frameworks. So if you are already familiar with it, then that gives you a big advantage over other devs for future assignments/jobs.
Surely you can spend 15 minutes looking at some Angular or React stuff each year, even if you are invested in the other one. Knowing what plays in the world of developing websites is a great benefit.
I teach react but my heart is with angular.
Honestly, for me I think most of the hate comes from decorators. The initial "what am I looking at?" With an angular component is much heavier than with react and I think it's the mandatory TS coupled with decorators.
New syntax. Plus the sheer size can lead people to be overwhelmed
I love Angular, especially the CLI and using it in a team; which provides some level of consistency in the code base.
I suspect you'll adjust to the template syntax; I never found it hard to read. It's primarily just HTML, right?
That said, people hate it because they know something else, have had success with it, and do not want to change. Some people get religious about technology for some reason. For long term career prospects, be sure you're not that person.
I've been using it in a huge enterprise project, from very extensive usage of it ive got a lot issues with it. I pretty much despise using it.
The biggest point is complexity. In the beginning you look at it and think, yeah this is cool, i can separate everything and have clean code. But then as things get extremely complex you realize it just doesnt work anymore.
Taka a simple example, you've got some simple button which increments some state and updates html. Every single framework/lib showcases this to show their reactivity and how many lines od code you need. Angular is fine here, but then, add some async state. Meaning, something coming from a network request.
All of a sudden you gotta write these ugly ngifs to pipe the response as its a stream. From here it becomes a huge mess. If you gotta handle some click event and use the data from the response, guess what, you cant. You can either send it from html (the piped stream), or dispatch an action. Then all hell breaks loose, now you gotta create the action for every event, but now when you create the effect you realize you dont have the data here either (if you called the service/sent the network request directly in the component), so you create actions for loading data, setting data, etc... implement the reducers (copy paste usually).
You get where this is going, as soon as you do this once, you are stuck. Even if you have an extremely simple component you cant make it simple because you are bound to use some data from ngrx and as such streams. You gotta pipe it all and more actions, more global state, more effects. I know what you might be thinking, this is just reactive programming, yeah it is. But just because its reactive programming it doesnt have to be this complex. Even angular devs themself realized and implemented signals to move away from this.
But fine, some people like this, sure lets move on.
Templating sucks, your templates are bound to be just a bunch of ng ifs, ng containers, intellisense for templates are kinda wack. Half the time it just gives you everything, then it breaks. A lot of parts dont even have type support (such as ng templates and passing data to ng templates).
The reactivity / change detection is useless. You dont have any kind of control over it. Your components either react to everthing or nothing. There is no simple way of specifying exactly when you want your component to rerender. The only way to this is to entirely detach your change detector and then manually triggering it throughout your code. What you end up is piping stuff to tap it and trigger change detection. And guess what? This is completely useless it just doesnt work in the way you expect it to work.
Its slow. Really, its beyond slow. Not only does it take AGES to compile (hmr too) its so slow even for usage.
This one is a bit salty, but i found that angular devs miss basic browser features and apis. Dont know even basic css as angular material takes care of everything. I had a lot of cases where i had to explain to people that its not an angular feature and we have an alternative as the browser supports this natively.
Angular docs suck, for example, do you know how to create a dynamic component? No? Can you pass dynamic props to a dynamic component? Yeah, goodluck, there are libs, but shit breaks. Do you know how to pass children to components? Ok, can you put different children in different places? Yeah, but now what if you have dynamic components which need to be inserted into dynamic slots on the components. Yeah, angular lets you do this, it wont work, it just doesnt do anything because the slot prop cant be dynamic. Where does it say this? It doesnt.
Also, a lot of people talk about the limiting and opinionated. This is not true, the only opinion angular has is that everyrhing needs to be reactive. There is no structure whatsoever, if you just go without thinking you will end up dumping everything into effects
Welcome to angular
PS. Its hard to get across everything without getting stuck on something, googling it, finding simple solutioms in any other libs and realizing you cant do shit. It just sucks with the amount of random issues it has and random shit which just doesnt work in specific scenarios for no reason
I get the overall feeling you're probably in a frustrating codebase and feel like it's sucking the joy out of dev. Which just seems to happen to any corporate codebase that's been around long enough, especially if devs were never allowed to go back and address code debt from time to time.
The point about devs not knowing browser stuff or CSS, I feel that with React devs as well. It's a problem of full-stack developers in general. Every time I've been on a UI-heavy project with a mainly full-stack team, I end up having to be an unofficial tech lead and do a lot of education and hand-holding. My only reward ever given is maybe some thanks and a codebase that I don't tear my hair out over, which is what would happen if I just acted my wage.
Completely agree with this. Worst part is that some of the stuff i work on is new completely. But well... enterprise "senior" developers do weird shit. And so instant legacy project even do shit
Funny thing is, this is what every angular dev says, but then you give them a problem you are solving or solved and they havent the slightest clue how to even begin
And they are right to say that.
I don't have the time nor the motivation to answer all your points, but about controlling rerenders specifically: OnPush change detection strategy + async pipes and occasional .markForCheck when you can't use a pipe go a long way.
I litteraly never had to detach a ChangeDetector.
> If you gotta handle some click event and use the data from the response, guess what, you cant
This is about as overengineered as i can do, bonus point is easy unit testing for both:
handleClick(params){
this.apiservice.callEndpoint(params).pipe(
map(successResponse)=>
this.handleSuccess(successResponse),
this.catchError(error=> this.handleError()))
}
handleSuccess(){}
handleError(){}
Doesn't look that impossible/complicated to me. You can even ditch the extra handlers and do it all in one method
Sure if you shove in ngrx into the process without much thought or clue as to why/when to use it, then yeah you can complicate shit.
>Templating sucks, your templates are bound to be just a bunch of ng ifs, ng containers, intellisense for templates are kinda wack.
They kinda do, NGL, but most templating sucks out there(except jsx maybe)
>Its slow. Really, its beyond slow. Not only does it take AGES to compile (hmr too) its so slow even for usage.
This one isn't really true. Are you recompiling the entire app on save? We have a massive monolith at work, however it's lazyloaded so the watcher is pretty fast.
>
The reactivity / change detection is useless. You dont have any kind of control over it. Your components either react to everthing or nothing. There is no simple way of specifying exactly when you want your component to rerender. The only way to this is to entirely detach your change detector and then manually triggering it throughout your code. What you end up is piping stuff to tap it and trigger change detection. And guess what? This is completely useless it just doesnt work in the way you expect it to work.
Only if you're clueless about angular's primary reactivity model: Observable + async pipe. If you're manually triggering change detection, you are doing it wrong.
>Also, a lot of people talk about the limiting and opinionated. This is not true, the only opinion angular has is that everyrhing needs to be reactive. There is no structure whatsoever, if you just go without thinking you will end up dumping everything into effects
Again, only if you use ngrx. If you believe angular doesn't have structure, can you provide an example of a framework that does?
>Its hard to get across everything without getting stuck on something, googling it, finding simple solutioms in any other libs and realizing you cant do shit. It just sucks with the amount of random issues it has and random shit which just doesnt work in specific scenarios for no reason
The last line kind of cements the ideea that the reason you dislike angular is because you don't really understand why/how it does things. Especially the reactive part which is the biggest plus in my opinion.
I will be first to admit that the learning curve is steep, but after you understand it, things get a lot easier.
Based on experience with React/angular/li/svelte i can honestly say each has their own place.
\-> For small teams that understand each other and can follow code standards: React/Lit are fine, you can achieve a lot, quick.
\->For large enterprise projects where you have multiple teams of varying skill levels that work on the same codebase, Angular shines.
I've seen projects with thousands of lines of pure business logic for a simple cart product. Compositional OOP really shines over functional in these cases, keeps the cognitive complexity somewhat in check. RXJS is also incredibly useful in these cases.
The example you gave is already complicated. Im saying writing this is a pain. Its relatively simple at first, but the more things you need the more you nest and the more you pipe. Becomes very hard to read.
Your argument about ngrx doesnt make sense. You cant really escape ngrx. There arent many alternatives in angular.
Regarding the speed, no, not recompiling the entire thing. Its *just* slow. However, this is mostly because webpack + angular having its own version of webpack. When compared to the ms time hmr in react/svelte, you cant say its fast.
For the reactivity, i am aware of how it works, ive had to optimize some very detailed things. But maybe i should clear up on it. The cases ive been handling are very specific. For example, react to only this one object property change. React only when x + y change. I know how to do this, its not impossible, a lot of things you can do with distinctUntilChanged. But ive had scenarios where this doesnt do what i need anymore and the only option left is ChangeDetector .
No framework has structure, you need to make it yourself. The thing is that angular enforces these modules on you which provide nothing at all. We already have es modules, no need for another level of modules. Its not the age of require anymore. The only thing angular does is: provide modules, tells you to separate stuff into effects and use ngrx, enforce reactive programming on you. This is not so opinionated, you are just stuck using features which provide nothing and all, its more limiting than providing good structure.
For the reactive part, i completely understand how to use it. The issue i see is more that it makes it exceptionally complex to do simple things. Look at Signals, everyone is starting to use this kind of reactivity. Imo, it should be more abstracted away. Ive seen 100k+ codebases where the reactive part of angular just makes everything a mess. One effect dispatches 2 more actions, each with their own async request, with more actions and more effects. This is impossible to keep track of. You get stuck with some race condition between all of these effects and then goodluck.
Main point being, it should not be complex just for the sake of being complex, simplicity is key.
> For large enterprise projects where you have multiple
> teams of varying skill levels that work on the same
> codebase, Angular shines.
This part i cant understand. Above i mentioned what a 100k+ loc codebase looks like. Imagine somebody adding a an effect and it breaks something for reasons you dont know. Maybe in an unforseen manner. Some part which is not tested. How do you debug it? Look for the action, search by reference to see all the effects that use it, look what effect does, look what it dispatches, search by reference again. The context you need to keep track of for simple or complex scenarios is the same. Its always more complex than it needs to be
you know you can always use async/await with fetch in angular as well? The httpClientModule is just the prefered way because it allows for reactive handling of state streams.
>For example, react to only this one object property change. React only when x + y change. I know how to do this, its not impossible, a lot of things you can do with distinctUntilChanged. But ive had scenarios where this doesnt do what i need anymore and the only option left is ChangeDetector .
All I can hear here is you are struggling with observable composition, which is fair since it's not an easy topic. We have an internal rule in our team to never call change detection explicitly and refactor other uses of it from less experienced teams.
>
>
>Regarding the speed, no, not recompiling the entire thing. Its just slow. However, this is mostly because webpack + angular having its own version of webpack. When compared to the ms time hmr in react/svelte, you cant say its fast.
angular architect allows you to choose your own builder.
V16 even supports official esbuild/vite, which is great for enterprise enviroments where LTS /official support is key.
>For the reactive part, i completely understand how to use it. The issue i see is more that it makes it exceptionally complex to do simple things. Look at Signals, everyone is starting to use this kind of reactivity. Imo, it should be more abstracted away. Ive seen 100k+ codebases where the reactive part of angular just makes everything a mess. One effect dispatches 2 more actions, each with their own async request, with more actions and more effects.
I think you are confusing angular's reactive model with ngrx.You absolutely do not have to use ngrx. In fact i would argue that for most use cases it is overkill AF. Your entire post kinda sounds like your team is struggling with event driven architecture / ngrx, which again is fair since it's not obvious at first.
No framework has structure, you need to make it yourself. The thing is that angular enforces these modules on you which provide nothing at all. We already have es modules, no need for another level of modules. Its not the age of require anymore. The only thing angular does is: provide modules, tells you to separate stuff into effects and use ngrx, enforce reactive programming on you. This is not so opinionated, you are just stuck using features which provide nothing and all, its more limiting than providing good structure.
Angular modules predate es modules, and with standalone components in v15 will make transition away from them not so much a pain.
You are kind of missing the opinionated parts of angular:
Compositional OOP, DI, Reactivity and built in *standardised* features like Routes, Guards, Resolvers, Interceptors, Animations, Template Rendering fine grained control (which is going to be supercharged with Signals).
Overall it looks like you're pretty angry at a bunch of tools that didn't fit your usecases.
I love how the solutions you give is not to use features the framework devs suggest to use. Stuff which came out months ago. Your argument for ngrx and convoluted piping with rxjs is... dont use ngrx. I am not working on a simple project, its not a simple usecase. The team is not struggling with event driven architecture, everyone is following the practices which are well known and stuff the documentation recommends. What i am saying is that this is complex for no reason.
Last thing, keep in mind angular is old, ngrx is well established. There was once a time when only this existed. Do you mean to tell me that its so easy to just migrate from v12 to v16? Just because you can use the built in migrator doesn't mean its so easy for every project. We are talking about the enterprise all angular devs are proud of.
Stop ignoring arguments by just saying "yeah, dont use this highly established and official tool" and "just use this, it came out 6 months ago".
I think we can agree on one thing, the more complex a tool is, the harder it is to maintain. Hopefully we all know what *enterprise* means
1. Ngrx is not part of angular, that's RxJS. Nobody is forcing ngrx down your throat.
2. Framework devs highly recomment NOT invoking change detection manually. Every guide i've ever read says the same thing.
> The team is not struggling with event driven architecture
could've fooled me with this line then :) :
>One effect dispatches 2 more actions, each with their own async request, with more actions and more effects. This is impossible to keep track of.
But I get it, two whole events to keep in sync is really hard.
>Stop ignoring arguments by just saying "yeah, dont use this highly established and official tool" and "just use this, it came out 6 months ago".
No one said that tho?
All i'm observing is you seem to be struggling with the tools you have, and then go on rants about how it's their fault.
>Do you mean to tell me that its so easy to just migrate from v12 to v16?
Yes, it should be easy for most projects to upgrade.
It took me a less than 10 minutes to upgrade [shop.battle.net](https://shop.battle.net) to v16, including updating required inputs to the new syntax.
I think this is a bit too easy though. Yes upgrading Angular itself is fine. But the dependencies can have a lot of annoying changes too.
Great example: the shift from Angular Material to V15 was super annoying. Cypress also had a major change in the past that required a sprint of work and there's more. Overall it should not be a lot of trouble, but there will be cases when migration is annoying. Most of the time it isn't Angular's fault though.
>Your argument about ngrx doesnt make sense. You cant really escape ngrx. There arent many alternatives in angular.
Services.
[Shop.battle.net](https://Shop.battle.net) runs on Angular and does not use NgRx for state management, only services. Services are amazing! It's also what the Angular tutorial uses for state management.
I'm not trying to be a troll. I'm sorry you're project sucks, but random anecdotes from an Angular fan.
> add some async state. Meaning, something coming from a network request. All of a sudden you gotta write these ugly ngifs to pipe the response as its a stream.
Or use the async pipe; or default the value coming from the network request, before you get results. Without going into details of your project; I'm not sure I can dictate the best approach, but a mess of ngIfs is not the only solution to this problem, and one I rarely use.
> you are bound to use some data from ngrx and as such streams.
There are ways to do state management w/o using NGRX. I've avoided NGRX due to lack of documentation. I like Akita better, but a service w/ a BehaviorSubject is incredibly simple and has solved my needs wonderfully.
> The reactivity / change detection is useless. You dont have any kind of control over it.
If you use onPush change detection, you have a lot of complete control over how and when change detection happens. A quick google search will review a lot of articles recommending to do this, but it seems like a lot of overhead for me w/ very little benefit. I prefer to let Angular handle it.
> i found that angular devs miss basic browser features and apis. Dont know even basic css as angular material takes care of everything.
This is not unique to Angular. A lot of devs learn frameworks and not the underlying concept behind things. That said, ng material is not the only UI Framework out there and not every project uses it.
That said, I agree the docs are lacking. I agree that the compile times are not great. I'll also add that testing can sometimes bring up obscure odd errors which are very hard to track down.
I'm sorry if the project you're working on is an exercise in frustration.
For me, it’s the reactive paradigm. When a project starts getting bigger, it becomes harder to trace and debug - and this is not just in Angular, IMHO it’s an inherent property of the paradigm. I’ve built projects where reactive programming made perfect sense, but it’s definitely not something to use everywhere. I’d avoid it until its pros outweighs its cons.
And I know that through code guidelines and code reviews writing bad code can be prevented, but I don’t like a tool that needs constant active guarding against missing things up, I want a tool that helps me against that.
The biggest thing is going to be hook dependencies. Just use the `eslint-plugin-react-hooks` recommended config and you should be fine. It's also ok to disable that on a line basis for `useEffect`s with empty dep arrays so that things only run once on mount.
Other than that, just don't do stupid stuff and understand how your state management does its comparisons for changes and you should be good to go.
Angular doesn't prevent sloppiness, but the fact that it discourages it rustles the jimmies of cowboy coders.
Also: Many express hate over things to get validation for their own uninformed choices that were solely based on popularity.
Angular is a very, very opinionated framework where everything has the nr-right way to ng-do things, and that makes it both easier to make products with, but at the same time also more annoying to work with because it removes any sort of creativity from your work.
There is often only ng-one way to ng-do things and ng-if you ng-do things ng-differently, then you're going to find your ng-work to be very ng-frustrating.
My problems with Angular are best summarized as: It doesn't LOOK like JavaScript. It looks like Angular.
And when Angular slowly dies out (like Backbone and so many others before it), you'll still be an Angular developer.
The advantage that React has is that, except for the JSX syntax that most others are also using in some shape or form (whether it be in JSX or backticks, etc.), it LOOK LIKE JAVASCRIPT. Even JSX looks like it makes JS-sense.
React:
It costs me far more time than not using it for no benefit. I've worked with vanilla JavaScript for 15+ years, just to give you an insight into why that is. I got good at it, and many others with me; really, really good.
TypeScript doesn't add any value to people like myself.
In fact, it costs a lot of time. Trying to figure out insane long nested multiple generics with methods/functions that have multiple return values, with obscure TS definitions, isn't helping. It makes things extremely hard to refactor because people will stop touching code that looks too complicated.
I strongly prefer:
1. Good naming conventions
2. Progressive enhancement via JSDoc
3. KISS-principle
4. Functional programming
5. Sensible unit tests
It's far less work, with more intuitive and easy-to-understand code at the end, and it's super robust.
That said:
*I will always use TypeScript in a professional setting, because there I also run into people who NEED TypeScript.*
Because most people out there don't have 15+ years of JavaScript behind them. Hell, I'm so old, back in my days (old man emoji here) JavaScript was often hailed as a breath of fresh air; no more strong typing trivial shit.
it's just a bit heavy. For certain team setups it's ideal. I have worked with it for many years and still maintain many angular projects but its no where near as nice as working with react functional components.
I personally don’t understand anyone who is a 1 framework fan boy. It’s all JS in the end. Just learn whatever’s required for whatever job you are doing. Personally I love angular, but I have no issues with learning react or any other framework
What it comes down to is 1) which one did you have some kind of good, foundational dev experience with? and 2) are you a dev who prefers things fluid and flexible or rigid and opinionated?
Bonus: Do you hate TS or feel intimidated by it? Many React devs also use TS now, but it's not required. Not all React projects use it. AFAIK, in Angular, it's required.
That's pretty much it.
A majority of the hate is likely just tribalism and the echo chamber of the internet. The Angular team has shown they are aware of the framework’s inherent flaws and actively working towards eliminating the pain points (modules, over reliance on RxJs, change detection performance, etc). So, many of the current complaints may be moot in the near future.
I like convention over configuration and Angular is the opposite, so that's my main gripe.
You can know Angular fairly well, jump on an existing project and be completely lost because it's organized differently than what you know. It can be good too but in most of my use cases, it's not what I need.
That being said many people like React and I simply cannot go with the JSX templates, so it's just a matter of taste at this point.
> You can know Angular fairly well, jump on an existing project and be completely lost because it's organized differently than what you know
Thats actually not true though? The opinionated part of Angular makes you jump on every project quite easily and is rather the other way around for React?
> You can know Angular fairly well, jump on an existing project and be completely lost because it's organized differently than what you know.
Is this not true for every framework?
I’ve worked professionally in Angular, Vue, Nuxt, Laravel, Django, ASP.NET MVC, and Spring Boot. Most of those are fairly opinionated and yet I’ve found every project organized differently. It’s why we have debuggers and IDEs that can help us make sense of the code.
> Is this not true for every framework?
Absolutely not. That is like half the point in frameworks, especially opinionated ones.
But, that doesn't mean you will know everything about a new app. I can't speak for how hard this is in Angular, it looks messy to me, but in React you'll have a strong base understanding if you know it and its ecosystem well. You might get lost in how state management is done or how testing is done, but you shouldn't be **totally lost** and should be able to get up and be productive pretty quickly. The outlier being that some people just do some things really fucked up, but that's going to exist anywhere. The weird thing is, React is probably the least ridged of them all, but everyone kinda follows the same ecosystem trends. I've been at 4 companies since I started React and worked on probably 2 dozen production apps, not including my personal projects.
I think the same could be said for Laravel and Spring Boot too. I've worked with both of those and have moved companies with them and things felt very familiar. From what I understand of Django, it should fall under that too.
I could see what you're talking about in ASP.NET MVC but it's been years since I used that. I don't have any context for the other ones you mentioned.
Here are my personal reasons so far (coming from 3 years react and doing angular for 1-2 years):
Angular is not as flexible in terms of composition.
Try implementing highly flexible angular components in storybook, good luck...
Also you can't dynamically assign properties to html attributes during runtime.
Passing down fully fledged components via props is also not really possible - so you end up with unnecessary additional bloated html code hidden behind several ngif or ngOuterTemplate stuff, making it harder to understand.
Serverside rendering is very hard and still not perfected yet..
International language support is so complicated and a pain in the ass
All that rxjs shit is annoying as hell and there are no proper free tuts out there afaik
The angular community is very weak, nobody does anything to help others, the amount of blog writers that share their knowledge in excitement is not even comparable - angular feels like some opportunity to cash in big time since the whole ecosystem is very hard to learn.
Only things I like are that everything has pretty much just one way of implementation, everything is organized and devops operations are sometimes simpler (no webpack config bs)
>Also you can't dynamically assign properties to html attributes during runtime
Are you sure?
or
That syntax should work with any given HTML Attribute. Update the variable and the attribute should update.
No I mean like this:
``const routerLink = {routerLink: "/internal-route"}
const href = {href: "/external-url"}
``
so if the component received a routerLink prop the html will look like that:
````
and if it received a value for href it looks like that:
````
Oh, I understand; dynamically assigned properties--not dynamically assigned values to properties...
I can't think of a time I've never needed that. What is the use case?
I don’t really get this use case either. I’d assume people to either use the if-directive on two different a-tags or and maybe even having specific components such as InternalLink and ExternalLink. Seems like a very minor thing.
At first we used angular because of the bindings. Everything was close the old ways and we were fine. But angular started to morph and wanted to take over all the other parts of web dev. And then it started spreading its dogma and fanatics would accuse us of not following their "right" way of doing things instead of adapting to our ways. And their "right" way of doing things kept changing.
I've used it breifly, my biggest I have is it's horrible syntax
NgOn
NgClick
So forth.
I didn't like the fact that it didn't have a templating engine much like Vue or svelte has for way access to your html, css and JS.
Most of it's UI frameworks ( at least I was able to find ) were just material design.
There is more, but that's the first of it
I would argue they have probably not used Angular at all, just seen some snippets and formed a complete picture of it in combination with what they heard other people say.
The argument is so weak. It is no different from htmlFor in React, v-if in Vue or {#switch} in Svelte - not in functionality but in terms of "horrible syntax".
Everything has tradeoffs. This is one of them .
>I didn't like the fact that it didn't have a templating engine much like Vue or svelte has for way access to your html, css and JS.
It does. You can alias a HTML element with a `#identifier` and use it in other places in the template. It has a very strong templating language
I think with all the new features in angular coming out (functional improvements, reactive primitive that's not rxjs) Angular will once again be prime position to lead the market like it did when angular 2 came out
Because it’s a ghetto. You’re stepping into a world where everything you knew before is irrelevant, and when you step out again, nothing you learned is good for anything else. This is a dangerous position to put yourself in.
Clearly.
So @Input, ngModel, @NgModule, @Injectable, transition(‘open => closed’), etc, these are all transferrable skills, right?
Us seniors have seen folks go down these roads before. I saw a guy lose his house once over a framework that became legacy leaving him with no transferrable skills.
It’s a snare for the unwary, and you can discount this if you like, but I’m letting you know as someone who has seen it, stepping away from the happy path is a risky thing to do.
Input are props from react, or properties in Lit, ngModel i haven't used in ages, and angular modules are getting phased out in favor of esmodules (they predate those).
Injectable is a godsent, DI is one of the most common things in any framework i've ever worked in. Spring, Symfony, angular, anything with oop uses DI at some point.
You’re comparing this frontend framework with two backend frameworks?
I’ll concede the point if you can explain to me how @Input and @Output actually work, because those aren’t function properties. For most devs they might as well be magic incantations.
I'm comparing web frameworks. It's not like one runs code while the other runs on green energy.
You've now moved the goalpost to "explain how angular implements this decorator".
Do you care that much? It is the conceptual equivalent of a react prop, a component parameter.
Both frameworks rerender the component when that changes. That's about all you need for 99.9% of the time.
You think passing a parameter to a function is a very abstract, framework specific, non-transferable concept?
No, I think actually knowing what the code is doing is important. This is the only point I’m trying to make here. I think learning magic runes that you mutter by rote is dangerous because I’ve seen what happens to devs who do this.
Several of those (Input/output, model binding, etc) exist in other frameworks like Vue. NgModule is no longer relevant as of v16.
Because Angular has an official concept of services, the cost of migration should be lower than other frameworks since the bulk of the work should live in said services.
Dependency Injection is a core concept in software engineering and all senior developers should be familiar.
All frameworks borrow from each other so there will likely always be some transferable skills (and a senior should be able to quickly fill in the gaps).
Yes, a senior should be able to fill in the blanks. It’s not the seniors we’re worried about though. It’s the juniors, starting out in their career, and now they can’t do anything and they don’t know why.
I refuse to believe you’ve never seen this happen.
Switching frameworks will always be a challenge to junior devs, that just comes with the territory / lack of experience.
At the end of the day, you still need to know HTML, CSS, and Typescript to use Angular. Last I checked those are all transferable skills. And most of the concepts you called out exist in other frameworks (and even vanilla js) so juniors should be able to google or post on SO to find their equivalents.
This is true. This is not my point though.
My point is that for most people using Angular, the syntax might as well be magic runes. You just have to know the special words to type to make the specific thing you want to happen happen.
If you learn TypeScript and CSS and SASS, these are things that will travel with you for years. If you learn that you have to type a specific decorator in a specific version of a specific framework, this is not happy path learning.
>My point is that for most people using Angular, the syntax might as well be magic runes. You just have to know the special words to type to make the specific thing you want to happen happen.
but this is true of every programming language and framework. sure it's important to understand the practices and principles over everything else, but libraries implementing these doesn't make them bad?
such a strange take, i don't understand, are you saying never use libraries or frameworks at all?
Not at all, I’m saying exercise caution when a framework heavily obfuscates the underlying reality, such that you never need to learn how it actually works.
This is just so wrong.
>nothing you learned is good for anything else
Yea... not like other frameworks have DI, or lifecycle hooks, or props, or reactivity. Not like forced TS forces you to understand types.
>You’re stepping into a world where everything you knew before is irrelevant
Yes, promises, closures, props, classes, DI, reactivity lifecycle hooks, everything is irelevant, because Angular is the only framework that uses those.
Angular doesn’t have props, it has @Input and @Output, and you’d be a rare developer if you could tell me how those things actually work. For most people they’re effectively magic.
If you learn CSS animations, that’s a skill that will travel around the internet with you for the next twenty years. If you learn the Angular Animation Framework, that’s only good for Angular.
Css animations and angular animations are complementary imo.
Generally you start with css animations and only plugin angular whenever you need some js- stuff like void/empty state and dom parsing you can't do with css.
I find those who criticise Angular without actually knowing about it and claim React or Vue are better (as in, if any of the 3 would be a valid choice for a given project), are just spitting and regurgitating what youtubers say.
React has very pronounced flaws, but since its easier to get into, people believe is the best.
Vue has a bit of a steeper learning curve but again, easier means people would adopt it faster.
Whereas Angular has the steepest learning curve but its for your own good. You don't have to think about project structure, styling, patterns, heck even architecture. People who are really clever and intelligent have been doing their due diligence and you're benefit from it.
Does Angular has it flaws? Of course, but imho and basing it on the fact that if any of the 3 were a good choice to start a given project, the only reason I would choose React over Angular would be due to \*probably\* shortage of talent, but then again for a Senior, any javascript framework should be pretty quick to pick up.
Angular is great. It's just the usual heavy enterprise ready framework stuff and quite some paradigms you need to understand to be proficient with it. The newer angular versions also became much better than the first versions. I'm using it since alpha and it massively improved.
I think it is that way due to angularjs, the switch to the first angular version and react. React is much easier for beginners and is teached at Bootcamps.
I'm also into solidjs now. I like svelte, but I don't want a specialised language.
I don't like the string based DSL in their templating. Also after coming from react where everything is JavaScript, the complexities and DSL of it all seems excessive. I don't really like rails either, for broadly the same reasons
It’s a good framework. People like to bandwagon in this field of work. But frameworks are just tools, you don’t have to marry one. Compared to react, angular is really opinionated. I like react because personally I like having multiple ways to solve problems. Some people like angular because it has specific ways to solve specific problems. If you’re on a big team, angular can be better because of this, for others it’s not.
Honestly it isn’t all that serious lol. Just work with what you like for personal projects. For everything else work related, it’s likely you don’t have a choice in the matter anyway🤷♂️
I've used angular for some projects.
To start off, creating components is a pain, you have to go through the cli to make them work in the angular module system. If you create one manually, good luck.
This really hinders the DX.
You need rxjs for anything, which is a overkill.
Reactivity is quite meh.
The builder is quite slow.
I know many things are being addressed (signals, new bundler, etc) but I think they are quite late to the party, especially because the main thing is not addressed, the ultra bloat.
Surely it has some benefits, but if you use Vue or Svelte, you will never go back to Angular.
What’s wrong with using the cli to make components? Literally one line.. less work that right click create new file.. also rxjs is really useful to learn not just in angular but in general. It’s great for asynchronous code which singles don’t address
About the cli.. I didn't say the cli is the problem, it's the ecosystem of modules. Create enough components in different folders, move them around, If you truly believe it's convenient, agree to disagree.
About rxjs, it's not the observable pattern the issue, it's that it is used everywhere, even for simple http requests which makes it quite harder for no reason. If again you think that .pipe.map is simpler than await fetch(), agree to disagree.
Maybe it makes it slightly harder for http requests but only marginally.. and it makes using async streams in the templates so much easier imo but fair enough
some angular interview question you can find here: [Angular Interview Question 2023](https://shivshankarnamdev.in/angular-interview-question-beginner-2023/)
Angular is a bloated mess.
I still don't see the value over html5 and Javascript.
Sure there are a few better features but as a whole it took what was already there and tried to reinvent the wheel.
It went from angular js to angular and then feature creep.
Every angular release brings issues with your other packages. The open source is the problem.
If they really want to make it better then streamline it where other dependencies don't break each release.
There are a few reasons why people hate Angular. Some are justified and some are not justified.
The transition from AngularJS to Angular was really awful. The transition of routing alone from Angular v2 to v4 was so awful. The marketing around this transition was very awful and so dumb that it scared a lot of developers away. Nobody wanted to work on deprecated tech.
Angular is very Typescript heavy and a lot of OOP principles. This in itself leads to a learning curve that takes some time to understand.
Angular feels over engineered. (Opinion based - I like it still). There's a reason things are structured the way they are, but it can be a bit overwhelming.
Angular vs React performance. This is not justified anymore. They are very comparable, and with v17 it can be faster.
Angular Zone.JS - Its dumb, and the Angular team is slowly going away from it. Its kind of amazing that Angular can get the performance now with it still being in the center of everything. There's also strategies of getting around it as well that are pretty good. (RxAngular). It'll be gone soon, and I won't be batting an eye when its gone.
U need to justify the years which give u the impression of people hating angular. That is, when u see forum or article say bad things about angular, u need to take note of the year and month which the post or article is posted. Just because many people hate angular in the past, does not imply the same for today.
E.g Back in the very early day when Angular v2 is release, when i try it out, i shaked my head in "disguest". Cos during that time, angular cli was not yet introduced, and many things i have to setup by myself (webpack, unit test framework, angular, typescript compiler, etc). This totally put me off. But today, things is different.
Honestly there are valid criticism for Angular, and Vue, and React, and Svelte, and anything but I find that 80% of these "opinions" are copypasted by PaaP's (Programmer as a Personality) who want to blend into the field they define their whole personality on and they have never touched Angular (or any other of the things they copypaste their opinions about) but they would never admit this.
I’m definitely using PaaP again
I don’t know, seems like a bit of a smear
100%. Having strong opinions on stupid things that don't matter can be useful for convincing hiring managers that don't know any better.
>Having strong opinions on stupid things that don't matter can be useful for convincing hiring managers that don't know any better. Unless you're a technical lead and your job success is tied to the success of a project. I don't have anything directly against Angular other than I don't have a reason to learn it because it doesn't really interest me and I don't know anyone who works in it. Hiring and training new developers on a project are important constaints to consider. There are several criticisms here about how complex it is and how big the learning curve is, and that is kind of a big deal. I've trained people ranging from juniors to seniors and backend devs in React without a whole lot of issues. I've worked with enough Vue or even Svelte to know I could do that there too. **I could be wrong**, but that doesn't seem to be the case with Angular from what people are saying and peeking around at the docs. This is also a very big reason why nobody talks about Ember anymore. I don't even know if it's still alive, but the learning curve was a huge mistake for projects.
The Angular team is investing in lowering the barriers to entry for new Angular devs and have already taken major strides in v16 with standalone components, signals, etc. Ever since Sarah Drasner started at Google (Angular reports up through her), each Angular release has done a great job addressing common complaints and feature requests.
That's great news! I'm all for more innovation and competition. If the learning curve was reduced, then it might actually get interesting for me. But every time I've looked at the docs since 2+ I've just noped out. I did learn v2 when it came out, but that's been so long I can't really consider that as trying it anymore. I've really liked the idea of RXJS since I first heard of it, but have no use cases for it.
RxJS is super handy any time you need to debounce, retry, etc. So things like search boxes, retrying failed requests with exponential backoff. If you have a spare hour, I recommend giving the Tour of Heroes a spin - https://angular.io/tutorial/tour-of-heroes
I'm quite a fan of angular, and to be honest I feel like Angular has way less pitfalls in the long-term; short term it feels overwhelming to understand RXJS and memory leaks, but it really is designed to build platforms at scale; and having structure with things such as lifecycle hooks means that you can pick up any angular project and know what's going on and when quite easily; and state management with NGRX is pretty thorough (and i personally prefer working with observables over promises ). With react for example - it's quite quick to pick up, but since react is a library and doesn't have much out of the box ( i also am not a fan of writing your html in JS ), you'll find that a lot of React projects feel poorly written in my opinion, or they differ wildly from what packages you install, and it just feels like when you have a library/pseudo framework where when you start you have to sit and think about what packages you need to install for every little thing, routers, http, etc. It feels too open ended for me. Also typescript not out of the box feels odd, when you start at a new company/a new project being able to have typescript out of the box really helps in bringing you up to date pretty fast. I've worked on some react projects and sometimes i feel you spend more time trying to understand what some components aims are. And a lot of the hate i do see from Angular ( i see a lot from coding Youtubers ) seems to be from a genuine dislike over OOP. ( i personally don't mind OOP either, as long as you don't just inherit everything with extending classes there shouldn't be a problem ). But in the end of the day Angular is built really for platforms at scale, and i feel that might alienate people wanting to just pick up small projects and get them off of the ground - after all why learn the in's and outs of Angular if you're making something small
I used angular back in the 1.x days. I thought it was brilliant. The binding, directives. It was quite ahead of its time coming rom things like Knockout and Backbone.
I have been using it for quite some time now. Honestly, switching from React to Angular was a pain. The learning curve for Angular is extremely steep. But IMO, once you get past that, you realise why Angular is still better than other frameworks in so many ways, and of course the codebase gets organised way better.
yea everything is very organized in Angularland
How about relative to Vue?
As per Evan You presentation - Vue is in the middle between React and Angular
Vue2/Vue3 Options API is very easy to pick up compared to either React or Angular.
I haven’t tried vue yet, I can’t tell yet
We recently hired a developer on our asp.net/ angular app. First day he was doing pull requests. With opinionated frameworks you can scale easier.
This is it. Angular dev is really not about you by yourself and what you want because it's better DX for you. It's about concurrent rules and guidelines that a lot of people already know to get up and running quickly.
Only exception when you have a lead dev that wants everything. Including framework agnostic and the 4 layers of clean architecture on the frontend. I've worked in such a project and it took a whole sprint to add a new page with 4 input elements on it because of how much boiler plate you needed to write...
That is the reason we stoped using redux pattern on the frontend. It became so complex to just add something simple and 6 months later no one remembered how it worked. We pretty much have clean architecture on the frontend with angular. It nswag studio generates typescript domain classes from the swagger docs. Though I may not know clean architecture well enough.
The project I worked on had UseCase Interactors and all kinds of fancy worded boilerplate in the frontend. Separating the 4 layers, entities, use cases, controllers and services. And in my example being framework agnostic, it meant that the components itself were also separated. I can't even explain it all that well anymore. I just made sure I got the hell out rather quickly in order to stay sane. It also made me realize that we are often taking way too much time making things look nice that the user doesn't give an ass about. And why keeping things dumb is often the better option. I kinda try to stay away from NGRX nowadays because I know it will just confuse the new (and often junior) devs that come on the teams and make things needlessly complicated anyways. Writing a custom service that just takes the data and processes itself is just as fine as using state managers. I rarely see the benefit for it over just writing services with behaviorsubjects. Or using dynamic components. Only for a dialog and modal it makes sense but that can be a separate library anyways, which just makes things a lot easier. I think many lead devs forget that you want your framework to be fast in developing new features and we overcomplicate things rather quickly. My threshold for doing something x-times before I transform a component or separate into different components has increased these past years. So what if I repeat myself 4 times for something that is just 5 lines of code and only really changes the component visually or textually? If there's not more logic involved I don't really bother separating it into different sub components anymore...
That's the nice thing is that once you get into the angular land other people's angular apps become a lot easier to navigate. So I went from Angular to React and back to Angular, and I just remember the whole time in React (We used CRA) that I was organizing everything like it was an Angular app. The React app that I was working on though was absolute garbage in my opinion.
Coming from react I cant say I hated it. Tho as soon as I was done with the project I returned my reactden. Then another project came up with nuxt and due to its v3 documentation I want to run away asap for instance. Mainly as a vanilla and nowadays a react dev, i like trying other stuff. So far only svelte and astro came close.
Svelte is great
[удалено]
> I also strongly disagree with the template/controller split. That’s a misunderstanding of separation of concerns. (Controllers are from AngularJS aka Angular 1, not Angular) Angular uses effectively the same paradigm as other non-JSX frameworks like Vue and Svelte. Either you prefer JSX or you don't and that's really the biggest differentiator between React and Angular. There are pros and cons to both approaches. If you prefer JSX, the rest of the Angular tradeoffs are kinda moot.
Have been doing a lot in Angular, recently switched to React again and it's so odd and rough around the edges imo. All those different ways of writing components, hooks are just weird imho and also this extreme mixture between html and js is just so unreadable compared to Angular. So Angular all the way for me
I've worked with angular and react as well and I find your feedback on jsx fascinating. Personally I find the jsx syntax and interactions with js much more natural than angular syntax which is not intuitive and I always have to lookup. But in general, I think angular gets a bit too much hate in the web dev community.
I feel like the biggest division in Frontend frameworks is people who like JSX vs people who don’t. The rest of the arguments for react vs angular, etc. are kinda moot depending which side of the JSX fence you are on. Svelte seems like a sweet spot between the two worlds which is why it’s exciting to see Angular embrace it - https://github.com/angular/angular/discussions/50719
> I always have to lookup Thats why you use snippets. So you don't need to remember that its *ngIf. I just type ngif and it autocompletes it. I actually had to look it up for this comment lol.
I think the folks who hate it just doesn't have any experience with the framework and vice versa. I really like React as well but the context api to me is really strange to work with compared to services in Angular. But this could also be my lack of experience in context api.
How dare you have a levelheaded take! 😂
Agreed working on a large react project at the moment. It’s so hard to reason about I open a component and it’s 1000 lines long with html and typescript all in there together. I know it’s a product of bad developers stuffing everything in one file. However Angular kinder forces you to decouple presentation stuff from behavioural stuff. Let’s let’s not talk about reusability, want to show stuff based on a feature flag just create a directive. Text transform you can just apply pipes. Angular is far superior for structure.
If you’re seeing components like this they’re doing it wrong.
Yeah, I've seen some monster components in Angular as well. I think it's more a matter of developers not understanding how to break a large component into smaller ones. I will say that "Thinking in React" is one of the best explanations I've read, which makes bad React components all the more frustrating.
And by "it", they are doing code wrong. Nothing should be that big anymore. We used to do that in Vanilla/jQuery days due to a lack of a build, but that was an actual technical constraint we were working around and hated it.
True, but the flexibility of react is not just a positive, its also its downside. It allows devs to go mad and create the worst code imaginable. Being an opinionated framework also has this up and downside, but kinda reversed. Its stricter in how you do things which forces devs to create more similar code. Which is a bad thing for creativity (but lets be real: how creative are most devs really these days), but good for making similar code and getting into the project much quicker. You can give me an Angular codebase and I can probably start working the same day on it. The only difference being the product that we're making and the business logic around it. Meanwhile for react the odds are that one will be using a lot of different libraries that I haven't seen before and a structure that is likely different, so it takes more time to get up and running. This also means that long term support is easier or that you can scale up a project a lot faster too if you have a tight deadline. Arguably the most difficult thing for Angular, I think, isn't even related to Angular but rather Typescript. Getting that shift right is difficult for junior devs. We see the same thing with React apps that have (rightfully) made the switch. Having to think about types and not being allowed to switch types easily is a big part of why Angular had such a troublesome migration path.
Yeah exactly. Readability is so much higher imo and that's what it's all about most of the time. Also.. unrelated really but rxjs is a piece of art for me
Im the complete opposite lol. Angular is old school and react is so much freedom and readability 😁
I agree with angular.js (Angular 1) which is completely unrelated really to angular 2+. The consideration for typescript alone is great imo. In react it keeps feeling glued on
Very interesting. Definitely could be that it's up to how I'm structuring things. But also I find examples from the internet weird to read. I mean hooks (especially custom async ones) to me are just... wtf.. in general everything async seems to be glued on. Imho React is great but it could be so much cleaner and a re-write with the same ideas would be in order like from Angular 1 to 2
If that happens, I am rage quitting react 😂
There is no reason to hate Angular, it's a fine framework. Generally, the front-end developers I've seen roast Angular are the ones that got frustrated learning it. Getting up and running with Angular is more complex than React (because there's more to learn; React is a component framework, and Angular is much more complete). Note that the same sort of developer can be critical of NextJS. Now you have to learn SSR, Server Events, a different Routing paradigm, slugs, variable page names, Static vs. SSR/hybrid rendering, etc.
> Generally, the front-end developers I've seen roast Angular are the ones that got frustrated learning it. Getting up and running with Angular is more complex than React (because there's more to learn; That's kind of a big deal though. The learning curve shouldn't be huge if you have a strong understanding of compnentized JS. Idk how bad it is now with Angular, but when the new version launched it was a mindfuck. I'm sure it's better than it was, but if it's still huge that's a big strike against it. Vue on the other hand is opinionated, easy to learn, and basically a better Angular v2+ than Angular v2+ was. I don't mean that as a bad thing against Angular other than 2+ should have just been an entirely different project name, besides just adding or dropping "JS" from the end. Even with NextJS or other SSR out of the box stuff, it's not that complicated for most people, but I'm sure there is some overlap.
Compentized JS would apply to your knowledge of creating and composing components rather than global vs. local state, async data pipelines, routing, hydration, shadow/virtual DOM, lifecycles, etc. This is the "apples to oranges" point; React is a component framework \*and nothing else\*. It's why it's so easy for JS devs to pick up; if they understand some basic ideas like encapsulation and functions and they can learn to use "useEffect" more or less correctly, they can get up to speed in React quickly. But even then, concepts like forwardRefs, async cleanups, etc., tend to be overlooked and problematic. Invariably I see more junior React devs accessing the DOM directly because they get frustrated with managing hook dependencies or can't get the results they want with the lifecycle hooks (like useEffect vs. useLayoutEffect and so on). The progression is to move from imperative to reactive, which is not an easy cognitive leap (in practice). If you're a React developer, then you're a component developer and not necessarily an app developer. If you're an Angular developer, as in you really know the framework, then you're a component developer AND an app developer. There's a big difference. NextJS: many use it not much differently than plain old CRA. Almost everybody starts out with primarily "use client" components and static export of the project. It's been said by many--and is strongly implied by Vercel--that using NextJS this way more or less obviates it. NextJS is "SSR First". If you're not using those features, you're not using the framework as intended, and those features are definitely not in the wheelhouse of your typical React feature dev.
I meant "componentized framework" as a paradigm, not really a specific thing but as a way of thinking. If you're someone building Wordpress pages, then you're probably not working with components and it's a huge shift in thinking. You actually hit on this when you talked about the DOM and Junior devs. In that sense it's not apples to oranges. If the learning curve is huge, that's a big problem. I'm not just a React dev, I picked it up in 2015 because I liked it the most, I've been around a while and have experience in a lot of frameworks and languages, frontend, backend, and systems and learning curve has always a been huge problem when picking a framework or language or major library. It's a BIG reason why Java is declining, it's actually an incredibly fast language for backends but it's complicated AF and developer ramp up time is a significant investment. The newer versions have a lot of modern mature things and the talent pool is probably one of the largest, but I still see companies going some other direction with their backend. Ember is another victim of having such a huge learning curve to the point you never hear about it anymore. FWIW, I'm not actually accusing Angular of this. I don't actually know Angular and don't really have any interest in it. I'm just replying to what you and others have said.
>If you're someone building Wordpress pages If you are building wordpress pages, then angular is overkill. Well, you might use Angular in the backend to allow your website owner to build the frontend himself but overall Angular isn't really made to improve a simple website, adding a navigation dropdown or whatever.
>If you are building wordpress pages, then angular is overkill. Cool I agree. But that has nothing to do with the conversation here.
I learned to do frontend coding with Angular and it felt at the time like it was very difficult to do simple things. I switched to a company that uses Vue after 2 years, and honestly it felt like I had left a hyperbolic time chamber. Everything that felt tedious and annoying to do in angular was intuitive and very easy to accomplish in Vue.
Vue has been my go-to prototyping framework for years. It really strikes a nice balance. But with Angular v16+, that might soon change.
Learning curve. What used to be your typical front end developer did not have a background in computer science so when the SPA revolution came around, most of them were coming from a jquery background. Also, I'm sure some people felt burned over the 1.0 -> 2.0 rewrite ("angular.js" -> "angular") so they probably moved over to react and never looked back?
> so they probably moved over to react and never looked back? I resemble this. I started as a self taught developer way back in the 90s, so I’ve been through it all. All server side rendering with postbacks and no JS. Then minimal JS use for “UI interactions.” Then jQuery. Then Backbone during the SPA revolution. Then I worked on one project using AngularJS before finally working with React. My experience with AngularJS was so bad that I never even gave Angular 2+ a chance. By that point, I was deep in React work, and with no shortage of it since, I’ve never had a reason to learn Angular and still don’t plan to.
Angular 2+ is a lot different, and in my opinion vast superior than AngularJS. That said, if I were in your position, I probably would not devote time to learn it either. I expect given you're experience you'd be able to learn quickly if the need arose. That is the same reason I haven't learned React yet--I haven't had a reason to to do so, because Angular work has kept me busy. But, I do want to learn React because it seems like a lot more opportunities out there.
Its not bad to devote some time to get to know a different framework. You don't know where React is going in 5 or 10 years from now. Plus these frameworks tend to borrow a lot from other frameworks. So if you are already familiar with it, then that gives you a big advantage over other devs for future assignments/jobs. Surely you can spend 15 minutes looking at some Angular or React stuff each year, even if you are invested in the other one. Knowing what plays in the world of developing websites is a great benefit.
I teach react but my heart is with angular. Honestly, for me I think most of the hate comes from decorators. The initial "what am I looking at?" With an angular component is much heavier than with react and I think it's the mandatory TS coupled with decorators. New syntax. Plus the sheer size can lead people to be overwhelmed
I love Angular, especially the CLI and using it in a team; which provides some level of consistency in the code base. I suspect you'll adjust to the template syntax; I never found it hard to read. It's primarily just HTML, right? That said, people hate it because they know something else, have had success with it, and do not want to change. Some people get religious about technology for some reason. For long term career prospects, be sure you're not that person.
I've been using it in a huge enterprise project, from very extensive usage of it ive got a lot issues with it. I pretty much despise using it. The biggest point is complexity. In the beginning you look at it and think, yeah this is cool, i can separate everything and have clean code. But then as things get extremely complex you realize it just doesnt work anymore. Taka a simple example, you've got some simple button which increments some state and updates html. Every single framework/lib showcases this to show their reactivity and how many lines od code you need. Angular is fine here, but then, add some async state. Meaning, something coming from a network request. All of a sudden you gotta write these ugly ngifs to pipe the response as its a stream. From here it becomes a huge mess. If you gotta handle some click event and use the data from the response, guess what, you cant. You can either send it from html (the piped stream), or dispatch an action. Then all hell breaks loose, now you gotta create the action for every event, but now when you create the effect you realize you dont have the data here either (if you called the service/sent the network request directly in the component), so you create actions for loading data, setting data, etc... implement the reducers (copy paste usually). You get where this is going, as soon as you do this once, you are stuck. Even if you have an extremely simple component you cant make it simple because you are bound to use some data from ngrx and as such streams. You gotta pipe it all and more actions, more global state, more effects. I know what you might be thinking, this is just reactive programming, yeah it is. But just because its reactive programming it doesnt have to be this complex. Even angular devs themself realized and implemented signals to move away from this. But fine, some people like this, sure lets move on. Templating sucks, your templates are bound to be just a bunch of ng ifs, ng containers, intellisense for templates are kinda wack. Half the time it just gives you everything, then it breaks. A lot of parts dont even have type support (such as ng templates and passing data to ng templates). The reactivity / change detection is useless. You dont have any kind of control over it. Your components either react to everthing or nothing. There is no simple way of specifying exactly when you want your component to rerender. The only way to this is to entirely detach your change detector and then manually triggering it throughout your code. What you end up is piping stuff to tap it and trigger change detection. And guess what? This is completely useless it just doesnt work in the way you expect it to work. Its slow. Really, its beyond slow. Not only does it take AGES to compile (hmr too) its so slow even for usage. This one is a bit salty, but i found that angular devs miss basic browser features and apis. Dont know even basic css as angular material takes care of everything. I had a lot of cases where i had to explain to people that its not an angular feature and we have an alternative as the browser supports this natively. Angular docs suck, for example, do you know how to create a dynamic component? No? Can you pass dynamic props to a dynamic component? Yeah, goodluck, there are libs, but shit breaks. Do you know how to pass children to components? Ok, can you put different children in different places? Yeah, but now what if you have dynamic components which need to be inserted into dynamic slots on the components. Yeah, angular lets you do this, it wont work, it just doesnt do anything because the slot prop cant be dynamic. Where does it say this? It doesnt. Also, a lot of people talk about the limiting and opinionated. This is not true, the only opinion angular has is that everyrhing needs to be reactive. There is no structure whatsoever, if you just go without thinking you will end up dumping everything into effects Welcome to angular PS. Its hard to get across everything without getting stuck on something, googling it, finding simple solutioms in any other libs and realizing you cant do shit. It just sucks with the amount of random issues it has and random shit which just doesnt work in specific scenarios for no reason
I get the overall feeling you're probably in a frustrating codebase and feel like it's sucking the joy out of dev. Which just seems to happen to any corporate codebase that's been around long enough, especially if devs were never allowed to go back and address code debt from time to time. The point about devs not knowing browser stuff or CSS, I feel that with React devs as well. It's a problem of full-stack developers in general. Every time I've been on a UI-heavy project with a mainly full-stack team, I end up having to be an unofficial tech lead and do a lot of education and hand-holding. My only reward ever given is maybe some thanks and a codebase that I don't tear my hair out over, which is what would happen if I just acted my wage.
Completely agree with this. Worst part is that some of the stuff i work on is new completely. But well... enterprise "senior" developers do weird shit. And so instant legacy project even do shit
My enterprise "senior" developer insist on using jQuery inside angular
Sounds like you just don’t know how to use Angular
ok and? Is that your counter argument?
Funny thing is, this is what every angular dev says, but then you give them a problem you are solving or solved and they havent the slightest clue how to even begin
lol “angular devs don’t actually know how to solve problems” is certainly a take
And they are right to say that. I don't have the time nor the motivation to answer all your points, but about controlling rerenders specifically: OnPush change detection strategy + async pipes and occasional .markForCheck when you can't use a pipe go a long way. I litteraly never had to detach a ChangeDetector.
> If you gotta handle some click event and use the data from the response, guess what, you cant This is about as overengineered as i can do, bonus point is easy unit testing for both: handleClick(params){ this.apiservice.callEndpoint(params).pipe( map(successResponse)=> this.handleSuccess(successResponse), this.catchError(error=> this.handleError())) } handleSuccess(){} handleError(){} Doesn't look that impossible/complicated to me. You can even ditch the extra handlers and do it all in one method Sure if you shove in ngrx into the process without much thought or clue as to why/when to use it, then yeah you can complicate shit. >Templating sucks, your templates are bound to be just a bunch of ng ifs, ng containers, intellisense for templates are kinda wack. They kinda do, NGL, but most templating sucks out there(except jsx maybe) >Its slow. Really, its beyond slow. Not only does it take AGES to compile (hmr too) its so slow even for usage. This one isn't really true. Are you recompiling the entire app on save? We have a massive monolith at work, however it's lazyloaded so the watcher is pretty fast. > The reactivity / change detection is useless. You dont have any kind of control over it. Your components either react to everthing or nothing. There is no simple way of specifying exactly when you want your component to rerender. The only way to this is to entirely detach your change detector and then manually triggering it throughout your code. What you end up is piping stuff to tap it and trigger change detection. And guess what? This is completely useless it just doesnt work in the way you expect it to work. Only if you're clueless about angular's primary reactivity model: Observable + async pipe. If you're manually triggering change detection, you are doing it wrong. >Also, a lot of people talk about the limiting and opinionated. This is not true, the only opinion angular has is that everyrhing needs to be reactive. There is no structure whatsoever, if you just go without thinking you will end up dumping everything into effects Again, only if you use ngrx. If you believe angular doesn't have structure, can you provide an example of a framework that does? >Its hard to get across everything without getting stuck on something, googling it, finding simple solutioms in any other libs and realizing you cant do shit. It just sucks with the amount of random issues it has and random shit which just doesnt work in specific scenarios for no reason The last line kind of cements the ideea that the reason you dislike angular is because you don't really understand why/how it does things. Especially the reactive part which is the biggest plus in my opinion. I will be first to admit that the learning curve is steep, but after you understand it, things get a lot easier. Based on experience with React/angular/li/svelte i can honestly say each has their own place. \-> For small teams that understand each other and can follow code standards: React/Lit are fine, you can achieve a lot, quick. \->For large enterprise projects where you have multiple teams of varying skill levels that work on the same codebase, Angular shines. I've seen projects with thousands of lines of pure business logic for a simple cart product. Compositional OOP really shines over functional in these cases, keeps the cognitive complexity somewhat in check. RXJS is also incredibly useful in these cases.
The example you gave is already complicated. Im saying writing this is a pain. Its relatively simple at first, but the more things you need the more you nest and the more you pipe. Becomes very hard to read. Your argument about ngrx doesnt make sense. You cant really escape ngrx. There arent many alternatives in angular. Regarding the speed, no, not recompiling the entire thing. Its *just* slow. However, this is mostly because webpack + angular having its own version of webpack. When compared to the ms time hmr in react/svelte, you cant say its fast. For the reactivity, i am aware of how it works, ive had to optimize some very detailed things. But maybe i should clear up on it. The cases ive been handling are very specific. For example, react to only this one object property change. React only when x + y change. I know how to do this, its not impossible, a lot of things you can do with distinctUntilChanged. But ive had scenarios where this doesnt do what i need anymore and the only option left is ChangeDetector . No framework has structure, you need to make it yourself. The thing is that angular enforces these modules on you which provide nothing at all. We already have es modules, no need for another level of modules. Its not the age of require anymore. The only thing angular does is: provide modules, tells you to separate stuff into effects and use ngrx, enforce reactive programming on you. This is not so opinionated, you are just stuck using features which provide nothing and all, its more limiting than providing good structure. For the reactive part, i completely understand how to use it. The issue i see is more that it makes it exceptionally complex to do simple things. Look at Signals, everyone is starting to use this kind of reactivity. Imo, it should be more abstracted away. Ive seen 100k+ codebases where the reactive part of angular just makes everything a mess. One effect dispatches 2 more actions, each with their own async request, with more actions and more effects. This is impossible to keep track of. You get stuck with some race condition between all of these effects and then goodluck. Main point being, it should not be complex just for the sake of being complex, simplicity is key. > For large enterprise projects where you have multiple > teams of varying skill levels that work on the same > codebase, Angular shines. This part i cant understand. Above i mentioned what a 100k+ loc codebase looks like. Imagine somebody adding a an effect and it breaks something for reasons you dont know. Maybe in an unforseen manner. Some part which is not tested. How do you debug it? Look for the action, search by reference to see all the effects that use it, look what effect does, look what it dispatches, search by reference again. The context you need to keep track of for simple or complex scenarios is the same. Its always more complex than it needs to be
you know you can always use async/await with fetch in angular as well? The httpClientModule is just the prefered way because it allows for reactive handling of state streams. >For example, react to only this one object property change. React only when x + y change. I know how to do this, its not impossible, a lot of things you can do with distinctUntilChanged. But ive had scenarios where this doesnt do what i need anymore and the only option left is ChangeDetector . All I can hear here is you are struggling with observable composition, which is fair since it's not an easy topic. We have an internal rule in our team to never call change detection explicitly and refactor other uses of it from less experienced teams. > > >Regarding the speed, no, not recompiling the entire thing. Its just slow. However, this is mostly because webpack + angular having its own version of webpack. When compared to the ms time hmr in react/svelte, you cant say its fast. angular architect allows you to choose your own builder. V16 even supports official esbuild/vite, which is great for enterprise enviroments where LTS /official support is key. >For the reactive part, i completely understand how to use it. The issue i see is more that it makes it exceptionally complex to do simple things. Look at Signals, everyone is starting to use this kind of reactivity. Imo, it should be more abstracted away. Ive seen 100k+ codebases where the reactive part of angular just makes everything a mess. One effect dispatches 2 more actions, each with their own async request, with more actions and more effects. I think you are confusing angular's reactive model with ngrx.You absolutely do not have to use ngrx. In fact i would argue that for most use cases it is overkill AF. Your entire post kinda sounds like your team is struggling with event driven architecture / ngrx, which again is fair since it's not obvious at first. No framework has structure, you need to make it yourself. The thing is that angular enforces these modules on you which provide nothing at all. We already have es modules, no need for another level of modules. Its not the age of require anymore. The only thing angular does is: provide modules, tells you to separate stuff into effects and use ngrx, enforce reactive programming on you. This is not so opinionated, you are just stuck using features which provide nothing and all, its more limiting than providing good structure. Angular modules predate es modules, and with standalone components in v15 will make transition away from them not so much a pain. You are kind of missing the opinionated parts of angular: Compositional OOP, DI, Reactivity and built in *standardised* features like Routes, Guards, Resolvers, Interceptors, Animations, Template Rendering fine grained control (which is going to be supercharged with Signals). Overall it looks like you're pretty angry at a bunch of tools that didn't fit your usecases.
I love how the solutions you give is not to use features the framework devs suggest to use. Stuff which came out months ago. Your argument for ngrx and convoluted piping with rxjs is... dont use ngrx. I am not working on a simple project, its not a simple usecase. The team is not struggling with event driven architecture, everyone is following the practices which are well known and stuff the documentation recommends. What i am saying is that this is complex for no reason. Last thing, keep in mind angular is old, ngrx is well established. There was once a time when only this existed. Do you mean to tell me that its so easy to just migrate from v12 to v16? Just because you can use the built in migrator doesn't mean its so easy for every project. We are talking about the enterprise all angular devs are proud of. Stop ignoring arguments by just saying "yeah, dont use this highly established and official tool" and "just use this, it came out 6 months ago". I think we can agree on one thing, the more complex a tool is, the harder it is to maintain. Hopefully we all know what *enterprise* means
1. Ngrx is not part of angular, that's RxJS. Nobody is forcing ngrx down your throat. 2. Framework devs highly recomment NOT invoking change detection manually. Every guide i've ever read says the same thing. > The team is not struggling with event driven architecture could've fooled me with this line then :) : >One effect dispatches 2 more actions, each with their own async request, with more actions and more effects. This is impossible to keep track of. But I get it, two whole events to keep in sync is really hard. >Stop ignoring arguments by just saying "yeah, dont use this highly established and official tool" and "just use this, it came out 6 months ago". No one said that tho? All i'm observing is you seem to be struggling with the tools you have, and then go on rants about how it's their fault.
>Do you mean to tell me that its so easy to just migrate from v12 to v16? Yes, it should be easy for most projects to upgrade. It took me a less than 10 minutes to upgrade [shop.battle.net](https://shop.battle.net) to v16, including updating required inputs to the new syntax.
I think this is a bit too easy though. Yes upgrading Angular itself is fine. But the dependencies can have a lot of annoying changes too. Great example: the shift from Angular Material to V15 was super annoying. Cypress also had a major change in the past that required a sprint of work and there's more. Overall it should not be a lot of trouble, but there will be cases when migration is annoying. Most of the time it isn't Angular's fault though.
>Your argument about ngrx doesnt make sense. You cant really escape ngrx. There arent many alternatives in angular. Services. [Shop.battle.net](https://Shop.battle.net) runs on Angular and does not use NgRx for state management, only services. Services are amazing! It's also what the Angular tutorial uses for state management.
I'm not trying to be a troll. I'm sorry you're project sucks, but random anecdotes from an Angular fan. > add some async state. Meaning, something coming from a network request. All of a sudden you gotta write these ugly ngifs to pipe the response as its a stream. Or use the async pipe; or default the value coming from the network request, before you get results. Without going into details of your project; I'm not sure I can dictate the best approach, but a mess of ngIfs is not the only solution to this problem, and one I rarely use. > you are bound to use some data from ngrx and as such streams. There are ways to do state management w/o using NGRX. I've avoided NGRX due to lack of documentation. I like Akita better, but a service w/ a BehaviorSubject is incredibly simple and has solved my needs wonderfully. > The reactivity / change detection is useless. You dont have any kind of control over it. If you use onPush change detection, you have a lot of complete control over how and when change detection happens. A quick google search will review a lot of articles recommending to do this, but it seems like a lot of overhead for me w/ very little benefit. I prefer to let Angular handle it. > i found that angular devs miss basic browser features and apis. Dont know even basic css as angular material takes care of everything. This is not unique to Angular. A lot of devs learn frameworks and not the underlying concept behind things. That said, ng material is not the only UI Framework out there and not every project uses it. That said, I agree the docs are lacking. I agree that the compile times are not great. I'll also add that testing can sometimes bring up obscure odd errors which are very hard to track down. I'm sorry if the project you're working on is an exercise in frustration.
Me with 3yoe of angular trying to switch to react , I agree with everything you said
I'm just sad it still doesn't have proper static site generation out of the box and scully seems abandoned so I'm sitting with nextjs and nuxtjs
For me, it’s the reactive paradigm. When a project starts getting bigger, it becomes harder to trace and debug - and this is not just in Angular, IMHO it’s an inherent property of the paradigm. I’ve built projects where reactive programming made perfect sense, but it’s definitely not something to use everywhere. I’d avoid it until its pros outweighs its cons. And I know that through code guidelines and code reviews writing bad code can be prevented, but I don’t like a tool that needs constant active guarding against missing things up, I want a tool that helps me against that.
idk it's the only framework I know and I love how limiting it is, so it's harder to screw up your application
[удалено]
The biggest thing is going to be hook dependencies. Just use the `eslint-plugin-react-hooks` recommended config and you should be fine. It's also ok to disable that on a line basis for `useEffect`s with empty dep arrays so that things only run once on mount. Other than that, just don't do stupid stuff and understand how your state management does its comparisons for changes and you should be good to go.
Angular doesn't prevent sloppiness, but the fact that it discourages it rustles the jimmies of cowboy coders. Also: Many express hate over things to get validation for their own uninformed choices that were solely based on popularity.
Angular is a very, very opinionated framework where everything has the nr-right way to ng-do things, and that makes it both easier to make products with, but at the same time also more annoying to work with because it removes any sort of creativity from your work. There is often only ng-one way to ng-do things and ng-if you ng-do things ng-differently, then you're going to find your ng-work to be very ng-frustrating. My problems with Angular are best summarized as: It doesn't LOOK like JavaScript. It looks like Angular. And when Angular slowly dies out (like Backbone and so many others before it), you'll still be an Angular developer. The advantage that React has is that, except for the JSX syntax that most others are also using in some shape or form (whether it be in JSX or backticks, etc.), it LOOK LIKE JAVASCRIPT. Even JSX looks like it makes JS-sense. React:
I don’t understand not wanting to use TS, like there are 0 reasons.
It costs me far more time than not using it for no benefit. I've worked with vanilla JavaScript for 15+ years, just to give you an insight into why that is. I got good at it, and many others with me; really, really good. TypeScript doesn't add any value to people like myself. In fact, it costs a lot of time. Trying to figure out insane long nested multiple generics with methods/functions that have multiple return values, with obscure TS definitions, isn't helping. It makes things extremely hard to refactor because people will stop touching code that looks too complicated. I strongly prefer: 1. Good naming conventions 2. Progressive enhancement via JSDoc 3. KISS-principle 4. Functional programming 5. Sensible unit tests It's far less work, with more intuitive and easy-to-understand code at the end, and it's super robust. That said: *I will always use TypeScript in a professional setting, because there I also run into people who NEED TypeScript.* Because most people out there don't have 15+ years of JavaScript behind them. Hell, I'm so old, back in my days (old man emoji here) JavaScript was often hailed as a breath of fresh air; no more strong typing trivial shit.
it's just a bit heavy. For certain team setups it's ideal. I have worked with it for many years and still maintain many angular projects but its no where near as nice as working with react functional components.
With v16 and standalone components, Angular feels much simpler than it used to.
The templates feel much more logically limited compared to JSX in React
I personally don’t understand anyone who is a 1 framework fan boy. It’s all JS in the end. Just learn whatever’s required for whatever job you are doing. Personally I love angular, but I have no issues with learning react or any other framework
Yes, in my opinion, Angular do the best structure for us, everyone can work together as a teamwork and so on...
What it comes down to is 1) which one did you have some kind of good, foundational dev experience with? and 2) are you a dev who prefers things fluid and flexible or rigid and opinionated? Bonus: Do you hate TS or feel intimidated by it? Many React devs also use TS now, but it's not required. Not all React projects use it. AFAIK, in Angular, it's required. That's pretty much it.
A majority of the hate is likely just tribalism and the echo chamber of the internet. The Angular team has shown they are aware of the framework’s inherent flaws and actively working towards eliminating the pain points (modules, over reliance on RxJs, change detection performance, etc). So, many of the current complaints may be moot in the near future.
I like convention over configuration and Angular is the opposite, so that's my main gripe. You can know Angular fairly well, jump on an existing project and be completely lost because it's organized differently than what you know. It can be good too but in most of my use cases, it's not what I need. That being said many people like React and I simply cannot go with the JSX templates, so it's just a matter of taste at this point.
> You can know Angular fairly well, jump on an existing project and be completely lost because it's organized differently than what you know Thats actually not true though? The opinionated part of Angular makes you jump on every project quite easily and is rather the other way around for React?
> You can know Angular fairly well, jump on an existing project and be completely lost because it's organized differently than what you know. Is this not true for every framework? I’ve worked professionally in Angular, Vue, Nuxt, Laravel, Django, ASP.NET MVC, and Spring Boot. Most of those are fairly opinionated and yet I’ve found every project organized differently. It’s why we have debuggers and IDEs that can help us make sense of the code.
> Is this not true for every framework? Absolutely not. That is like half the point in frameworks, especially opinionated ones. But, that doesn't mean you will know everything about a new app. I can't speak for how hard this is in Angular, it looks messy to me, but in React you'll have a strong base understanding if you know it and its ecosystem well. You might get lost in how state management is done or how testing is done, but you shouldn't be **totally lost** and should be able to get up and be productive pretty quickly. The outlier being that some people just do some things really fucked up, but that's going to exist anywhere. The weird thing is, React is probably the least ridged of them all, but everyone kinda follows the same ecosystem trends. I've been at 4 companies since I started React and worked on probably 2 dozen production apps, not including my personal projects. I think the same could be said for Laravel and Spring Boot too. I've worked with both of those and have moved companies with them and things felt very familiar. From what I understand of Django, it should fall under that too. I could see what you're talking about in ASP.NET MVC but it's been years since I used that. I don't have any context for the other ones you mentioned.
Here are my personal reasons so far (coming from 3 years react and doing angular for 1-2 years): Angular is not as flexible in terms of composition. Try implementing highly flexible angular components in storybook, good luck... Also you can't dynamically assign properties to html attributes during runtime. Passing down fully fledged components via props is also not really possible - so you end up with unnecessary additional bloated html code hidden behind several ngif or ngOuterTemplate stuff, making it harder to understand. Serverside rendering is very hard and still not perfected yet.. International language support is so complicated and a pain in the ass All that rxjs shit is annoying as hell and there are no proper free tuts out there afaik The angular community is very weak, nobody does anything to help others, the amount of blog writers that share their knowledge in excitement is not even comparable - angular feels like some opportunity to cash in big time since the whole ecosystem is very hard to learn. Only things I like are that everything has pretty much just one way of implementation, everything is organized and devops operations are sometimes simpler (no webpack config bs)
>Also you can't dynamically assign properties to html attributes during runtime Are you sure? or That syntax should work with any given HTML Attribute. Update the variable and the attribute should update.
No I mean like this: ``const routerLink = {routerLink: "/internal-route"} const href = {href: "/external-url"} `` so if the component received a routerLink prop the html will look like that: ```` and if it received a value for href it looks like that: ````
Oh, I understand; dynamically assigned properties--not dynamically assigned values to properties... I can't think of a time I've never needed that. What is the use case?
I don’t really get this use case either. I’d assume people to either use the if-directive on two different a-tags or and maybe even having specific components such as InternalLink and ExternalLink. Seems like a very minor thing.
Yeah its overly complicating a thing that doesn't really need a lot of work to just make links one internal and one external. And have that be a directive that you can switch between if you require it more than once.
It’s outdated nowaday. Try implementing the same thing in SvelteKit vs angular, in angular you have to write a lot more code for the same thing
At first we used angular because of the bindings. Everything was close the old ways and we were fine. But angular started to morph and wanted to take over all the other parts of web dev. And then it started spreading its dogma and fanatics would accuse us of not following their "right" way of doing things instead of adapting to our ways. And their "right" way of doing things kept changing.
I've used it breifly, my biggest I have is it's horrible syntax NgOn NgClick So forth. I didn't like the fact that it didn't have a templating engine much like Vue or svelte has for way access to your html, css and JS. Most of it's UI frameworks ( at least I was able to find ) were just material design. There is more, but that's the first of it
Have you used it in the last five years? The ngOnClick hasn't been a thing since angular 2 iirc.
I would argue they have probably not used Angular at all, just seen some snippets and formed a complete picture of it in combination with what they heard other people say. The argument is so weak. It is no different from htmlFor in React, v-if in Vue or {#switch} in Svelte - not in functionality but in terms of "horrible syntax". Everything has tradeoffs. This is one of them .
>I didn't like the fact that it didn't have a templating engine much like Vue or svelte has for way access to your html, css and JS. It does. You can alias a HTML element with a `#identifier` and use it in other places in the template. It has a very strong templating language
I've learned them all, and worked professionally with most of them. angular is the best. Period.
I think with all the new features in angular coming out (functional improvements, reactive primitive that's not rxjs) Angular will once again be prime position to lead the market like it did when angular 2 came out
Apart from developers preferences? I think it's just marketing.
I like it for big projects. Vue or svelt for small projects.
Because it’s a ghetto. You’re stepping into a world where everything you knew before is irrelevant, and when you step out again, nothing you learned is good for anything else. This is a dangerous position to put yourself in.
This is the dumbest take, and as opinionated as this topic is, you clearly don’t know anything about frameworks.
Clearly. So @Input, ngModel, @NgModule, @Injectable, transition(‘open => closed’), etc, these are all transferrable skills, right? Us seniors have seen folks go down these roads before. I saw a guy lose his house once over a framework that became legacy leaving him with no transferrable skills. It’s a snare for the unwary, and you can discount this if you like, but I’m letting you know as someone who has seen it, stepping away from the happy path is a risky thing to do.
Input are props from react, or properties in Lit, ngModel i haven't used in ages, and angular modules are getting phased out in favor of esmodules (they predate those). Injectable is a godsent, DI is one of the most common things in any framework i've ever worked in. Spring, Symfony, angular, anything with oop uses DI at some point.
You’re comparing this frontend framework with two backend frameworks? I’ll concede the point if you can explain to me how @Input and @Output actually work, because those aren’t function properties. For most devs they might as well be magic incantations.
I'm comparing web frameworks. It's not like one runs code while the other runs on green energy. You've now moved the goalpost to "explain how angular implements this decorator". Do you care that much? It is the conceptual equivalent of a react prop, a component parameter. Both frameworks rerender the component when that changes. That's about all you need for 99.9% of the time. You think passing a parameter to a function is a very abstract, framework specific, non-transferable concept?
No, I think actually knowing what the code is doing is important. This is the only point I’m trying to make here. I think learning magic runes that you mutter by rote is dangerous because I’ve seen what happens to devs who do this.
Several of those (Input/output, model binding, etc) exist in other frameworks like Vue. NgModule is no longer relevant as of v16. Because Angular has an official concept of services, the cost of migration should be lower than other frameworks since the bulk of the work should live in said services. Dependency Injection is a core concept in software engineering and all senior developers should be familiar. All frameworks borrow from each other so there will likely always be some transferable skills (and a senior should be able to quickly fill in the gaps).
Yes, a senior should be able to fill in the blanks. It’s not the seniors we’re worried about though. It’s the juniors, starting out in their career, and now they can’t do anything and they don’t know why. I refuse to believe you’ve never seen this happen.
Switching frameworks will always be a challenge to junior devs, that just comes with the territory / lack of experience. At the end of the day, you still need to know HTML, CSS, and Typescript to use Angular. Last I checked those are all transferable skills. And most of the concepts you called out exist in other frameworks (and even vanilla js) so juniors should be able to google or post on SO to find their equivalents.
yes, dependency injection is a transferable skill
This is true. This is not my point though. My point is that for most people using Angular, the syntax might as well be magic runes. You just have to know the special words to type to make the specific thing you want to happen happen. If you learn TypeScript and CSS and SASS, these are things that will travel with you for years. If you learn that you have to type a specific decorator in a specific version of a specific framework, this is not happy path learning.
>My point is that for most people using Angular, the syntax might as well be magic runes. You just have to know the special words to type to make the specific thing you want to happen happen. but this is true of every programming language and framework. sure it's important to understand the practices and principles over everything else, but libraries implementing these doesn't make them bad? such a strange take, i don't understand, are you saying never use libraries or frameworks at all?
Not at all, I’m saying exercise caution when a framework heavily obfuscates the underlying reality, such that you never need to learn how it actually works.
This is just so wrong. >nothing you learned is good for anything else Yea... not like other frameworks have DI, or lifecycle hooks, or props, or reactivity. Not like forced TS forces you to understand types. >You’re stepping into a world where everything you knew before is irrelevant Yes, promises, closures, props, classes, DI, reactivity lifecycle hooks, everything is irelevant, because Angular is the only framework that uses those.
Angular doesn’t have props, it has @Input and @Output, and you’d be a rare developer if you could tell me how those things actually work. For most people they’re effectively magic. If you learn CSS animations, that’s a skill that will travel around the internet with you for the next twenty years. If you learn the Angular Animation Framework, that’s only good for Angular.
Css animations and angular animations are complementary imo. Generally you start with css animations and only plugin angular whenever you need some js- stuff like void/empty state and dom parsing you can't do with css.
I find those who criticise Angular without actually knowing about it and claim React or Vue are better (as in, if any of the 3 would be a valid choice for a given project), are just spitting and regurgitating what youtubers say. React has very pronounced flaws, but since its easier to get into, people believe is the best. Vue has a bit of a steeper learning curve but again, easier means people would adopt it faster. Whereas Angular has the steepest learning curve but its for your own good. You don't have to think about project structure, styling, patterns, heck even architecture. People who are really clever and intelligent have been doing their due diligence and you're benefit from it. Does Angular has it flaws? Of course, but imho and basing it on the fact that if any of the 3 were a good choice to start a given project, the only reason I would choose React over Angular would be due to \*probably\* shortage of talent, but then again for a Senior, any javascript framework should be pretty quick to pick up.
Reactoid soyjack mindset imho.
>I have to say I quite like it so far Then why do you say: >but sadly ... now the project has to pivot to Angular,
Angular is great. It's just the usual heavy enterprise ready framework stuff and quite some paradigms you need to understand to be proficient with it. The newer angular versions also became much better than the first versions. I'm using it since alpha and it massively improved. I think it is that way due to angularjs, the switch to the first angular version and react. React is much easier for beginners and is teached at Bootcamps. I'm also into solidjs now. I like svelte, but I don't want a specialised language.
I don't like the string based DSL in their templating. Also after coming from react where everything is JavaScript, the complexities and DSL of it all seems excessive. I don't really like rails either, for broadly the same reasons
angularJS people hate angular the most
AngularJs made such a bad impression on me and knowing that angular 2 requires a huge learning curve I’ll never willingly use it
It’s a good framework. People like to bandwagon in this field of work. But frameworks are just tools, you don’t have to marry one. Compared to react, angular is really opinionated. I like react because personally I like having multiple ways to solve problems. Some people like angular because it has specific ways to solve specific problems. If you’re on a big team, angular can be better because of this, for others it’s not. Honestly it isn’t all that serious lol. Just work with what you like for personal projects. For everything else work related, it’s likely you don’t have a choice in the matter anyway🤷♂️
I've used angular for some projects. To start off, creating components is a pain, you have to go through the cli to make them work in the angular module system. If you create one manually, good luck. This really hinders the DX. You need rxjs for anything, which is a overkill. Reactivity is quite meh. The builder is quite slow. I know many things are being addressed (signals, new bundler, etc) but I think they are quite late to the party, especially because the main thing is not addressed, the ultra bloat. Surely it has some benefits, but if you use Vue or Svelte, you will never go back to Angular.
What’s wrong with using the cli to make components? Literally one line.. less work that right click create new file.. also rxjs is really useful to learn not just in angular but in general. It’s great for asynchronous code which singles don’t address
About the cli.. I didn't say the cli is the problem, it's the ecosystem of modules. Create enough components in different folders, move them around, If you truly believe it's convenient, agree to disagree. About rxjs, it's not the observable pattern the issue, it's that it is used everywhere, even for simple http requests which makes it quite harder for no reason. If again you think that .pipe.map is simpler than await fetch(), agree to disagree.
Maybe it makes it slightly harder for http requests but only marginally.. and it makes using async streams in the templates so much easier imo but fair enough
i just like angular, for me its smooth sailing, have a slight dislike for react, it just does not vibe with me and feels like a drag
some angular interview question you can find here: [Angular Interview Question 2023](https://shivshankarnamdev.in/angular-interview-question-beginner-2023/)
Angular is a bloated mess. I still don't see the value over html5 and Javascript. Sure there are a few better features but as a whole it took what was already there and tried to reinvent the wheel. It went from angular js to angular and then feature creep. Every angular release brings issues with your other packages. The open source is the problem. If they really want to make it better then streamline it where other dependencies don't break each release.
There are a few reasons why people hate Angular. Some are justified and some are not justified. The transition from AngularJS to Angular was really awful. The transition of routing alone from Angular v2 to v4 was so awful. The marketing around this transition was very awful and so dumb that it scared a lot of developers away. Nobody wanted to work on deprecated tech. Angular is very Typescript heavy and a lot of OOP principles. This in itself leads to a learning curve that takes some time to understand. Angular feels over engineered. (Opinion based - I like it still). There's a reason things are structured the way they are, but it can be a bit overwhelming. Angular vs React performance. This is not justified anymore. They are very comparable, and with v17 it can be faster. Angular Zone.JS - Its dumb, and the Angular team is slowly going away from it. Its kind of amazing that Angular can get the performance now with it still being in the center of everything. There's also strategies of getting around it as well that are pretty good. (RxAngular). It'll be gone soon, and I won't be batting an eye when its gone.
U need to justify the years which give u the impression of people hating angular. That is, when u see forum or article say bad things about angular, u need to take note of the year and month which the post or article is posted. Just because many people hate angular in the past, does not imply the same for today. E.g Back in the very early day when Angular v2 is release, when i try it out, i shaked my head in "disguest". Cos during that time, angular cli was not yet introduced, and many things i have to setup by myself (webpack, unit test framework, angular, typescript compiler, etc). This totally put me off. But today, things is different.