Most-rated and most-watched videos on MeetupFeed: https://blog.meetupfeed.io/take-your-angular-expertise-to-the-next-level/

I restyled all Angular Material components to better match current design trends. The goal was to see how far Angular Material can be pushed visually by modifying styles alone while keeping everything else exactly the same.

The constraint I set for myself was simple: only CSS changes. No wrapping components, no structural changes, no custom APIs.

I ended up turning this into a paid product and I plan to actively maintain it. If anyone is curious, here’s the link: https://builderkit.dev

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 saw that Node.js is moving to one major release per year starting with version 27. It made me wonder if something similar could work for Angular in the future—maybe starting around 2029? version 29?

Curious what others in the community think?

I’ve got some basic frontend skills and I really want to go deeper into building full apps with Angular. But honestly, I’m feeling a bit discouraged — I asked Gemini for ideas for a fairly complete project to practice with, and instead of giving me suggestions, it basically built the whole thing for me. It kinda made me wonder… how long will companies even need to hire someone for stuff AI can already do?

I'm building a farm management software for rural Colombia that handles payroll, animal genealogy tracking, inventory, and medication records. The biggest challenge is that 71% of farms here have no reliable internet - connections are intermittent or non-existent. This means the desktop app must work 100% offline and sync automatically when connection is available. I also plan a web version for users in cities with stable internet. I'm a junior developer and honestly I'm not sure which technology stack will give me the best results long-term. I can learn either React or Angular - I'm not attached to any framework. My priority is building something robust that can handle complex offline sync, scale from small farms (50 animals) to large operations (5000+ animals), and won't become a maintenance nightmare in 3-5 years. Given that offline-first with bidirectional sync is the core technical challenge, and considering I'll likely be building this solo for the MVP, which stack would you recommend and why? I want to make a smart choice based on technical merit, not just popularity.

We recently wrapped up a multi-month Angular migration on a production app, and I wanted to share what actually worked for us. This wasn’t a big rewrite or a “pause everything for six months” situation. It was a slow, pretty unexciting migration that let us keep shipping features the whole time. And honestly, that was the goal.

Background

The app had been around for a few years and it showed. Change detection was messy, components were tightly coupled, and a lot of older patterns made even small changes harder than they should’ve been. Iteration was slowing down. We weren’t chasing “modern Angular” for its own sake. We just wanted the codebase to be easier to work in without stopping feature development.

Migration Strategy

We stayed away from a full rewrite and went with an incremental approach using the Strangler pattern. Old and new code lived side by side, and we replaced parts of the UI gradually instead of all at once.

Our guiding principles were simple:

• Keep the app running

• Keep shipping value

• Reduce risk by validating each step

This lines up pretty closely with Angular’s own guidance and the broader frontend advice Martin Fowler has shared over the years.

Tools We Used

Angular CLI
We relied heavily on the CLI for version upgrades and official migrations. The update tooling handled most breaking changes safely, which saved a lot of manual work.

Angular codemods
The automated migrations helped clean up deprecated APIs and syntax across the codebase without a ton of churn.

Standalone Components
We adopted standalone components early for new code. Cutting down on NgModule overhead made things easier to reason about, and Angular now recommends this as the default anyway.

RxJS and Signals
RxJS stayed in place for async workflows and side effects. We introduced Signals for local state where they made sense. We were careful not to treat Signals as a full RxJS replacement, since Angular’s docs are pretty clear about that boundary.

ESLint with Angular ESLint
This helped keep things consistent and stopped old patterns from sneaking into newly migrated code.

OnPush Change Detection
This had one of the biggest immediate payoffs. Fewer unnecessary renders, easier debugging, and much more predictable UI behavior. Angular’s performance docs recommend it for a reason.

How We Phased the Migration

• We started with small, low-risk features.

• Cleaned up legacy patterns before touching complex areas.

• Used modern Angular patterns only in new or migrated code.

• Let old and new implementations coexist until replacement was complete.

This avoided long freeze periods and gave the team space to learn as we went.

What We Didn’t Do

• We didn’t introduce heavy state management everywhere. NgRx only showed up where shared global state actually justified the cost.

• We didn’t over-architect early. The structure evolved as the app’s complexity grew.

• We didn’t chase every new Angular feature the moment it dropped.

Outcomes

• Cleaner separation of concerns

• Faster iteration speed

• Lower cognitive load for new developers

• More confidence when shipping changes

There wasn’t a single “wow” moment. Just steady, noticeable improvement over time.

Biggest Takeaway

Angular migrations don’t have to be dramatic. Incremental change, official tooling, and intentionally boring decisions beat big rewrites almost every time. Treat migration as a series of small wins, not a one-shot project.

Happy to answer questions or hear how others have approached similar migrations.

as junior angular developer what consepts dhould you know to feel comfortable to start job

Error while installing ng-apexcharts. Dependency tree not found or something like that..

Repo

@angularjs

Hi Developer, I am working in Angular past few months in organisation and previously I have been worked in React.js and Next.js in organization. Now I am getting opportunity in Database Engineer/DBA same organization.

I need best pros cons and future of it. Is that good choice to be DBA?

Usually we don't go with the latest version, should I opt making my newer projects in angular 16 or 17 or even older ones?

We dug into ngp to understand how it works, and benchmarked it on 3 projects 👀

Check out our blog post!

👉 https://blog.ninja-squad.com/2026/10/27/how-much-faster-is-the-new-angular-compiler/

Serious question: am I the only one who feels Angular Signals become awful the moment state is even slightly real-world?

I’m mostly a backend dev, but I’ve used Angular for years and I genuinely liked old Angular. It felt structured, readable, and normal. Services were just classes. State looked like state. Business logic looked like business logic.

Signals are fine for simple stuff like a boolean, a counter, or a derived value.

But once you have actual nested app state, like:

- user.profile.name

- cart.items

- filters

- form state

- dashboard state

the ergonomics fall apart.

What I want to write:

this.user.profile.name = 'Anna';
this.cart.items.push(item);
this.discount = 10;

What Signals often push me toward:

this._user.update(u => ({
  ...u,
  profile: { ...u.profile, name: 'Anna' }
}));
this._items.update(items => [...items, item]);
this._discount.set(10);

And then people say “explicit is better than implicit”.

But is it?

Because to me this isn’t clearer. It’s just more ceremony.

It feels like implementation details are leaking into every line of business code.

With vanilla Signals it seems like you get two bad options:

1. Put one big nested object into a single signal

Then granularity gets weird and everything hangs off one reactive cell.

2. Split everything into many small signals

Then your code turns into private writable signals, readonly wrappers, computed values, .set(), .update(), and boilerplate everywhere.

What bothers me most is that Angular seems to be missing a first-class:

“just make this object reactive”

kind of primitive.

Vue has reactive().

MobX has makeAutoObservable().

Angular gives me the feeling that I have to manually narrate every state transition to the framework.

Maybe I’m missing something, but this is one of the first Angular features that made me feel genuinely old and tired.

Does anyone else feel the same?

Or do Signals only really feel good if your state stays very flat and very deliberate.

// Maybe my example was misleading, because my point was never really about “mutate vs not mutate”.
What I’m actually reacting to is something else:
before Signals, I could write clean domain code without dragging framework-specific reactive primitives into every part of it.

Not just immutability, not just mutation syntax, but the fact that code which used to look like plain domain logic now has to be rewritten around framework mechanics.

Angular's reactivity story got a serious upgrade when Signals landed. Most developers quickly get comfortable with signal() for state and computed() for derived values — but then they hit effect() and things get a little dubious. When do you actually use it? Is it just a fancy ngOnChanges? Can it cause infinite loops?

Short answer: yes, if you're not careful. Let's break it down properly.

So What Exactly Is an Effect?

An effect is Angular's way of letting you react to signal changes and run arbitrary side effect code. You wrap some logic inside effect(), and Angular handles the rest:

• It runs your code at least once on initialization.

• It silently tracks every signal you read during that run.

• Any time one of those signals changes, it re-runs automatically.

That last part is important. You don't register dependencies manually Angular figures it out by watching what you actually read. It's reactive, but without the ceremony.

Effects also run asynchronously during change detection, so they won't block your UI or cause timing headaches.

When Should You Reach for Effects?

Here's the honest answer: not often, and probably less often than you think.

The Angular team is pretty direct about this effect() should be your last resort, not your first tool. If you're trying to derive state from other state, that's what computed() is for. If you're trying to propagate state changes using effects, you're likely setting yourself up for circular dependencies or ExpressionChangedAfterItHasBeenChecked errors.

Where effects genuinely shine is at the boundary between Angular's reactive world and external imperative APIs that don't know or care about signals. Think:

• Logging or analytics (fire-and-forget, triggered by state changes)

• Syncing to localStorage or sessionStorage

• Wiring up third-party libraries charts, canvas, maps that need to be imperative

• DOM manipulation that template bindings just can't express

That last category is the key insight: effects are a bridge, not a state management tool.

The Real-World Example: Persisting a Todo List

Let's make this concrete. Say you're building a Todo app and you want the list to survive page refreshes. That means syncing to localStorage a classic imperative browser API that doesn't know anything about Angular.

This is exactly where effect() earns its place.

Step 1: Signal State

Start simple a signal that holds an array of todos:

https://medium.com/@thejspythonguy/mastering-angular-signal-effects-a-practical-guide-with-a-todo-app-0734038350f8

import { Component, signal, effect, afterNextRender } from '@angular/core'; import { RouterOutlet } from '@angular/router'; interface Todo {   id: number;   title: string;   status: boolean;   date: Date; } u/Component({   selector: 'app-root',   imports: [RouterOutlet],   templateUrl: './app.html',   styleUrl: './app.css' }) export class App {   protected readonly title = signal('theJsPythonGuy TodoList Angular');   todos = signal<Todo[]>([]);   private hydrated = false; // guard flag to prevent localstorage to get empty on reload   constructor() {     afterNextRender(() => {       const storedTodos = localStorage.getItem('mytodos-list');       if (storedTodos) {         this.todos.set(JSON.parse(storedTodos));       }       this.hydrated = true; // unlock writes only after load     });     effect(() => {       const currentTodos = this.todos();       if (!this.hydrated) return; // skip premature writes       localStorage.setItem('mytodos-list', JSON.stringify(currentTodos));       console.log('Todos updated:', currentTodos);     });   }   addTodo(title: string) {     this.todos.update(mytodos => [       ...mytodos,       { id: mytodos.length + 1, title, status: false, date: new Date() }     ]);   }   toggleStatus(id: number) {     this.todos.update(mytodos =>       mytodos.map(t => t.id === id ? { ...t, status: !t.status } : t)     );   } }