r/angular

We have probably one of the largest monolithic Angular apps in the world and migrate from webpack to esbuild and while that has been great in local development ad the build duration dropped significantly, there is no chance we can use esbuild for production builds.

The amount of chunks that esbuild creates puts such a throttle on the application startup even with http 2.

I am sure other large Angular apps have faced this problem as well - have you found any solution?

Hey everyone,

While working on one of my projects, I kept running into the same problem: checking the UI across different screen sizes was taking more time than the actual change sometimes.

I’d fix something on desktop, then notice it looked off on mobile. After fixing mobile, tablet would need changes too. Most of the time I was just resizing the browser, switching device modes, and trying to remember what broke where.

I looked for tools that could make this easier, but most of them didn’t really fit how I wanted to review things. So I built a small Chrome extension called Multi Device Viewer.

It lets you preview multiple screen sizes side by side in one place, so you can catch responsive issues faster.

A few things it helps with:

• Viewing multiple devices at once
• Testing mobile, tablet, desktop, and custom screen sizes
• Spotting layout issues across breakpoints
• Reviewing UI changes without constantly resizing or switching tabs

I’m still improving it, so I’d really appreciate any feedback, ideas, or bug reports if you try it.

https://preview.redd.it/3w0lr6rhcb2h1.png?width=3024&format=png&auto=webp&s=8a4eea5e922b1c65461cfe3bae817a18780e9c8d

https://chromewebstore.google.com/detail/multi-device-viewer/jfcnekmenjickfihkniaoaklehjmdhdb?authuser=0&hl=en-GB

Hi guys quick question do you find ai tools to be useful when generating html and css codes for ur designs when using ai prompt to designer tools?

I have created this guide for anyone who has an Angular interview coming up. Before writing, I observed that most of the resources covered a listicle kind of thing without proper explanation. So, I thought that a more detailed and on-point resource is needed.

The advanced section covers Signals, Ivy, performance optimization, and state management patterns, which are now common in senior interviews.

You're gonna love this. Do check it out, here.

Hi guys,

I'm a Junior Frontend Engineer (Angular) with around 2 YOE.

Last week, I got laid off from a startup. I had already started applying for jobs back in November 2025 when I began noticing red flags due to team restructuring, but so far I’ve barely received any responses apart from 2 screening calls.

I’m applying through multiple platforms including LinkedIn, Naukri, Indeed, Instahyre, Cutshort, Wellfound, and company career pages. I also checked my resume ATS score across different platforms to make sure that wasn’t the issue, and it consistently scores above 85.

One thing I’ve noticed is that the Angular job market seems much smaller compared to React. At this point, I’m confused about whether I should:

• Continue focusing mainly on Angular and keep applying, or

• Spend the next couple of months learning React, build a few projects, and apply for jobs in parallel.

Would really appreciate suggestions from people who’ve been in a similar situation or are currently hiring/frontend devs themselves.

P.S. If this isn’t the right sub for this post, please suggest better ones where I can ask this.

We started TailNG mainly for our own Angular projects.

Initially, the idea was simple: create some wrapper components on top of \@angular/aria``. But once we needed more complete components similar to Angular Material, we slowly started building our own components with the help of AI tools.

We are already using these components in one of our projects and fixing the gaps we face while using them as developers.

The current direction is:

• Angular-only
• Signal-first
• Mostly targeting Angular 21+
• Accessible primitives/components
• Easy to customize
• Useful for normal apps as well as dynamic UI rendering

One thing we are also experimenting with is generating UI from JSON at the client side.

We had built a POC where an AI chat window can be added to an existing (angular) app, and users can perform tasks by chatting. But generating dynamic HTML directly through AI feels slow. So we are trying to make these components usable in that kind of JSON-driven UI scenario too, without affecting performance.

Still early, but sharing here to get feedback from Angular developers.

https://tailng.dev
https://github.com/tailng/tailng-ui

I know that somehow this should be possible but not sure exactly since which version angular supports this? This comes from the underline webpack (or vite most recently) bundler isn't so?

I have a relatively large app in angular 15 and it does not seem to apply tree shaking (I see large bundles)

Actually I am not even sure how to check if tree shaking is applied or not - when tree shaking is applied vs. not applied what kind of savings % to expect on the output bundles?

Should the code be written in a specific way for tree shaking to work?

Most cookie-consent options I evaluated for a recent Angular project felt tied to the NgModule era, pulled in dependencies I didn't want, or hadn't seen a commit in a while. So I ended up rebuilding one from scratch for Angular v17+.

Current state — v0.6, working towards a stable v1.0:

• Standalone components, no NgModule
• Signal-based consent state (with RxJS bridges for the holdouts)
• Functional setup: provideCookieConsent({ ... })
• *ngrIfConsent="'youtube'" for conditional rendering
• Google Consent Mode v2 adapter built in — maps your category state to gtag consent signals (the only adapter shipped today; others can plug in)
• SSR-safe, zero runtime deps
• Compose categories from typed cookie items each having their own toggle (GOOGLE_ANALYTICS, META_PIXEL, HOTJAR, YOUTUBE, …) via a makeCategory() helper — or hand-roll a category if you want full control.

A simple Live demo (interactive): https://ngrithms.aalbadra.workers.dev/cookie-consent

What I'm not sure about yet and would genuinely like opinions on:

1. Storage is a cookie on the current origin. Has anyone needed cross-device / server-side persistence + an audit log of consent changes, or is that comfortably out-of-scope for a frontend library?
2. Anything you've hit in production with other consent libs that you'd want this one to handle out of the box?

Not trying to dunk on existing libs. This is just the version I wished existed when I started.

https://preview.redd.it/is97zz5cyn1h1.png?width=2880&format=png&auto=webp&s=fabfa5917085cabcda4099350f89647e01ddf757

Repo: https://github.com/aboudbadra/ngrithms-cookie-consent

npm: https://www.npmjs.com/package/@ngrithms/cookie-consent

Happy to take harsh feedback — better now than after 1.0.

This is part of a small family of focused Angular libraries I've been building under `@ngrithms/*`. The other one currently live is `@ngrithms/idle` (signal-first user-inactivity detector with multi-tab sync) — demo at https://ngrithms.aalbadra.workers.dev/idle if anyone's curious. If you've got a "I wish there was a small Angular lib that just did X" itch, I'm taking suggestions.

Running into an architectural problem with AG Grid and Angular signals and not sure what the right pattern is.

The setup: My rowData is derived from a chain of computed signals:

randomNoteDetail (linkedSignal)

→ randomNoteLines (computed)

→ sortedLines (computed)

→ gridRowData (linkedSignal) ← resets here

The problem: Whenever transferNoteDetail changes for any reason, gridRowData resets to server state and wipes any unsaved in-grid edits the user made via cell editing or applyTransaction.

I know AG Grid manages its own internal row model independently of the rowData binding — so they diverge after first render. But linkedSignal re-evaluates eagerly and keeps pushing stale server data back into the grid.

The tricky part: updates to rransferNoteDetail are legitimate — buyer, seller, date etc. can all change — but those updates cascade into lines which cascades into rowData and resets everything.

How are others handling this? Is the answer to fully abandon reactive rowData and own the grid state entirely via applyTransaction? Or is there a clean way to keep the two in sync?

A week ago I posted about ArchUnitTS, my library for enforcing architecture rules in TypeScript projects as unit tests.

A few of you specifically asked whether this could be used to enforce clean Angular feature/module boundaries in real projects: making sure feature modules don’t import directly from each other’s internal files, and instead communicate through public API barrel files like index.ts or public-api.ts.

So to that request I’ve added exactly that.

---

First a mini recap of what ArchUnitTS does:

• Most tools catch style issues, formatting issues, or generic smells.
• ArchUnitTS focuses on structural rules: wrong dependency directions, circular dependencies, naming convention drift, architecture/diagram mismatch, code metrics, and so on.
• You define those rules as tests, run them in Jest/Vitest/Jasmine/Mocha/etc., and they automatically become part of CI/CD.

In other words: ArchUnitTS allows you to enforce your architectural decisions by writing them as simple unit tests.

That matters more than ever in Claude Code / Codex times, because LLMs are great at generating code but they love to violate architectural boundaries, especially when they get stuck.

Repo: https://github.com/LukasNiessen/ArchUnitTS

---

Now what’s new

Exclusion-aware dependency rules for Angular public API boundaries

Before, ArchUnitTS could already enforce internal dependency rules like:

• “components must not depend on infrastructure”
• “core must not depend on shared”
• “feature A must not depend on feature B”
• “folders must be cycle-free”

But one common Angular case was still a bit annoying to express cleanly:

A component in one feature should not import directly from another feature’s internal files.

For example, this should usually be forbidden:

import { OrderService } from '../orders/internal/order.service';
import { OrderCardComponent } from '../orders/components/order-card.component';

But this should be allowed:

import { OrderSummary } from '../orders';
import { PUBLIC_ORDERS_TOKEN } from '../orders/public-api';

This is not technically always a circular dependency.
But it is still architectural coupling.

It means another feature now knows the internal folder structure of orders. If the orders feature reorganizes its components, services, hooks, facades, or models, unrelated features can suddenly break.

So ArchUnitTS now supports except in pattern matchers.

Example:

import { projectFiles } from 'archunit';

it('should consume orders only through its public API', async () => {
  const rule = projectFiles()
    .inPath('src/app/**/*.ts', {
      except: { inPath: 'src/app/orders/**' },
    })
    .shouldNot()
    .dependOnFiles()
    .inFolder('src/app/orders/**', {
      except: ['index.ts', 'public-api.ts'],
    });

  await expect(rule).toPassAsync();
});

This says:

• check all Angular app files
• exclude files inside orders itself, because a module may use its own internals
• forbid other features from depending on files inside orders
• but allow imports through orders/index.ts and orders/public-api.ts

So this fails:

import { OrderService } from '../orders/internal/order.service';

But this passes:

import { OrderSummary } from '../orders';

You can also make the exceptions explicit by target:

.inFolder('src/app/orders/**', {
  except: {
    withName: ['index.ts', 'public-api.ts'],
  },
});

This is especially useful in Angular projects because Angular feature modules often create natural architectural boundaries, but violations tend to accumulate silently over time.

And these imports are very hard to catch in code review because they look like normal TypeScript imports.

Now the boundary can be tested directly.

---

Very curious for any type of feedback! PRs are also highly welcome.

I will be honest there was a stretch where Angular felt like it was losing the plot. While React is winning hearts with their simplicity and Claude (Claude AI responses are in react.), Angular was still making you set up NgModules just to sneeze. It felt heavy. Ceremonial. Like framework bureaucracy.

Then something shifted.

Starting around v16, the Angular team stopped patching the old machine and started building something new underneath it. Quietly, consistently, version by version they rewired the whole thing. And now with v21 dropping in May 2026, I think it's finally time to say it out loud: Angular is genuinely exciting again.

Here's how we got here.

v16 & v17 —> The Wake-Up Call

Angular 16 was the first sign something was different. Signals landed in developer preview a lightweight reactivity primitive that had nothing to do with RxJS observables or zone.js magic. Just clean, trackable state. It was not flashy, but developers who paid attention knew what it meant.

v17 was where things got loud. They redesigned the docs, refreshed the brand, and more importantly, gave us a new control flow syntax u/if, u/for and u/switch that actually looked like code instead of XML markup accidents. *ngIf always felt like a workaround. u/if feels intentional.

They also shipped u/defer for lazy loading components, which I would describe as the best quality of life improvement Angular has had in years. And swapping Webpack for Vite + esbuild cut build times by something like 67%. That alone changed how the framework felt to work with day to day.

v18 & v19 —> Killing zone.js (Slowly, Carefully)

Zone.js has always been Angular's secret weapon and its dirty secret at the same time. It is how Angular knew when to check for changes  but it iss also a monkey patching library that wraps every async operation in the browser. Not exactly elegant.

v18 introduced experimental zoneless change detection. The idea if your app runs entirely on Signals, Angular can skip zone.js altogether and only update the DOM when a signal says something changed. Faster, leaner, more predictable.

v19 made standalone components the default (finally), and added linkedSignal and the resource() API which, if you've ever tried to manage async loading states with RxJS, will feel like a revelation. It handles the loading/error/data cycle for you in a signal native way. It is the kind of thing that makes you wonder why it took so long, then realize the groundwork had to be laid first.

v20 —>Stabilization (The Unglamorous but Necessary One)

v20 does not have a flashy headline feature. What it has is stability and that actually matters. The zoneless APIs went stable. effect(), linkedSignal, the whole reactive core production ready. You could finally build a greenfield app without nervously checking whether that API was still experimental.

They also tightened security: automated XSS/CSRF protections, stricter Content Security Policy enforcement. And dynamic component creation got significantly less painful. No more wrestling with ViewContainerRef for basic runtime use cases.

v21 —> Where It Gets Interesting

Angular 21 is the first version where I feel like the team is going on offense rather than playing catch up.

Signal Forms  have been the one area where Angular reactivity story fell apart. ReactiveForms work, but they don't feel reactive in the modern sense. Signal Forms are a ground-up rethink: signal-based, zoneless compatible, and built around validation patterns that don't require you to think four layers deep. It's still early, but the direction is right.

Angular Aria Package Accessibility primitives built directly into the framework. Not a third-party bolt-on, not a style guide recommendation actual framework-level tooling for building accessible components. This is the kind of thing that matters enormously for enterprise teams who have compliance requirements and not enough time.

MCP Server Integration This one's forward looking. Angular 21 ships with Model Context Protocol server tools, which means AI coding assistants can actually understand your Angular project structure and generate correct, idiomatic code. Whether or not you're bullish on AI tooling, the fact that Angular is investing here signals (pun intended) where developer workflows are heading.

The Honest Summary

Compare an Angular 15 codebase to an Angular 21 codebase and they look like different frameworks. The NgModules are gone. The *ngIf soup is gone. Zone.js is optional. The build tool is fast. The reactivity model is coherent.

None of this happened overnight, and none of it happened by accident. It was a deliberate, multi-year migration and the Angular team mostly pulled it off without breaking existing codebases, which deserves more credit than it gets.

If you wrote Angular off a few years ago, I get it. The timing probably made sense then. But if you haven't looked at it lately, it's worth a fresh look. The framework that made you set up a module to register a pipe is not the one you'd be using today.

I'm trying to learn how to build a proper CRUD app in Angular by looking at how professionals structure their code. I thought the fastest way would be to download a fully working, modern project and study it side by side while I build my own. But I'm hitting a wall.

I found a few repos, but they're either Angular 17 or lower, or they don't even run after I do npm install and ng serve—broken dependencies, missing backends, that kind of things. I just want something that works, no much extra setup for a database or server.

Also, when I do find one, is npm install enough or do I need to run any other commands? I know sometimes there's a npm audit fix or --legacy-peer-deps thing.

If you know a good repo that fits this, please drop the link. And if there's any other posts, guides, or sources you'd recommend for understanding how to actually structure a CRUD app (not just the basics, but the real wiring), I'd really appreciate that too.

I really am motivated to analyze some well made code from someone that knows how to code, how do things connect with each other inside angular that would help me a lot.

Hey everyone. I’ve been learning React for about half a year (State management, Next.js, etc.) and I’m now adding .NET for the backend. I’m being pressured to switch to Angular because apparently, that’s the "standard" pairing for C# devs

Is there any truth to this anymore? and if so how much time do you think it would talk me to make the switch (I am pretty comfortable with state management, react query, caching srr, ssg, tailwind css, design patterns)

What is your favourite Angular feature?

Mine is signal, because it allows to update UI when data changes.

Hi, I have been working in angular on and off from ng 2. But never worked on mobile app built based on ng. I have requirement on side project for web and mobile and can’t hire any dev, I will leverage ai to get up and running. I also have time and eager to learn mobile apps. So, should I start ng and capacitor. Any one actually tried to keep both mobile and web apps from same code base and how is you experience and lessons. Appreciate your responses

So I built the animated number component I kept wishing existed:

smooth odometer-style digits for counters, stats, prices, timers, dashboards, and any UI where numbers change.

Built for Angular. No animation libraries.

GitHub:

https://github.com/ayangabryl/ngx-digit-flow

https://reddit.com/link/1tcy5tr/video/xkudyw6lk81h1/player

I am writing this as a founder who works closely with Angular teams building large SaaS products every day. Everywhere the same frustration keeps showing up. Why do so many enterprise Angular applications become harder to maintain as they grow? From where I sit, Angular 22 is starting to answer that question very differently. Angular is no longer optimising around framework abstraction first. It is moving toward explicit reactivity, predictable rendering, and systems that scale operationally over time.

Signals are a good example of this shift. For years, Angular applications relied heavily on global change detection and observable-heavy local state patterns. That worked, but it also created applications where rendering behavior became increasingly difficult to reason about as products grew. Angular 22’s continued push toward signals changes that model. Updates become more granular. Rendering becomes more predictable. Complex forms and workflows become easier to manage without unnecessary application-wide checks happening constantly in the background.

The interesting part is that these improvements are not really about developer convenience alone. They affect how products actually feel to users. In large B2B SaaS platforms, rendering inefficiencies eventually become operational problems. Slow dashboards create frustration. Workflow lag creates support tickets. Confusing UI state creates onboarding friction. Sales demos feel heavier than competitors even when the underlying product is technically stronger.

Angular’s movement toward OnPush-style defaults and zoneless architecture also reflects a bigger frontend trend that many teams are slowly recognising. Frontend engineering is becoming architecture-first again. The challenge is no longer building components quickly. AI can already generate components and boilerplate code in seconds. The difficult part is building systems that remain understandable, performant, and maintainable after years of product growth and evolving business logic.

AI still struggles with the problems that matter most inside enterprise frontend applications. It cannot reliably decide rendering boundaries. It cannot reason through workflow orchestration across deeply connected systems. It cannot fully understand why one onboarding flow creates cognitive overload while another reduces support dependency by 40%. Those decisions still require human product judgment, architectural thinking, and real operational experience.

From a founder’s perspective, the strongest frontend engineers today are not simply framework specialists. They are systems thinkers. They understand state management, rendering strategy, performance tradeoffs, accessibility, onboarding behavior, and long-term maintainability as one connected product problem rather than isolated frontend tasks.

Angular 22 does not feel like a flashy reinvention of the framework. It feels more mature than that. It feels like Angular recognising that large frontend systems succeed or fail based on predictability, maintainability, and operational clarity over time. That is probably the direction enterprise frontend development needed all along.

I am not sure if what am I about to say is related to Angular, but for you guys context, I have been working with Angular for more than 5 years now (from Angular 7 to 16, now migrating my legacy mindset to more modern Angular architecture).
In the current rising age of AI-driven SDLC in my workspace, I am working closely with AI to handle task, asking AI question regarding architectures, best practices, analyze tickets, etc...
In short, AI took the fun out of developing for me (any some other too), so I decided for myself to do something refreshing to scratch that coding itch of my which is creating a Tic-Tac-Toe in plain HTML/JS and oh boy how I struggling hard with that.

• I took a very long time on how to generate 3x3 matrix (struggling to chose between nested 3x3 array or flat array)
• How to properly render 3x3 html div and assign the array element to node
• Failed to recognize the pattern to utilize Math.floor() and modulo operator to know where the index in the 3x3 board
• Doing everything manually without the help of Rxjs or signal make my code very inefficent and all over the place

To summary, this experience humble myself as a developer hard, I imagine if I take a leet code interview now I would fuck up pretty hard.
Do you experience similar thing as myself here, let me know your thought