HTMX and Razor: Fast Server-Rendered UX Without SPA Overhead

Not every web product needs to start as a full single-page app.

For dashboards, admin panels, workflow tools, and form-heavy systems, I often prefer a simpler approach: let the server render reliable HTML, then use HTMX to update only the part of the page that changed.

The result can feel fast, stay maintainable, and avoid a lot of client-side complexity.

Why this pattern is useful

Many business applications are not animation-heavy consumer apps. They are built around:

• forms
• filters
• tables
• detail panels
• validation
• approvals
• search results
• operational dashboards

In those systems, the user mostly wants the interface to respond quickly and predictably.

HTMX works well because it lets the browser request small HTML fragments. Razor works well because it keeps server-side rendering close to the .NET application model. Together, they can create a polished experience without turning every screen into a client-state problem.

The 100ms mindset

Users do not care which framework rendered the page. They care whether the interaction feels immediate.

For small updates, I try to keep the response path tight:

• return partial HTML instead of a large JSON payload
• update only the changed region
• avoid unnecessary hydration
• cache stable page chrome
• keep validation feedback close to the form
• measure slow interactions instead of guessing

HTMX does not magically make an app fast. It encourages a smaller interaction model, and that is often enough to protect speed.

Patterns I keep using

The patterns that work best are simple:

• Razor partials for table rows, form sections, and detail panels
• normal links and forms first, HTMX as enhancement
• server-side validation that returns the updated form fragment
• small endpoints for focused UI changes
• progressive enhancement so the page remains understandable

This style is especially useful in enterprise systems because it reduces the number of places where business rules can drift.

The server already knows the validation rules, permissions, and workflow state. Returning the correct HTML from there keeps the interface honest.

When I would still choose a SPA

HTMX and Razor are not a universal answer.

I would still choose React, Angular, or another SPA approach when the product needs:

• complex client-side state
• offline-first behavior
• rich drag-and-drop interaction
• heavy real-time collaboration
• highly interactive canvas or editor surfaces
• a frontend team that needs strong component isolation

The point is not to avoid SPAs. The point is to avoid starting SPA-first when the product is mostly workflow and content.

Engineering takeaway

My rule is:

Start with the simplest architecture that can deliver a fast, maintainable user experience.

For many .NET products, Razor plus HTMX is that architecture. It keeps the system close to the backend, makes performance easier to reason about, and still gives users the smooth interactions they expect.

Related:

• .NET and Azure full-stack engineer
• Modular Monolith in .NET 9
• Writing archive