The Frontend Dispatch
Angular, React & the AI Frontier Architecture deep-dives, rendering strategies, and workflows that actually work
This week: why Angular’s new architecture deserves a second look, what React 19’s compiler changes mean for your codebase, and a practical AI workflow I’ve been running in production for 3 months.
In This Issue
Angular’s signal-driven architecture — a real-world audit
React rendering in 2026 — compiler, RSC & the mental model shift
AI frontend workflows — what’s actually saving me hours
Three tools worth your attention this week
01 · Angular Architecture
Signals changed everything — here’s what the hype misses
I ran a full architecture audit on a mid-size Angular 17 codebase this month. 42 components, three lazy-loaded feature modules, and a mess of RxJS subscriptions that had been accumulating since Angular 9. The mandate: migrate to signals. The finding: most guides get the tradeoffs backwards.
Signals genuinely shine in leaf components — anything that renders derived state from a single source. Where they struggle is orchestration layers: components that coordinate multiple streams, trigger side effects on value change, or need to debounce/throttle user input. That’s still RxJS territory, and the idiomatic answer is toSignal() at the boundary.
The real architectural win from signals isn’t reactivity — it’s that
OnPushbecomes the default mental model, not an optimization you bolt on at the end.
The injection hierarchy is the piece nobody talks about. With inject() replacing constructor injection, the dependency graph is flatter and easier to test — but it breaks the intuition devs have built around constructor-based DI. Spend time here before you migrate.
Takeaway for your codebase: Migrate leaf components first. Keep your service layer in RxJS and use toSignal() as the bridge. Don’t try to signals-ify everything in one sprint — you’ll ship bugs and burn out your team.
02 · React Rendering
The React compiler is not a silver bullet
React’s compiler landed in stable and the discourse immediately split: half the community celebrated the death of manual memoisation, the other half pointed out it introduces new invariants you have to understand to use safely.
Here’s the mental model shift that actually matters: the compiler doesn’t eliminate the need to understand renders — it makes violations of the rules of hooks more consequential. The compiler depends on your components being pure. Introduce a side effect in the render body and the compiler’s output will surprise you in production, not in dev.
React Server Components and the compiler are orthogonal. RSC is a data-fetching boundary. The compiler is a perf optimization. Conflating them is the source of most confusion I see in teams right now.
My current recommendation: enable the compiler on new code, leave legacy code alone until you have strict lint rules enforcing component purity. The gradual adoption path is real and works well in monorepos.
Use RSC for Use compiler for Keep manual memo for Data fetching, DB queries, auth checks at route level Eliminating manual useMemo / useCallback in pure components Expensive calculations, stable references passed to child props
03 · AI Frontend Workflows
The AI workflow I’ve been running for 90 days straight
I’ve tried most of the “AI for frontend devs” advice floating around. Most of it optimises for demo impressions, not daily use. Here’s what actually stuck after three months of shipping real features.
Spec-first prompting. Before touching a component, I write a 5-line spec: what it renders, what props it takes, what events it emits, what accessibility role it has, and what edge cases it should handle. That spec goes in the prompt verbatim. Output quality jumped immediately. The model stops guessing intent.
Tests as scaffolding, not afterthought. I prompt for the test file before the implementation. The model writes what it expects the component to do. I read it, correct any misunderstandings, then ask for the implementation. Caught two scope mismatches in the first week.
Accessibility review pass. At PR time I paste the component JSX and ask for an accessibility audit against WCAG 2.2. It catches about 60% of what an axe scan would catch, faster, with explanations. Not a replacement — a first pass.
The one thing to try this week: Write your component spec in plain English before you open your editor. Even without AI, this alone will make you a faster developer. With AI, it’s a force multiplier.
04 · Worth Your Attention
Three things worth trying this week
Angular DevTools v17+ Signal tracking in the component tree is genuinely useful. Install and inspect before you migrate.
React Scan Visual render highlighting. More legible than the Profiler for catching unexpected re-renders fast.
Biome 2.0 Formatter + linter in one. Replaces ESLint + Prettier with sub-100ms runs on large repos.
The Frontend Dispatch — written by a developer, for developers. No fluff. No sponsored takes.
If this issue was useful, forward it to one person on your team who would appreciate it.