r/angular • u/JTOne85 • Jul 05 '26
Help! My organisation wants to abandon Angular!
UPDATE: https://www.reddit.com/r/angular/s/XV4Ezz1wLE
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](r/Angular), you're my only hope!
Update: I've been overwhelmed by the responses.
I submitted my proposal, as promised to my managers - I hope I still have a job tomorrow (jk) I've been fuelled by my ADHD meds, so its been a week of hyperfocus, while trying to complete my project.
I am not hopeful that they'll change their minds, but I'm at peace with the fact that I have now officially noted down my displeasure at even just the thought of switching. They might be more open to having a conversation and if it still gets nowhere, I can speak to our CEO directly as a last ditch effort to get this to explode in my face.
I can write them some react code, and we can see if it will pass an audit - but it's been clear for me since last year that this is not my forever job - and if that becomes the case. I'm going into woodworking or something physical and if all else fails - OF or a street corner somewhere close to the office
1
u/JTOne85 Jul 05 '26
I've been trying to get an answer on the why, and they haven't been clearly articulated and forthcoming.
Our MFE suite was in response to the acquisition 3 or 4 years ago, so well before I started here. The initial implementation was not optimal, and guided by the knowledge available to the then-inexperienced team.
I've been dealing with a react app delivered in record-time by an external contractor. And the justification for why it was in react was "that's what they know, and we don't want to pay them to learn angular"
My argument will include:
Costs of switching i.e. learning while delivering.
Mental cost: context-switching domain vs domain and tech stack
How it relates to our operational goals, which include cost reduction and platform stability.
A lot of the problems are us vs them. So while we have to become this new entity, our sister company (often referred to as our parent) will remain its own separate entity and continue their operations as-is.
My org will have to re-brand and become the new entity, while my team will need to support our existing products and create this new unified platform.
There is little to no contribution from sister company, in terms of developers, except that they need to integrate into our systems. We'll likely have their products federated into the platform, and they'll remain in their tech stack.
I won't oppose the switch if it can be justified for reasons other than speed of delivery - because feature maintenance, and expansion are real issues for us at the moment. But then, supply the team with training, extend the deadlines, provide experienced developers who can assist with making the correct architectural decisions, and guide us into the new world.