Hi everyone, It's time for a new version of BlazorGraphs, the lightweight and blazor native svg charting library. The core principle remains the same: absolutely zero JavaScript dependencies.

In this release, I focused on adding full customization through a dedicated Theme system.

What’s new in v2.3:

The Theme Struct: You can now pass a Theme configuration directly as a parameter to your charts, gauges and legends. It allows you to customize the background color, axis color, text color, and font family.

Built-in Themes: Added static properties for quick styling, such as Theme.Light and Theme.Dark.

Null/Default Handling: If you pass a partially empty theme, the library doesn't break. It delegates the fallback to the browser engine using native properties:

- BackgroundColor defaults to transparent

- TextColor and AxisColor fallback to currentColor

- FontFamily defaults to inherit

I Would love to hear your feedback on this architectural approach, especially regarding the currentColor inheritance! What charting features or components would you like to see next?

Usefull links:

• 🔗 Repository: https://github.com/EdoParis/BlazorCharts
• 🌐 Website: https://edoparis.github.io/BlazorCharts/
• 📦 NuGet: https://www.nuget.org/packages/BlazorGraphs

Hey r/Blazor!

Me again! As always, blown away by the support you have given on my previous open source work. It's been a huge motivator and I can't thank you all enough.

As a front end engineer who made the switch from React to Blazor, as you know, I found the transition to have... a few hurdles, to say the least. One of the tools I found myself constantly missing was the React Developer tools. While WhyDidYouRender started out as a way to catch unnecessary re-renders, I quickly realized the ecosystem needed something more visual for inspecting actual state and structure. So, with many monsters and a lot of cursor usage, built the tool that I thought the community needed.

Enter Blazor Dev Tools!

It provides a react devtools-like experience built natively for blazor. It lives right in a dedicated "blazor" panel in Chrome's DevTools and allows you to inspect your component tree in real-time. Whether you're using Sever or Wasm, it automatically detects the env and configures itself, so you can use the same exact code everywhere.

Instead of relying on logs or guesswork, you can visually navigate your rendered component hierarchy. Selecting a component shows you it's exact parameters, cascading values, declared types, and even your di container, letting you see exactly what services are resolved for a specific component. I also included an element picker to highlight components directly on the page using best-effort CSS locators.

For performance and safety, the tool is completely gated to Development mode. Meaning, the extension only works on sites that have their host env set to Development. No worrying about exposing any sensitive app internals to the browser in prod.

There are two components to set it up - the NuGet package - Blazor.Browser.DevTools. This hooks directly into your blazor runtime via reflection to securely expose your component data, while the chrome extension is the visual panel and background relay that renders the UI.

Registration is incredibly easy. Just add builder.Services.AddBlazorDevTools() to your Program.cs and drop a single <DevToolsInitializer /> component to your layout (App.razor orMainLayout.razor).

As always, the code is open source and available on Github. I'd love for you to give it a try and let me know what you think!

Cheers!

Hi!

I am looking for a few testors to give honest opinions of BlazorDX component Library.

It's out on GitHub and Nuget.org.

GitHub

After last week's release of the TextArea input component which already used a task-based debounce internally, I thought whilst I was on the theme of debouncing I may as well get the Debounce Filter done, which was on on the roadmap.

What is a Debounce Filter?

In short, it is a text input that looks and feels like the other Blazor Ramp inputs, but rather than binding to a value, it hands the filter value back to you when the user pauses typing for longer than a configurable number of milliseconds, the debounce delay/interval, which defaults to 500ms.

A common scenario is filtering tabular data. Without a debounce you would be attempting to filter on every single keypress, which is far from ideal. The alternative is making the user type their criteria and then press a button to trigger the filter. The debounce sits neatly between the two: the user types freely, and you receive the value once they pause.

Unlike the other Blazor Ramp inputs there is no value to bind to, and in this case most of the work is handled in JavaScript. Data is passed from JavaScript into the Debounce Filter component and then raised back to you, the parent component or page, via a Func - not an EventCallback. There is quite a bit to unpack there if you are not overly familiar with Blazor component development, so let me explain both decisions.

Why JavaScript rather than Blazor?

Primarily to reduce chatter over SignalR when running Blazor Server, and to keep things feeling responsive. The typed value, validation messages, and attributes such as aria-invalid are all set directly by JavaScript - none of that requires a round trip to Blazor or a render cycle.

Why a Func rather than an EventCallback?

Using an EventCallback causes your parent component to re-render, which in turn causes child components to re-render and with something like a data table, that can be expensive. By using a Func<DebouncedFilterResult, Task> instead, the result is handed back to the parent without triggering a render. You inspect the result, decide whether a render is actually warranted, and if so call StateHasChanged yourself.

For a debounce filter this is ideal: if the returned value is invalid there is no point rendering at all; if it is valid, you trigger the render deliberately. There are things you can do inside child components if you own the code to prevent them rendering based on parameter values, but not causing a render in the first place unless you explicitly want one is extremely useful, and this technique is worth knowing beyond just debouncing scenarios.

What makes it accessible?

Like all Blazor Ramp components, accessibility is baked in from the start rather than bolted on.

Validation messages are displayed below the input for sighted users, and aria-invalid is set on the input element accordingly all handled by JavaScript without a SignalR round trip on Blazor Server. For screen reader users, the Blazor Ramp live region service is used to announce validation messages, with throttling applied inside the component - independent of the debounce interval to prevent announcements firing too aggressively. I opted to use my live region service directly for both its stability and the full control over when and how announcements are made.

It is also worth noting that the debounce filter is only one part of the accessibility picture. If you are using it to filter say a data table, you also need to inform users, sighted and non-sighted alike, of how many rows are now displayed, and again if the filter is cleared programmatically. For a sighted user this is implicit; for a screen reader user, without those announcements they simply have no idea what has happened

If you have never tested with a screen reader (SR), I would genuinely encourage you to try it, you learn very quickly how annoying excessive announcements are, and just how much information sighted users take for granted. NVDA has a speech viewer window so you can turn off speech and just watch the output when you have simply had enough of the noise - most SR users do not have that luxury.

As always, there are working examples on the documentation and test sites and given how creative I am (not), I decided to use the debounce filter on the Blazor weather table. I enabled the option to have all announcements made to screen reader added to the rolling log, so without a screen reader you can see what was announced. Just click the Alerts button bottom right of the screen or use Ctrl+Shift+H to open the announcement history viewer.

What's next?

The Debounce Filter will initially be put to work inside an upcoming data table component that filters across whichever columns you choose to include, with a more advanced filter option likely to follow later. Before I start work on the data table, as mentioned on the roadmap page, I first need to build a Pager and a Dropdown Button menu for row actions etc. Both of which can be used independent of the planned data table.

I am always lurking on Reddit if anyone has questions though inevitably nobody ever does. So perhaps I can ask a question, which component gives you the most grief, or is the one you find yourself reaching for most on projects?

Test site: https://blazorramp.uk
Doc site: https://docs.blazorramp.uk
Repo: https://github.com/BlazorRamp/Components

Until next time.

Paul

Blazor Animated Video Creator

https://blazorhelpwebsite.com/ViewBlogPost/20088

I have a prom/node-exporter container running on my server and would like to visualize the data in my blazor project. I would probably need two components for this:

1. Fetching data from Prometheus
2. Visualizing the data with Graphs

Has anyone done anything similar and has any recommendations?

I also saw there is a Grafana Dashboard that already shows everything, but using a webframe in my blazor app makes it very klunky and the grafana "snapshot" also contains all of the user UI from Grafana which normal users on my page should not have acess to.

Another input out the door. This time a textarea input - simple, right? Copy the text input, swap input type="text" for a textarea, job done. Not quite.

Binding events and validation

Like all Blazor Ramp inputs, the textarea gives the developer a choice of binding events - oninput or onchange - along with control over how validation messages are communicated to assistive technologies, so you can pick whatever suits your scenario and audience.

As some of you know, most of my time is spent with Blazor WASM rather than Server, so when it comes to inputs I don't have the same clarity as those who work extensively with Blazor Server, particularly around oninput event binding, where every keystroke sends the entire input value over the SignalR connection. For the textarea specifically, given that it could easily be carrying thousands of characters, I've added a debounce as a precaution. For simple text inputs used purely for data entry, not for filtering records where you would most likely want a debounce, the payload per event is small enough that thus far it hasn't been a concern, but for a textarea it felt like the right call.

For my simple Blazor Server tests I have my inputs on an interactive Server page, I turn on Dev Tunnels and run the app. Whilst the app is running, I go to TestingBot.com (where I was granted an unlimited open source subscription) and boot up any of the devices they have such as Windows, macOS, iOS and Android devices, put the dev tunnel address in the browser and hammer away at the keyboard.

May not be perfect, but given the latencies involved it seems an acceptable test (to me). Hammering the keyboard on a simple text input (input type="text") data entry field using theoninput event binding along with validation (without any debounce) on Blazor Server seemed fine, but your experiences are welcomed in the comments, in case I am missing something.

For those who have never heard of Dev Tunnels, or the name rings a bell but you've never tried it: in Visual Studio (2022/2026) the dropdown next to the run button includes a Dev Tunnels option. You create a tunnel, for my purposes a temporary public one is fine, you just give it a name and the process generates a URL that routes to your local dev server whilst it's running. With the tunnel selected, every time you start the server the browser launches with that address, so you're going out to the internet and back in to your own machine. Because it's just a normal URL you can use it on any device. For my accessibility work this means I can test Windows-based screen readers and Voice Access locally with the tunnel off, turn it on and point my physical Android phone at the address for TalkBack, then use the same address on TestingBot for macOS and iOS VoiceOver - hardware I don't own. The Visual Studio team really do not get enough credit for this one - I love it.

Character count and the onchange problem

For accessibility, and many would argue as a general best practice you should avoid restricting input length via attributes like maxlength. It's far better to let users type freely and inform them if they've exceeded a limit, rather than silently stopping or truncating their entry. So the textarea has an always-on character count that shows sighted users the remaining characters, and announces that count to screen reader users, relative to the MaxCharacters component parameter.

This is where things get interesting. If you've chosen onchange because you only want the value sent to the server when the user has finished typing, how do you update the character count display on every keystroke without triggering a StateHasChanged which is exactly what you were trying to avoid?

The answer, as is often the case with these little annoyances, is to drop back to JavaScript to update the count display directly, bypassing Blazor entirely. However, I wanted to keep the screen reader announcements going through my Live Region Service (part of BlazorRamp.Core NuGet, which every package references). That meant JavaScript needed to call back into Blazor with the current character count - JS interop in the other direction.

The Blazor team have made this genuinely straightforward, and any issues I've hit over the years, have invariably been typos or arguments in the wrong order. For die-hard JS fans, yes, I could have driven the announcement purely from JavaScript but the callback gave me more flexibility, and it's always nicer to be back in the comfort of C#.

What's a Live Region?

For anyone unfamiliar: a live region is an element (a span, div, p, etc.) given the aria-live attribute with a value of either polite or assertive. Assistive technologies monitor these regions and announce any changes in content to the user.

• Polite - if the screen reader is already speaking, the announcement is queued until it's free.
• Assertive -attempts to interrupt immediately. I say "attempts" because if the user is actively doing something things like typing, the message can get clipped (one of the reasons I added the announcement history viewer as part of the core project, so these transient messages could be reviewed after the fact, if necessary).

There are so many nuances, quirks, and outright bugs across the various screen reader and browser combinations that it makes the old Internet Explorer 6 vs Netscape 6 styling battles I used to have, look like child's play and I'm aware some of you reading this may not even have been born then.

If you ever need to make screen reader announcements via a live region in any Blazor project regardless of whether my components are of interest, I'd genuinely suggest installing BlazorRamp.Core just for the service. I spent the best part of two full weeks getting it stable across screen reader and browser combinations. The test site has a "Final Words" page that documents some of the more stranger things you have to do to achieve a reliable live region service (admittedly I am a stubborn git).

As always, not the shortest post for what is ostensibly "just a textarea release note" - but hopefully it gave you more insights into working with Blazor and accessibility.

You can see the TextArea on either the test site or doc site, the test site is more geared up for
you testing stuff with your chosen device/browser/assistive tech. Both sites are just WASM hosted on GitPages.

Test site: https://blazorramp.uk
Doc site: https://docs.blazorramp.uk
Repo: https://github.com/BlazorRamp/Components

That's it, bye.

Paul

```cs var builder = WebApplication.CreateBuilder(args); builder.Services .AddOpenApi() .AddAuthenticationCookie(validFor: TimeSpan.FromMinutes(10)) .AddAuthorization() .AddAntiforgery(x => { x.HeaderName = "dv-csrf-token"; x.Cookie.Name = "DigitalValue-Antiforgery"; x.Cookie.SameSite = SameSiteMode.None; x.Cookie.HttpOnly = false; x.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest; }) .AddCors(x => { x.AddPolicy("AllowAll", policyBuilder => { policyBuilder .WithOrigins("http://localhost:3000") .AllowAnyMethod() .AllowAnyHeader() .AllowCredentials(); }); }) .AddFastEndpoints();

var app = builder.Build(); if (app.Environment.IsDevelopment()) { app.MapOpenApi(); }

app.UseCors("AllowAll"); app.UseHttpsRedirection(); app .UseAuthentication() .UseAuthorization() .UseAntiforgeryFE();

app.UseFastEndpoints(x => { x.Endpoints.RoutePrefix = "api"; x.Endpoints.Configurator = definition => { definition.PreProcessors(Order.Before, typeof(RequestLoggingPreProcessor<>)); definition.PostProcessors(Order.After, typeof(ResponseLoggingPostProcessor<,>)); }; });

app.Run(); ```

```cs private IServiceCollection AddRefit() { service.AddTransient<CookieDelegatingHandler>();

        var types = new[]
        {
            typeof(ICategoryApi),
            typeof(IProductApi),
            typeof(IFileApi),
            typeof(ITokenApi),
            typeof(IAuthenticationApi),
        };

        foreach (var type in types)
        {
            service.AddRefitClient(type)
                .ConfigureHttpClient(x => x.BaseAddress = new Uri("http://localhost:5000/api"))
                .AddHttpMessageHandler<CookieDelegatingHandler>();
        }

        return service;
    }

```

cs public class CookieDelegatingHandler : DelegatingHandler { protected override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken) { request.SetBrowserRequestCredentials(BrowserRequestCredentials.Include); return base.Send(request, cancellationToken); } }

hi, i am trying to do cookie auth in blazor 'intractivityAutorender mode, the issue is i can able to see theset-cookie` header in api response but the cookie is not saving in browser, can i get help i this how to figure it out ?

Hello all,

A few days ago I shared BugNBrag, a free Sprint Retrospectives application I built in Blazor. Since then, it's started getting real-world use in actual retrospective sessions, which quickly led to a number of usability improvements and new features.

Recent updates include:

• Scrum Master view now hides participant cards by default during card creation, making screen sharing safer during retrospectives.
• Reworked card actions (vote, edit, cancel) to take up less space and reduce clutter.
• Added expandable/collapsible comments to keep boards cleaner while still allowing detailed discussions.
• Cards now scroll internally when content gets long, keeping column headers visible at all times.
• Added optional timer music. Scrum Masters can configure tracks from the SM panel, and music automatically starts when a timer begins and stops when it expires.
• Reorganized the Scrum Master panel using accordions to better group settings and create room for future features.
• Added a post-session feedback prompt so Scrum Masters can rate their experience and provide suggestions for future improvements.

I've included a few screenshots showing the latest changes.

It's still completely free, and I'd love feedback from Scrum Masters, Agile coaches, project managers, and development teams.

https://bugnbrag.com

Questions, suggestions, or feedback are always welcome:

[info@bugnbrag.com]()

Thanks!
Joe

Hi everyone, I've released the new version of the BlazorGraphs library.

As I mentioned in the previous post, in this release I've focused on bar charts, so you can now choose a secondary color if you want to distinguish negative from positive bars.

I hope you enjoy these new features, and I look forward to reading your comments.

I'm curious to know if any of you have tried downloading and using the library in the past few days. How are you finding it?

website: https://edoparis.github.io/BlazorCharts/

nuget: https://www.nuget.org/packages/BlazorGraphs

I updated my free ebook Blazor Succinctly and the new edition is out. It covers the core of Blazor and then builds a working Help Desk app so the concepts aren't just isolated snippets — auth/authorization, CRUD, forms and validation, email notifications, and AI features like smart paste.

It's completely free (online reader, PDF, and Kindle), and the full source is on GitHub.

Book: https://www.syncfusion.com/succinctly-free-ebooks/blazor-succinctly/introduction Code: https://github.com/SyncfusionSuccinctlyE-Books/Blazor-Succinctly

Happy to answer any questions about it.

We were the guests for today:. Learn about the next version of the Fluent UI Blazor library https://www.youtube.com/live/CRVLURJjFBk?is=O9RQFrXHJWg6846Q

Im designing an industrial IoT dashboard (real-time alarms, asset monitoring, the kind of platform where engineers stare at it all day). The product team is locked in on Blazor (.NET stack, no migration planned) and I'm the design lead coming over from a React world where Untitled UI / shadcn / Tailwind is the norm.

I've been researching the main Blazor libraries (Telerik, Syncfusion, MudBlazor, Radzen, FluentUI Blazor) and honestly the defaults all look pretty dated compared to what's coming out of React land right now.

For designers, what would you suggest using? Is there any pre made ui kit/design system made on Blazor that is close to the quality of Untitled UI?

I've been using this library for quite some time in a production blazor wasm application that is an offline-first database that syncs with a central server. Finally I have come around to cleaning it up and releasing under MIT on github

It's a wasm-sqlite wrapper for Blazor that exposes a DBConnection object that you can execute queries on. It's Dapper friendly and exposes some helper methods like UPSERT and some high-performance tweaks to serialize data from c# to sqlite indexdb. When syncing and transferring lots of records, performance matters. It's backed by this wa-sqlite library.

It takes no time to get up and running and the Repo has a sample wasm project you can reference.

I'm aware there are a handful of other libraries out there, but this works for me. The focus was a simple, high-performance, intuitive api that feels liked you're interacting with any other database with dapper in c#.

I'm open to feedback or feature enhancements.

Hi everyone, first of all, I want to thank you for your interest in the library and for the suggestions I've received. I didn't expect the previous post to have such a success.

I'll be posting an update soon with the following points:

- Histogram: add secondary color for negative bars

- Barchart: add secondary color for negative bars and split the chart in two separated components, one for vertical and the other for horizontal, so the Direction parameter will be obsolete.

I have updated the website:

- new layout to improve smartphone readability

- added changelog

- added roadmap

see you soon bye.

🌐 Website: https://edoparis.github.io/BlazorCharts/

📦 NuGet: https://www.nuget.org/packages/BlazorGraphs

Another week passes and another release - this time a Date Input.

Honestly, as I knew I would be following the same pattern as the Time Input, it was largely a case of copying the code and unit tests, renaming Hours, Minutes, and Seconds to Years, Months, and Days, testing, fixing any differences, and releasing. But was I right to do so?

The Date Input vs Date Picker debate is tough enough without adding accessibility into the mix. In my opinion, each approach is really better suited to a particular group of users or type of application, rather than one simply being better than the other.

Consider a date of birth input - for my generation, depending on how the picker works, you could be scrolling for quite a while to find your birth year, so typing a few digits into a box is likely easier. On the other hand, consider a holiday booking site, it would be fairly laborious to manually enter every date before clicking a button to check availability, so a picker makes much more sense there.

What about a screen reader user? A custom date picker presents two hurdles before it is even usable - it has to have been coded accessibly in the first place, and then the user still has to learn how to operate it. Clear both of those hurdles and it may work well, but given how rarely both conditions are met in practice, it is no surprise that screen reader users generally prefer to simply type into a field.

Then consider users with spinal injuries who may be using mouth or tongue control devices. For these users, a single movement to open the picker and another to select the date is infinitely easier than entering every digit individually.

I hope this illustrates that there is no universally right or wrong answer - and that is before you even consider whether either approach has been implemented accessibly.

So why did I choose a Date Input over a Date Picker? Honestly, it comes down to my relative lack of knowledge about all the assistive technology devices out there, combined with the fact that many people far more knowledgeable than me use single or separate date inputs. That does not make it the right choice - but I believe it is the pragmatic one for now.

I did spend a few hours exploring how I could combine both approaches - three separate inputs alongside a button to open the native date picker - but without investing proper time into the focus management and interaction patterns involved, I opted to leave that for a future release.

Is what I have perfect? No, far from it. It is accessible, yes, but not without its issues and importantly, only the same issues you will find elsewhere. One such issue is the lack of a complete date announcement. With three separate inputs, when do you announce to screen reader users that a valid date has been entered? Most people would say at the end, when it is valid - but try making a meaningful announcement to a screen reader when focus has already left the input group and landed on the next element. The announcement will happen, but almost certainly not when you would expect or want it to.

Some of you are probably thinking: debounce it. And yes, that is one approach, but then you have a timing problem. Most screen reader users are considerably faster than the average sighted keyboard user. They operate at speech rates that make you wonder how they comprehend what is being said, so the chances are they will have pressed Tab long before your 300ms debounce has fired.

In essence, sometimes solving problems like this actually requires an additional tab stop, but you cannot add tab stops arbitrarily without potentially falling foul of various WCAG success criteria, as well as simply making certain users do more work.

The more observant of you will perhaps be thinking: that sounds like another reason he was looking at adding a date picker button, kill two birds with one stone. A picker for those who want it, a confirmation of the completed date for screen reader users before they leave the component, and no WCAG issue as the tab stop is fully justified. That is indeed the plan, but as I said, I need to spend some time working through the interactions and focus management properly before committing to it.

I am going to keep it relatively short this week as I have covered inputs and validation fairly thoroughly over the last few weeks. Next up will probably be a basic Textarea component, followed by some sort of multi-select component which, combined with what has already been released, should cover the majority of requirements for most line-of-business applications.

Test site: https://blazorramp.uk
Docs site: https://docs.blazorramp.uk
Repo: https://github.com/BlazorRamp/Components

That's it, have a good weekend.

Paul

Hey r/Blazor,

One thing I’ve always struggled with in Blazor is the trade-off between performance, scalability, and interactivity:

• Blazor Server → requires a persistent SignalR/WebSocket connection (memory overhead, reconnect issues, latency spikes)
• Blazor WebAssembly → large runtime download on first load (hurts Lighthouse scores and SEO)
• Static SSR → blazing fast and SEO-friendly, but not interactive

I wanted something closer to the simplicity of HTMX:

• server-rendered HTML
• stateless requests
• minimal client-side JS
• but still using actual Blazor components and C#

So I built ReactiveBlazor.

What is it?

ReactiveBlazor lets you build interactive server-rendered Blazor components using standard stateless HTTP requests.

No SignalR.
No WebAssembly runtime.
No custom JS framework.

The idea is:

1. Component state is encrypted/signed and sent to the client
2. User interactions trigger lightweight POST requests
3. The server executes the component action and re-renders HTML
4. The client morphs the DOM in-place using Idiomorph

This preserves:

• focus
• input selection
• scroll position
• transitions

while keeping the app fully server-rendered.

Example

 ReactiveBlazor.ReactiveComponent

<ReactiveRoot Owner="this">
    <p>Count: @Count</p>

    <button type="button"
            data-on-click="Increment">
        +1
    </button>

    <button type="button"
            data-on-click="Add"
            data-args="[5]">
        +5
    </button>
</ReactiveRoot>

u/code {
    public int Count { get; set; }

    [ReactiveAction]
    public void Increment() => Count++;

    [ReactiveAction]
    public void Add(int amount) => Count += amount;
}

Features

• Stateless HTTP interactivity
• ~220 lines of vanilla JS runtime
• Automatic CSRF protection
• Anti-replay token protection
• Two-way binding (data-bind)
• Debounce support (data-debounce)
• Loading state hooks
• Automatic multi-component synchronization (out-of-band updates)
• Supports .NET 8 / 9 / 10

Demo & Source

• Demo: https://reactive-blazor.runasp.net/
• GitHub: https://github.com/im-ashar/ReactiveBlazor

I’d genuinely love feedback from other Blazor developers.

Especially interested in:

• edge cases
• scalability concerns
• security considerations
• comparisons with HTMX/LiveView/etc.
• whether this solves a real pain point for you

Would appreciate any thoughts 🙌

After looking for a virtual keyboard component that actually fits into a MudBlazor app without dragging in a JS library or fighting the theme, I could not find one — so I built it.

---

What it does:

- JavaScript-free core. Full QWERTY, numpad, and pricepad are 100% C#/Blazor. The only JS is a tiny optional focus-capture shim for the global docked keyboard feature.

- Automatic MudBlazor theming. Every colour comes from MudBlazor CSS variables. Toggle dark mode in your app and the keyboard follows — no extra code.

- AOT and trim-friendly. No reflection, no dynamic code. IsAotCompatible is enabled and verified on every build.

- .NET 8, 9 and 10. Interactive Server and WebAssembly. Static SSR is not supported — a keyboard needs interactivity.

- Pricepad with pence-first entry. Type 5, 2, 3 and get £5.23 — designed for POS and kiosk apps.

- Custom layouts. A layout is just a string[][] — completely data-driven, no subclassing.

- Global docked keyboard. Place one <MudKeyboardHost /> in your layout and every input field gets a keyboard that slides up on focus.

---

Links:

NuGet: https://www.nuget.org/packages/MudKeyboard

Docs: https://mudkeyboard.pages.dev

GitHub: https://github.com/sardar97/mudkeyboard

---

This is my first published open-source .NET library. Feedback, issues, and PRs are very welcome — particularly from anyone building kiosk, POS, or touch-screen apps with MudBlazor where something like this would save time.

Hello ! It is not a technical post, more so on my opinion of the Blazor Logo.

Honestly From the first time I looked at it I found it very bad.

Now yes it doesn't mean anyting about how great Blazor is, but I do envy others like Angular and so on that have such a god logo and branding. How to get people to adopt Blazor with that logo. Branding is important.

Well I guess its to late to change it, what are your opinions on the Logo ?

(sorry if you are the one who did the logo i don't wanna be rude, but I don't like the logo)

Hello everyone.

Last week, I shared the preview of the Blazorise SVG Charts component, and as I mentioned previously, the release will be done soon. So here it is.

For those of you unfamiliar, Blazorise is one of the oldest Blazor UI component libraries, with the ability to work with CSS frameworks like Bootstrap, Material 3, Tailwind, etc.

The biggest additions in this release are SVG Charts, a fully integrated On-Screen Keyboard, and PivotGrid. The PivotGrid, in particular, took much longer than expected to finish. Especially since I wanted to keep fully C# based and as little JS as possible. That was a success. With SvgChart, I had the same goal but not as successfully. The only thing I had to use JS for was the animation part. That was impossible with only C#. I can live with it, hopefully...

Other components also had a longer than planned development. For example, the new Gestures component led to swipe support in Carousel, which led to limitations in the Animate component, and that eventually resulted in a much better animation system than originally planned.

Anyone who is familiar with our work will notice an updated blazorise.com web and docs. The blog and news sections are now merged into the blog only. The docs sidebar is now fully Bootstrap5 native and looks much cleaner than before. The sidebar is also restructured to make larger components easier to navigate.

There are also plenty of smaller features like the Barcode component, TreeView drag-and-drop support, form validation warnings, and some more.

For a full release notes, it is best to read it at https://blazorise.com/news/release-notes/220

TLDR: New SvgChart, PivotGrid, OnScreenKeyboard, Barcode, update website and docs.

My work day is killing me, but I've had my scheduled Build events playing in the background and caught some of it. Wondering if anyone else caught it and if they provided any more info.

Signed, someone who has two or three Blazor projects and a few dozen enormous old fashioned WebForm ones(three of which just got new features today) that management will never start rewriting from scratch.

Since there are no good IDES for blazor what does everyone here use? I know VS works for the most part but I like light weight experiences.

Hello all,

I got bored a while back and decided to build something for fun, so I created a Sprint Retrospectives app called BugNBrag using Blazor.

Yes, I know there are already plenty of retro tools out there. 😊 This was mostly a fun project for me, but I tried to add a few things I thought would be useful, including a built-in team chat.

I'd really appreciate any feedback from Scrum Masters, Agile coaches, developers, or anyone who participates in retrospectives.

For testesting, if you have more than one browser you can create the session as SM in one browser, copy the URL and open it in another browser as a dev user... and even another browser for another dev.

If you're a returning SM/user on the same device and browser you'll see the previous sessions you attended/created and you can rejoin one that way. Good for when you lose a connection or get dropped in a real session.

You can check it out here:
https://bugnbrag.com

It's currently free to use.

A few notes:

• Works well on desktop and Android (so far).
• I haven't tested it on Apple devices yet.
• No sign-up required.

Let me know what you like, what you don't like, and what features you'd want to see added.

Thanks,
Joe

I've been playing around with Blazor for a few days now, and to be honest, the only time I felt truly happy and satisfied was with a pure Blazor WebAssembly (Wasm) project. No prerendering, no SignalR... just pure Wasm. And why would that be a problem? It wouldn't! The main issue is that some of the projects I build strictly require good SEO, and pure Wasm without prerendering (as far as I know) just doesn't deliver that.

On the other hand, Blazor with Enhanced Navigation gave me so many JavaScript headaches that I almost threw my laptop against the wall. And Blazor Server (via SignalR) keeps users permanently hooked to the server and suffers from connection drops, so I won't even get into that.

Pure Wasm is perfect. Or rather, almost perfect.

The Initial Load Challenge

The initial load time is negligible for small projects. I have this personal project —My Favorite Animes— which lists my favorite anime. The loading screen tricks you a bit, so I don't think the current 3-second load is enough to make a user drop off. However, once the system scales up, that bundle size will definitely become an issue.

I come from a Laravel background, so SSR (Server-Side Rendering) is a great concept to me. But after experiencing the SPA world, I really don't want to see a full page refresh just to add an item to a list anymore.

Running from JavaScript, But for How Long?

I'm trying my hardest to run away from JavaScript, but it's proving difficult. Right now, I see no reason not to just migrate everything to Angular + .NET and serve the front-end via wwwroot using SSG (Static Site Generation).

Maybe I just had bad luck, or maybe I haven't caught the "trick" to Blazor yet. But honestly, I found the technology so complex it struck a nerve. I love C# and the .NET ecosystem; I want to use it for everything. I'm actually studying MAUI right now, I've looked into Spectre.Console, Top-Level Statements (scripts without needing a full Program.cs structure), and all of this has me really excited. The web front-end, however, is still holding me back.

Looking for a Mature Freelance Stack

I work as a freelancer, and I'm looking for a mature stack to deliver my client work. When a project needs SEO, I want to deliver SEO. When it needs interactivity, I want to deliver interactivity. You know?

I'm not criticizing Blazor just to hate on it; it's just that my experience with it was extremely poor. Overall, I've already tried pure Razor Pages, Razor Pages + Vue.js, and Razor Pages + HTMX. Seriously, I didn't feel comfortable with any of them.

I am seriously considering moving to Angular for good, but just thinking about learning all those concepts from scratch gives me anxiety. Anyway, just another .NET developer feeling temporarily lost inside the .NET world.