HDA is not a universal prescription. It is an architecture that fits a specific, large class of web applications extremely well and fits others poorly. This section draws the boundary and describes how to handle the cases that fall on either side of it.
Where HDA excels
HDA is the natural architecture for any application where the primary interaction is reading, writing, and navigating server-managed data. This covers:
Content-heavy sites. Media publications, documentation platforms, blogs, knowledge bases, wikis. The content lives on the server. The user reads it. The server renders HTML. There is nothing to manage on the client. These applications gain nothing from a client-side framework and pay a real cost in complexity if they adopt one.
CRUD applications. Admin panels, CRM systems, ERP interfaces, internal tools, project management dashboards. The interaction pattern is: list records, view a record, edit fields, save. Every step is a request-response cycle that maps directly onto HTTP. htmx’s partial page replacement handles the dynamic parts (inline editing, live search, filtered lists) without requiring client-side state.
Form-heavy workflows. Onboarding sequences, multi-step applications, surveys, checkout flows, approval processes. Forms are native HTML. Validation can happen both in the browser (HTML5 attributes) and on the server. The Post/Redirect/Get pattern handles submission cleanly. Adding htmx provides progressive enhancement: inline validation, step transitions without full page reloads, conditional form sections that load from the server based on prior answers.
E-commerce. Catalogue browsing, product search, filtering, cart management, checkout. These are read-heavy with occasional writes. The product page is server-rendered content. The cart is server-managed state. Search is a server query. The few interactive elements (add to cart, quantity adjustment) are simple HTTP requests that return HTML fragments. Shopify, the largest e-commerce platform, serves server-rendered pages.
Dashboards with periodic data updates. Reporting interfaces, analytics dashboards, monitoring views. If the data refreshes on a cadence measured in seconds or minutes (not milliseconds), server-sent events or periodic htmx polling deliver updates without client-side state management. A dashboard that refreshes every 30 seconds does not need React.
The common thread: the server owns the data, the user interacts through standard HTTP patterns (links, forms, requests), and the UI is a representation of server state rather than an independent application with its own state model.
Where SPAs are genuinely superior
Some applications have interaction models that fundamentally require client-side state. For these, HDA is the wrong tool.
Real-time collaborative editing. Google Docs, Figma, and Linear all maintain local copies of document state on the client. Edits apply optimistically, synchronise with the server via WebSockets, and reconcile conflicts using operational transformation or CRDTs. Figma’s multiplayer system gives each document its own server process and maintains persistent WebSocket connections for every collaborating client. This is architecturally incompatible with request-response HTML. The client must own state because it must apply edits instantly and resolve conflicts locally before the server confirms them.
Offline-first applications. Applications that must function without a network connection need a complete client-side data model, a sync engine, and a conflict resolution strategy. Service workers and IndexedDB provide the storage. CRDTs or similar structures handle the merge logic. The server is not available to render HTML when the user is on an aeroplane, so the client must be a self-sufficient application.
Continuous manipulation interfaces. Drawing tools (Figma, Excalidraw), music production software, video editors, spreadsheets with real-time formula recalculation. These require sub-16ms frame rendering for smooth interaction. A server round-trip is physically incompatible with the latency budget. Many of these applications bypass the DOM entirely, rendering to <canvas> or WebGL because even DOM manipulation is too slow for their needs. Google Docs moved to canvas-based rendering to sidestep DOM performance constraints. Quadratic, an open-source spreadsheet, chose WebGL over HTML because the DOM cannot handle millions of cells.
Extreme latency sensitivity. In-browser IDEs need sub-50ms keystroke-to-render times. Trading dashboards require sub-second updates with client-side filtering across large datasets. Audio applications measure latency in single-digit milliseconds. Any architecture that routes through the server for UI updates cannot meet these constraints.
The common thread across all four: the client must own state because the interaction model is physically incompatible with server round-trips. This is not a preference or a trade-off. It is a hard constraint imposed by latency, connectivity, or rendering performance.
Steelmanning client-side frameworks
The SPA vs HDA comparison covered the technical strengths of client-side frameworks in detail: component encapsulation, developer tooling, TypeScript type checking, and the component library ecosystem. Those arguments are real and worth reading.
Beyond the technical merits, there are organisational strengths that matter for team decisions:
Hiring and ecosystem momentum. React appears in roughly 45% of developer survey responses. Job postings that require React are abundant. Job postings that require htmx are nearly nonexistent. Adopting HDA means training developers rather than hiring specialists. The htmx learning curve is shallow (it is a small library over standard HTML), but the absence of a recognised hiring category creates friction for teams accustomed to recruiting by framework name.
Established patterns for complex UIs. The React ecosystem has converged on well-documented patterns for routing, data fetching, state management, and component composition. A developer joining a React project finds familiar structure. The HDA ecosystem has fewer established conventions, and the patterns vary more between projects. This is improving (htmx’s own documentation is thorough, and this guide exists for the Rust stack), but it is not yet at parity.
The component library gap. This is worth repeating because it is the most concrete practical difference. Libraries like shadcn/ui and Radix provide accessible, production-quality date pickers, command palettes, data tables, comboboxes, and dropdown menus with keyboard navigation, focus trapping, and screen reader support built in. The HDA ecosystem has nothing at comparable maturity. Building an accessible combobox from scratch is significant work. If your application needs several such components, the React ecosystem delivers them faster today.
These are genuine advantages, not strawmen. For many teams, the hiring argument alone outweighs the architectural benefits of HDA. The right response is not to dismiss these concerns but to weigh them honestly against the structural costs documented in the preceding sections.
The islands pattern
Most applications are not purely one thing. A CRUD application might need a rich text editor on one page. A dashboard might need a real-time chart alongside otherwise static report content. A form workflow might need an interactive date range picker.
The answer is not to adopt an SPA framework for the entire application because one page needs a complex widget. The answer is islands: HDA as the default architecture, with isolated client-side components for the specific interactions that require them.
The concept is straightforward. The server renders the page as HTML. Most of the page is standard hypermedia, driven by htmx. One region of the page mounts a standalone JavaScript component, a chart library, a rich text editor, a custom date picker, whatever the specific interaction demands. That component owns its own state and manages its own rendering within its DOM region. The rest of the page is unaware of it.
Events are the integration mechanism. The island communicates with the surrounding hypermedia through DOM events. When the rich text editor saves, it dispatches a custom event. An htmx attribute on a nearby element listens for that event and triggers a server request. When the server needs to update the island, it can return an HTML fragment containing updated data- attributes or a <script> tag that the island picks up. The boundary between hypermedia and non-hypermedia is clean: HTML and HTTP on one side, JavaScript and local state on the other, with events bridging the gap.
This is not a compromise. It is the architecturally correct approach: matching the interaction style to the interaction requirements. Using htmx for a contact list is correct. Using a JavaScript charting library for a real-time visualisation is also correct. Using React for both, or htmx for both, optimises for consistency at the expense of fitness.
The practical implication is that an HDA project should have a clear policy for when an island is warranted. A reasonable threshold: if a component requires persistent client-side state that cannot be modelled as a series of server requests, it is an island. If it can be expressed as “user acts, server responds with HTML,” it is hypermedia. Most features in most applications fall into the second category.
The web’s actual composition
SPA frameworks dominate developer discourse, conference talks, blog posts, job listings, and tutorial ecosystems. This creates a perception that SPAs are the standard way to build for the web.
The data tells a different story. According to W3Techs, React is used on roughly 6% of all websites. Angular and Vue each account for 1-2%. Even granting that some sites use client-side frameworks not captured by these measurements, and that some React sites are server-rendered via Next.js, the total share of websites running as true single-page applications is well under 10%.
The remaining 90%+ is WordPress (43% of all websites alone), other CMS platforms (Shopify, Squarespace, Wix, Drupal, Joomla), static sites, and traditional server-rendered applications. The web is overwhelmingly server-rendered, content-oriented, and CRUD-driven.
This matters because the architecture you choose should match the architecture your application actually needs, not the architecture that dominates Hacker News. If you are building a collaborative design tool, use a client-side framework. If you are building a content site, an admin panel, a form workflow, a dashboard, or an e-commerce platform, you are building the kind of application that constitutes the vast majority of the web. HDA is the architecture designed for that majority.