Greg vs Angular

I’ve been building software for about thirty years. I’ve written Z80 assembler before the web existed. I survived COM and ActiveX. I endured WebForms, I migrated to MVC. I watched jQuery rise, dominate, and fade into “legacy.” I’ve seen frameworks come and go like fashion trends.

I’ve worked through multiple generations of .NET, desktop frameworks, web stacks, and frontend revolutions. I’ve seen architectures evolve, collapse, and reinvent themselves with better names.

So when I decided to “learn enough Angular to speak confidently about it in interviews,” I took what I believed would be the sensible route: I followed Microsoft's "Create an ASP.NET Core app with Angular in Visual Studio" tutorial.

First step was to create a new solution using the "Angular and ASP.NET Core" template. That'd get me a working project that I could explore, modify and learn from. That’s what templates are for.

What I didn’t expect was to spend five hours debugging the template before learning anything about Angular itself.

What could possibly go wrong?

The template generated a simple enough project. The whole system would fetch five weather forecasts from a .NET backend, and display them in an Angular component.

After resolving some tedious versioning mismatches, I hit "Debug" - hoping for the best.

[ERROR] TS2304: Cannot find name 'WeatherForecast'. [plugin angular-compiler]        

Oh. No idea what's caused that, in an out-of-the-box project. I've no idea where `WeatherForecast` should be defined - that's the sort of thing I was hoping to learn from the tutorial. So, being an experienced developer - I Googled it (other search engines are available). Found an issue logged with Microsoft Developer Community. Hurrah!

My excitement was short-lived, however; the issue is "Under investigation" with no suggestions as to how to fix it.

Next stop, ChatGPT (other resource-hungry AI behemoths are also available). Over the next few hours, ChatGPT talked me through this, and various other holes in the Angular + .NET Core, template.

Eventually I got the project to build and run without raising any errors. Then we got stuck making it actually work.

The Angular component called /weatherforecasts endpoint. The browser tools told me the call was being made, that the backend responded with "200 - OK", and the response contained five lovely items in a tidy JSON payload.

The page displayed no items.

Huh!?

The backend returned five; the component logged five; Angular assigned five. Yet the UI displayed none. No error, no warnings; just confidently incorrect output.

Trigger Hot Module Reloading by editing the template? The UI updates to show five.

Refresh the page? Back to zero.

That’s the kind of behavior that makes experienced developers weep. Not because it’s impossible — but because it violates a very basic expectation:

If the state is 5, the UI should show 5.

The realisation: This wasn’t a beginner problem

What followed wasn’t “learning Angular.” It was diagnosing:

• Bootstrapping differences
• NgModules vs standalone components
• Runtime providers
• Change detection behavior
• Template configuration

In other words, I was debugging framework transition seams. Angular in 2026 is evolving toward standalone components, simplified configuration, and cleaner APIs. That’s good; evolution is healthy.

But the current Visual Studio template incorrectly attempts to bridge multiple architectural generations:

• Legacy NgModule structure
• Modern standalone patterns
• Updated build pipelines
• Runtime behaviour that depends on configuration

That mix makes the template technically dysfunctional, conceptually very confusing and - in my humble opinion - worse than useless.

The bigger lesson

The irony is that Angular’s core mental model is actually clean:

• Components hold state.
• Templates bind to that state.
• Services are injected via dependency injection.
• HttpClient returns Observables.
• Change detection updates the DOM.

That’s a coherent system. My difficulty wasn’t understanding Angular’s concepts - it seems pretty similar to Vue.JS. My problems came from the scaffolding around them.

For someone trying to learn fundamentals, encountering architectural transition layers before understanding the basics adds unnecessary friction.

What did I learn?

This experience reinforced a few things:

1. Framework transitions are messy, even when the end goal is improvement.
2. Official templates don’t always represent the cleanest mental model.
3. Determinism matters — especially to experienced engineers.

When a system logs 5 and renders 0, even temporarily, it breaks trust. Not because it’s unsolvable, but because it undermines predictability; and predictability is the foundation of confidence.

Where I landed

Once I stripped away the template noise, the actual Angular concepts were straightforward and sensible.

Components. Dependency injection. Observables. Template binding. Routing. Those are learnable, understandable things that I can confidently talk about in an interview.

My frustration wasn’t with Angular itself, it was with encountering ecosystem transition complexity during onboarding. That’s an important distinction.

ChatGPT and I never got to the bottom of the "Five equals Zero" issue. I've now deleted the project that Visual Studio scaffolded for me, and I'll build myself an entirely standalone .NET Core back-end, and a completely separate Angular project to consume it. Hopefully, I can then build and learn something useful.

Final thought

Modern frameworks evolve quickly. That’s part of staying relevant. Clearly the Visual Studio template hasn't moved as quickly, and by exposing transitional plumbing instead of core concepts, it made learning become archaeology instead of exploration.