Angular

TypeScript 7 has arrived, and the first reaction across the developer world is a mix of excitement, curiosity, and caution. That feels like a healthy response to a release this big. For frontend developers, this is the kind of update that genuinely changes the feel of work. Faster builds, quicker feedback, and lighter editor workflows are not abstract improvements; they make coding more pleasant and less interruptive. This is also a story about reducing friction in daily developer life, not just improving benchmark numbers. In the TypeScript 7.0 announcement, Microsoft says the release can deliver major speedups, with examples from VS Code, Sentry, Bluesky, Playwright, and tldraw showing much faster builds. ...

In How to Stretch Cursor Pro Further, I argued for treating Cursor as the execution layer and routing planning, research, and cheap thinking elsewhere. Ollama got a few paragraphs — enough to explain why local models belong in the pipeline, not enough to actually set them up. This post is the missing piece: install Ollama on Manjaro, pick models for your hardware, and connect local agents that can read your repo, edit files, and run commands without sending code to a cloud API. ...

I use Cursor every day across a lot of codebases — not just one repo. At work that is mostly a large Angular/Nx monorepo plus many smaller web projects. At home it is broader still: playground companion repos tied to omid.dev articles, browser demos on playground.omid.dev, Rust/WASM experiments, Linux tooling, and whatever the next post needs. Agent mode, multi-file refactors, and inline edits are genuinely faster than doing the same work by hand on any of them. ...

Most frontend teams do not have a testing problem because they lack tests. They have a testing problem because nobody can explain why a specific test exists. The result is familiar: hundreds of unit tests that prove implementation details; a few end-to-end tests that fail whenever timing changes; component tests that duplicate what unit tests already cover; slow CI pipelines that people stop trusting; high coverage numbers with very little confidence. This is especially common in large Angular codebases. Angular gives teams a serious testing toolbox: TestBed, standalone components, dependency injection, router testing, HTTP testing utilities, harnesses, and good compatibility with tools like Jest, Vitest, Cypress, and Playwright. The tooling is not the hard part. ...

Flaky tests are worse than failing tests. A failing test tells the team something broke. A flaky test teaches the team to negotiate with reality: “Run it again.” “CI is weird today.” “It passes locally.” “That test always fails on Mondays.” “Merge it, the failure is unrelated.” That is how a test suite loses authority. The first few flakes feel harmless. Then people stop reading failures carefully. Then a real regression hides inside the noise. ...

Open almost any mature Angular screen and you will find the same shape: 1 2 3 4 5 loading = false; error: string | null = null; data: Account[] | null = null; retrying = false; submitted = false; The template then becomes a negotiation: 1 2 3 4 5 6 7 8 9 @if (loading) { <app-spinner /> } @else if (error) { <app-error [message]="error" /> } @else if (!data?.length) { <app-empty-state /> } @else { <account-table [rows]="data!" /> } This looks fine. It ships. It passes review. And then production teaches you that the screen was never modeled as one thing. It was modeled as five independent switches that sometimes agree and sometimes do not. ...

Angular has always had a complicated relationship with tooling. People call it “heavy” when they want something lighter, but that same weight is often what helps large teams keep moving without reinventing the architecture every sprint. That is why Angular’s MCP server work in the Angular 21 cycle is more interesting than another code-generation headline. This is not just “AI can write Angular now.” AI could already write Angular, often badly. The real question is whether Angular can give AI tools enough project-aware context to stop generating outdated, half-remembered patterns. ...

Every framework eventually discovers the same truth: developers love nice syntax until nice syntax becomes a hiding place. Angular’s recent template improvements are genuinely useful. Multiple consecutive @case blocks make some @switch statements cleaner. Spread and rest support in templates removes awkward helper code in small cases. Angular 21.2’s template additions, such as arrow functions and exhaustive @switch checks with @default never, continue the same direction: templates are becoming more expressive and more type-aware. ...

Most forms discussions start in the wrong place. They compare syntax. Reactive Forms gives us FormGroup, FormControl, validators, status flags, and a lot of well-known muscle memory. Signal Forms gives us fields, signal-shaped state, form-level submission, custom controls, and migration tools. It is tempting to treat this as a cleaner API for the same old job. But that misses the bigger shift. Signal Forms are not only about filling inputs and showing validation messages. They push forms into the same mental model as the rest of modern Angular state: explicit signals, derived values, and state transitions that can be composed instead of chased through subscriptions. ...

In the software world, the “Ship of Theseus” paradox is a daily reality. We replace parts of a system until, eventually, none of the original code remains. But usually, the industry moves toward the “shiny new thing.” At work, we did something that might sound like heresy to some: we migrated our core legacy React applications to Angular. This wasn’t a decision made out of fanboyism. It was a strategic move driven by the need for governance, stability, and long-term maintainability in a high-stakes FinTech environment. I’ll explain the architectural “why” and the pragmatic “how” of moving against the grain. ...