Angular 22's proposed @Service decorator and the likely stabilization of the resource API family. Also in brief: Angular feature lifecycle stages, Native Federation v4 changes, and fresh Oxc Angular compiler benchmark context.
Angular 22 preview: @Service and resource APIs
The release of Angular 22 comes closer, and we are also getting more and more information about the changes.
For example, we will get a new decorator for services, which will also be called @Service. What's the difference compared with the existing @Injectable decorator?
By default, @Service will automatically provide the service in root, and you cannot use constructor-based dependency injection anymore, but have to go via the inject function.
And another PR, which is still open, says the resource family, including httpResource, but also rxResource, will leave the experimental stage and become stable. So the developer preview gets skipped. One also has to say that we have had the resource APIs for almost 1.5 years now, so it is more than time.
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
Alejandro Cuba Ruiz wrote on the ng-conf Medium publication about what he calls the five lifecycle stages of an Angular feature: experimental, developer preview, stable, deprecated, and removed. The article is not a secret internal document; it lines up with what we occasionally also hear from the Angular team.
Experimental means the API can move under minors or patches, so the author argues to keep it out of production and to experiment in isolation. Developer preview is "we like the design, show us real-world pain" - safer than experimental, still not semver-frozen. Stable is the contract: breaking changes belong in majors, with migrations when possible. Deprecated gives you the familiar two-major-version runway, and removed is the point where the code is actually gone.
He also mentions tooling outside the official docs, for example a "Can I Use Angular Features" grid from Gerome Grignon, which can be handy if you support more than one Angular version.
Next to experimental, developer preview, and stable, there are also the deprecation and removal stages that Alejandro also covers.
So quite a sound guide to help you decide if and when you want to use a certain 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
Native Federation is next to Module Federation one of the most used libraries when it comes to building microfrontends in Angular. Native Federation version 4 was released and brings a bunch of updates, whereas the most visible one is a website with a lot of documentation. The GitHub repository was also moved to a new organization, the code is now split into multiple repositories, and an orchestrator that manages the microfrontends takes or will take over the old runtime.
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
In a former episode of ng-news, we've already covered Void Zero's experiments on writing the Angular compiler in the Oxidation Compiler, which is built on Rust.
There is now an official article where they publish official numbers and also give some background information on their development process, which is of course heavily AI-based.
They describe on the order of two months of work, mainly with Claude Code and Codex, under the steering of experienced engineers - not "the model wrote a compiler overnight," but agents doing large-scale porting and review work once the architecture and guardrails exist.
The headline numbers are eye-catching: they report on the order of six times faster compiles than the Angular CLI.
As always, be careful with those numbers, but they could be reasonable. Especially since they omitted some heavy tasks like template type-checking. They also admit that the non-existing type-check is a significant performance booster.
The compiler is available as a Vite plugin, @oxc-angular/vite.
VoidZero also writes that the repository will not be maintained long term. In parallel, they note that the Angular team has its own experiments with Oxc.
Top comments (0)