I hate Angular with a passion. It's easily the most verbose, overly complex front end framework I've ever used which just takes the fun out of building web apps and make it a pure pain. I would rather work on a farm and shovel pig shit all day than work in Angular again.
My last job forced Angular on me, I quit after a while (not because of solely that reason) but I told them Angular was a bad choice and they chose to overrule me. Pretty funny now, they will have to endure the pain of migrating a large app which makes me feel good.
To offer a differing experience, I've been working in Angular for a couple of years now and personally like it quite a bit. I don't like frontend frameworks in general, but given the choice I prefer Angular over React.
I seldom see this opinion but I'm glad to read it. People complain about JSX on the React side but what on Earth am I reading when I see the templating language that Angular came up with? ngIf, ngBlah. Much worse than JSX, which is subordinate to JavaScript code, not equal. I also have been forced to use Angular at the workplace and it killed any fun making web apps had. People say Angular is great for enterprise because it removes the burden of deciding things, but this indicates an organizational problem being solved technologically. In other words: Never a good thing.
The template syntax of Angular isn't the problem most people have with it. It's the boilerplate, the forced OOP paradigm, having to work with observables even when they're not appropriate (thus having to understand "hot" vs "cold" observables), and up until recently, having to scatter each component across three different files. And to top it off, when the lack of expressivity is touted as a feature for taming complexity, that points to a development culture that doesn't sit well with me either.
You have literally never had to scatter each component across three files. From the first release of Angular 2, you had "single file components", with template, styles and js all in one file.
It does appear I was wrong about the "until recently" bit: Angular still doesn't have a single-file component format like Vue or Svelte. Of course you can stick templates in string literals (and IDEA will even treat them as angular templates). Just be prepared to escape your quotes I guess. The official tutorial still uses separate files, and the tooling defaults to them too.
Honestly the real shame is that IDEs don't present a more integrated UI for separate files, and that on the other hand in my Vue apps I still have to argue over the order of script/template/style sections. I guess Angular at least avoids that second problem.
Not as much in Jetbrains IDEs: it detects the string is HTML and highlighting, formatting, and mode-specific functionality all just work inside the string. In an Angular source file, all the template properties like "ng-if" autocomplete too, not sure if any code completion inside props works though (it doesn't with the AngularJS 1.x I just tested, but that's a different plugin that's probably less capable). Have to be careful about escaping the outermost quotes too if you use them in the template. So not exactly terrible, but still a little bit janky.
You could do that with angularjs 1.5 components too. But afaik it was/is not standard practice to embed html and css inside your js, because many (most?) editors treat html inside a string as a string instead of as html.
I didn't care so much about the syntax but rather the over reliance on the subscriber pattern that you have to have like a subscriber to even read something as fundamental as query params. And the funny thing is that is will fire once and then again when the query params is actually set. So you will have an empty fire for when they are not yet set for some strange reason, presumably from when the observer is created.
The problem with Angular, especially as the app grows is that you will have many different subscribers that all listen on the same state changes, then fire them again so you will have code that just runs again and again and it's extremely hard to have a mental model on how the system work and what code runs when.
The code also easily gets super slow because you run something, it affect state, then it triggers something else that triggers something else that just happen to affect the first state, whoops now you have a loop. Even if the loop resolves, it's pretty much inevitable to get a loop sometimes if the app is complex enough, at least in my experience working with several other devs.
Sounds more like a misunderstanding of the framework and observables. The problem many faced with angular is they chose not to learn observables, then got angry.
If you have different subscribers, all on the same state change, you may not have chosen to use ShareReplay, or filter, or bothered to use a tool like ngrx that has memoized selectors.
The same problem you're complaining about is the same thing people in the react community are complaining about because they never bothered to understand useEffect, and now have massive cascading updates.
There is a very good reason they chose to make everything a subscriber, and it helps avoid pitfalls, because it doesn't hide away the async nature of everything. Signals are just a simpler way to understand and use that same async nature.
Well perhaps, but I think it's so overly complex and verbose to the point that learning it and making sure that everyone working on the project is on the same level is hard or near to impossible.
I really tried to learn RxJS, I used a lot of different methods like filter and what not but I still got into a huge amount of issues but honestly a lot of that was because angular was not really fit for the type of application we were trying to build. Especially as we relied heavily on query params for state. There were many strange behaviors of Angular Router that I ran into several times. It has some kind of own internal state and fires updates in an unexpected way. I remember sitting hours just to try to get the query params to update correctly and I was not the only one having these kinds of issues.
Even if I agree useEffect is unnecessary complex, it's still far far away from being as complex as RxJS and Angular. I remember I was trying to add some pipe service or whatever it was called and it was near to impossible to achieve what I wanted to do which would be trivial in any other framework/vanilla JS (unfortunately I don't remember what it was).
Then using third party stuff in Angular is a nightmare as well. You have to deep dive into how it's being built to make sure all the stuff is brought into the build step etc. The configuration is a nightmare if you want to do something special like making use of Angular Elements that's barely documented at all.
I never got to use the Signals feature, because I left the company before it got introduced into Angular.
> the templating language that Angular came up with? ngIf, ngBlah
The new templating syntax is simply @if () @else () ... it makes it much clearer to read in many cases.
I never had a problem with *ngIf as long as you are controlling the visibility of one element. It became messy when you needed "else" statements in there.
I’ve hated working on every Angular project I’ve worked on. No matter the team, the experience level or complexity, it’s always been an absolute misery.
I cannot understand how it was invented/why it exists, how smart people at Google convinced themselves to use it. I cannot understand how they let it escape into the wild or even why those not forced to use it, choose it.
I know I’ve begged before for this, and it’s pointless, but please if you’re in the position to, please consider snuffing it out and starting over.
It's worse, everyone jumped from Angular to the React bandwagon. I use these types of things as litmus tests for if I want to join a new company/team. No sense in cussing under my breath all day every day. It's really hard to smile after you just invented a new vulgar phrase to describe mangled tech.
Agreed. I think the earlier days of Angular put a bad taste in many people's mouths. Many people who complain about Angular being verbose seem to only have experience working on smaller apps.
I suspect the migration effort will be fairly minimal. We recently migrated a bunch of stuff in a large codebase to use signals instead of observables and it was very straightforward. Couple of days for a junior engineer levels of straightforward.
I personally find Angular to be fine - sure there is a learning curve but that is true of anything (it's not like you can just pickup modern react and make anything functional without having to know how react works and spend ages picking libraries and installing and learning how to use npm, spending 6 months in a sanatorium getting therapy after realising you have to use npm for react and accept the shit show dumpster fire you are letting yourself in for by relying on npm, and deciding if you should use hooks or not and what about JS vs TS etc etc ). I find JSX in React an uncomfortable compromise that throws out a bunch of hard-learnt best practice in computer science (mixing up and confusing presentation with business logic in the same file). Separation of concerns is a good thing.
Angular will continue to be a solid choice for large professional outfits that care about things like maintainability, repeatable builds, dependency management, readability etc etc. Having Angular be the framework that powers websites like google.com and YouTube is just going to make it even more of a "no-brainer" choice than it already is if people are picking a web UI framework.
My last job forced Angular on me, I quit after a while (not because of solely that reason) but I told them Angular was a bad choice and they chose to overrule me. Pretty funny now, they will have to endure the pain of migrating a large app which makes me feel good.
Make stupid choices, win stupid prizes.