Blazor Blueprint brings a shadcn-style component layer to .NET 10

The design-system gap the project names

Blazor Blueprint starts from an observation about the.NET ecosystem. The README states that Blazor developers lack a modern, design-system-first UI library equivalent to what React developers have with shadcn/ui, and the project is explicitly inspired by shadcn/ui.

That framing determines the shape of the library. It is not a single monolithic theme package but two layers that a team can mix. The styled layer gives ready-made components for speed, and the headless layer gives primitives with the behaviour but not the appearance, for full control. The README calls this a two-layer architecture, and it is the same split that made shadcn/ui popular.

The stack is.NET 10, and the v4 release is explicit that the components, primitives and icon packages target net10.0, dropping.NET 8 and.NET 9 support. That is a deliberate narrowing rather than an accident, and it is the kind of decision that determines whether a team can adopt the library at all. Rendering modes are covered broadly, with Server, WebAssembly and Auto all named as targets, and the topic list on the repository includes blazor-server, design-system, primitives, headless-ui, radix-ui and tailwindcss.

The library ships as a NuGet package named BlazorBlueprint.Components, and the project has a public documentation site at blazorblueprintui.com with separate pages for components and for primitives. The repository is not archived and the last push was on 2026-10-20, so the v4 line is still moving.

The bb: prefix and the cascade layer that keeps Tailwind intact

The most interesting engineering decision in the library is how it coexists with Tailwind without stepping on it.

The stated promise is zero configuration. The pre-built CSS is included with the package, so there is no Tailwind setup, no Node.js and no build tooling in the project. Every utility in that prebuilt CSS is prefixed bb:, and the utilities are kept in their own cascade layer, so they never collide with a developer's own Tailwind build. The prefix is what makes the coexistence safe at the class-name level, and the cascade layer is what makes it safe at the specificity level.

Theming follows the same idea of borrowing from an existing standard. The library offers full shadcn/ui theme compatibility, so themes from shadcn/ui or from tweakcn can be used directly, and dark mode is built in through CSS variables rather than through a separate stylesheet. The README also lists theme presets and scoped appearance in the v4 notes, where density, font family, surface and menu options persist alongside colours and radius, and a `BbThemeScope` component carries local settings across the portal boundary into floating overlays. The portal boundary matters because Blazor renders overlays outside the normal DOM flow, and a component that lives in a dialog still has to inherit the density and colour of the scope that opened it.

This design has a consequence for teams that already have a Tailwind design system. The components will look consistent with the rest of the application only if the theme variables are wired to the same values, and a mismatch in radius or surface tokens shows up as a component that looks slightly foreign rather than as an error. Anyone adopting this should plan for that mapping work rather than assuming the shadcn theme drops in unchanged.

Headless primitives, styled components, and a 5,300 icon set

The component surface is wide, and the interesting parts are the ones a general purpose component library rarely ships.

The styled set has grown by ten components in v4, including `BbChip` and `BbChipSet` for selectable and dismissible pills, `BbFab` for a screen's single main action, `BbStepper` and `BbStep` for progress through a sequence, `BbLink` for a link that sits on the text baseline, `BbHighlighter` to mark what matched a search, `BbImage` with a fallback for a source that will not load, `BbScrollToTop`, and `BbExitPrompt`, which holds a navigation while there is unsaved work. A set of mobile components arrived with the same release, including `BbAppBar`, `BbBottomNav`, `BbNotificationBadge`, `BbQuantityStepper` and `BbSectionHeader`, along with Drawer snap points that can be resized by pointer or keyboard, Select rendered as a bottom sheet, and a DataView mobile toolbar that puts sorting and filtering in one place.

Charts are the other headline. There are 14 types built on Apache ECharts with a declarative composition API, covering Area, Bar, Candlestick, Funnel, Gauge, Heatmap, Line, Map, Pie, Radar, Radial Bar, Rose, Sankey and Scatter. Colours resolve from the theme's CSS variables at runtime and re-render when the theme changes, and an `OnDataPointClick` callback maps a click on the chart straight back to a position in the bound collection, which is the part that makes a chart usable as a control rather than a picture. Icons are bundled as well, with the README advertising 5,300 or more of them.

Accessibility is not an afterthought in this list. The stated features include ARIA attributes, keyboard support and semantic HTML structure, and several of the newer components name their keyboard behaviour explicitly, such as the Drawer snap points and the segmented date and time inputs.

Scheduler, editable DataGrid, and the shape of v4

Two components in v4 are substantial enough to describe on their own, because they are the reason a team might pick this library over assembling primitives.

The Scheduler provides Day, Week, Monday to Friday WorkWeek and Month views, with resource lanes, overlapping appointments, and drag to move or resize either time boundary. All-day events draw as bars in a band above the time grid, and a multi-day run is drawn as one bar rather than a chip per day, which is a small decision with a large effect on how a busy week reads. An `ActiveHours` property mutes or refuses the parts of a day the schedule is not about, recurring series support individual exceptions, and IANA time zones come with daylight-saving validation while `TimeZones` lets a team name its own. The extension points are explicit as well: derive from `SchedulerEvent` to carry your own fields into the editor, filter the visible resources, replace the toolbar, and right-click a slot or an appointment for a context menu.

The DataGrid gained cell and batch editing, with isolated drafts, validation, rejected-save recovery and keyboard save and cancel. Inline editors preserve column widths, accept custom Bb input controls, and reapply sorting after an accepted edit. The application supplies a deep-copy `EditItemFactory` and persistence callbacks, so the grid does not own the data.

The release also adds right-to-left support. Wrapping the layout in `BbDirectionProvider` makes the library mirror for Arabic or Hebrew, and it does so through logical CSS properties rather than through C#. A convention test keeps it that way, overlays inherit the direction across the portal boundary, and the components that place content with pixel maths read the direction at the moment of the gesture. Parameters that name a physical side, `SheetSide` and `ToastPosition` among them, keep their promise by design.

For an existing v3 user, this is a breaking release. The README points to the changelog entry dated 2026-09-19 and to a separate V4-MIGRATION-GUIDE.md for breaking changes, and the repository also holds a V3-MIGRATION-GUIDE.md from the previous major version, so both transitions are documented.

Getting the package and the stylesheet into a project

The README's table of contents lists a Getting Started section, and the section itself is not included here, so the details of that walkthrough are not in hand. What the project does state is where to get the code and how the pieces fit together.

The library is published on NuGet as BlazorBlueprint.Components, with the documentation, the component list and the primitives list all hosted at blazorblueprintui.com. The reference is added the usual way for a Blazor package, and the stylesheet that carries the pre-built CSS is included with it, which is the whole point of the zero-configuration claim. A project that installs the package and references the stylesheet gets the styled components with the bb: prefixed utilities already present, with no Node toolchain and no Tailwind configuration to write.

The first real use is a component from the catalogue, either a styled one or the headless primitive behind it. The styled ones are the faster path, since the theme variables have to be wired for the colours and density to look right. The primitives are the path for anything the styled set does not cover, and they are the same behaviours the styled components are built from.

Two things in the repository help with a first run. The demos directory holds demo applications, and the README's v4 notes point at a specific guide inside them, the Right-to-Left guide in the BlazorBlueprint.Demo.Shared project, which shows the provider wired into a real layout rather than described in prose. The repository also has a global.json, a Directory.Build.props and a solution file, so the demo and the library build from one checkout.

Licence, trademark note and a repository that documents its history

The licence is Apache-2.0, with a LICENSE file and a NOTICE file at the top of the repository, and a badge in the README that points at the same terms. Apache-2.0 is permissive and includes an explicit patent grant, and the NOTICE file means a downstream distributor carries the attribution for bundled components. That is an observation about the licence text, not legal advice, and a team with a compliance process should still run its own review.

There is a separate TRADEMARK.md file, which is unusual in a component library and worth reading before the components are put into a product. The project name and the Blueprint branding are not automatically free to use, and the presence of that file signals the author is drawing a line between the code, which is licensed, and the marks, which are not.

The repository also documents its own history unusually thoroughly. There are CHANGELOG.md, RELEASE.md, V3-MIGRATION-GUIDE.md and V4-MIGRATION-GUIDE.md, a THEMING.md for the theme model, a CONTRIBUTING.md and a CLAUDE.md, which describes the conventions used with AI assisted development. The src, tests, tools, scripts and demos directories cover the library, its tests, the tooling, the build scripts and the sample applications.

There are no GitHub releases, so the version history lives in the changelog file rather than in tags, and the package on NuGet is the artefact users install. Since the v4 line targets net10.0 only, the practical upgrade path for an existing user is to read the v4 migration guide first, then move the project to.NET 10, and only then take the new package version.

Editorial conclusion

Blazor Blueprint fits a .NET team that wants a modern design system for Blazor without hand-assembling a Tailwind build pipeline, and that needs the deeper primitives such as a Scheduler, an editable DataGrid or TreeSelect rather than a set of styled buttons. It is the wrong choice for a project still on .NET 8 or 9, since v4 targets net10.0 and drops those versions, and it is the wrong choice if you want the copy-into-your-repo model that shadcn/ui itself uses, because this is distributed as a NuGet package. Before adopting it, read V4-MIGRATION-GUIDE.md alongside CHANGELOG.md, check that the shadcn or tweakcn theme you plan to use maps cleanly onto the bb: prefixed utilities, and confirm the Apache-2.0 terms and the trademark note in TRADEMARK.md fit your product naming.

Frequently asked questions

Official sources

1. blazorblueprintui/ui on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README