PrimeNG’s new licensing model and A2UI for model-controlled Angular interfaces are the headline topics this week.
Also in brief: OpenNG’s community fork, transactional router resource behavior, and the current Native Federation and Module Federation options for Angular.
Future of PrimeNG
PrimeNG, a very popular UI component library, has announced that future major versions won’t be available as open source anymore, except through a free Community license for individuals, students, non-profits, non-commercial open source projects, and small organizations.
That doesn’t just apply to the Angular version but to the React and Vue versions as well. The reason is that the library has grown over time, which means if you do this as open source you have to spend much more time on it, and at some point, the income that they got from selling things around the library itself didn’t cover the costs anymore.
The new licensing brand is PrimeUI. The launch price is USD 599 per developer. That is perpetual, so for life for the covered versions, and it includes one year of updates. It also includes PrimeUI PRO, which contains components for charts, text editor, scheduler, task board, and more. The Pro components are not part of the Community license.
PrimeUI
PrimeUI is a complete UI ecosystem — premium component libraries, advanced pro components, UI kit, and design resources to build modern web applications.
primeui.dev
That being said, OpenNG, an organization which maintains unmaintained libraries, announced that PrimeNG went closed-source, the GitHub repository was archived on June 28th, 2026, and OpenNG created a copy of the project with regenerated open issues and PRs. Their goal is to release a beta version supporting Angular 22. So we are talking here about a fork. At the time of this writing, the current name is open-prime, but OpenNG says it is too close to PrimeNG because PrimeTek plans to put trademarks on it.
OpenNG Update: Funding, Versioning, PrimeNG and ngneat projects | OpenNG posted on the topic | LinkedIn
As people have questions about the future of projects such as Spectator or PrimeNG, here is the current state of our actions.
OpenNG
We just renamed the initiative from OpenNG Foundation to OpenNG to avoid confusion and to respect the OpenJS Foundation trademark policy.
Funding
We are working on a funding model to support the maintenance of the projects and give back to contributors. We submitted the initiative to Open Collective and contacted HeroDevs for partnership.
Versioning Policy
We’ll start over with v1.0.0 for all the packages. Each project will include a matrix compatibility table with the supported major Angular versions (including the previous package). Some packages were already not following the Angular versioning policy, and this will allow us to author a major version for breaking changes anytime.
PrimeNG
PrimeNG went closed-source, and the GitHub repository was archived on June 28th, 2026. Discover the announcement here.
We created a copy of the project and regenerated the open issues/PRs. Out of 968 open issues, 58 have already been closed, and 23 triaged as still relevant and accepting contributions to resolve them. Triaging was made possible thanks to the contribution of the community.
Our goal this week is to release a beta version supporting Angular 22, as people were already delaying updating their projects.
It’ll include:
– a set of unreleased changes from the original repository (modernize existing components, add a few new ones)
– ng add support for new projects
– ng update support as unreleased changes include a few breaking changes (camelcase selectors removed, deprecated APIs removed)
Our current blocker for this release is to find a proper name for the project. Currently named open-prime, it’s too close to PrimeNG as PrimeTek plans to put trademarks on it. We asked the community for suggestions here.
We’re evaluating proposals, with the main restriction being to avoid confusion with another project (many UI frameworks are matching the proposals).
ngneat projects
Out of the 34 original repositories, we decided to start working on the following ones:
– cashew
– query
– elf
– spectator
We have a volunteer working on cashew, currently preparing the first release.
Spectator is our priority within the ngneat ecosystem, planning a release this week. We also have a contribution to expose the jasmine package as a standalone (like jest/vitest ones, planned to land in 1.1.0.
We still need to triage the remaining repositories to understand if we should keep them or not. 13 of them might not be maintained anymore due to low activity or having a better alternative nowadays.
GitHub: https://lnkd.in/eE7QuzZR
linkedin.com
A2UI
Devin Chasanoff from the Angular team has published an article on how to use A2UI with Angular, which enables dynamic UI that is controlled by an AI model.
The user expresses an intent through the frontend. The frontend sends that intent and relevant context to a model. This communication can also include a component catalog that the frontend knows how to render. The model can then decide whether UI components are needed, which components are appropriate, and return structured UI instructions to the application.
A2UI is a protocol used for these agent-generated UI use cases. A2UI messages can be transported over HTTP, WebSocket, or Server-Sent Events, depending on the application architecture.
Demystifying A2UI: How to Make AI Agents “Speak UI” in Your App | by Devin Chasanoff | Jun, 2026 | Angular Blog
I’ve spent a fair amount of time experimenting with A2UI, a protocol for building agentic interfaces. Why? Quite simply, because I think…
blog.angular.dev
routerResource
In other news, work on integrating resource behavior with the router seems to have begun. A PR meant for internal usage popped up, which uses a snapshot-like router resource behavior to integrate navigation-specific information.
That snapshot would freeze a resource’s state, for example the value, while a navigation happens. Once the navigation succeeds, the underlying value is exposed, and if the navigation is cancelled, the frozen value would still be there during rollback recovery.
Imagine the following use case. A resource has a router parameter as its own parameter. That could be a product id which loads a product by id. If the user stays on the same component but navigates to a different product id, the resource would immediately change its state and the UI would change while the navigation happens. That could cause flickering effects, especially if the navigation gets cancelled via a guard and the product id changes back to its initial value.
With the introduced router resource behavior, that is not going to happen. Again, the PR’s description explicitly states that this is not currently exposed for public use, but it is very likely the start to get resources and the router together.
Angular PR #69490: Create transactional router resource
Micro-Frontends
In other news, going with Micro-Frontends is an architectural need which we find very often in enterprises. Although they are not an Angular framework feature, there are two common community solutions in the form of Native Federation and Module Federation.
The main distinction in Angular is that Native Federation works with esbuild, so the modern Angular builder, and Module Federation traditionally works with the old webpack builder or alternative builders such as Rspack.
Native Federation is maintained by Angular Architects, and Module Federation support in Nx has been common for Angular workspaces. In the release blog for Nx 23, Nx now recommends @angular-architects/native-federation for Angular and deprecates the older Nx-specific Module Federation generators and executors.
Nx 23: 4x Faster Nx Agents, Agentic Nx Migrate, improved targetDefaults, .Net GA | Nx Blog
Nx 23 brings a smarter multi-major nx migrate, performance wins across the local engine and Nx Cloud agents, native Node.js TypeScript stripping and V8 compile cache on by default, more precise target configuration, and a big cleanup of deprecated generators, executors, and APIs.
nx.dev
