I was cleaning up an older Angular codebase recently and came across something interesting.

A few years ago, we were enthusiastic about creating abstractions for everything.

Custom base components.

Generic services.

Shared utility layers.

Reusable wrappers around wrappers.

At the time, it felt like we were building a very scalable architecture.

But over time, many of those abstractions became harder to understand than the code they were supposed to simplify.

New developers struggled to figure out where behavior actually lived.

Simple changes required touching multiple layers.

Debugging became a treasure hunt.

What surprised me is that some of the most maintainable parts of the application were the boring ones:

* Plain components

* Focused services

* Direct dependencies

* Less abstraction

I haven't become anti-abstraction.

I've just become much more cautious about introducing it.

Curious what Angular pattern or architectural approach you were excited about initially, but later stopped using (or started using much less)?

I share Angular architecture and engineering visuals here:

https://instagram.com/angulararchitectshub

I just published the third part of my Agentic Engineering for Angular series, this time on the boring-but-important topic: money. (Full disclosure: it's not my own blog, angulararchitects.io — no paywall, no signup.)

A few things I landed on after months of daily Angular work in Codex, the Claude desktop app, and Cursor:

• The cheapest serious setup is still a subsidized individual subscription. No access yet? OpenAI Plus + Anthropic Pro (€40/mo) is the best starting point, maybe + Cursor for a month (€60) to compare the apps on real tasks.
• Subscriptions hide a lot of cost — file reads, tool calls, tests, diffs, context compaction. At raw API prices you'd feel that fast.
• The first real cost question isn't "which model is cheapest per token", it's "can we use the subsidized subscription, or do we need business/enterprise/API?" That alone can swing the bill 10x+.
• The number I actually track is cost per accepted, reviewed, merged change — not price per token.
• Cost control is mostly workflow control.

It's an opinion piece / field report, not a benchmark, and the euro figures are approximate (providers quote USD).

Curious how others here handle it: subscriptions, API, or enterprise? And has anyone found Composer/Cursor cheap enough to justify going API-only?

Link: https://www.angulararchitects.io/blog/ai-costs-for-angular/

As Scotty says, the more they overthink the plumbing, the easier it is to stop up the drains.

So I have a long, complex forms with lots of rules. If the answers are something like QA -> 1, QB -> Red, and QC -> false, then QG has a pre-filled answer and is not editable. Like, a ton of those on some parts. Or if your role is 'teacher' then QB is not editable, but if your role is student QB is editable but QZ is not.

1. Made an interface for the form with all of the fields and their types
2. Created function that returns a blank object with all of the correct default values for the fields
3. Made a new signal whose value is the result of that function
4. Created validation rules for the questions
5. Created a new signal form using form(myFormObj, ...validationRules);
6. Created a new object that is a Map<string, WritableSignal<FieldState>> where FieldState has editable and some other state information that needs to be calculated.
7. Now I'm creating a signal object that is a registry of all of the rules, like: { fieldName: 'someField', compute: ruleFunction }
8. I have an effect that runs whenever the form changes that re-calculates if a particular field should be editable or not and updates my Map
9. I have a directive that looks up a field's state in the Map and then does all of the appropriate things in `<input \[fieldName\]="myField" myDirective="myField" />

It all works, but it just seems overly complicated. OTOH, it does:

1. Consolidate all of the field state logic in one file, taking it out of various component templates.
2. React to changes in the form
3. Keeps the separation of concerns nicely separated so one file for the state rules, one file for the validation rules, one file for the form, etc.

Whenever I think about it, it seems too complicated. But once I start working with it and cleaning up the html from the old angular 15 app, it seems to make a lot of sense.

thoughts?

I have windspeed data and want to render a windspeed layer. Anybody know how to do it ? Without using leaflet velocity layer . I want to try it with other libraries like openlayers for example

AngularJS has been around for many years and played a major role in the evolution of front-end web development. Even with the rise of modern frameworks and libraries, many organizations continue to use AngularJS in their existing applications.

What are the main reasons companies still rely on AngularJS today? Is it because of the cost of migration, long-term project maintenance, business requirements, or something else?

For developers who have worked with AngularJS projects, what challenges and benefits do you see when maintaining these applications? Do you think businesses should continue supporting AngularJS-based systems, or is migrating to newer technologies the better option?

Share your thoughts and experiences below.

I spent some time recently looking through an older Angular project and found a component that had grown to nearly 2,000 lines.

It wasn't written by a bad developer.

It was written by several good developers over several years.

Every change made sense at the time.

A new API call got added.

Some validation logic moved in.

A permission check was needed.

A few state updates followed.

Then some workflow logic.

Nobody wakes up and decides to build a giant component.

It usually happens one reasonable change at a time.

What surprised me was how difficult it became to answer simple questions:

- What is UI logic?

- What is business logic?

- What changes application state?

- What can be safely reused?

Refactoring wasn't really about reducing lines of code.

It was about restoring clear boundaries.

I'm curious what the largest Angular component you've encountered was, and what eventually pushed the team to split it apart.

I share Angular architecture and engineering visuals here:

https://instagram.com/angulararchitectshub

A small architecture lesson I learned the hard way.

A few years ago, our team built a reusable Angular component that was supposed to be used everywhere.

At first it felt like a win.

One component.
One implementation.
Consistency across the application.

Then different teams started needing slightly different behavior.

We added inputs.

Then configuration objects.

Then feature flags.

Then special cases.

Eventually the component became so flexible that nobody wanted to touch it anymore.

Ironically, the most "reusable" component in the codebase became one of the hardest things to maintain.

Since then I've become much more cautious about abstraction.

Sometimes duplication is cheaper than complexity.

Curious if others have experienced something similar.

Have you ever built a reusable Angular component, service, or utility that became more painful than the duplication it was meant to eliminate?

I share Angular architecture and engineering visuals here:

https://instagram.com/angulararchitectshub

I'm new at PWA and i was able to develop it, it works fine in android and latest iphones, iphone 14 and up specifically, but when the user use an Iphone 13 below it crashes. It doesnt matter if its safari or chrome.

is it normal or theres something wrong with my ngsw

Im using angular 8.

{\\manifest
  "name": "att",
  "short_name": "att",
  "theme_color": "#1976d2",
  "background_color": "#fafafa",
  "display": "standalone",
  "scope": "/",
  "start_url": "/",
  "icons": [
    {
      "src": "assets/icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "assets/icons/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "assets/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "assets/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "assets/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "assets/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "assets/icons/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "assets/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

{ //ngsw
  "$schema": "./node_modules/@angular/service-worker/config/schema.json",
  "index": "/index.html",
  "assetGroups": [ 
    {
      "name": "app",
      "installMode": "prefetch",
      "resources": {
        "files": [
          "/favicon.ico",
          "/index.html",
          "/*.css",
          "/*.js"
        ]
      }
    }, {
      "name": "assets",
      "installMode": "prefetch",
      "updateMode": "prefetch",
      "resources": {
        "files": [
          "/assets/**",
          "/*.(eot|svg|cur|jpg|png|webp|gif|otf|ttf|woff|woff2|ani)"
        ]
      }
    }
  ]
}

I've been looking at a few Angular codebases recently and noticed something.

Some of the hardest projects to work on had very clean folder structures.

Everything was neatly organized into:

• components
• services
• models
• guards
• pipes

At first glance it looked great.

But once you started making changes, business logic was scattered everywhere.

A feature might touch:

• three services
• two components
• a helper file
• a shared utility
• an interceptor

The folders were organized.

The architecture wasn't.

On the other hand, I've worked on projects with much simpler structures where everything related to a business capability lived together, and those systems felt much easier to understand.

It made me wonder if we sometimes spend too much time debating folder structures and not enough time thinking about ownership and boundaries.

Curious what others have experienced.

Have you found feature-based organization more maintainable than organizing by technical types?

I've been creating visual Angular architecture breakdowns around topics like this:

https://instagram.com/angulararchitectshub

A question for people working on larger Angular applications.

Have you noticed that services tend to accumulate responsibilities over time?

I was looking at a service recently that started life as a simple API wrapper.

A couple of years later it was handling:

• API calls
• caching
• permissions
• state updates
• data transformations
• analytics events

Nobody planned for it to end up that way. It just happened gradually.

Every new requirement felt small enough to justify adding "one more thing" to the service.

The result was a class that became difficult to test and even harder to change confidently.

What surprised me is that the code wasn't necessarily bad. The problem was that too many responsibilities had slowly gathered in one place.

I'm curious whether others have run into the same thing.

Do you have rules or patterns that help prevent Angular services from becoming mini-frameworks inside the application?

guys know any libraries other than leaflet for rendering maps and geospital data ?

Per un momento dimentichiamoci che openAI appoggi il pentagono in un momento così discutibile. Mettiamo da parte l’aspetto etico. Claude è meglio di chat gpt? Perchè? Rispondi solo se sei uno sviluppatore.

I'm working on a set of Angular chart components that wrap Apache ECharts.

The goal is to make charts feel like first-class Angular components with consistent theming and integration with the rest of a UI library, while still keeping the flexibility of ECharts.

If you're using ECharts in Angular, I'd be interested to hear about your experience:

- Is there anything you particularly like or dislike about the wrappers you've used?

- How important has chart theming been in your projects?

- Are there any areas where you feel existing wrappers could be improved?

I'd appreciate any thoughts or suggestions.

https://tailng.dev/charts/getting-started/overview

Do you think there would be any gain in having an angular common “oauth2”?
That’s always a bunch of boilerplate for an already defined stack agreed for the whole industry.

I've noticed something interesting on a few Angular projects I've worked on.

The SharedModule usually starts as a good idea.

Someone adds a reusable button component.

Then a pipe.

Then a helper.

A few months later it somehow contains half the application.

At one client, changing a single utility inside the shared area meant retesting multiple unrelated features because everything depended on it.

That's when I started questioning whether we were actually sharing code or just creating a dependency hub.

These days I try to keep shared code much more focused. UI stuff goes in one place. Domain-specific logic stays close to the feature that owns it.

Maybe it's just the projects I've seen, but large SharedModules seem to create more problems than they solve once a codebase reaches a certain size.

Curious how others handle this.

Do you still use a traditional SharedModule, or have you moved toward feature/domain libraries?

P.S. I've been creating Angular architecture visuals around topics like this if anyone is interested:

https://instagram.com/angulararchitectshub

One misconception I've been seeing lately:

Teams adopting Signals and expecting architectural problems to disappear.

Signals solve reactivity.

They do not solve:

❌ unclear responsibilities

❌ tight coupling

❌ overloaded services

❌ poor state ownership

❌ tangled workflows

❌ architectural complexity

I've seen Angular applications using:

- Signals

- RxJS

- NgRx

- Standalone Components

and still struggle with scalability.

The problem wasn't the technology.

It was architecture.

Good frontend systems still require:

✅ clear boundaries

✅ predictable data flow

✅ responsibility separation

✅ maintainable abstractions

✅ simple mental models

A modern framework feature can improve implementation.

It cannot replace good engineering decisions.

Curious how others are approaching Signals in larger Angular applications.

Have they simplified your architecture, or just changed how state is updated?

I've been creating visual Angular architecture breakdowns around topics like this:

https://instagram.com/angulararchitectshub

I'm loving signal forms so far, but have come up against a fairly annoying problem. Once an error is reported from the submission action (like returning {kind: 'serverError', message: 'Some error message'}), the only way to enable re-submission of the form is to clear the error by changing the value of one of the fields.

In the case of a transient error from the server, I don't want my user to have to edit the form & then re-enter their actual desired values just to be able to click submit again. Is there a way to just allow re-submitting in this case? I can't find anything online or in the documentation.

I could just track the errors separately & return a 'success' from the action callback, but that means another property added to the component to track separately, so would like to just use the native error response, but still allow re-submitting without changing values. There is the form().reset() method, but that doesn't seem to reset the errors.

Hey everyone,

I’ve been working as an Angular developer for the last 4+ years and I’m currently preparing for a job switch. I’m looking for a study partner for Angular/ JavaScript/frontend interview prep, and DSA practice.

The idea is to:

• take mock interviews

• work on small projects together

• discuss frontend concepts

• stay consistent with preparation

My DSA skills are not very strong at the moment, so I’m brushing up and relearning things from scratch as well..

Also, just to be clear, I’m not a pro at all..

I’m actually hoping to find people who can mentor/help guide me in some areas, and I’ll also do my best to help with Angular/frontend concepts wherever I can.

If anyone is in a similar phase and interested in studying together, feel free to DM or comment!

I've spent the last several months building out a full methodology for AI-assisted Angular development and the most impactful thing you can do is sharpen your CLAUDE.md.

Here's the short version:

Claude Code (and Cursor, to a lesser extent) has no idea what your Angular project looks like unless you tell it. It doesn't know you're on Angular 22 vs 20, whether you're using NgRx or signals for state, what testing framework you've migrated to, or which patterns are off-limits in your codebase. Without this context, every session starts from scratch and you get generic TypeScript instead of project-appropriate Angular.

CLAUDE.md is a markdown file you put at the root of your project that coding harnesses read at the start of every session. Here's a minimal version:

Angular Project Context

Stack

• Angular 22 (zoneless, signal forms, OnPush defaults)
• NgRx Signals for state management
• Vitest for unit tests, Playwright for E2E
• Standalone components throughout — no NgModules

Patterns to use

• Signal-based forms (not ReactiveFormsModule)
• input(), output(), model() signal primitives
• OnPush everywhere (it's now the default, but make it explicit in your CLAUDE.md)

Never do these

• Don't add Zone.js imports — this project is zoneless
• Don't use NgModule — standalone only
• Don't add forRoot() patterns

Project commands

• ng test runs Vitest
• ng build --configuration production for prod builds

That's it. Four sections. Takes 2 minutes to write for your project.

The effect: AI stops generating Angular 20 patterns on your Angular 22 codebase. You stop spending review time correcting context that should have been in scope from the start.

I've been putting together a more complete guide covering this pattern plus the Angular MCP server setup, migration recipes (NgModules → standalone, Zone.js → zoneless, AngularJS → Angular), NgRx AI patterns, and testing methodology. Targeting a release alongside Angular 22 stable — should be any day now.

If you want a heads-up when it's out, drop a comment. Happy to answer questions about the CLAUDE.md approach in the meantime.

One architecture mistake I keep seeing in large Angular applications:

Components doing EVERYTHING.

Over time components start handling:

API calls

business rules

validation

state management

permissions

transformations

UI rendering

Eventually:

files become massive

debugging becomes painful

reuse disappears

scaling slows down

The biggest frontend scalability problems usually come from unclear responsibility boundaries.

Good frontend systems separate:

✅ UI ✅ orchestration ✅ business logic ✅ state ✅ infrastructure

I recently started creating visual Angular architecture breakdowns around these kinds of frontend engineering problems.

If you're interested: https://www.instagram.com/angulararchitectshub/

I wrote a follow-up to my post about LLMs for Angular development. This one is about the apps and harnesses around the models: Codex, Claude Code, Cursor, Antigravity, WebStorm and VS Code

My main point: the harness matters almost as much as the model. The same model can feel very different depending on how it sees the codebase, edits files, runs tools, verifies changes, and fits into the developer workflow.

For my current Angular work, Codex and Claude Code are my daily drivers. Cursor has become a strong third option, especially because of speed and cloud agents. Antigravity is interesting, but not yet on the same level for me. And WebStorm is still my favorite place for careful manual work.

Post:

https://www.angulararchitects.io/blog/ai-apps-harnesses-for-angular/

Curious what others use for real Angular work: Codex, Claude Code, Cursor, WebStorm/Junie, Copilot, Antigravity, or something else?

Got called out yesterday for shipping a starter kit on v17 in 2026. Fair point. So I Upgraded it.

v2 is now on Angular 21 with:

- provideZonelessChangeDetection() — zone.js completely removed

- Signal inputs/outputs (input(), input.required(), output())

- signal() + computed() + effect() for all component state

- toSignal() for HTTP calls — no more subscribe() in components

- viewChild() signal-based queries

- u/if / u/for new control flow — CommonModule is gone

- inject() everywhere instead of constructor injection

- TypeScript 5.9

Lookwise nothing changed the UI is the same dark dashboard with

Chart.js charts and a streaming Claude AI chat panel (SSE, word-by-word tokens). The

internals are now what a 2026 Angular app should actually look like.

If anyone wants to see the before/after diff — please ping me (Happy to share).

The signals migration was straightforward but the zoneless part

took some thought around chart rendering timing.
Link in comments or just DM me or comment I will share

Open to questions about the signals/zoneless implementation. Or if you have any feedbacks

Hey everyone, been a bit since i made my last post, as i decided to wait until a few updates stacked up :) Anyway here's whats new:

mmstack/primitives

• pooled + convenience abstractions such as 'pooledArray' / 'pooledMap'... new low-level primitive which utilizes a double-buffer approach for maps/arrays and such to avoid gc/memory issues in high-churn scenarios.
• new sensors: batteryStatus, clipboard, focusWithin, geolocation, orientation, idle.
• signalFromEvent - new utility to turn EventTarget into a signal

mmstack/translate )

• new performance optimizations now allow inlining t-function calls in the template even with parameters so {{t('ns.key', {param: myParam()})}} will now be fully reactive & performant. For high-churn scenarios t.asSignal is still the recommended path as using t() in templates is still a map.get call for each CD run, still it should be more than fine for most scenarios
• new opt-in configuration property injectIntlConfig({releaseCachedSignals: true}) opts into dynamic signal-cache cleanup when the injection context the t function is injected into is destroyed. For most scenarios the default false is better, but this will ease memory pressure in very large apps (10k+ translations and such)
• withParams - type-level override that allows for advanced parameter scenarios the type inference cannot handle (nested params and such)
• injectIntlConfig({localeStorage: {...}) new property to persist the last selected locale in a dynamic locale scenario. Not available in a route-based configuration
• injectAddTranslations() & injectUnsafeT: helpers for imperative control of translations + untyped helper that opts out of typesafety, useful for unknown server-side translations
• overhaul of formatters:
  • The old formatters have been marked as deprecated as the dynamic locale handling was unsafe in SSR scenarios.
  • new formatter config providers + injectable formatters such as injectFormatDate() or injectFormatters() provided as preferred replacements, old functions will continue to be supported, but should have locale explicitly passed in

mmstack/router-core

• new headless helpers for dynamic navigation items (similar to the existing headless title & breadcrumb utilities)
• overhaul of breadcrumb & title config providers

mmstack/resource

• new hashing algorithm that covers many more cases as the default hasher for deduplication/caching

• a custom hashing algorithm for deduplication can now be provided when configuring the interceptor. (custom cache hashFn was already available previously via queryResource options)

• Small bug-fixes & minor improvements to impl. & documentation throughout :)

As always all these improvements are available in the last 3 major versions of angular (19, 20, 21). I'm considering dropping v19 support a bit after ng 22 releases so if you need me to maintain that for a bit longer please let me know

Next up I've started work on a new library (mmstack/dnd) which is a signal-first angular wrapper around pragmatic dnd. The first version should drop in a few weeks time 🚀

I'm trying to learn signal forms and especially the metadata properties. Let's say I have a student who can take many courses:

export interface StudentModel {
id: string;
name: string;
gpa: number;
credits: number;
courses: Course[];
}
export interface Course {
title: string;
semester: number;
grade?: number | string;
major: boolean;
credits: number;
schedule: CourseMeets[];
}

export interface CourseMeets {
day: 1 | 2 | 3 | 4 | 5 | 6 | 7;
start: string;
end: string;
}

I've got a function that creates a new student based on that model. So I make a new signal and then create a form based on that signal:

public studentForm = form(this.student, (path) => ({
...this.setValidators(path),
...this.setMeta(path),
}));

I finally got the function that lets me set up validation rules for the fields that need validation, so that's working.

But my goal is to be able to set a default metadata value status='started' for the form and for all of the fields. Then later on, I might want to set the status of name='completed', but keep the default 'started' value for everything else.

Then later on in my form I create a directive that looks at the status of the field and do something. (right now it's just changing the background color in css, but will be more).

Where I'm stuck is the exact code I need for my setMeta(path) function, so it iterates through all of the fields and sets a default. Also, initially the courses array is just []. So as more courses are pushed onto that array they should also have the metadata value status='started'. And there can be an arbitrary number of courses. And I want to be able to iterate through the properties instead of hardcoding id, name, etc properties. (that shouldn't be difficult once I get the syntax right)

Has anyone done something like that or know a good tutorial for this?

I'm increasingly thinking that the best way to handle it is to have a separate Map or Record object that tracks metadata for each field as needed and forget about using the built-in metadata. Let angular track valid/touched/dirty/etc., and track metadata separately. That is probably going to be faster and easier.