Blazor Community Standup: Blazor validation in .NET 11
TL;DR
.NET 11 is filling three big Blazor validation gaps at once — Andre walked through work-in-progress support for localized validation messages, async validation, and client-side validation for static SSR, with the team currently targeting a future .NET 11 preview around Preview 5.
Localization is moving from awkward RESX-only patterns to the standard .NET localizer pipeline — instead of hard-coding
ErrorMessagestrings or using verboseResourceType/ResourceNamepairs, Blazor’s new validation pipeline can useIStringLocalizerFactory, including JSON, database-backed, and community localizer implementations.Async validation is finally getting a first-class Blazor story — the team showed a prototype
UniqueEmailvalidator that simulates checking whether an email is already registered, plus newEditContextAPIs to track pending and faulted async validation so the UI can show “checking...” states instead of freezing or deadlocking.Static SSR gets lightweight client-side validation without dragging in jQuery — Blazor will emit MVC-style validation metadata and use a built-in JavaScript library under 4 KB, versus the old MVC/jQuery validation stack at 40+ KB compressed plus jQuery itself.
The team is deliberately trying to make Blazor the no-compromise default .NET web UI framework — Daniel Roth framed these validation fixes alongside other .NET 11 work like TempData and session support as part of closing the remaining gaps with MVC and Razor Pages.
Some details are still open, and Microsoft wants feedback now — Andre repeatedly called out pending API review questions like whether async validators should always skip when sync validation fails, and invited developers to weigh in on GitHub before the .NET 11 design solidifies.
The Breakdown
Three validation pain points Blazor is finally tackling
Daniel Roth opens by framing the whole session around one theme: validation in Blazor has needed love, and Andre has been deep in the trenches on it for .NET 11. Andre lays out the three targets clearly: localization of validation messages, async form validation, and client-side validation for static SSR, especially for forms that currently require a full post just to discover they’re invalid.
Why localization in Blazor has felt clunky for years
Andre starts with a deliberately boring form to make the pain obvious: old-style data annotations mostly give you English defaults unless you use the verbose ResourceType/ResourceName setup. He calls out the drawbacks bluntly — it’s reflection-heavy, compile-time oriented, and lousy if your translations live in JSON, a database, or anything other than classic RESX files.
The new localization pipeline uses real .NET localizers, not hacks
In the .NET 11 sample, the exact same form suddenly shows properly localized validation output because it’s wired into the newer Microsoft.Extensions.Validation pipeline and IStringLocalizerFactory. Andre shows a custom JSON-backed localizer just to prove the point: if a community package already implements IStringLocalizer, it should work “for free,” and he even proposes a fallback key-provider model so developers don’t have to repeat localization keys on every validation attribute.
Async validation goes from awkward workaround to native experience
The next segment tackles a long-requested feature: validating things like username or email uniqueness without blocking the app. Daniel explains why this has been tricky — validation APIs in .NET have historically been synchronous, and simply bolting on async isn’t enough when the UI also needs to show that something is still in flight.
The email demo shows the UX they’re aiming for
Andre demos a registration form where EmailAddress runs synchronously first, and a prototype async UniqueEmail validator only kicks in once the value is at least a valid email. You see the field switch into a “checking” state, and he points out the subtle but important design choices here: pending validation, cancellation, faults, and whether async checks should run when sync checks already failed are all real UX questions, not just API details.
New EditContext APIs are the missing glue for async validators
A big practical point is that these additions aren’t just for Microsoft’s built-in validators. Andre says the new async hooks in EditContext are meant to support third-party validators too — FluentValidation comes up repeatedly — so package authors won’t have to keep doing the “suboptimal heavy lifting” around Blazor’s current sync-only entry points.
Static SSR finally gets real client-side validation, minus jQuery baggage
The final demo is the most strategic one: a statically rendered Blazor app validates on the client without any postback, WebSocket, or WebAssembly runtime. Andre contrasts this with MVC’s old approach — jQuery, jQuery Validation, and Microsoft’s adapter layer, totaling 40+ KB compressed — versus the new Blazor bundle, which includes a purpose-built validation script under 4 KB.
This is part of a broader “Blazor without compromise” push
Daniel zooms out and makes the case for why this matters beyond forms: Blazor is now Microsoft’s recommended .NET web UI framework because it can span static SSR, interactive server, and WebAssembly in one model. He ties these validation improvements to other .NET 11 gap-fillers like TempData, session support, and auth tooling, then ends with the usual but meaningful caveat: this is all still in review, and if you care about the details, now is the time to show up on GitHub.