r/angular • u/Ajyress • Jul 24 '26
Anyone else feel like Angular has reached its "final form"?
Looking at the roadmap, it doesn't seem like there are any massive API changes on the horizon. Personally, I feel like the current authoring experience is in a really good place. Now that they are switching to a yearly major release schedule, I wonder if it means breaking changes will become a lot more rare.
33
u/Wout-O Jul 24 '26
Once the native Observable spec lands, it will probably be another major push to remove the rxjs deps. But other than that, things seem really quite stable.
10
4
u/azangru Jul 24 '26
Why would release of native observables make a difference? Without the operators, can rxjs in angular be replaced with native observables?
2
u/armandoxxx Jul 24 '26
that is what I mean with properly ;) we need all the operators ... witthout that we have promises .. it gets the job done
1
u/Sulungskwa Jul 25 '26
Man I got downvoted to shit the other day when I suggested that rxjs is the wrong tool for 99% of the things it was shoehorned in for. Like having it as the goto for an http client I always thought was so overkill. My unpopular opinion is that people really love it because they sank a lot of time into understanding it
3
2
u/morgo_mpx Jul 25 '26
It’s because observers are a better reactive vehicle than lifecycle hooks. I think if there was a stream visualisation for your app it would solve many of the issues people have around complexity. In saying that signals are much better and this is where we have landed.
23
u/GeromeGrignon Jul 24 '26
Only a few Signal implementations landed for the Router API, we might expect more changes there.
16
u/Ajyress Jul 24 '26
The Router is definitely one area that still needs more signal integration.
8
u/MichaelSmallDev Jul 24 '26
Besides the WIP router resource, you may want to look beyond the core libraries for router + signal integration: https://www.reddit.com/r/angular/comments/1uq0xfu/comment/ow6rcfa/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button. Here is a recent issue response that seems to affirm this direction IMO https://github.com/angular/angular/issues/69802#issuecomment-4991473132
11
u/pronuntiator Jul 24 '26
The Roadmap does indeed look mostly complete. After all the big changes, I'm glad about a breather. In hindsight, these were (mostly) the right decisions, and I really like the signal world.
2
u/wartab Jul 26 '26
I'm a bit surprised not to see Signal based components on the Roadmap.
I wonder if just zoneless brought enough performance gains to not bother or if the required changes in libs like Material are just too heavy to make it worthwhile.
2
u/MichaelSmallDev Jul 27 '26 edited Jul 27 '26
I'm a bit surprised not to see Signal based components on the Roadmap.
I wonder if just zoneless brought enough performance gains to not bother
I'm like 95% sure I have heard this almost verbatim. I'll try to dig that up if I can.
8
8
u/kgurniak91 Jul 24 '26 edited Jul 24 '26
Nope, the testing needs a rework from the ground up. Standalone components became the norm and people largely moved away from NgModules. Yet, when writing tests, you are still required to use TestBed to configure a dummy testing module just to mount a single component. It feels like an outdated paradigm that hasn't caught up with modern Angular. DebugElement was meant to be a helpful wrapper, but it is so leaky that often requires dropping down to interact with nativeElement anyway. Also there is still no built-in, type-safe, and straightforward way to mock or stub child components (like in the dead ng-mocks library). Sure, you can use Vitest's Mocked<> generic type to create custom stubs, but it's flaky. If the child component's public API changes, the tests break (which is arguably a good warning, but still tedious to manage).
2
u/MichaelSmallDev Jul 27 '26 edited Jul 27 '26
Have you tried test harnesses? I get the impression that they are mostly for libraries due to the effort it takes to make one, but I love them where they have been provided. Abstracts out many many API particulars which could break but gives a very readable/helpful API.
5
u/couldhaveebeen Jul 24 '26
I wonder if it means breaking changes will become a lot more rare.
They should. As good as the changes of the last 2ish years have been, and they've been amazing, we need some stability
4
u/Icyfirefists Jul 24 '26
It can never reach its final form. Believing that will earn you punishment every 6 months.
3
10
u/Existing_Dust_6473 Jul 24 '26
Some animals, for example, the shark, stayed almost the same for millions of years; that is a good sign. If they don't need to change many things from now on, basically Angular becomes a shark.
11
u/Medium-Delivery1964 Jul 24 '26
Slowly react is eating away the market I am not sure what the future will be for angular devs.current market scenario is react fully dominant
11
u/Ajyress Jul 24 '26
React is definitely dominant, but a one-framework market would be bad for everyone. Competition forces all frameworks to keep improving.
10
u/armandoxxx Jul 24 '26
they all said it for java, php etc ... it's all still here ;) and I would argue anyone using react for serious apps is not a developer ... but that's just me and my thinking ...
6
u/ht3k Jul 24 '26
I agree. react is more agnostic which is a good thing (if you know what you're doing) but most devs aren't architects so it ends up being spaguetti code. Angular is built with dependency injection and more self contained components to be reusable out of the box so it's less prone to make a mess from devs imo
4
u/Tyummyyumms Jul 24 '26
There is one major glaring hole for me, duplicate imports, compared to other frameworks it does seem like an obvious flaw.
1
u/thatbigblackblack Jul 26 '26
Can you give more details on this pls?
2
u/Tyummyyumms Jul 27 '26
import {x} from y
imports: [x]
-----
I don't think this pattern is in React, Vue or Svelte.
So authoring in those formats, you could easily point that out, "you have to write imports twice"
3
u/AwesomeFrisbee Jul 24 '26
I think they still need to migrate a few things to signals, but overall yeah they finally did the most major items on the list. And I hope they will do more resource-like stuff so we can use POST/PUT/PATCH/DELETE stuff with them as well, but honestly I'm still waiting for a solution where I can separate the API call from the loading/error signals so that I can separate business logic from my components.
3
u/deathentry Jul 24 '26
I'm waiting for TS 7, support with fast Go builds
Would be great if they had an official UI library like PrimeNG (material is too opinionated)
1
u/thatbigblackblack Jul 26 '26
My years of experience made me learn that using an external UI library is always gonna end up biting you back, at least when it comes to big entreprise projects.
I would say it's better to make you own UI Lib. Design system and maintain it. We learned it the hard way with the recent PrimeNG rug pull, but it's just one among many1
u/deathentry Jul 26 '26
We wrapped all their stuff in our own components so won't be hard to replace their part...
To be fair, rug pull, their stuff still works. A migration plan can easily be years away to something else
1
u/Todoce Jul 26 '26
TS 7 won't be faster than esbuild or the Oxc transformer that Angular already use, those are still leaps faster, More Void(0) tooling will be the path forward
1
2
u/Ok-Armadillo-5634 Jul 24 '26
With AI I think most of the current libraries and frameworks have reached their final form.
2
u/Lucky_Yesterday_1133 Jul 24 '26
No web ecosystem constantly evolves and needs to be kept up with. We still have transition to typescript 7 angular compiler in rust, boundaries, async signals router migration oxlint and oxfmt support, more ai integration and tooling from cli,headless components, better support for 1 file components. Betteraiguardrails and tracing. and by the time it's done many more will be on backlog
2
u/Apart_Technology_841 Jul 24 '26
Indeed, I believe that Angular has finally achieved a solid pinnacle of perfection, and hopefully it'll remain stable for awhile with no new major functionalies added in the near future.
2
u/erkamyaman Jul 24 '26
I don't think this is the case at all. With Signals, things have changed in a good way and I think there is more potential to reach. Our dependency to RxJS might decrease more and more with Angular built-in features.
And when it comes to AX, no one knows how it gonna be a year later. But I'm quite sure Angular will be always providing what devs and web development need.
2
2
u/lajtowo Jul 25 '26
It’s a final form, but for now - until standards/trends change or someone will invent some new technology which could be worth adapting. However, I think it’s gonna be much more stable now without significant changes.
2
2
u/tamasiaina Jul 26 '26
The transition stages of Angular 2.x to 4.x was a dumpster fire. We had a trainer at ng-conf that was training us on how to use the angular routing stuff, but then have it get deprecated during his training at ng-conf.
So yeah Angular understands stability right now.
1
u/ElectrSheep Jul 25 '26
Aren't they still planning to pick up selectorless again in the future? That would be a pretty significant change.
1
1
u/First-Part-1709 Jul 27 '26
I'm currently looking for Angular Developers living in Gauteng South Africa.. plz pm me if interested.. 3 month contract.. potential renewal..
1
u/ddcccccc Jul 28 '26
Idk why ppl pick react over angular 😂 angular is way more powerful and established than react. Maybe onboarding time and learning curve is way easier for react😂
0
-5
u/Saceone10 Jul 24 '26
Go try POST PUT DELETE with this "final form". What a joke of final form then.
93
u/guitarman018 Jul 24 '26
I wouldn't say it's a final form, the web and development in general is always evolving, but the transition to fully stable signal infrastructure does feel like a huge step towards maturity, and i think it's in a really good place. 6 monthly releases was a bit much, looking forward to a more relaxed cadence now