Angular Development Services | Signals, Zoneless, Angular v22
Angular is Google's framework for large, long-lived web applications, and since version 22 it is a signal-based, zoneless framework built with esbuild rather than webpack. Mixcore Studio builds new Angular applications on the current line and modernises existing ones that are still running on zone.js, the deprecated webpack builders and Karma.
Most of what a 2021-era Angular tutorial teaches is now the legacy path. Change detection no longer runs through zone.js, OnPush is the default rather than an optimisation, asynchronous data has first-class primitives in resource() and httpResource(), and the build no longer goes through webpack. If your team learned Angular before v20, the framework you maintain and the framework Google ships today are meaningfully different applications of the same name.
What we build with Angular
- Line-of-business applications — admin consoles, back-office platforms and internal tools with deep permission models, where consistency across a large codebase matters more than shaving kilobytes.
- Long-lived regulated products — Angular's first-party router, forms, HTTP client, i18n and now Angular Aria reduce the number of third-party dependencies you have to keep patched over a decade.
- Angular SSR applications — server-rendered and hydrated pages for products that need to be indexed, shared and measured, instead of shipping an empty shell and hoping crawlers wait.
- Modernisation work — moving an existing application onto v22, zoneless change detection and the application builder without pausing feature delivery.
- Shared component libraries — Angular design systems consumed by several teams, with component test harnesses so behaviour is asserted rather than assumed.
Angular in August 2026
Angular v22.0 was released on 3 June 2026 and is the current line, following v21 in November 2025 and v20 in May 2025. The changes that matter commercially are these.
- Zoneless is the default —
provideZonelessChangeDetection()has been stable since v20.2, zoneless is the default for new projects from v21, and zone.js is fully optional in v22. Angular now re-renders where signals actually change rather than after every asynchronous event the browser fires. - OnPush is the default strategy —
ChangeDetectionStrategy.Defaultwas renamed to Eager. Components written on the assumption that Angular re-checks everything are now the exception you have to justify. - Signal Forms are production-ready — form state expressed as signals rather than as an observable-shaped API layered over it. Existing reactive forms keep working; new work goes here.
- resource() and httpResource() — declarative async data with loading, error and reload state built in, replacing hand-rolled RxJS pipelines for the ordinary fetch-and-render case.
- Angular Aria — twelve accessible UI components, promoted to stable in v22, shipped first-party instead of pulled in from a component kit you then have to audit yourself.
- Smaller ergonomics — the
@Servicedecorator as shorthand for@Injectable({providedIn: 'root'}), andinjectAsyncfor lazy-loaded services.
Deprecations matter as much as additions here. Angular has deprecated the webpack-based build system, including the @angular-devkit/build-angular browser builder. Investment is going into the esbuild application builder, including support for TSGo, the Go-native compiler behind TypeScript 7.0 released on 8 July 2026. Microsoft's TypeScript team reports 8x to 12x faster full builds from that port, with a full type check of the VS Code codebase falling from 125.7 seconds to 10.6 seconds. Worth knowing before you plan around it: TypeScript 7.0 ships no stable programmatic API until 7.1, so tools that embed the compiler, typescript-eslint among them, trail behind. Angular v22 supports TypeScript 6 today.
Testing is moving the same way. Karma is being replaced by Vitest, and Angular ships migration tooling for it.
Migrating an existing Angular application
The release cadence changed too, and it belongs in a budget rather than a backlog. Angular moved from six-monthly to yearly majors. v23 is scheduled for approximately June 2027, and each major now gets 24 months of support, 12 months active followed by 12 months of LTS. That is one planned upgrade a year, predictable and not optional. Releases older than v20 pre-date this cadence and their windows have closed or are closing.
The upgrades themselves are a sequence, not a rewrite. A v17 application reaches v22 through successive ng update steps, each one small enough to ship. The cost is concentrated in three places, and migration estimates usually go wrong by underestimating the second.
- Removing zone.js — code that relied on Angular re-checking after any
setTimeout, third-party library callback or non-Angular event will silently stop updating rather than throw. The fix is signals for state that drives the view, and explicit change detection where a library genuinely sits outside Angular. - Custom webpack configuration — Module Federation setups, custom loaders and build-plus style extensions have to be re-expressed against the esbuild application builder. This is where the real days go.
- Karma to Vitest — the automated migration handles the common cases; tests that depend on real browser timing or Karma-specific behaviour need rewriting by hand.
We audit first and give you the three numbers separately, because a client who is told a flat figure for "the upgrade" has no way to decide which parts to fund now and which to defer.
When Angular is the wrong choice
Angular is a poor fit for content, marketing and commerce sites. Single-page-application-by-default is no longer the mainstream answer for those; server-rendered pages with islands, or server components with instant navigation, are, and client-only rendering is now the option that has to be argued for. If the brief is a marketing site, a documentation portal or a publication, Astro or SvelteKit will give you a faster page with a smaller team, and we will say so.
Angular's structure also carries a fixed cost. It repays over years and across several teams working in one repository. On a three-screen internal tool with one developer, the same structure is overhead. And if your hiring pool is React-shaped, choosing Angular for a single project creates a maintenance island. That is a conversation for the first meeting, not for handover.
One honest note on RxJS. Signals have taken over component state and simple asynchronous data, which is a genuine simplification. RxJS has not gone away and should not. Event streams, websockets, debounced search and multi-source coordination are still better expressed as observables, and teams that set out to remove RxJS entirely tend to rebuild a worse version of it.
Performance, accessibility and dates that are already fixed
Google's Core Web Vitals thresholds are unchanged: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, assessed at the 75th percentile of real-user field data. INP is the one that punishes JavaScript-heavy interaction, and zoneless change detection helps directly, because the framework stops re-checking the component tree on every event.
Route changes are no longer invisible either. Chrome 151 shipped soft navigations unflagged in July 2026, so a single-page application can now report FCP, LCP, CLS and INP across JavaScript-driven route changes, with support in web-vitals v6.0.0 and later. How soft navigations will ultimately be reported in CrUX is still undetermined, so we treat this as a measurement improvement to instrument now rather than a ranking change to panic about.
Accessibility has hard deadlines rather than aspirations. The European Accessibility Act, Directive (EU) 2019/882, has applied to newly marketed products and services since 28 June 2025, covering e-commerce, banking and financial services, e-books, passenger transport and more. In the United States, the DOJ ADA Title II rule requires WCAG 2.1 Level AA by 26 April 2027 for state and local governments serving 50,000 people or more, and by 26 April 2028 for smaller entities. We build to WCAG 2.2 and use Angular Aria's first-party accessible components with automated checks in the pipeline, so conformance is asserted in CI, not audited once and then quietly regressed.
Who is accountable for the code
Mixcore Studio is a team of around twenty. We have been building for the web for over eight years and have delivered more than 320 projects.
Buyers now ask about code provenance, and they are right to. The DORA 2025 State of AI-assisted Software Development report, based on roughly 5,000 technology professionals, found that 90% use AI at work and that AI adoption now shows a positive relationship with delivery throughput but continues to show a negative relationship with delivery stability. Its summary line is worth repeating: "AI doesn't fix a team; it amplifies what's already there." The Stack Overflow 2025 Developer Survey of more than 49,000 developers found 84% using or planning to use AI tools while only 3% highly trust the accuracy of the output, and 66% reporting AI solutions that are almost right, but not quite.
Our answer is process, not abstinence. Every change has a named human reviewer, template type checking and lint run in CI, and behaviour is covered by tests that would fail if the change were wrong. Angular helps here, because strict templates and typed forms catch a class of plausible-looking mistakes before review.
Framework patch cadence has become a procurement question too. React2Shell, CVE-2025-55182 with a CVSS score of 10.0, was an unauthenticated remote code execution flaw in React Server Components, disclosed on 3 December 2025 and fixed in React 19.0.1, 19.1.2 and 19.2.1. It changed how buyers assess framework risk regardless of which framework they use. For an Angular engagement we tell you which version line you will sit on, when its support window ends, and how quickly we can ship an emergency patch to your environment.
Our expertise
- Angular v22 application development
- Signals and zoneless migration
- Signal Forms and complex form logic
- Angular SSR and hydration
- WCAG 2.2 accessibility engineering
- Build, test and CI modernisation
Frequently asked questions
Is Angular still a sensible choice for a new project in 2026?
For large, long-lived applications with several teams in one codebase, yes. Angular v22 gives you signals, zoneless change detection, Signal Forms, first-party accessible components and a maintained upgrade path, with far fewer third-party dependencies to patch than an assembled stack. For a marketing site, documentation portal or content publication it is the wrong tool, and we will point you at Astro or SvelteKit instead.
How hard is upgrading an older Angular application to v22?
The version-to-version path is well tooled and runs through successive ng update steps, so it is a sequence of shippable increments rather than a rewrite. The real work is elsewhere. Removing zone.js exposes code that quietly relied on Angular re-checking after every asynchronous event, and any custom webpack configuration has to be re-expressed against the esbuild application builder. We audit and price those two separately from the version bumps.
What does going zoneless actually change in our code?
Angular stops re-checking the component tree after every browser event and instead re-renders where a signal changed. State that drives the view has to be in signals, or change detection has to be triggered explicitly at the boundary with non-Angular code. The upside is fewer wasted render passes, which shows up directly in INP, one of the three Core Web Vitals. The risk is components that stop updating silently rather than failing loudly, which is why this work needs test coverage before it starts.
How often will Angular force us to upgrade, and what does that cost?
Angular now ships one major a year rather than two, with v23 scheduled for approximately June 2027. Each major is supported for 24 months, 12 active and 12 LTS, so a version can be skipped at most once before you are outside support. In practice we budget one planned upgrade window per year, which is far cheaper than the multi-year catch-up that teams face when they let four majors pass.
Will an Angular application pass Core Web Vitals and accessibility requirements?
It can, but not by default. Google's thresholds are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 at the 75th percentile of real-user data, and since Chrome 151 shipped soft navigations in July 2026, single-page route changes are measurable too. We use server-side rendering, lazy routes and zoneless change detection to hold those numbers, and build to WCAG 2.2 on Angular Aria's accessible components so accessibility is checked in CI ahead of the EU Accessibility Act and the April 2027 and April 2028 ADA Title II deadlines.
Contacts
We are always happy to talk with you.
Feel free to contact us in any suitable way
Request a quote
Let's discuss your project!
Please, provide us with a brief description of what you
already have and what you are going to achieve.
Mail us contact@brainiacminds.com