TLDR: I need advice and input to try and course-correct a really questionable technological decision.

Background: I'm a senior full-stack developer who is also the frontend lead at my company. And we have built an extensive suite of Angular applications over the last 10 years. I specifically joined this company because they were using Angular.

Problem: The company was acquired a few years ago, and we need to now start delivering a unified product. An arbitrary, to me, decision has been made to switch to react.

My small team of Angular devs and I (4 in total) will be mainly responsible for creating this new platform UI, with little to no assistance from the parent company.

Our micro frontend suite is already fragmented across versions from 17-22, partly due to team size, silos and speed of priority changes from our internal stakeholders. This is how I found it, and I've tasked myself with getting this into a proper single workspace and single versiob. Think duplicated components, services re-invention of the wheel in terms of auth - for every single MFE.

I'll be honest, that we are also trying to rebuild our reputation as a team within our business, and due to the factors mentioned above, we've been delivering inconsistently for the last 18 months - which I am trying to fix.

I implicitly know the benefits of Angular, because I've also worked with AngularJs (1.7.8) and have been exposed to more React code than I would like to admit.
And I'm so committed to Angular that I'd likely start a cult if I could!

Has anyone here managed to reverse a decision like this and managed to convince the organisation to stick with what their team knows? I'm really trying to save us from a disastrous (in my opinion) direction change - which I've seen fail spectacularly at my previous job.

I have an elaborate document that I need to refine present to management. . My managers are mostly onboard, but this will ultimately be presented to our executive leadership team too.

Preferred stack:
* Angular 22, Built on our existing APIs, with signals for state and rxjs where absolutely necessary.

* Native federation instead of iframes (requires version upgrades, but can run in parallel for a while)
* Un-styled Angular CDK components where possible with TailwindCss and accessibility built in, tables are a big thing for us, and the mat-mdc overrides have been laborious
* Angular material where cdk is insufficient
* Firestore where needed
* Graphql where used currently - no new gql for now
* AI integration for developer productivity improvements where needed

This is my proposed outline.

* How does this align with our Org goals?
* Language/framework/library?
** What is react good at?
** What is angular good at?
** Tradeoffs
*** Learning curve
*** Technical decisions, ownership and maintainability
*** Recruitment i.e. cv driven development vs proper architecture and solutions

* Why does it make more sense to use Angular in a ln enterprise environment?
** Existing use of google technologies
** First class integrations into maps and firestore

* How do we achieve our goals and keep our organisations and developers happy?
** Upgrade our existing suite to the same versions
** Move them into a single work space
** Extract truly shared concepts
*** Auth
*** Models
*** Data retrieval
*** Feature flagging
*** Ui components

Have I missed anything? Is there something that you would add if you were in my position?

I have also left a previous job about a similar decision, so I'm serious about this topic. And I have explicitly stated that it will affect my decision to stay on, or perhaps changing dev-streams from full-stack to backend-only. Which is not ideal for me because I really like doing both (within my specific tech stacks of course).

Please help me r/Angular, you're my only hope!

Hey everyone,

I’m building an open source package called ng-openapi-signals:

https://www.npmjs.com/package/ng-openapi-signals

It generates Angular API clients from an OpenAPI specification, using resource() and fetch().

Why I built it:

I wanted an OpenAPI generator that produces code I would actually enjoy using in a modern Angular app: typed, readable, signal-friendly, and not overloaded with abstractions.

It can be useful if you want to focus more on pure Signal-based logic in your Angular application and prefer not to structure your API layer around the traditional Angular request patterns anymore.

A lot of existing generators are great and very feature-rich, but for my own projects I wanted something smaller and more focused. The idea is to generate simple Angular-first clients that work nicely with newer Angular APIs.

The current focus is:

• Angular-friendly generated clients
• Request state handled through resource()
• Requests executed with fetch()
• Strong typing from the OpenAPI schema
• Readable generated code
• Minimal boilerplate in the application
• A lightweight API that is easy to understand
• A good fit for apps that want to lean more into Signals

Since this is still early, I’d love to get feedback from Angular developers who use OpenAPI, Swagger, generated clients, or Signals.

I’m especially interested in:

• Does the generated API feel useful in real projects?
• Does the resource() approach make sense for your use cases?
• Would this fit apps where you want to focus mostly on Signal-based logic?
• Are there OpenAPI specs where the output breaks or feels awkward?
• What features would you expect before using something like this?
• How does the DX compare to what you currently use?

I expect there to be bugs and missing features, so any feedback, issues, feature requests, or contributions would be really appreciated.

Thanks for your time!

Hi everyone! I have about one year of experience with Angular 16 and my company is currently migrating our codebase directly to Angular 21 (v21). We are shifting toward Signals as our primary state management tool.

I am running into a design dilemma regarding how to handle the initial state of complex objects (e.g., user profiles) before an API call finishes, and I want to make sure I'm writing clean, idiomatic Angular.

The Dilemma

If I have a complex interface like IUserData (which has 15-20 fields), I see two main approaches, but both feel messy:

Approach 1: Initialize with mock/empty data

public user = signal<IUserData>({ id: 0, name: '', role: '', email: '', ...15 more fields });

ngOnInit() {
  this.api.getUser().subscribe(data => this.user.set(data));
}

• The issue: If the interface is large, this results in a massive block of boilerplate mock data just to satisfy TypeScript. It feels highly unmaintainable.

Approach 2: Initialize as undefined

public user = signal<IUserData | undefined>(undefined);

• The issue: This forces me to pollute the child templates with the safe navigation operator (user()?.name) everywhere, even though I know the data will strictly be there once the page loads.

My Questions:

1. Coming from regular variables where we could sometimes play loose with initialization, what is the community's best practice for handling large object structures in signals before the API resolves?
2. In TypeScript arrays, we can use the non-null assertion operator (e.g., list.find(...)!) if we are 100% sure the data exists. Is there an elegant equivalent for Signals in the template, or is ?. the only way if we go with the undefined route?
3. Are there architectural patterns (like RxJS interop toSignal) that completely bypass this initialization headache?

Would like to hear how you all handle this in your production apps!

I’ve been developing in Angular in an enterprise environment for 5 years. Based on my recommendation, five teams switched to PrimeNG. We have thousands of Spectator-based tests. In recent weeks, Spectator has disappeared and PrimeNG has become paid.

Of course, comments will come saying the big company should just pay for it. But in a large company, everyone operates as a small development team with a strict budget, and a procurement like this can take years. It’s often simpler to just rewrite everything using NG-ZORRO.

I like Angular’s enterprise approach and the fact that everything is integrated, but if I use tools that are not integrated into the ecosystem, like Spectator or PrimeNG, it will eventually become a pain.

I understand the OpenNG Foundation initiative, but I feel that in the long run it will fade away. Far fewer people contribute to enterprise frameworks, because most companies’ policies prohibit that kind of activity, and for hobby projects people do not necessarily choose this stack either.

Lately, I’ve been asking myself: does this have a future? Will there be a community behind it?

Yes, I know this may sound like “ultra rich multinational company can no longer use a community-maintained tool for free,” but at the end of the day we are also just a small team of few people with a budget and limited time. If I have to spend that time developing basic tools, then I would rather just switch to React, because in that ecosystem these things are already available.

I'm curious how others see this.

Hey there guys. first time poster, looong time lurker.

I’ve been working on this project for quite some time. in fits and start.

i was inspired by Dustin Brett’s ReactOS ( aka daedalOS ) and PuterOS (account now needed to access), that were posted a few years ago.

Dustin’s tutorial were instrumental in getting me off the ground. many thanks 

Anyway, here is my modest take on this exercise.

Note! There are a lot of bugs, and more things still need to be fixed and, or improved.

it is not a mobile friendly site….yet ( on my todo list), and a number of odds and ends waiting to be tied up 

 Honest feedback / criticism is very welcome 

Ng add angular material gives you the library installed and configured. PrimeNg and Spartan does not do this. Instead you have to either config manually or run a :init schematic manually. Same for updates with breaking changes in PrimeNg.

Also why wouldn’t tailwindcss support a simple ng add tailwindcss schematic? I can understand if the library is not angular specific, but what f.ex. about PrimeNg?

Is it very complicated to support, are the developers «lazy» or are there better reasons?

Thanks for your insights.

After the CSS Conference recently I was so inspired so I want to see how far I can go. As a Proof Of Concept I create this tooltips Directive. You should not use it tho due to the lack of browser support. This is the npm package.

I leverage interestfor, anchor position and use Angular DI to keep 1 single Popover alive at all time. With signal now being stable I could just use it to project text content. Variables are used to follow Angular Material mat-sys-token. I just like Angular Material :D.

As per usual, I write the code in away that you can just copy paste it into your codebase.Also check out my File Drop.

Started a project in PrimeNG About 15% completed, but with the new commercial license, what the best course of action? rewrite with a new ui or just keep going?

Gross. No thanks. I hope this fails miserably. The end of an era.

As announced on June 29th, PrimeNG is moving away from the open-source model, and the original primeng GitHub repository has been archived.

You can find community reactions here: https://www.reddit.com/r/angular/comments/1uilrlx/primeng_v22_is_no_longer_open_source/

As part of the new OpenNG Foundation, we are considering taking up the lead to maintain a fork of the MIT version of the lib.

It's under discussion, and we would need community feedback to evaluate if it's doable and on how to manage the current situation.

Some statements:

- an update is required to rename everything from 'primeng' to 'openprime' due to PrimeTek trademark
- the components need to be updated to the latest Angular APIs (including input(), control flow among other things)
- there are 900+ issues opened (including 300+ in stale state)
- there are 200+ open pull requests
- there would be no support for previous primeng versions
- the focus would be to make the library stable and accessible: adding features would happen only if people contribute
- over time, some changes might make this fork differ from the new PrimeUI project, not providing a way to easily migrate.

PrimeNG is still a big project, we are considering starting with a trial maintenance initiative for 2 months: depending on the community effort at helping with existing issues/prs, there will be long-term maintenance.

It'll be a great way to identify active contributors who might be promoted to maintainers if they want to be more active on such a project, making the whole thing a community effort.

A 'fork' has been created already, porting all existing open issues/pr: https://github.com/openng-foundation/open-prime

What are your thoughts?
Do you have some pain points not covered here?

Hi Reddit,

After a decade of fighting complex form requirements, state management nightmares, and rebuilding the exact same inputs across different frameworks, our team of three finally built the library we always wished we had.

Meet GolemUI an Open Source headless library that turns your entire form into a single, plain data definition. One JSON definition renders as native components in Vue, React, Angular, Lit, or Vanilla JS. Because it's just data, you can store it in a DB, version it, and have an LLM generate it as validated JSON instead of code.

We ship a deterministic MCP that grounds and validates the model's output, plus 25+ headless widgets you style with CSS variables or your own kit.

You can find more information here:
https://golemui.com

Happy to hear any feedback from you and answer any question!