htmx and the business application someone must maintain

For an internal application built around forms, tables and approvals, server-rendered HTML with selective page updates is a strong starting point. It can let a small team maintain one main account of application state on the server, instead of coordinating a second substantial application in the browser. htmx is one way to build that interaction. The saving is a hypothesis about fewer responsibilities, not a measured promise that every project will cost a fraction as much.

The decision should start with who will change the software after its first release. An order screen may look modest, but it will acquire exceptions: partial deliveries, changed permissions and corrections to already approved records. Choose an architecture whose behaviour the future maintainer can follow through those changes.

A restrained release is useful evidence

The htmx 2.0.0 announcement, published on 17 June 2024, says most core functionality and the core API remained unchanged. Internet Explorer support ended, and extensions moved to separate repositories with independent versions. That is evidence of a compatibility approach, not proof of a five-year support commitment.

There were real migration details. The announcement calls out changed DELETE parameter handling and an SSE extension that needed upgrading. A small library can still break an application that depends on a changed default. Maintenance requires a dependency inventory and verification of the interactions actually used, regardless of how few lines of JavaScript the team wrote.

Reading the current documentation in November 2026 also requires care: its installation examples name later 2.x versions. They are not a record of exactly what a June 2024 installation contained. The relevant architectural idea is stable enough to discuss without copying a current snippet into a historical account: the server normally returns HTML, and the library places it in the selected part of the page.

Count the state the team must explain

Consider an illustrative purchase-approval tool. An employee submits a request, a manager approves it, and a table shows its status. With server-rendered responses, the server can validate the request and return the updated row or form, including any error message. The browser still has interaction state, but it need not keep a separate durable interpretation of the purchasing rules.

A single-page application can represent the same process well. It may also need decisions about cached records, optimistic updates and reconciliation when the server refuses a change. Those mechanisms can be worthwhile. They become a cost when the product does not need their user-facing advantages and the team has to maintain them anyway.

The meaningful comparison is therefore between complete designs for one workflow. Include authorization, validation errors, navigation and recovery after a lost connection. Comparing an unfinished HTML demo with a mature React application would tell you little about either approach's final maintenance burden.

Partial updates still need product design

Replacing a page fragment does not automatically make an interface understandable. After an approval fails, the manager needs to know whether the request remains pending and whether trying again could repeat an action. After a table changes, keyboard users need a sensible place to continue. A loading indicator must communicate that an operation is underway without implying it has succeeded.

These are proposed acceptance criteria for the purchase tool, not findings from a tested implementation. No htmx application was executed for this article. The point is to include these behaviours in the estimate instead of treating a successful fragment replacement as the finished feature.

Authorization must also be checked by the server for the operation being requested. Hiding an approval button is a presentation decision. It cannot establish that a different user is allowed to approve the underlying record. Returning HTML rather than JSON does not remove that responsibility or confer a general security advantage.

Where the browser should own more

The strongest case for a rich browser application is a product where substantial local state is the work itself. Think of an illustrative visual editor with selections, undo history and continuous manipulation, or an offline field application that must accept changes without a network connection. A server round trip for each meaningful interaction is a poor default for those requirements.

A native mobile application changes the calculation too. If web and mobile must consume a shared data API, HTML fragments alone do not provide that interface. You can keep a shared domain layer and expose both HTML and JSON, but then count both delivery surfaces in the design. htmx does not make that arrangement impossible; it reduces the force of the argument that one HTML interface is all the business needs.

An existing team with a well-understood SPA architecture may also deliver more cheaply by extending it. Replacing working expertise to satisfy an architectural preference can create the very maintenance cost the change was meant to avoid. Team continuity belongs in the estimate alongside library size.

Make the choice on a difficult screen

Before commissioning the full system, specify one representative screen with a meaningful failure case. Ask how a maintainer would change a validation rule, explain an authorization failure and recover from a repeated submission. Compare the necessary responsibilities rather than the apparent simplicity of the initial markup.

Use server-rendered partial updates when they keep those answers short and clear. Choose more browser state when the interaction genuinely requires it. A stable core API and separately versioned extensions are useful signals, but they do not decide the application architecture for you.

For custom software development, the useful outcome is an application the next maintainer can change confidently. Forms and tables often justify a simpler starting point than a separate browser application. That conclusion should survive the hardest required interaction before it becomes a budget assumption.