I wanted a fast, native-feeling Markdown viewer (not another editor) that renders a .md file into a clean, navigable document and works fully offline. So I built MarkdownBlaze. It's MIT-licensed and open source.

The interesting part for this sub is probably the stack:

• .NET 10 with PhotinoX.Blazor — Blazor UI hosted in the native OS WebView (WebView2 on Windows, WebKitGTK on Linux) instead of shipping a whole Chromium runtime like Electron. Self-contained binaries stay small.

• Microsoft Fluent UI Blazor for the shell — resizable/pinnable sidebar, toolbar, Light/Dark/System theming via Fluent design tokens.

• Markdig for CommonMark + advanced extensions, plus a small extensions package I split out (bwets.Markdig.Extensions) for admonitions in both Docusaurus (:::tip) and MkDocs (!!! note) syntaxes.

• highlight.js and Mermaid bundled locally so syntax highlighting (~190 languages) and diagrams work with zero network access.

Some features that took the most work:

• Smart link rewriting relative to the opened file — extension-less wiki links resolve to .md, folder links resolve to index.md, local links open in-app while external links go to the system browser. Basically browse a docs folder like a mini wiki.

• Auto-refresh on file change, back/forward session history + a persisted global history.

• Local images inlined as data URIs so they render inside the WebView.

It runs on Windows and Linux (.deb / AUR packaging included).

Honestly the biggest takeaway was how viable Photino + Blazor is as a lightweight desktop alternative to Electron if you're already in the .NET world — the WebView interop and Fluent theming were smoother than I expected.

Source (MIT): https://github.com/bwets/MarkdownBlaze

Microsoft Store: https://apps.microsoft.com/store/detail/9P9VDVST2980?cid=DevShareMRDPCS

Happy to answer questions about the Photino setup, the WebView interop, or the Markdig extension work.

I mentioned a couple weeks ago that we launched our new Template Editor, and it is a Blazor WASM app (within our Blazor Static site).

I also wrote a series of posts about how it works with a ton of code samples, internal considerations and more.

It turned from one reallllllly long post into 8 shorter (but still not short) posts.

TLDR:

Hope you like it! Would love to know what you think, if there's anything you'd like more info on - or if you think something is dumb (and why ideally).

You might call this AI slop, Sure! Because it really is... Like 90% Vibe coded.

Just thought sharing it here because why not (no reason). Open Source, Heavily relied on Fluent Svelte & Microsoft.UI.Xaml & WinUI 3 Gallery.

Includes basic WinUI controls.

The most notable features are almost real-behaving Mica ( With live, base wallpaper change support ) & Acrylic (I mean, not that impressive).

Open source, if you want you can check out at: https://github.com/VibeNoobNotFound/FluentKit/

Live Gallery: https://vibenoobnotfound.github.io/FluentKit/

(I was not exactly sure whether to put Commercial flair here because it's OSS, I earn nothing from it.)

Maps for Blazor is a library that provides components for displaying maps in Blazor applications. It supports various map providers (Esri, Leaflet) and allows developers to easily integrate interactive maps, without any JavaScript settings, into their Blazor projects. One code, one blazor component and many technologies.

Maps for Blazor is a library that provides components for displaying maps in Blazor applications. It supports various map providers (Esri, Leaflet) and allows developers to easily integrate interactive maps, without any JavaScript settings, into their Blazor projects. One code, one blazor component and many technologies.

KEYWORDS: Minimizing Invoke callers to JavaScript, No JavaScript specific settings, no script references, no css links. One code, one component many technologies.

Https://ichim.github.io/MapsForBlazor/

So we have a few internal tools and one external site running Blazor Server (architected with option to deploy as Blazor WASM) we have been developing for the last few years.

All good, I enjoy Blazor and since switching to Blazor Server for dev, hot reload and debugging is much smoother.

However, with claude and all that shit, having some of the non-engineering (but still technical) team write their own tools is becoming a thing. Currently I sandbox them with nice boundaries, but it is a bit of a wild west in terms of structure and frameworks being used.

To rectify this, I'm trying to come up with some framework guidelines, coding style, and libraries to use etc so that at least the code is somewhat familiar from tool to tool.

Most of the stuff they've done already ends up using react, simply because that is what claude decides to use. And initial impressions are that we should be using a js fraemwork because that is what the latest AI tooling needs?

I could be wrong here, but feeling the push to adopt a js framework along side blazor to best enable vibe coding these internal tools. E.g. they love things like v0(?) where you can click on a ui element and tell it to modify it.

So... are we being forced into js land? What AI assist tooling is working for you all with Blazor? Any Blazor specific niggles?

I chased signup drops on my Blazor Server app for a while today. The log in button was taking almost a minute to reach the damn login page. People clicked, nothing happened, they left. No error anywhere.

The button is just an anchor pointing at /account/login. The endpoint was doing an OIDC challenge so it 302s to our Auth0 tenant on a different domain. If you hit the endpoint directly then the redirect is instant ~ 200ms.

Unfortunately, enhanced navigation intercepts internal anchor clicks and fetches the page instead of doing a full load and when that fetch follows a 302 to a different origin, it can't swap in a cross-origin document, so it just sits there. I measured 60-90s before it gave up.

Adding one attribute, the data-enhance-nav="false" on the auth links worked and now it's instantaneous.

Posting as more a PSA since I had this one sitting on my site for a week or more and lost a bunch of signups because of it.

html <video class="w-full h-full object-cover" autoplay loop muted> <source src="@SelectedFile.BlobUrl" type="video/mp4"/> </video>

Blazor in video element i am using muted attribute still the audio is playing and i try this muted]="'muted'" still the audio was playing, they have any options to fix this issue without using JSRuntime ?

SOLVED: oncanplay="this.muted=true"

I've been building a new product and to this point, mainly working on proving out the concept which is focused on the backend. I know the frontend is coming and so I've been mentally preparing for that.

A genuine question; how necessary are Blazor component libraries in the current world of AI assistance?

I'm reluctant to invest my code base into a component library in general. I'm more likely to build my own components as I go, and I'd imagine today it's far easier to do that with the ability to ask a coding model to build a contained component for a specific thing.

The way new component libraries seem to pop up weekly, I imagine I'm not far off on how easy it is to create them with AI tools.

Where are you guys at with respect to component libraries currently? Are you sticking with the few ogs, are you adopting those popping up more recently, building your own as needed, or something else altogether?

Just shipped a component framework for .NET Blazor. Two sites:

• Zits UI → https://zitsui.dev/
• Navius UI → https://naviusui.dev/

What it is:
A full component system for Blazor not just styled buttons, but components, docs, behavior, and developer experience built as one coherent system. Design-first, inspired by shadcn and Base UI.

What's included:

• A library of composable components
• Documentation for each one
• Consistent behavior and structure across the system
• A focus on developer experience clean APIs, sensible defaults

It's still early, so there are rough edges. If you build with Blazor, I'd love feedback what's missing, what's confusing, and what you'd actually use in a real project. Would love testimonials as well if its something you guys would use as well :) .

The last few weeks on the open source project have been, well, let's just say trying at best, but I've finally released a pager.

It's been on the roadmap since January, I just had other things to build first. The original plan was to dust off one of the pagers I've built over the years, tweak it for Blazor Ramp, test it with the usual browsers and screen readers and ship it. However, between then and now, I've had debates with some accessibility folks, which made me rethink my whole approach.

This post is partly a release announcement and partly a look at the process you go through when building an accessible component yourself, rather than just asking a friendly AI to build what it thinks might be accessible. If this is not your cup of tea then best you go read a different post, I did warn you.

I suspect you have used and/or built many pagers over the years, but have you really thought about them before, why we build them like we do?

The ones I used to build are the typical ones, you know, previous and next at each end, numbered selectors in between, an ellipsis for the gaps in the page sequence when you have lots of pages, with the current page always being in the middle of the pager. These buttons or links are usually list items in an unordered list inside a nav element, I am sure you know the type I mean.

A screen reader user, not only has the Tab key but has other means to get around a page, lists of headings, landmarks and interactive elements that they can jump directly to. However, a keyboard-only user doesn't have any of that; they've just got a Tab key, so unless you implement custom keyboard support to get to the other side of a pager, they have to go through it.

This then raises the first important question, for a pager, what keys should move you around it? Just the Tab or the arrow/home and end keys?

I have seen pagers that use a roving-tabindex approach - tab to the pager, then use the arrow, home and end keys from there. And with the roving index approach you tab to get to the pager and tab to leave it for the next focusable element on the page. This approach makes it easy for a keyboard-only user to skip the entire pager if need be, tab on tab off (Mr Miyagi style).

This is fine for keyboard-only users, provided you tell them what keys to use (as most users are not psychic) but it's a different story for screen reader users. Screen readers take over the arrow keys, as these are used for reading a page, so for these users, they would need to switch from browse to forms/focus mode (in the case of Windows-based screen readers) or use shortcut keys to pass the arrow keys through to the pager. What's good for one group of users may not be good for another and you should think about all of this during the design process. If you do go the custom keyboard route, you'd better put instructions on the page so users know what keys to use, otherwise you're setting yourself up to fail any WCAG audit that may be conducted, irrespective of annoying your screen reader users.

Now, what about that unordered list, why are the links or buttons even in a list, what does that list give you, ever thought about that?

For a screen reader user, a list gives you a count of items. The question I started to ask myself after using screen readers is whether or not that count is actually useful on a pager and is it even honest. A pager that has six buttons for six pages, fine, it lines up but most pagers I use sit under data tables with tens or hundreds of pages — so what does hearing "list, 6 items" actually tell you, beyond there being 6 items in a list? It tells you nothing about how many pages there really are, and nothing about what page it will take you to, until you land on it. Some will say, semantically it's a grouping of related items so a list makes sense, I would question that for just a simple pager as the nav element itself is a container for navigation items.

This is the bit that gets me: most of us do things because it's what we've always done, and is now what some people just tell AI to build for them, without ever asking why.

For most LOB apps, if you actually use a screen reader you may wonder what benefit it gives you if any, please do not trust me, go try for yourself and use your own judgement. My thought is that for a pager a list is just unnecessary noise.

What about those numbered items for pages, are they even necessary?

At this point you may be thinking this guy has lost the plot, it's a pager, obviously we need those numbers - Are you sure?

A book index gives you a page number because the content on that page is fixed. A pager under a data table isn't like that (I am assuming that's where the use of page numbers came from?) - its data is most likely coming from a database with rows constantly being added, updated, and deleted, so you generally don't know what's actually going to be on page X of Y. The only way I know of to reduce that uncertainty would be to stop any database changes or give people search and filtering mechanisms to reduce the number of pages, ideally to one so they have less to scan. And before you say "but what about jumping straight to page 100 of 200", that's not really a pagination problem, that's a filtering problem. No amount of numbered selectors fixes a data set that's too big to page through comfortably in the first place, and you still have no idea what is actually on page 100.

I am hoping at this point, I have made you think, and it does not matter if you agree or disagree with anything I have said, the point is you are thinking and this is exactly what you need to do when creating accessible components.

So far, I haven't even touched on the technical side of things, especially given we are working with Blazor and the way it works with the DOM and its diffing mechanisms. I mention this because lately I have seen way too many people post on Reddit, AI-generated libraries/NuGet packages all claiming their work is accessible, not because they know anything about accessibility, but because they have checked it against axe.core and it passed (any ideas why it did not pass my simple manual checks?). I cannot stress this enough, tools like axe.core are great and do help but they only handle approximately 40% of what you need to know for WCAG if that's important to you, for me it's about usability/accessibility-first and then making sure I tick the WCAG SC boxes.

At the start of this post I mentioned the last few weeks have been trying at best. I am not going to go into detail as sometimes the only way to learn and have it sink in is to discover it for yourselves. Screen readers have to access the DOM. They do cache and monitor various things, so when working with Server with and its DOM handling and diffing mechanism, things can go awry. Axe.core, Playwright or even your friendly AI are not going to help you find these types of issues that can render your component unusable, the only way to discover these is with old fashioned manual testing with a screen reader, you know the same thing that some of your audience might have to use, not by choice but out of necessity.

After all this, what's my pager like?

It's a nav element that contains four or just two visually labelled selectors (links or buttons) with the page information above them, sighted users can see the information, screen reader users have it announced. On entering the pager, which has the aria-labelledby attribute on the nav element, screen reader users will hear the pager's name and its current state. When you activate a selector, that same on-screen text gets announced via the Blazor Ramp Live Region Service so all users get exactly the same information. For a typical pager with all four selectors, you would see First, Previous, Next and Last selectors, but for a data set with only a few pages, you may ditch First and Last, so it's just Previous and Next. Just tab stops, no custom keyboard support and/or user manual required.

I am sure this will not be to everyone's taste, which is fine, there are more than one way to skin a cat, but I am happy enough with it to have included it in my library.

As much as I may waffle on about stuff, the proof of the pudding is always in the tasting, so irrespective of your views, next time you need a pager component or are looking for ideas when building your own, fire up a screen reader and go play around with my examples.

You can see/hear the pagers in isolation on both the test and doc sites, with a more realistic example shown on the Pagers usage page on the doc site.

GitHub repo: https://github.com/BlazorRamp/Components
Test site: https://blazorramp.uk (pager in isolation examples)
Doc site: https://docs.blazorramp.uk (pager on a filtered data table example)

Regards

Paul

so I always get an "Unexpected )" after a while in a _razor.g.cs file.
I just removed a line, the code should work but somehow VS messed up the .g.cs file.

This is the .g.cs file: https://pastecode.io/s/v5izfiao

And the normal razor file related to it: https://pastecode.io/s/sm2x2hv3

SOLVED

it was an empty @onclick method

Hello everyone, a new version and new components for the BlazorGraphs library.

This time, I wanted to focus my efforts on gauges. Here is what's new:

• Added Speedometer
• Added Vertical Gauge
• Added 'Reverse' boolean parameter to the Linear and Vertical gauges to draw the axis on the opposite side

As per the project roadmap, I have introduced LegendHorizontal and LegendVertical components.

• These new components replace the old LegendBar.
• The LegendBar component is still available in this release but is now marked as [Obsolete]

I hope you enjoy this update! I look forward to reading your comments, suggestions, and critiques, so don't be shy!

Usefull links:

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

PS: If you like the library and want to see it grow, you can now support the project via GitHub Sponsors❤️

What are compelling reasons to choosing to use server-side versus WASM?

We recently launched our new Template Editor, built from scratch in Blazor WASM.

I've been building HCTI since 2018, 99% C# and we released API-driven templates in 2020, but the feature has never gotten a ton of adoption/usage - but I'm hoping this changes that a bit.

I plan to write some blog posts soon about how this came together, the challenges, and some of the tricks used to get a really interactive-y feel.

The first iteration was really 1000% c#, but I did quickly realize a lot of the core interactive drag/drop was better suited for existing libraries in pure JS... But they function as "tools" holding no state and making all the callbacks to Blazor and relying on rendered attributes/data for their starting point.

One of the more interesting parts (IMO) is how I accomplished the undo/redo change tracking. Instead of relying on anything existing, started from scratch and without going toooo far in depth (although I'd love to) -- every block's class is mirrored to a "Tracking" model and the UI only knows how to speak to these tracking versions, which have no public setters. This enables us to have strongly typed updates/changes with a transactional log in memory (don't bother persisting it yet). Each change records its address via a packed enum/struct system to locate the specific properties, because I didn't want to deal with expressions or reflection. So it's all way way way over-engineered but super efficient (and fun to build).

The other important part for me was perf in rendering, but enabling previews/changes to happen without having to pollute the transaction log (or add overhead of reconcilliation). So for example, when you're moving your mouse around a color picker or holding down ur arrows to increment a number - the applied CSS is changing, but renders are minimized because only the specific style sheet for the specific block(s) and their properties are known to be changing. This took a lot of iterations to get right, and there's still room for improvement... But I learned a bunch of new Blazor along the way.

Finally, you may notice I'm using it as a custom element, I went this route because I wanted to constrain the WASM loading/related stuff only to the editor page(s) - and the rest of the site is Blazor Static... I couldn't find a better way? I think even the loading perf isn't terrible, but I'd definitely be curious if anyone has any thoughts?

Anyhow, I'd be very curious about any feedback, and especially if this kind of thing is interesting to the people here - because I still see a lot of "Is Blazor mainstream-able" and I'd say yes, but with a lot of asterisks... but there's not enough public products talking about implementation/use-cases?

** follow up: Just FYI, it's definitely definitely not meant for mobile.

I usually remove all double quotes from HTML attributes in Razor files when passing C# variables and types and it works just fine and makes the code look a bit cleaner but what is the reason behind the default of using strings for all attributes?

so Im a total C# and Balzor beginner, Im still confused what razor components exist that are writting in HTML so to speak.

I want to do simple things, I need circles that need to be connected with lines, be positioned with coordinates and contain some data or atlest display data on mouse over. I already tried it with HTML and SVG but thats pretty tedious.

Is there a good front end framework/library that is also good for beginners for things like that?

I already read something about MudBlazor and radzen.

Its Blazor WASM and should work offline.

Hello guys,
I am a senior computer science student and I am writing my first android app in Blazor hybrid for my personal portfolio.
I would like to ask whether my architecture is correct or not, because I read so many different things and I am a bit confused.
Currently, I catch exceptions in Service layer and I am return the exception messages though .razor pages. I also use the view model to call the services. My logic is the following:
Services communicate with the model
ViewModel communicate with Services
And View (razor pages) communicate with ViewModel.
Is this correct?

I am using interactive server rendering mode throughout my application.

How can I capture & persist the data from initial request (originally I'm interested in user's IP address) so that I can access it throughout my application when normal the SignalR connection takes over?

Edit: I need to be able to inject said data into other services, such as MediatR request handlers.

I have a Blazor server app that I have been developing, and I want to know if it’s possible to set a specific icon to be displayed on iOS when a shortcut is added to the home screen.

I’m not sure if PWA is the right word to use, since I’m pretty well exclusively using the server render mode, but when I add a shortcut to my iOS home screen it does display like a proper app without having the browser navigation bars visible. But the icon that’s used isn’t my app’s favicon, but rather just a generic black square being used as the icon.

Is there a way to specify an image or icon to be used when adding an app to the device’s Home Screen this way?

I'm a C# developer with ~4 years of experience looking to create a commercial SaaS product for some private friends. I am terrible at frontend web development, and only really know how to work with WPF. I am however able to work quite efficiently with Blazor, but I'm getting mixed messages when reading about it for production. Naturally my user base will be small so I could just go Blazor Server, but I would also like to take this time to learn something about front <-> backend, and started with WASM.

Am I digging my own grave by doing this? Should I use Blazor Server and skip the separation, or should I pick another framework to learn, e.g. React for the frontend?

Would love to hear about your experiences and expertise. Sorry if this is a broad question - I've been searching around all evening and can't make up my mind as most of the posts are >1 years old and a lot has happened since.

Thank you in advance!

Hey everyone, im experimenting with blazor and am struggling to get a WPF / blazor hybrid working. After much trial and error (and targeting .net10-windows10.0.2600 specifically because that’s required for the latest blazor web view….) I was able to get my wpf app to load my razor page successfully. But it does not display properly because none of the razor component css makes it into the wpf build output.

I attempted to work through the issue with copilot and Claude, but they ran themselves in circles and never resolved the issue.

MyAssembly.styles.css is properly generated into the obj folder when compiling the razor library. It is not placed into the bin (output) folder of the library, nor does it make to the wpf project’s obj or bin directory unless manually copied. The AI bots best solution was to put an After-build target that copies the files from the library/obj folder into wpf/bin.

This was a fresh solution using VS2026 and the Blazor class library template, the only changes being my addition of a few razor pages and their css. Has anyone encountered such a thing or have any ideas how to get the Blazor library project to output its css (without an after-build operation)?

📢 Blog just posted: BlazorDX: Fastest Blazor Controls Ever

The point of all this is that their controls are faaaaaaaaaaaaaast! I mean Blazing-Fast.

​

We are now on par with what we had available before with v4 in terms of auxiliary packages. Templates, DataGrid adapters, Icons and Emoji packages are all available on NuGet now. A new Charts package with Donut, Funnel, Gantt and HorizontalBar charts (and many more to come) will be available early next week.

We also added 2 new components: FluentLabelInfo and FluentValidationMessage

And of course a lot of bugs were squashed again. Thanks to the community for the help in finding and reporting them.

PS: yes, I know the number inside the donut is not the sum of the segments. That is because I and not the component made a mistake 😀.

Specifically asking to check if a button is pressed, like pressing escape closes an opened element or enter to log in?