htmx.landing Open editor

web/htmx

HTMX Playground for Hypermedia and HTML Fragments

Learn what hx-get and hx-swap actually do by watching them swap real HTML into a real page — with fragments living in your project instead of behind a server you have to stand up first.

Open the htmx editor Where do fragments come from?
libraryhtmx 2.x, ~14 KB
returnsHTML, not JSON
fragmentsfiles in the project
servernot required
index.htmlfragments/rows.html
<button
  hx-get="/fragments/rows.html"
  hx-target="#list"
  hx-swap="beforeend"
>
  Load more
</button>

<ul id="list"></ul>
swapped

01 platform

htmx needs something to fetch — here it is a file

This is the first thing to settle. htmx asks a server for HTML and swaps the answer into the page; without something to answer, none of the attributes do anything.

  • The fragment is a file in your project

    Point hx-get at /fragments/rows.html and htmx fetches it exactly as it would an endpoint. The preview serves a real directory, so the request is genuine rather than intercepted.

  • That covers the whole attribute surface

    hx-get, hx-post, hx-target, hx-swap, hx-trigger, hx-indicator and the swap positions all behave normally, because htmx cannot tell a file from a handler that returned the same bytes.

  • What it does not cover is state

    A fragment file returns the same HTML every time. A counter that increments, a row that disappears after deletion, an authenticated view — those need a process on the other end, and there is not one here.

  • Which is exactly the right split for learning it

    The hard part of htmx is not the server; it is the mental shift from returning JSON to returning HTML. That part is entirely learnable against files.

02 deep dive

Why the server returns HTML instead of JSON

htmx is small enough to read in an afternoon. The idea behind it is the part worth the time, and it inverts something most developers have assumed for a decade.

Any element can make a request. Historically only links and forms could. htmx generalises that: any element, any HTTP method, triggered by any event, targeting any part of the DOM.

The response is markup, not data. The server sends the HTML that should appear, so the client needs no template, no rendering layer and no model of what the data means.

That removes the state-sync problem rather than solving it. There is no client-side copy of the server's data to drift out of date, because the client never held one.

The cost is a round trip per interaction. That is the honest trade, and it is why htmx suits CRUD interfaces and dashboards better than a drawing tool or an offline-first app.

requests from
any element
response
HTML fragments
client state
none to sync
cost
a round trip
fragments/rows.html
<li class="row">
  <span>Ada Lovelace</span>
  <button hx-delete="/fragments/gone.html"
          hx-target="closest .row"
          hx-swap="outerHTML">Remove</button>
</li>

03 features

The attributes worth learning first

There are around thirty. These six carry most of what htmx is used for, and all of them work against fragment files.

  • hx-get and hx-post

    The request. Any element, any method — hx-put, hx-patch and hx-delete are there too and behave the same way.

  • hx-target

    Where the response lands. A selector, or closest, next and find for relative targets, which is what makes a row able to replace itself.

  • hx-swap

    How it lands: innerHTML, outerHTML, beforeend, afterbegin, delete, none. Choosing the wrong one is the most common early mistake and the easiest to see.

  • hx-trigger

    What starts it. Clicks by default, but also keyup changed delay:300ms for a search box, revealed for infinite scroll, or every 2s for polling.

  • hx-indicator

    What shows while it is in flight. A spinner that appears for the duration of the request, with no state variable to manage.

  • hx-boost

    Turns ordinary links and forms into AJAX requests, which is how an existing server-rendered site adopts htmx without rewriting its markup.

04 workflow

Watching a swap happen

One real sequence: a click, a fetch, a swap, and the mistake almost everybody makes on the way.

session
  • click → hx-get /fragments/rows.html
  • GET /fragments/rows.html → 200 · 412 bytes
  • hx-swap="innerHTML" replaced the list instead of appending
  • hx-swap="beforeend" → save
  • 3 rows appended · list intact

  • The request is a real HTTP request

    It appears in the network panel with a status and a size, because the preview serves files rather than intercepting the call.

  • Swap position is where people trip

    innerHTML replaces the target's contents, beforeend appends inside it, outerHTML replaces the element itself. Reading that list is slower than trying all three.

  • Nothing to restart

    Change the attribute, save, click again. There is no build and no server process holding stale state.

05 ecosystem

A hypermedia page among other stacks

An htmx page can sit beside a React component and a Python script; XCODX picks the right handling per file rather than per project.

  • React
  • Vue
  • Angular
  • Svelte
  • SolidJS
  • Lit
  • HTMX
  • Vite
  • TypeScript
  • JavaScript
  • HTML
  • CSS
  • SCSS
  • Less
  • Pug
  • Tailwind
  • Bootstrap
  • Vuetify
  • Ant Design
  • shadcn/ui
  • Phaser
  • Node.js
  • Python
  • Java
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • SQL
  • Bash

06 languages

Every language this editor understands

Highlighting and IntelliSense cover 70+ languages. These are the ones XCODX also compiles or executes for you.

Compiled in your browser11

Zero build step. Transform runs on a Web Worker, so typing never blocks.

  • JSX
  • TSX
  • TypeScript
  • Vue SFC
  • Svelte
  • Angular (JIT)
  • SolidJS
  • SCSS
  • Sass
  • Less
  • Pug

Rendered natively8

Straight to the live preview, no transform in the way.

  • HTML
  • CSS
  • JavaScript
  • JSON
  • Markdown
  • Jupyter (.ipynb)
  • SVG
  • YAML

Executed on demand22

70+ languages run through a self-hosted Piston engine. stdout, stderr, images and tracebacks land in the console.

  • Python
  • Java
  • C
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • Lua
  • Scala
  • Perl
  • Haskell
  • Elixir
  • Dart
  • R
  • Julia
  • SQLite
  • Bash
  • PowerShell

07 questions

htmx in a browser editor — common questions

The questions that decide whether this fits your work.

htmx needs a server. How does it work here?

Its requests point at HTML fragment files in your project. The preview serves a real directory, so hx-get="/fragments/rows.html" is a genuine HTTP request that returns genuine markup — htmx cannot tell it from an endpoint that returned the same bytes.

So what can I not do?

Anything that needs the response to change. A counter that increments, a row that stays deleted, a form that validates against a database, anything authenticated. A file returns the same HTML every time, and that is the honest limit.

Is it still useful for learning htmx, then?

Very. The hard part of htmx is not the backend — it is the shift from returning JSON and rendering it to returning HTML and swapping it. Every attribute, every swap position and every trigger behaves exactly as it will in production.

Which version of htmx is this?

htmx 2.x, the current line. It is around 14 KB and has no dependencies, which is a large part of why it is used at all — the whole library is smaller than most single components.

Can I combine it with Alpine.js or a CSS framework?

Yes. Install either from the npm panel or link a CDN build. htmx handles requests and swaps; something like Alpine handles the local interactivity that never needed a round trip, and the two compose without overlapping.

Does hx-boost work?

Yes, against pages in the project. It intercepts ordinary links and forms and swaps the body, which is how a server-rendered site usually adopts htmx — worth trying here before committing to it.

What about WebSockets and server-sent events?

Those are htmx extensions and they need a live connection to something, which a fragment file is not. The request-and-swap core is what this environment covers.

Where should I go when I need a real backend?

Anywhere that serves HTML: Django, Rails, Laravel, Go, Express. htmx is deliberately backend-agnostic — everything you write here moves across unchanged, because the attributes live in the markup rather than in a build.

Do I need to install anything to use XCODX Studio?

No. XCODX Studio is a browser-based IDE — the editor, the compilers and the preview all run client-side. There is no download, no package manager to set up and no configuration file to write. Opening the editor is the whole setup step.

Where is my code stored?

In your own browser. Projects, file history and Git objects live in local storage on your device and are never uploaded to a server. That also means XCODX works offline: it is a Progressive Web App, so you can install it and keep coding with no connection.

Is XCODX Studio free?

Yes. The editor, the live preview, the 70+ language runtimes, npm installs, Git and the integrated terminal are all free to use.

Can I use XCODX on a tablet or Chromebook?

Yes. The editor is a responsive web app, so a Chromebook, an iPad or an Android tablet gets the same compilers and the same preview a laptop does — there is no desktop-only build, because there is no build to install at all. The layout adapts to the screen rather than shrinking a desktop UI into it.

Can I export a project or move it to my own machine?

Yes. Export the whole project as a zip with its folder structure intact and open it locally, or commit it and push. It is ordinary source on disk from that point on — no proprietary format and no lock-in, which is also why importing an existing repository from GitHub works the same way in reverse.

Nothing to install

Try htmx now

Attributes swapping real HTML in seconds, with fragments in your project and no server to stand up first.

Open the htmx editor Read the docs