HN Debrief

Htmx 4.0

  • Programming
  • Web Development
  • Developer Tools
  • AI
  • Open Source

The release post for htmx 4.0 introduced the next major version of the HTML-first library for adding dynamic behavior to server-rendered pages. The biggest change people focused on was a breaking shift in attribute inheritance, which now moves toward explicit behavior by default. The post also added hx-live, Alpine compatibility helpers, migration notes, and “skills” files aimed at LLM-assisted development. A few commenters caught broken copy, busted anchors, and an accidentally borrowed release image, all of which were quickly fixed in public. That reinforced the project’s appeal for fans: opinionated, informal, and visibly maintained rather than polished into corporate blandness.

If you are building a mostly server-rendered product, htmx now looks even more viable as a default path, especially for small teams leaning on AI-assisted coding. If you are building a true client-side app with rich local state, treat htmx as the wrong tool and avoid forcing it into SPA-shaped work.

Discussion mood

Strongly positive. Most people like htmx as a simpler, HTML-first way to build interactive server-rendered apps, and they were upbeat about 4.0 despite minor launch-day glitches. The main caution came from engineers building true SPAs, who see htmx as a poor fit once rich client-side state becomes central.

Key insights

  1. 01

    Rails teams are replacing Turbo selectively

    One production pattern stood out from the generic praise. A Rails team said they swapped much of Hotwire Turbo for htmx because htmx lets the client decide when to fetch and replace content, instead of having the server push rendered fragments with replacement instructions. For live updates they kept ActionCable, but only send tiny JSON notifications that trigger htmx reloads for specific elements. That is a useful middle path. It keeps server-rendered HTML while avoiding the heavier server-driven stream model of Turbo Streams.

    If you already run Rails with Hotwire, you do not need an all-or-nothing rewrite to evaluate htmx. Try using htmx for pull-based updates and reserve websockets for lightweight invalidation events.

      Attribution:
    • dajonker #1
  2. 02

    Cheap HTML tests help coding agents

    The strongest AI-related point was not that models can write htmx syntax. It was that htmx apps are easier to test without spinning up a full browser automation stack for every interaction. When the UI contract is mostly HTML returned from the server, you can assert directly on markup and keep many tests fast and cheap. That makes coding agents more useful, because their output quality rises with tight test feedback loops.

    If your team is leaning on agentic development, optimize for stacks that let you write lots of fast deterministic tests. htmx is attractive when your UI can be validated as HTML instead of through fragile end-to-end flows.

      Attribution:
    • bluesnowmonkey #1
  3. 03

    The winning stack is boring on purpose

    The stack recommendations were remarkably consistent. People kept converging on server frameworks like Django or Go, a relational database like Postgres or SQLite, then htmx plus Alpine.js or light web components for the small amount of client behavior that remains. The point was not nostalgia. It was developer velocity from a single codebase, no build step, and fewer moving parts for both humans and LLMs.

    For internal tools, SaaS back offices, and CRUD-heavy products, consider a no-build server-rendered stack before defaulting to React. You may get faster delivery and lower maintenance with fewer frontend specialists.

      Attribution:
    • sgt #1
    • Analemma_ #1
    • WD-42 #1
    • farmeroy #1
  4. 04

    htmx is an architecture choice

    A useful correction cut through the 'LLMs can write JavaScript now' argument. htmx is not just a shorthand for avoiding hand-written JS. It pushes you toward server-sent documents and a different split of responsibilities between client and server. That means the comparison is not 'htmx versus generated JavaScript' so much as 'HTML-over-the-wire versus client-heavy app architecture.'

    When evaluating htmx, decide at the architecture level first. Do not compare it to raw JavaScript as if they solve the same design problem.

      Attribution:
    • Capricorn2481 #1
    • recursivedoubts #1
    • vb-8448 #1
  5. 05

    Explicit inheritance may trip existing AI habits

    One subtle consequence of 4.0 is that the move away from implicit attribute inheritance is good for readability, but it may briefly reduce how well existing models autocomplete old htmx patterns. That matters because a lot of current enthusiasm around htmx is tied to AI-assisted development. Cleaner semantics for humans can create short-term friction for models trained on earlier conventions.

    Expect code review and linting to matter more during the 4.0 migration if your team relies heavily on AI-generated snippets. Update prompts, examples, and internal docs so models learn the new explicit style quickly.

      Attribution:
    • recursivedoubts #1
    • jamesforestwest #1

Against the grain

  1. 01

    SPA-style products are still a bad fit

    For engineers building real client-side applications, htmx did not read as liberating. It read as moving presentation and state coordination back to the server in ways that feel clumsy once the UI has substantial local behavior. The sharpest version of this argument was not anti-htmx. It was that there are clear lanes. Static sites, lightly interactive server-rendered apps, and true client apps should not all share one default tool.

    If your product needs complex client-side state, offline behavior, or rich in-browser workflows, keep using a proper SPA stack. Do not pick htmx because it is fashionable if your app is clearly in the client-app lane.

      Attribution:
    • rednb #1
    • perardi #1
    • embedding-shape #1
  2. 02

    Alpine AJAX may be enough

    One commenter tried htmx 4 and concluded Alpine AJAX covered the needed feature set with a smaller footprint. Because htmx itself links to Alpine AJAX as a sanctioned alternative, this was not a random drive-by. It highlighted that some teams may not need the full htmx model if they already live in Alpine and only want a narrow slice of HTML-over-the-wire behavior.

    Before standardizing on htmx, check whether a smaller companion tool already fits your stack. If you are already committed to Alpine.js, Alpine AJAX might solve the immediate problem with less conceptual overhead.

      Attribution:
    • james2doyle #1
    • recursivedoubts #1
  3. 03

    Fixi may be the more important influence

    A commenter argued that Fixi, another project by the same author, is the deeper reason htmx 4 exists and may be the more powerful idea. That claim was not widely expanded, but it is a useful reminder that the release is part of a broader line of thinking about hypermedia and simpler web interaction models, not just a standalone library bump.

    If htmx’s direction resonates with you, look beyond the changelog and inspect adjacent projects like Fixi. The next architectural shift may come from those experiments before it lands in htmx proper.

      Attribution:
    • alsanan #1

In plain english

ActionCable ↩
Rails’ built-in framework for WebSocket-style real-time communication between server and browser.
Alpine.js ↩
A lightweight JavaScript framework that adds small interactive behaviors directly in HTML.
Angular ↩
A full-featured frontend framework for building client-side web applications, typically with TypeScript.
CRUD ↩
Create, read, update, delete, the basic operations behind many business applications.
Django ↩
A Python web framework for building server-rendered and database-backed applications.
Fixi ↩
A related project mentioned by commenters as an influence on htmx 4’s direction.
Hotwire ↩
A Rails-oriented set of tools for building interactive server-rendered apps without a heavy frontend framework.
HTML-over-the-wire ↩
An architecture where the server sends ready-to-render HTML fragments to the browser instead of JSON data for client-side rendering.
htmx ↩
A JavaScript library that lets HTML attributes trigger server requests and update parts of a page without building a full single-page app.
hx-live ↩
A new htmx 4 feature mentioned in the release that adds live updating behavior for page content.
JSON ↩
JavaScript Object Notation, a common text format for sending structured data between systems.
LLM ↩
Large Language Model, a machine learning model trained to generate and analyze human-like text.
Postgres ↩
PostgreSQL, a widely used open source relational database.
Rails ↩
Ruby on Rails, a web framework for building database-backed applications in Ruby.
React ↩
A popular JavaScript library for building user interfaces in the browser.
SPA ↩
Single-page application, a web app that loads once and then updates the interface mainly in the browser without full page reloads.
SQLite ↩
A lightweight relational database that runs from a local file and is often used for simple deployments or embedded apps.
Turbo ↩
Part of Hotwire that speeds up navigation and partial page updates in server-rendered web apps.
Turbo Streams ↩
A Hotwire mechanism where the server sends HTML fragments plus instructions telling the browser what to update.
web components ↩
A set of browser standards for creating reusable custom HTML elements with encapsulated behavior.

Reference links

Project and release context

Stack examples and alternatives

  • The HUGS stack blog post
    An example stack writeup pairing Go, SQLite, and htmx for simple interactive apps
  • RASX app framework
    A Rust, Axum, SQLite, and htmx stack example shared as a variant on the same idea
  • Alpine AJAX
    Suggested as a smaller alternative for teams that mainly want htmx-like features inside Alpine.js
  • Datastar
    Mentioned as a related alternative inspired by the same HTML-first direction
  • Fixi project
    Referenced as an adjacent project that may have influenced htmx 4’s design

Release jokes and side references