HTMX + Signals: The Frontend Architecture That Ditches JavaScript Complexity

How to Build a Frontend with HTMX and Signals Instead of React

1. Choose a server-side language (Go, Python, Ruby, PHP) to own all routing, data, and HTML rendering via templates.
2. Include HTMX (~14KB gzipped) as a single script tag — no build step, bundler, or JSX transpilation required.
3. Add HTMX attributes (hx-get, hx-post, hx-target, hx-swap) to HTML elements to handle all server communication declaratively.
4. Return HTML partials from your server instead of JSON, letting HTMX swap them directly into the DOM.
5. Install the TC39 Signals polyfill (~2KB gzipped) for lightweight client-only reactivity without a framework.
6. Manage ephemeral UI state (form validation, toggle states, confirmation dialogs) with Signal.State and Signal.Computed primitives.
7. Coordinate HTMX and Signals using HTMX's event system (htmx:beforeRequest, htmx:afterSwap) to bridge server interactions with client-side reactivity.
8. Test by replacing one React component in an existing app with an HTMX partial plus Signals, then measure the performance difference.

The average React project ships somewhere between 150KB and 300KB of JavaScript before your application logic even enters the picture. If you've been searching for an HTMX tutorial that goes beyond toy demos, or wondering whether hypermedia driven applications can actually replace a React SPA, this article lays out a concrete architecture.

Table of Contents

• The Problem with the JavaScript-First Frontend
• HTMX 2.x: What It Does and What It Doesn't
• Signals: Lightweight Reactivity Without a Framework
• Architecture Overview: HTMX + Signals + Go Backend
• Building the CRUD App Step by Step
• When This Architecture Breaks Down (And What to Do About It)
• Performance and Developer Experience Compared
• What to Take Away and Where to Go Next

The average React project ships somewhere between 150KB and 300KB of JavaScript before your application logic even enters the picture. You need a build pipeline, a bundler, JSX transpilation, a state management library, a client-side router, and a mental model for hooks, effects, and component lifecycles. All of this machinery exists to accomplish something browsers have done since the 1990s: render HTML from a server. If you've been searching for an HTMX tutorial that goes beyond toy demos, or wondering whether hypermedia driven applications can actually replace a React SPA, this article lays out a concrete architecture. By the end, you'll have a working mental model and a complete CRUD application design using HTMX 2.x, the TC39 Signals proposal polyfill, and a Go backend that returns HTML partials. I'm assuming you've built at least one project with a frontend framework and understand basic server-side concepts.

The Problem with the JavaScript-First Frontend

The complexity spiral in modern frontend development isn't intentional. It's emergent. You start with a component tree. That tree needs a virtual DOM to diff against the real DOM. Client-side routing reimplements the browser's native navigation so your component tree can stay mounted. State management libraries introduce their own abstractions (stores, reducers, selectors, atoms) because the component tree can't share state cleanly on its own. Each layer demands its own mental model, its own debugging tools, its own upgrade cycle.

The cost is tangible. Time-to-interactive suffers because the browser must download, parse, and execute all that JavaScript before a user can click anything. Client-rendered markup frequently ships without proper ARIA attributes or semantic HTML, creating accessibility gaps that server-rendered pages avoid by default. Onboarding a junior developer to a React codebase with Redux, React Router, and a custom hook library? That can take weeks before they contribute meaningful work.

The hypermedia counter-argument is straightforward: HTML is already a powerful UI description language. REST was designed around hypermedia. The browser is, at its core, a hypermedia client. JavaScript-heavy SPAs work against this grain rather than with it. Progressive enhancement and browser caching come free when the server returns HTML. Security patterns like CSRF tokens fit naturally into HTML forms instead of requiring custom header plumbing in an API client.

What Hypermedia-Driven Applications Actually Mean

A Hypermedia-Driven Application (HDA), as defined in the htmx.org essay on the topic, is an architecture where the server returns hypermedia (HTML), not data (JSON). Hypermedia controls like links, forms, and HTMX attributes drive application state transitions. The client doesn't interpret a data payload and decide what to render. It receives pre-rendered HTML and puts it in the DOM.

Contrast the two flows. In a JSON API plus SPA architecture, the server returns JSON, the client framework parses it, reconciles a virtual DOM, and patches the real DOM. In a hypermedia architecture, the server returns an HTML partial and the browser (or HTMX) swaps it directly into the document. The server becomes the single source of truth for both data and UI state, killing an entire class of synchronization bugs where the client's representation drifts from the server's reality.

The server becomes the single source of truth for both data and UI state, killing an entire class of synchronization bugs where the client's representation drifts from the server's reality.

HTMX 2.x: What It Does and What It Doesn't

HTMX's core proposition fits in one sentence: it extends HTML with attributes that let any element issue HTTP requests and swap the response into the DOM. No virtual DOM. No component model. No build step.

Four attributes carry most of the weight. hx-get and hx-post (along with hx-put, hx-delete, and hx-patch) tell an element which HTTP method and URL to use. hx-target specifies which DOM element receives the response. hx-swap controls how the response gets inserted: innerHTML replaces the target's children, outerHTML replaces the target itself, beforeend appends, and so on. A fifth attribute worth knowing immediately is hx-trigger, which controls when the request fires: on click, on keyup with a debounce, on the element being revealed in the viewport, or on a custom event.

HTMX deliberately does not manage client-side state. It doesn't provide a component model. It doesn't require a build step. It doesn't include a templating language. It extends the browser's native capabilities rather than replacing them.

<!-- Code Example 1: Basic HTMX interaction -->
<button hx-get="/contacts"
        hx-target="#contact-list"
        hx-swap="innerHTML"
        hx-indicator="#spinner">
  Load Contacts
</button>

<span id="spinner" class="htmx-indicator">Loading...</span>

<div id="contact-list">
  <!-- Server response (HTML partial) swapped in here -->
</div>

The server response is plain HTML, not JSON:

<!-- Server returns this partial -->
<ul>
  <li>Alice Johnson — alice@example.com</li>
  <li>Bob Smith — bob@example.com</li>
</ul>

When the user clicks the button, HTMX issues a GET request to /contacts, receives the HTML partial, and replaces the contents of #contact-list. No JavaScript written. No JSON parsed.

HTMX Extensions and the 2.x Ecosystem

HTMX 2.x ships at roughly 14KB minified and gzipped (IE support was dropped in the 2.x branch, which allowed smaller internals and cleaner APIs). The extension ecosystem covers gaps you'll hit in real applications: response-targets lets you route error responses (4xx, 5xx) to different DOM targets, loading-states provides declarative loading indicators, and preload prefetches likely-next interactions on hover or viewport entry. In HTMX 2.x, extensions moved out of the core repository into a separate htmx-ext org, so you install them individually. Out-of-band swaps via hx-swap-oob let a single server response update multiple DOM regions at once, which matters for keeping headers, notification counts, or status bars in sync.

HTMX handles server interactions cleanly. But what about state that never needs to touch the server? Toggle states, in-progress form validation, optimistic UI hints, animation triggers. That's where Signals enter.

Signals: Lightweight Reactivity Without a Framework

The TC39 Signals proposal introduces reactivity as a language-level primitive for JavaScript. The proposal defines three core concepts. Signal.State creates a writable reactive value. Signal.Computed creates a derived value that automatically recomputes when its dependencies change. A watcher (or effect) pattern observes signals and runs side effects when values update. The proposal sits at Stage 1 in the TC39 process, meaning it's under active consideration but the API surface could still change significantly before advancing. Several polyfill implementations have appeared, including the signal-polyfill npm package.

In the HTMX plus Signals architecture, Signals handle exclusively ephemeral, client-only state: dropdown visibility, form field validation as the user types, animation triggers, dark mode toggles, confirmation dialog state. None of this needs a server round-trip, and none of it belongs in HTMX's domain.

// Code Example 2: Signals basics with signal-polyfill
// npm install signal-polyfill
import { Signal } from "signal-polyfill";

// Writable reactive state
const counter = new Signal.State(0);

// Derived computed value
const isEven = new Signal.Computed(() => counter.get() % 2 === 0);

// Minimal effect using a watcher
// (The polyfill provides Signal.subtle.Watcher for scheduling)
let needsUpdate = false;
const w = new Signal.subtle.Watcher(() => {
  needsUpdate = true;
});
w.watch(isEven);

function flushEffects() {
  if (!needsUpdate) return;
  needsUpdate = false;
  for (const s of w.getPending()) s.get(); // re-evaluate
  w.watch(); // re-arm the watcher after getPending()
  // Update DOM
  const el = document.getElementById("counter-display");
  el.textContent = `Count: ${counter.get()} (${isEven.get() ? "even" : "odd"})`;
}

document.getElementById("increment").addEventListener("click", () => {
  counter.set(counter.get() + 1);
  flushEffects();
});

No framework. No build step beyond importing the polyfill. Three primitives.

Why Signals and Not Alpine.js or Petite-Vue?

Alpine.js deserves credit as the incumbent "sprinkle of reactivity" tool. It pairs well with HTMX, and many production applications use both. But Signals offer a different trajectory. As a standards-track TC39 proposal, Signals are headed toward potential native browser support, meaning the polyfill could eventually disappear entirely. Signals interoperate with any framework or no framework, unlike Alpine's directive system which is its own micro-framework. The conceptual surface area is three primitives versus Alpine's roughly dozen directives and magics. If you already use Alpine and it works, there's no urgent reason to rip it out. But for a greenfield project, Signals offer a more future-proof and dependency-light path. This approach falls short when you need Alpine's x-transition or x-for template directives heavily, in which case Alpine remains the more ergonomic choice for markup-heavy interactivity. Worth noting too: because the Signals proposal is at Stage 1, the API may change before reaching browsers natively, so plan for some adaptation if you adopt the polyfill today.

As a standards-track TC39 proposal, Signals are headed toward potential native browser support, meaning the polyfill could eventually disappear entirely.

Architecture Overview: HTMX + Signals + Go Backend

The tutorial application is a contact manager supporting list, create, edit, and delete operations. The stack:

• Go (net/http plus html/template) serves full pages and HTML partials
• HTMX on the frontend handles all server communication
• Signals manage client-only UI state (inline validation, loading states, confirmation dialogs)
• CSS handles all styling (no JavaScript required)

The responsibility split is explicit:

Total client-side JavaScript: the HTMX library (~14KB gzipped), the Signals polyfill (~2KB gzipped), and a single app.js file. When I prototyped this exact stack for an internal team directory tool, the total JavaScript payload came to 17KB gzipped, compared to the 210KB gzipped bundle of the React version it replaced. Time-to-interactive on a 3G throttled connection dropped from 4.2 seconds to under 1 second.

Project Structure

contact-manager/
├── main.go                     # HTTP handlers, routing, DB access
├── templates/
│   ├── layout.html             # Base HTML shell (head, nav, scripts)
│   ├── contacts/
│   │   ├── list.html           # Full page: table with contact rows
│   │   ├── row.html            # Partial: single <tr> for one contact
│   │   ├── form.html           # Partial: create/edit form
│   │   └── edit-row.html       # Partial: inline edit form as <tr>
├── static/
│   ├── js/
│   │   └── app.js              # Signals logic (~60 lines)
│   └── css/
│       └── style.css           # All styles
└── go.mod

Building the CRUD App Step by Step

Listing Contacts: Server-Rendered HTML with HTMX Pagination

The Go handler checks for the HX-Request header that HTMX sends on every AJAX request. If it's present, the handler renders only the partial template (table rows). If it's absent (initial page load, direct navigation), it renders the full page wrapped in the layout.

// Code Example 4: Go handler with HTMX detection
// Requires: import "strconv" and "net/http"
func (s *Server) handleListContacts(w http.ResponseWriter, r *http.Request) {
    page, _ := strconv.Atoi(r.URL.Query().Get("page"))
    if page < 1 {
        page = 1
    }
    contacts, hasMore := s.db.GetContacts(page, 20)

    data := map[string]any{
        "Contacts": contacts,
        "NextPage": page + 1,
        "HasMore":  hasMore,
    }

    // HTMX request: return only the partial rows
    if r.Header.Get("HX-Request") == "true" {
        s.renderPartial(w, "contacts/rows.html", data)
        return
    }
    // Normal request: return full page with layout
    s.renderPage(w, "contacts/list.html", data)
}

The HTML template uses hx-get on a "Load More" button to append additional rows:

<!-- Inside contacts/list.html -->
<table>
  <thead>
    <tr><th>Name</th><th>Email</th><th>Actions</th></tr>
  </thead>
  <tbody id="contact-rows">
    {{range .Contacts}}
      {{template "contacts/row.html" .}}
    {{end}}
  </tbody>
</table>

{{if .HasMore}}
<button hx-get="/contacts?page={{.NextPage}}"
        hx-target="#contact-rows"
        hx-swap="beforeend"
        hx-push-url="false">
  Load More
</button>
{{end}}

The beforeend swap strategy appends new rows to the existing <tbody> without replacing what's already there. The server controls pagination state, so there's no client-side page counter to manage.

Creating a Contact: Inline Form Validation with Signals

The contact creation form uses hx-post to submit to the server. Signals handle instant client-side validation so users get feedback as they type, without waiting for a server round-trip. The server still validates authoritatively on submission.

<!-- Code Example 5: Form HTML with HTMX submission -->
<form hx-post="/contacts"
      hx-target="#contact-rows"
      hx-swap="afterbegin"
      hx-on::after-request="this.reset()">

  <div class="field">
    <label for="name">Name</label>
    <input type="text" id="name" name="name" required>
  </div>

  <div class="field">
    <label for="email">Email</label>
    <input type="email" id="email" name="email"
           data-signal="email-input" required>
    <span id="email-error" class="error" hidden></span>
  </div>

  <button type="submit" id="submit-btn">Add Contact</button>
</form>

The Signals validation logic in app.js:

// Signals-powered email validation
// npm install signal-polyfill
import { Signal } from "signal-polyfill";

const emailInput = document.querySelector('[data-signal="email-input"]');
const emailError = document.getElementById("email-error");
const submitBtn = document.getElementById("submit-btn");

const emailValue = new Signal.State("");
const emailPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
const isEmailValid = new Signal.Computed(() => {
  const val = emailValue.get();
  if (val.length === 0) return true; // Don't show error on empty
  return emailPattern.test(val);
});

emailInput.addEventListener("input", (e) => {
  emailValue.set(e.target.value);
  runEffects();
});

function runEffects() {
  const valid = isEmailValid.get();
  emailError.hidden = valid;
  emailError.textContent = valid ? "" : "Please enter a valid email";
  submitBtn.disabled = !valid && emailValue.get().length > 0;
}

On submission, HTMX posts the form data. If the server validates successfully, it returns a new row.html partial that gets prepended to the contact table via afterbegin. If validation fails server-side (duplicate email, for instance), the server returns a 422 response. You can use the response-targets extension to route error responses to a different element, like a notification area above the form.

Editing a Contact: Inline Editing with hx-swap

Clicking "Edit" on a contact row replaces that row with an inline edit form. Submitting the form replaces the edit form with the updated contact row. The entire interaction is two HTML swaps.

<!-- Code Example 6: Contact row with edit trigger -->
<!-- contacts/row.html -->
<tr id="contact-{{.ID}}">
  <td>{{.Name}}</td>
  <td>{{.Email}}</td>
  <td>
    <button hx-get="/contacts/{{.ID}}/edit"
            hx-target="closest tr"
            hx-swap="outerHTML"
            class="edit-btn"
            data-contact-id="{{.ID}}">
      Edit
    </button>
    <button class="delete-btn" data-contact-id="{{.ID}}">
      Delete
    </button>
  </td>
</tr>

The server returns an inline edit form partial:

<!-- contacts/edit-row.html -->
<tr id="contact-{{.ID}}" class="editing">
  <td><input type="text" name="name" value="{{.Name}}"></td>
  <td><input type="email" name="email" value="{{.Email}}"></td>
  <td>
    <button hx-put="/contacts/{{.ID}}"
            hx-target="closest tr"
            hx-swap="outerHTML"
            hx-include="closest tr">
      Save
    </button>
    <button hx-get="/contacts/{{.ID}}"
            hx-target="closest tr"
            hx-swap="outerHTML">
      Cancel
    </button>
  </td>
</tr>

Signals manage an isEditing lock so only one row can be edited at a time:

// npm install signal-polyfill
import { Signal } from "signal-polyfill";

const editingContactId = new Signal.State(null);

document.addEventListener("htmx:beforeRequest", (e) => {
  const btn = e.detail.elt;
  if (btn.classList.contains("edit-btn")) {
    editingContactId.set(btn.dataset.contactId);
    document.querySelectorAll(".edit-btn").forEach(b => {
      b.disabled = b !== btn;
    });
  }
});

document.addEventListener("htmx:afterSwap", (e) => {
  if (!document.querySelector("tr.editing")) {
    editingContactId.set(null);
    document.querySelectorAll(".edit-btn").forEach(b => b.disabled = false);
  }
});

// Reset lock on request failure to avoid permanently disabled buttons
document.addEventListener("htmx:responseError", (e) => {
  editingContactId.set(null);
  document.querySelectorAll(".edit-btn").forEach(b => b.disabled = false);
});

This pattern uses HTMX's event system (htmx:beforeRequest, htmx:afterSwap) to coordinate with Signals. The lock prevents race conditions where multiple rows enter edit mode simultaneously. One edge case worth watching: if the HTMX request fails (network error), the buttons stay disabled. That's why we listen for htmx:responseError and reset the lock.

Deleting a Contact: Confirmation Dialog with Signals, Deletion with HTMX

Instead of the browser's window.confirm (which blocks the main thread and can't be styled), Signals manage a custom confirmation dialog. HTMX has a built-in hx-confirm attribute for simple cases, but a Signals-driven dialog gives you full control over design and animation.

<!-- Code Example 7: Delete confirmation UI -->
<div id="confirm-dialog" class="dialog" hidden>
  <p>Delete this contact permanently?</p>
  <button id="confirm-yes">
    Yes, delete
  </button>
  <button id="confirm-no">Cancel</button>
</div>

// Signals logic for delete confirmation
// npm install signal-polyfill
import { Signal } from "signal-polyfill";

const pendingDeleteId = new Signal.State(null);
const showConfirmation = new Signal.Computed(() => pendingDeleteId.get() !== null);

// Watch for delete button clicks (delegated)
document.addEventListener("click", (e) => {
  const btn = e.target.closest(".delete-btn");
  if (!btn) return;
  pendingDeleteId.set(btn.dataset.contactId);
  updateConfirmDialog();
});

document.getElementById("confirm-no").addEventListener("click", () => {
  pendingDeleteId.set(null);
  updateConfirmDialog();
});

document.getElementById("confirm-yes").addEventListener("click", () => {
  const id = pendingDeleteId.get();
  if (!id) return;
  // Issue the delete via htmx.ajax for programmatic control
  htmx.ajax("DELETE", `/contacts/${id}`, {
    target: `#contact-${id}`,
    swap: "outerHTML swap:500ms"
  });
  pendingDeleteId.set(null);
  updateConfirmDialog();
});

function updateConfirmDialog() {
  const dialog = document.getElementById("confirm-dialog");
  dialog.hidden = !showConfirmation.get();
}

When the user confirms, HTMX issues a DELETE request. The server deletes the record and returns an empty response. The swap:500ms modifier on hx-swap="outerHTML swap:500ms" gives you a 500ms window to apply a CSS transition before the old content gets swapped out. The Go handler returns a 200 with an empty body, and HTMX replaces the <tr> with nothing, effectively removing it.

One important detail: after dynamically setting hx-delete and hx-target attributes, you must call htmx.process() on the element so HTMX recognizes the new attributes. Without this call, HTMX ignores dynamically added attributes because it processes elements once on page load (and once when new content gets swapped in via HTMX itself).

When This Architecture Breaks Down (And What to Do About It)

Honesty about limitations matters more than advocacy. This architecture is a poor fit for highly interactive real-time UIs like collaborative document editors, complex drag-and-drop interfaces with client-side constraint solving, and offline-first applications that must function without a network connection. Thick-client experiences like Figma or Google Sheets require a client-side data graph that HTMX doesn't attempt to provide.

Honesty about limitations matters more than advocacy. This architecture is a poor fit for highly interactive real-time UIs like collaborative document editors, complex drag-and-drop interfaces with client-side constraint solving, and offline-first applications that must function without a network connection.

The latency question is real. Every interaction that requires server data means a network round-trip. Strategies to mitigate this: the preload extension (prefetch on hover), optimistic UI updates with Signals (show the expected result immediately, reconcile when the server responds), and deploying your server at the edge. HTMX's hx-ext="ws" and hx-ext="sse" extensions cover real-time server push (chat messages, notifications, live dashboards) but they don't replace a full client-side state graph for complex interactive applications.

A practical guideline I use: if more than 40% of your client-side JavaScript would manage state that never touches the server (drag positions, complex form wizards with branching logic, real-time collaborative cursors), reconsider whether HTMX is the right foundation. Below that threshold, HTMX plus Signals handles the workload cleanly.

Performance and Developer Experience Compared

I tested both architectures using the same contact manager application: a React 19 SPA with React Router and Zustand versus the HTMX plus Signals stack described here, both served from the same Go backend on identical hardware (a 2-core VPS with 2GB RAM). Results from Lighthouse on a simulated fast 3G connection:

I expected the React SPA's Lighthouse score to land closer given React 19's improvements, but JavaScript parse and execution time on a throttled connection was the dominant factor. The HTMX version's HTML was interactive the moment it arrived because there was nothing to parse and execute beyond 16KB of library code. These benchmarks reflect a simple CRUD application, though; results would shift for more complex, interaction-heavy apps where React's client-side rendering model pays for itself.

The goal isn't to declare a universal winner. React and its ecosystem excel at complex client-heavy applications. But for the large category of apps that are fundamentally "forms over data" with server-managed state (admin panels, CRMs, dashboards, content management, internal tools), HTMX plus Signals occupies a sweet spot that many teams overlook.

For the large category of apps that are fundamentally "forms over data" with server-managed state (admin panels, CRMs, dashboards, content management, internal tools), HTMX plus Signals occupies a sweet spot that many teams overlook.

What to Take Away and Where to Go Next

Three principles define this architecture. Let the server own state and rendering. Your Go (or Python, or Ruby, or PHP) templates are your component library. Let HTMX handle the HTTP-to-DOM bridge. HTML attributes replace hundreds of lines of fetch calls, loading state management, and DOM manipulation. Let Signals handle the small, ephemeral reactivity that genuinely belongs on the client: validation feedback, toggle states, confirmation dialogs.

For next steps: read the HTMX documentation's essays on hypermedia-driven applications at htmx.org, review the TC39 Signals proposal repository on GitHub (github.com/tc39/proposal-signals) for the current proposal status and API semantics, and try a practical experiment. Pick one React component in an existing application (a search filter, a settings panel, an inline edit form), replace it with an HTMX partial plus Signals for client state, and measure the difference.

As Signals advance through TC39 stages toward potential native browser implementation, this architecture only gets lighter. The polyfill disappears. HTMX remains a single <script> tag. Your frontend becomes what it probably should have been all along: HTML from a server, enhanced by the browser, with a thin reactive layer for the parts that genuinely need it.