The suggested @Service decorator for Angular 22, along with the expected finalization of the resource API family, head up this roundup. Additional highlights include the lifecycle phases for Angular features, updates in Native Federation v4, and recent benchmark data from the Oxc Angular compiler.
Angular 22 preview: @Service and resource APIs
With Angular 22 on the horizon, details about what’s coming keep trickling in.
One notable addition is a fresh service decorator named @Service. How does it differ from the long-standing @Injectable?
With @Service, root-level provisioning becomes the default, but constructor injection is a thing of the past—you’re required to use the inject function instead.
Furthermore, an unresolved PR hints at the resource APIs, such as httpResource and rxResource, jumping straight from experimental to stable, bypassing the developer preview phase. Given that these APIs have been around for nearly 1.5 years, it’s about time they hit that milestone.
feat(core): introduce @Service decorator
#68195
These changes introduce the new @Service decorator which is a more ergonomic alternative to @Injectable. The reason we're adding a new decorator is that @Injectable has been around since the beginning of Angular and it has a lot of baggage that adds unnecessary overhead for users that generally want to define a singleton service, available in their entire app. The key differences between @Service and @Injectable are:
-
@ServiceisprovidedIn: 'root'by default. You can opt into providing the service yourself by settingautoProvided: falseon it. -
@Servicedoesn't allow constructor-based injection, only theinjectfunction. -
@Servicedoesn't support the complex type signature of@Injectable(useClass,useValueetc.). Instead it supports a singlefactoryfunction.
Example:
import {Service} from '@angular/core';
import {HttpClient} from '@angular/common/http';
import {AuthService} from './auth';
@Service()
export class PostService {
private readonly httpClient = inject(HttpClient);
private readonly authService = inject(AuthService);
getUserPosts() {
return this.httpClient.get('/api/posts/' + this.authService.userId);
}
}
refactor(core): promote `resource`, `rxResource` & `httpResource` to stable
#68253
The time has come.
Note: #67382 introduced a breaking change where you could notice some sublte timing change on how value is set when using rxResource or a stream on a resource
Feature lifecycle stages in Angular
On the ng-conf Medium blog, Alejandro Cuba Ruiz breaks down what he identifies as the five stages an Angular feature goes through: experimental, developer preview, stable, deprecated, and removed. Far from being some insider memo, the piece mirrors signals we pick up from the Angular core team now and then.
Under experimental, APIs remain liable to shift even in minor or patch releases; his advice is to steer clear of production code and test the waters in isolation instead. Developer preview is more of a "we're sold on the direction, bring us your real-world edge cases" — safer than experimental, though not yet locked down by semver. Once something hits stable, it becomes a formal promise: breaking tweaks only land in major versions, ideally paired with automated migrations. Deprecation signals the familiar two-major-release grace period, and removal marks the moment the feature vanishes from the codebase for good.
Beyond what the official docs cover, he points to community tooling like Gerome Grignon's "Can I Use Angular Features" grid, which proves useful when you're juggling multiple Angular versions at once.
Alongside the experimental, developer preview, and stable tiers, deprecation and removal rounds out the list in Alejandro's write-up.
All in all, it's a solid reference for weighing when—or whether—to jump on a given feature.
The 5 lifecycle stages of an Angular feature
Versioning and releases • Angular
The web development framework for building modern apps.
angular.dev
Native Federation v4 updates
When constructing microfrontends in Angular, Native Federation ranks among the top choices, second only to Module Federation. With the release of version 4, the library now boasts an extensive documentation website as its standout change. Furthermore, the GitHub repository has transitioned to a new organization, the codebase has been divided across several repositories, and a new orchestrator is either assuming or will assume control of the previous runtime for managing microfrontends.
Native Federation — Micro Frontends with Web Standards
A browser-native implementation of Module Federation for building Micro Frontends using web standards like ESM and Import Maps.
native-federation.com
Oxc Angular compiler benchmarks and caveats
An earlier edition of ng-news discussed Void Zero's effort to rebuild the Angular compiler on top of Oxidation Compiler, a Rust-based toolchain.
Now, an official write-up has been released with concrete benchmark figures, along with a look into how the team operated — a process that leans heavily on AI assistance.
According to the post, the bulk of the work took roughly two months. Claude Code and Codex handled much of the porting and evaluation under the guidance of seasoned developers, rather than a fully automated, overnight solution. The key was having a solid architecture and guardrails in place before letting the agents run.
The performance claims are hard to ignore: compiles clock in at roughly six times the speed of the Angular CLI.
As is often the case, those stats warrant a degree of skepticism, though they might hold up. Notably, some heavy lifting—like template type-checking—is excluded, and the authors concede that dropping type-checking is a major win for speed.
The compiler is shipped as a Vite plugin, @oxc-angular/vite.
VoidZero also notes that this repository isn't slated for long-term upkeep, and mentions that the Angular team is separately running its own Oxc-based experiments.
