Learn what is new in the Visual Studio Code November 2025 Release (1.107).
Learn what is new in the Visual Studio Code November 2025 Release (1.107).
Come see what’s new in Angular v21—another incredible update for us!
Angular v21 just dropped and honestly? It’s yet another fun, developer-friendly release, and I do not know how they are going to keep this up! Between long-awaited features landing, accessibility leveling up and an adorable new mascot entering the scene, this release feels like Angular saying:
“Hey, we heard you. Let’s make building apps easier, clearer and way more enjoyable.”
Here are my top four highlights—plus a mini-demo where I try out experimental Signal Forms with Kendo UI and the new Angular MCP Server.
Angular ARIA is now officially part of the Angular platform, bringing automatic accessibility helpers directly into the framework. Instead of bolting on ARIA roles or scrambling to match spec-accurate keyboard behavior, developers can rely on headless, standards-aligned primitives that do this work for them.
The library launches with core components and examples, including accordion, combobox, grid, listbox, menu, tabs, toolbar and more—each built with semantic correctness and reliable interactions enforced out of the box. Radiogroup was intentionally removed because native HTML already handles it well, and the team is actively working on future additions like a datepicker.
In my Angular Air conversation with Wagner Maciel from the Angular team, we dug into why the Angular team created this new library, how it supports both internal Google consistency and external developer flexibility, and why it’s separate from the CDK. Angular ARIA’s primitives are powered by signals-driven state machines, giving developers a framework-supported foundation for accessible design systems—and making it possible to port these same primitives to other frameworks that support signals.
Wagner also clarified that Angular Material will not be rewritten or ported over to ARIA components, and developers shouldn’t treat ARIA as a replacement; it’s an additive capability, not a migration path.
The result is one of those features that quietly makes everything better: fewer accessibility mistakes, more consistent user experiences and a future where “accessible by default” is the expectation, not an afterthought. If you want the deeper dive into the design decisions, semantics and framework-level accessibility vision behind Angular ARIA, the full episode is here:
Forms are getting a long-overdue glow-up.
Signal Forms are:
We did two Angular Air episodes digging deep into how Signal Forms work, their design philosophy and what we can expect going forward:
Signals + Forms deep dive (Sander Elias):
Signal Forms + Mutation/Resource APIs overview (Manfred Steyer):
TL;DR: Signal Forms streamline everything—state stays in sync, your models stay type-safe and all your validation lives in one clean, centralized place.

Angular finally has a mascot and its name is Angie—a friendly, shield-shaped beam of TypeScript joy.
Mascots matter more than we admit. They give a framework personality, community identity and a real “face” for events, docs and content.
Expect to see Angie everywhere: in docs, social posts, stickers, conference swag and maybe … your IDE.
This one I am so excited about.
Angular now ships an official Model Context Protocol (MCP) server, which means:
To get started with it:
ng mcp
Which will list out json bits to stick in your mcp.json file (at least for VS Code).
And suddenly … your AI has Angular-native knowledge, access to your code and the ability to help you build and debug real components.
The Progress Kendo UI for Angular library is already fully compatible with Angular v21.
Even better, the Progress Kendo UI teams have been shipping performance improvements and modern Angular patterns for several versions, so components already take advantage of the:
Kendo UI is currently on v18, and it brings a surprising number of built-in boosts that line up neatly with Angular v21 principles.
If you’re on Kendo UI and you want to upgrade to Angular 21—you’re good to go.
Over the past three episodes, Angular Air has basically been the unofficial Angular v21 launch tour. Quick summaries:
How the team rebuilt forms on top of Signals and what mental models change going forward.
Mutation APIs, Resources, linkedSignals and what form validation looks like in the new world.
Why accessibility needed a first-party answer, and how Angular ARIA will level up design systems and complex component libraries.
If you want the “developer commentary” version of the v21 notes—these three episodes are it.
I wanted to do a tiny “let’s build something” segment to wrap my head around what’s new.
Here was my plan:
You need Node v20.19.0 or higher for Angular 21. I’m on Node 22, so we’re good.

npm install -g @angular/cli
Then I generated a brand-new project—flowforge2.0:
I prompted the Kendo UI Agentic UI Generator to scaffold my form UI, and it gave me a full Angular + Kendo UI component tree.

I also asked it to quickly swap the UI to a purple theme. Check it out:
Then I asked the Angular MCP Server to analyze the code and give feedback:
Analysis Overview:



This was honestly wild—getting Angular-aware feedback on code you just generated … instantly.
Angular 21 feels like it turned a corner—not just shipping features, but continuing to ship joy:
And with Kendo UI fully compatible (and shipping its own MCP server!), v21 is the most exciting Angular release in years.
Join us for our release webinars next week for more details on what Progress has been cooking up! https://www.telerik.com/blogs/ai-forward-telerik-kendo-ui-2025-q4-release-webinars-coming
A customer reported that their program encountered rendering problems when they created elements that were a half billion pixels tall, and they wondered why this was happening.
A half billion pixels is an awful lot of pixels. At 96 pixels per inch, that gives you an element whose height is over 82 miles (132 km). There is no monitor that tall nor piece of paper that large.¹
The conceptual reason things break down with elements that large is that you have far exceeded any reasonable limits for element size. You have ventured into unexplored territory.
The practical reason that things break down is that XAML operates internally with single-precision IEEE floating point values. (For performance reasons, the internal calculations are performed only to single-precision accuracy even though the API surface exposes double-precision IEEE floating point. Attempts to revise the API to be less deceptive and expose the values as single-precision IEEE floating point values ran into compatibility problems.)
Single-precision IEEE floating point can represent exact integers up to approximately ±2²⁴ = ±16,777,216, and the customer’s 500,000,000-pixel-tall element is far beyond that. And even if the value could be represented exactly, the value is now so large that you have lost all fractional pixels, which will cause all sorts of rounding errors.
Since there is no screen large enough to display an entire 500,000,000-pixel tall element, you can shrink the element down to a size that is, say, only three times² the size of the user’s screen. If the user scrolls the viewport, you can adjust the element accordingly so that the visible portion of your virtual element remains realized.
¹ By some calculations, the largest possible PDF document is 381 km × 381 km. These calculations have, however, come into dispute.
² I chose “three times” because I believe that that is the factor used by XAML virtualizing control (like ListView) to determine the size of the realization window.
The post Why does XAML break down when I have an element that is half a billion pixels tall? appeared first on The Old New Thing.