Rendered at 21:17:08 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
vyrotek 1 days ago [-]
I must admit, modern angular has been a pleasure to use. It's a shame that the ecosystem is a little rough. Luckily you get so much out of the box already.
Klaster_1 1 days ago [-]
Same experience here.
I wish Angular dropped their weird compiler that's tight coupled to tsc and moved into more pluggable approach so you can use it with whatever TS compiler. App and unit test cold build times are still crap, but at least with a coding agent you care about this less.
spankalee 1 days ago [-]
Angular should ditch the compiler altogether - it really hinders them in so many ways, especially now with AI-codegen where tools have to specifically choose to do the work to integrate the Angular toolchain instead of using plain TypeScript and HTML.
embedding-shape 1 days ago [-]
"plain TypeScript"? Just like Angular, TypeScript depends on a compiler too, regardless of where in your toolchain it is, unless I missed browsers somehow being able to straight up run TypeScript nowadays. Bit ironic to cite "ditch the compiler" as the reason to switch from one compiler to another.
bpavuk 1 days ago [-]
[dead]
mhitza 1 days ago [-]
Are projects still chosing to pick RxJS (or equivalent) which make the code heavily layered and a pain to debug?
Or has sanity reached the Angular ecosystem by now?
jonkoops 1 days ago [-]
I believe Signals are the go-to now, but surely RxJS is still present for complex use cases. Are Zones fully gone?
andriy_koval 1 days ago [-]
Now we have promises, observables and signals.
I would be more happy if it would be just one of those..
halflife 1 days ago [-]
Each one of these solves a different problem.
Promised - async
Observables - streams
Signals - reactivity
wartijn_ 22 hours ago [-]
In theory that’s true (although observables are for reactivity too), but Angular uses observables for its http library and http requests are very much not streams. It’s one of the main downsides of working with Angular, the http library is mediocre and does come with the added overhead and complexity that rxjs brings.
Until this release (if you only use stable features) using forms meant dealing with observables too, even if you just want to read data when submitting a form and validating some data on change/blur.
And often you’ll find that your data from promises, observables and signals need to interact with each other, which can be annoying.
Fortunately the situation with signals and their async usage is improving, and iirc the Angular team wants to make rxjs optional, but until it is Angular can be a confusing mess on some points.
halflife 16 hours ago [-]
I partially agree, there is an overlap between signals and rxjs, however the core business is different- observables are about data manipulation, while signals are about efficient state management.
Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and using DI it’s a drop in replacement.
5 hours ago [-]
azangru 23 hours ago [-]
> Observables - streams
> Signals - reactivity
The r in rx stands for reactive.
halflife 16 hours ago [-]
The react in react stands for reactivity, however it is not.
azangru 14 hours ago [-]
React reacts to changes in state or properties by automatically updating the UI. What's not reactive about that?
halflife 13 hours ago [-]
Its entire state management is not reactive, it’s always on push, not pull. You always need to call setState to get render changes.
azangru 13 hours ago [-]
But why is push vs pull the definition of reactivity?
I suppose we can say that there are different kinds of reactivity. Signals is one kind. Observables à la rxjs is a different kind (the whole model of programming with rxjs was referred to as "functional reactive programming"). Observables are push-based. Signals, as I heard, are a more complex primitive, which, under the hood, is push-pull.
React's reactivity model may be crap; but this doesn't make it non-existent.
halflife 7 hours ago [-]
Maybe push pull wasn’t the best metaphor, but the point is that everything can be reactive, it only depends on how much boilerplate you need to write to achieve the desired result.
Since react doesn’t have a true reactive model, you need to subscribe to changes manually (use effect) to create computations, while in signals it’s a primitive (computed).
I actually created a lib that operates signals over reacts state management (https://roypeled.github.io/react-logic/), so I removed the boilerplate to create a true reactive system.
If you want, you can create reactive system just from JS primitives, using callbacks. But that doesn’t make JS reactive by nature.
azangru 4 hours ago [-]
> you need to subscribe to changes manually (use effect) to create computations
How do you mean? Since the render function reruns during every update to state/props, derived/computed values can be calculated from the updated state/props during rendering.
halflife 2 hours ago [-]
When all you need is a synchronous operations, yes. When it involves async, batching, buffering, and user input, it becomes much more complicated, and every step needs to be setup manually.
zigzag312 7 hours ago [-]
UI is reactive, not state. You push changes to state and UI reacts to it.
halflife 7 hours ago [-]
A derived state is certainly reactive.
zigzag312 6 hours ago [-]
Of course you can have reactive state, your complaint however was:
"The react in react stands for reactivity, however it is not." [because] "Its entire state management is not reactive"
React is primarily an UI library, not full state management library. And its UI is reactive.
halflife 5 hours ago [-]
Agreed, the OP said that the r in rxjs stands for reactivity, so my point was the the names have little bearing on the actual design patterns achieved with the libs
The problem with Angular is that the http client service used to return observables by default and that made people think that you had to use them as such. It was a mostly useless, massive pain. Working with Angular became a pleasure the moment we decided to just cast our service calls to promises.
For the rest, RxJS is cool where you actually need it and want it.
mablopoule 6 hours ago [-]
Agree. RxJS is a beast to approach at first but it's a genuinely cool library, as long as you don't spread observable around when you don't actually need them. I used the same approach for a few years (pushing my http calls behind domain-specific api services that only return promise), and it's way simpler to handle.
I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, url state and api responses. Those top-level page usually keep the default change detection instead of the 'on-push' strategy).
jessyco 6 hours ago [-]
I never understood the problem with the rxjs, its a challenge to learn for those not used to the pattern but its very nice.
Regardless signals is also fine, we have ways now to interop between rxjs to signal for those looking for it:
Personally the http client workflow is fine. Usually lives in a service and exposes the needed values in any form we want.
majora2007 1 days ago [-]
What is rough in the ecosystem? I haven't had any issues finding packages. Most packages have been keeping up with the signal trends as well.
majora2007 1 days ago [-]
Really excited for this. I've been dying to use signal-forms and resources since they were experimental. Once I got on the signal train, I could never go back and having to use RxJS for forms became a major pain point.
darkteflon 1 days ago [-]
Could you say more about signals? Is it are all analogous to, say, game engine signals paradigms (eg Godot) - components at any depth emit signals and any other component can subscribe? Or something totally different?
I'm learning Godot right now with ambitions to launch a game on steam! Are you working on a game yourself?
kaicianflone 1 days ago [-]
Wow Angular Aria looks fantastic. Even have full docs for the more complicated scenarios like autocomplete. Can't wait to get this in my hands and see if it replaces the custom screen reader autocomplete I had to make.
embedding-shape 1 days ago [-]
Maybe I'm dumb, but I go to: https://angular.dev/guide/aria/overview#showcase and try out the keyboard controls, somehow they've decided that those elements should be navigated with the arrow keys instead of much more commonly used tab and shift+tab? Even the tabs from their own documentation, right above that example, also uses tab/shift-tab for moving focus between them.
miguel-muniz 23 hours ago [-]
A lot of those behaviors aren't their decisions, they're specs from the W3C[1]. The tab behavior may be an oversight though, the W3C page specifies subsequent tab presses should move the focus outside of the tab list, but it could also be an exception. I'm not an expert but sometimes there are exceptions made due to the realities that operating systems, browsers, and screen readers all have varying degrees of support for accessibility features. Accessibility is a very deep rabbit hole, which is why these kind of libraries are popular in the first place.
Yeah, sure, I'm well aware of that, it was more a reaction to parent saying that specifically the accessibility stuff looks amazing, but seems they haven't even nailed the basics yet, so I'm wondering where the amazing parts are.
With that said, the autocomplete example which parent mentioned, does seem well made. Was just surprising to see such a basic mistake in the documentation for the accessibility stuff, one would think they would take extra care to get it right there, as that's what people (and LLMs...) will read and retain.
beart 21 hours ago [-]
I recently upgraded a relatively complex angular project from v14 to v21. I feel like Angular development slowed down for a few years. However, looking at the changes over those versions in total makes it feel like a whole new framework.
TheChaplain 1 days ago [-]
I like Angular, it feels a bit like Django. Easy to use with everything included.
sgt 1 days ago [-]
Or I mean, you could just use Django (or some faster backend with templating and SSR). Using that with htmx you get the SPA experience and still without the madness of an actual rotten JS ecosystem.
NuclearPM 11 hours ago [-]
What is the “I mean” for? Are you clarifying a comment you made earlier?
CodeCompost 7 hours ago [-]
A few years ago I was in the process of abandoning Angular in favor of React.
I've gone back to advocating Angular because it has been making a major comeback. It's genuinely awesome now.
mablopoule 6 hours ago [-]
Same, I'm currently working more in React project, and I miss Angular so much that I actually use it in my personal project, it can be a genuine pleasure to use if you avoid over-engineering the rest.
React shines when it comes to the composability of components, eg. for data-table with customizable rows. It's still possible in Angular, but it's heavier.
For the rest (syntax, the ecosystem, routing, data-handling, DI), Angular is so much more straightforward. Services with dependency-injection is 99% of the time way simpler to reason about than React hooks, especially when you start to need cascading changes between hooks after user interaction.
hmokiguess 22 hours ago [-]
I enjoyed Angular before React, had a good run with it, it was a vibe, now if I'm being honest I totally forget it ever existed. Not to praise React either, lately I've been actually digging the htmx way, though I feel like the battle is now which framework/language is the agent more proficient with and the static/compiler level tooling can help catch mistakes.
kumarvvr 20 hours ago [-]
Been using Angular v21 for a very complex app. Have had a wonderful experience, in terms of the cognitive load to make and work with components, state and data flow.
Signals and signal stores make it very easy.
Did the whole coding by hand, no ai coding tools too.
healthDev 1 days ago [-]
Angular has made my programming career joy and it has not felt like work at all, all the best to angular dev team! Nothing better than getting to work with favorite language, learning better and getting paid :D
ku-man 23 hours ago [-]
[dead]
pan69 1 days ago [-]
import {signal} from "@angular/core"
import {form} from "@angular/forms/signals"
So, signal comes out of core and form comes out of forms/signals. This must be a terminology thing I don't get.
Other than that. Looking forward to try Angular again after a decade of absence. I think it looks pretty good.
majora2007 1 days ago [-]
Signals are a privative data structure in Angular, hence core. Signal-based forms are part of the Forms module. You aren't using forms, you don't get the overhead.
exac 1 days ago [-]
primitive
vyrotek 1 days ago [-]
There are a lot of ways to do Forms in Angular. I assume that's importing the new "Signals" based form.
etothet 23 hours ago [-]
I haven't been involved in Angular for quite some time. As someone who uses other JavaScript frameworks (Vue, React, Svelte), what am I missing out on? I'd be curious to hear from people who would pick Angular over any of the other big frameworks.
HatchedLake721 13 hours ago [-]
Angular (and e.g. Ember) are the “Rails” of frontend frameworks.
React/Vue/Svelte are view libraries that give you more flexibility.
Angular gives you structure.
For large enterprise apps with many developers, consistency and standardization is often the main reason people choose it.
eatsyourtacos 22 hours ago [-]
I would just say in general Angular is best if you basically want to build an old school application as a website.. and especially if you kind of hate javascript and web development but focus on the backend as the main part.
dzonga 20 hours ago [-]
most enterprises would be better served by being on an angular stack than the hodgepodge of shit called React.
fsuts 24 hours ago [-]
How does modern angular performance compare to the alternatives? Is it as fast?
majora2007 7 hours ago [-]
What does "fast" even mean? I always see people talk about performance and wonder, what kind of applications are they building where they are seeing a massive gap in performance between frameworks?
I'm pretty sure in this late game, all the frameworks are more-or-less the same in terms of render performance. Angular has a lot of cool tricks (with these signals) that allow for only re-rending what changes.
merb 1 days ago [-]
the biggest problem in angular is that it is so hard to use a custom toolchain, i.e. not their angular/cli product instead mix it with other stuff in lets say vite
zcdziura 1 days ago [-]
What kinds of features or workflows are you missing that Angular's CLI doesn't cover? Or is it just that you're used to Vite (or something else) and wish you could use that instead of Angular's own tooling?
I'm not on the Angular development team or anything, though I do use Angular at $DAY_JOB and I'm overall perfectly fine with the framework and its tooling. However, the grass might be greener elsewhere; I'm just not familiar with it!
merb 15 hours ago [-]
Mixing with existing code gradually migrating to and from angular
anthonypasq 1 days ago [-]
for many people this is the biggest bonus
equasar 23 hours ago [-]
explain your use case, I always wonder what kind of scenarios people do have, it is something easily solved? it is complicated? what is stopping you?
merb 15 hours ago [-]
Mixing with existing code gradually migrating to and from angular
shay_ker 1 days ago [-]
Seems like Angular has gotten better since v2 (my last experience).
Has anyone done a modern Angular vs. React comparison that's not an AI slop article?
I'm also curious if it's "simple made easy" for performant applications. React is arguably "simple made hard", but there are notable, highly performant applications written with it (Linear comes to mind).
vyrotek 1 days ago [-]
Angular Control Flow alone is a massive QoL improvement compared to the React way to do template conditions, switches, loops, etc.
Because the React team 100% cares about miniscule optimization enhancements, and 0% about otherwise making the tool better.
Source: Just look at what's been in the last couple years of updates.
zcdziura 1 days ago [-]
Modern Angular is MUCH nicer to use than the v2 days (or even the v4 days when I first started working with it). A lot of the required boilerplate is unnecessary nowadays. And even RxJS and NgRX are becoming less and less necessary to use too, which is great.
pjmlp 16 hours ago [-]
React basically is now focused on being Next.js infrastructure and designed to support Vercel and partners.
I only touch it when doing projects like Sitecore, Contentful, Sanity, and co, where React/Next.js are the official extension points.
So many hooks, use "this" and "that".
woodpanel 24 hours ago [-]
Out of curiosity I’ve progressed away from Angular around 2018. My peak spa-ish reduxian state management experience was building an NgRX combo with @ngrx/effects for side effects.
Till this day I remember this fondly as it gave me so much ease of control of the application’s many complex states. Especially when I nowadays deal with all sorts of false-prophets in forms of hooks and what ever reactive primitive du-jour (don’t get
Me wrong they are 80% of the time the better choice, it’s just that they don’t scale).
What’s today’s version of complex state management in Angular-Land?
stopyellingatme 6 hours ago [-]
NGRX Signals is the new way and its lovely.
Instead of having 5 files to get state hooked up, its usually 1 file and all/most functionality is co-located.
smrtinsert 15 hours ago [-]
A framework releasing an official MCP as well as making AI tooling a key offering is new to me and it immediately strikes me as absolutely necessary.
onesingleblast 21 hours ago [-]
[dead]
partsch 1 days ago [-]
Using angular in 2026 is mad :D
thm76 1 days ago [-]
When I look at job postings and see "React" I go "ugh" these days and find myself looking for Angular instead. That's the complete opposite of my thoughts from just two years ago.
I would still rather use something else (instead or React or Angular) but 1) most jobs in my area are asking for one of those, and 2) I'm actually starting to lean towards Angular even for personal projects.
Angular is great these days, and they're making really nice improvements.
rezonant 23 hours ago [-]
Absolutely same. I have been with Angular the whole time and it's only getting better and better.
I hope more teams give it serious consideration as I just am not excited about dealing with React and it's numerous spinoffs.
javier123454321 1 days ago [-]
Have you used it in the last 8 years? Its actually quite a good piece of software.
jessyco 6 hours ago [-]
You should try using it, using react is mad in 2026 for me.
I wish Angular dropped their weird compiler that's tight coupled to tsc and moved into more pluggable approach so you can use it with whatever TS compiler. App and unit test cold build times are still crap, but at least with a coding agent you care about this less.
Or has sanity reached the Angular ecosystem by now?
I would be more happy if it would be just one of those..
Promised - async
Observables - streams
Signals - reactivity
Until this release (if you only use stable features) using forms meant dealing with observables too, even if you just want to read data when submitting a form and validating some data on change/blur.
And often you’ll find that your data from promises, observables and signals need to interact with each other, which can be annoying.
Fortunately the situation with signals and their async usage is improving, and iirc the Angular team wants to make rxjs optional, but until it is Angular can be a confusing mess on some points.
Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and using DI it’s a drop in replacement.
> Signals - reactivity
The r in rx stands for reactive.
I suppose we can say that there are different kinds of reactivity. Signals is one kind. Observables à la rxjs is a different kind (the whole model of programming with rxjs was referred to as "functional reactive programming"). Observables are push-based. Signals, as I heard, are a more complex primitive, which, under the hood, is push-pull.
React's reactivity model may be crap; but this doesn't make it non-existent.
Since react doesn’t have a true reactive model, you need to subscribe to changes manually (use effect) to create computations, while in signals it’s a primitive (computed).
I actually created a lib that operates signals over reacts state management (https://roypeled.github.io/react-logic/), so I removed the boilerplate to create a true reactive system.
If you want, you can create reactive system just from JS primitives, using callbacks. But that doesn’t make JS reactive by nature.
How do you mean? Since the render function reruns during every update to state/props, derived/computed values can be calculated from the updated state/props during rendering.
"The react in react stands for reactivity, however it is not." [because] "Its entire state management is not reactive"
React is primarily an UI library, not full state management library. And its UI is reactive.
https://angular.love/angular-21-whats-new
For the rest, RxJS is cool where you actually need it and want it.
I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, url state and api responses. Those top-level page usually keep the default change detection instead of the 'on-push' strategy).
Regardless signals is also fine, we have ways now to interop between rxjs to signal for those looking for it:
https://angular.dev/api/core/rxjs-interop/toSignal
Personally the http client workflow is fine. Usually lives in a service and exposes the needed values in any form we want.
[1] https://www.w3.org/WAI/ARIA/apg/patterns/toolbar/
[2] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
With that said, the autocomplete example which parent mentioned, does seem well made. Was just surprising to see such a basic mistake in the documentation for the accessibility stuff, one would think they would take extra care to get it right there, as that's what people (and LLMs...) will read and retain.
I've gone back to advocating Angular because it has been making a major comeback. It's genuinely awesome now.
React shines when it comes to the composability of components, eg. for data-table with customizable rows. It's still possible in Angular, but it's heavier.
For the rest (syntax, the ecosystem, routing, data-handling, DI), Angular is so much more straightforward. Services with dependency-injection is 99% of the time way simpler to reason about than React hooks, especially when you start to need cascading changes between hooks after user interaction.
Signals and signal stores make it very easy.
Did the whole coding by hand, no ai coding tools too.
Other than that. Looking forward to try Angular again after a decade of absence. I think it looks pretty good.
React/Vue/Svelte are view libraries that give you more flexibility.
Angular gives you structure.
For large enterprise apps with many developers, consistency and standardization is often the main reason people choose it.
I'm pretty sure in this late game, all the frameworks are more-or-less the same in terms of render performance. Angular has a lot of cool tricks (with these signals) that allow for only re-rending what changes.
I'm not on the Angular development team or anything, though I do use Angular at $DAY_JOB and I'm overall perfectly fine with the framework and its tooling. However, the grass might be greener elsewhere; I'm just not familiar with it!
Has anyone done a modern Angular vs. React comparison that's not an AI slop article?
I'm also curious if it's "simple made easy" for performant applications. React is arguably "simple made hard", but there are notable, highly performant applications written with it (Linear comes to mind).
https://angular.dev/guide/templates/control-flow
Source: Just look at what's been in the last couple years of updates.
I only touch it when doing projects like Sitecore, Contentful, Sanity, and co, where React/Next.js are the official extension points.
So many hooks, use "this" and "that".
Till this day I remember this fondly as it gave me so much ease of control of the application’s many complex states. Especially when I nowadays deal with all sorts of false-prophets in forms of hooks and what ever reactive primitive du-jour (don’t get Me wrong they are 80% of the time the better choice, it’s just that they don’t scale).
What’s today’s version of complex state management in Angular-Land?
I would still rather use something else (instead or React or Angular) but 1) most jobs in my area are asking for one of those, and 2) I'm actually starting to lean towards Angular even for personal projects.
Angular is great these days, and they're making really nice improvements.
I hope more teams give it serious consideration as I just am not excited about dealing with React and it's numerous spinoffs.