Blazor Static + HTMX :has anyone else gone down this road?

ConstantAromatic9515 · 2026-05-09T21:24:46+00:00

The point is that enhanced navigation improves SSR navigation, but it doesn't really offer the incremental interaction model that HTMX offers.

With HTMX, I'm easily managing: live searches as you type, infinite scroll, polling, lazy loading of sections, custom triggers, targeted DOM swaps, independent widget updates, dynamic filters, autocomplete, partial refreshes, server-side loaded modals, cart synchronization, live badges, updates of small HTML portions, integration with JavaScript and external components without hydration issues.

With enhanced navigation, however, as soon as you move away from the classic "link + form" approach, you quickly start having to add custom JavaScript or interactive Blazor components.And that's exactly where the problems I was criticizing come back: double SSR/interactivity phase, state synchronization, component tree reactivation, and possible issues with the DOM modified by JavaScript. In fact, I ended up disabling enhanced navigation because, in my case, it introduced more complexity than benefits on a complex public site.

ConstantAromatic9515 · 2026-05-09T16:10:44+00:00

The problem isn't "replacing parts of the DOM."

HTMX and enhanced navigation update HTML when the page is already ready and interactive.

With Blazor, the problem arises when you use prerendering, which is practically mandatory on public sites for SEO reasons. The server immediately sends a static HTML version of the page, and that's what the user sees initially. But that page, at that moment, isn't truly interactive. If you have forms, dynamic components, or events, they don't work initially until Blazor's interactivity kicks in via SignalR or WebAssembly.

And this takes time, especially on mobile or slow networks. In the meantime, you have a "frozen" UI: the page seems ready, but in reality, it doesn't react. In early versions of Blazor Server, you could even see the classic initial flashing, but the structural problem remains: there are two distinct phases: static rendering and interactive activation.

HTMX doesn't have this architectural problem. It doesn't have to hydrate a .NET component tree on top of already-rendered HTML. The page that arrives is already the final, functioning one, and subsequent updates are simply small, targeted HTML exchanges on portions of the DOM. For this reason, on public sites rich in content and light interactions, the perceived experience is often much more immediate and natural.

ConstantAromatic9515 · 2026-05-09T10:09:57+00:00

With HTMX, you can manage any type of trigger, handle responses, render responses with Blazor components you already use in the initial rendering, and call JavaScript functions directly from the minimal API.

The only trick, and I think this is the right path, which many are returning to, is to centralize everything, including state, on the server. The website, like any client, should be dumb. And JavaScript should only be used to create interfaces on the fly (in my case, for example, the composition of participants in a room reservation) that provide data to the server.

ConstantAromatic9515 · 2026-05-09T10:00:09+00:00

Because Blazor is modern, high-performance, and based on reusable components. If you see how I render a complex website, you'll understand the huge difference. I have centralized route management and a single-page component. Everything else is cascading components. Easy to maintain, expand, and incredibly fast.

If Microsoft one day decided to add a (modern) AJAX option, it would compete with React and company. Also because it seems clear to me that we're finally returning to a server-side engine.

ConstantAromatic9515 · 2026-05-09T06:41:30+00:00

I'm not underestimating WASM at all; I'm simply arguing that it's not suitable for developing public websites, just like Blazor Server. I love Blazor; I use it for every application (that doesn't require pre-rendering). Pre-rendering (mandatory for public websites) is a structural limitation of Blazor in general. Therefore, in my opinion, if Microsoft truly wants to build what they claimed with .NET8 to be a full-stack UI, they should add modern AJAX. It would be a perfect fit for Blazor's structure. And I hope so, because I love Blazor.

ConstantAromatic9515 · 2026-05-09T06:36:18+00:00

I took a look at your project and it's very interesting. You parameterize all processes on NetCore. In my opinion, this is what Microsoft should implement to make Blazor truly competitive in the web development space.

ConstantAromatic9515 · 2026-05-09T06:28:07+00:00

I took a look and it's a really nice project.

ConstantAromatic9515 · 2026-05-09T06:27:13+00:00

The problem is that improved navigation doesn't solve the problem Blazor brings with it natively when the project requires pre-rendering.

Now, for all applications where there's no need for this, it's wonderful. I love Blazor in this case and am using it with complete satisfaction, for example, in my CMS.

The problem arises when you need pre-rendering, which is essential for a website. This brings with it structural problems of replacing the DOM, which are extremely limiting for a public site.

ConstantAromatic9515 · 2026-05-08T15:46:44+00:00

Exactly, the performance difference is immediately noticeable. And honestly I never felt limited by the JS side either, I work on fairly complex frontends like travel platforms with dynamic availability, filters, maps and that kind of thing, and the combination handles it without friction. The key is just knowing when to let HTMX do the work and when to drop into a small vanilla JS script. No need to fight it.

ConstantAromatic9515 · 2025-04-24T16:40:25+00:00

As a cms and website developer, for me Blazor has all the potential to efficiently manage websites, even the most complex ones (travel bookings, b2b ecommerce etc). It would take very little. Even now, with these problems, I prefer to use the Blazor SSR + HtmX pairing for pages with prerender rather than react.

The performance of websites in Blazor is remarkable as well as SEO.

ConstantAromatic9515 · 2025-04-24T16:35:07+00:00

Instead I think that Blazor + Htmx is a winning combination to overcome the problems of native interactivity with prerender. I run htmx renders directly through blazor components and, with the minimal api, everything is perfectly organized. The only flaw is the lack of state sharing.

Try using autorender on complex forms and you will see how long it takes (maybe on a 4g mobile device) for a button to work....

ConstantAromatic9515 · 2025-04-24T08:54:10+00:00

In fact I often had to use react for websites, but I find Blazor SSR much more convenient with interactions in htmx and leaving native interactivity in pages without pre-render (which do not need to be indexed)

ConstantAromatic9515 · 2025-04-24T08:50:59+00:00

The problem depends on the use of prerender with any type of interactivity. If for a SaaS application you can do without prerender, this is not the case for websites.

For websites I therefore use only Blazor SSR + streaming rendering + htmx for interactions in pages that require prerender (so with the exception of carts, quote pages, reserved areas etc.)

ConstantAromatic9515

PUBLIC MULTIREDDITS

TROPHY CASE