Build a complete frontend in HTML

Update only what changed

Following an Unpoly link doesn't tear down the page. The server responds with HTML (a full page is fine), and Unpoly extracts the targeted fragment, discarding the rest:

The rest of the page stays: your scroll position, your focus, the form you were halfway through.

And because every response can be a full page, every URL keeps working on its own: in a new tab, for a bookmark, for a crawler. You don't build separate fragment endpoints. Unpoly works with the routes you already have. Rendering only the fragment is a simple, optional optimization; most screens never need it.

Built for tough requirements

These are the screens that usually get an app rewritten in React. With Unpoly they stay on your server. You render them as HTML and enhance them with a few attributes:

Escape hatches everywhere

When attributes aren't enough, you can recompose Unpoly's behavior using its extensive JavaScript API. Every attribute has a JavaScript twin: [up-submit] is up.submit(), and modifying attributes become options.

// Let the user create a record in an overlay, then use the result:
let { email } = await up.layer.ask({ url: '/users/new' })
up.submit('#invite-form', { params: { email } })

Along the way, Unpoly emits the events you wish the platform had:

Link

clicked following preloading lazy-loading

Form

submitting validating switching fields

Overlay

opened accepted dismissed

Fragment

loaded inserted keeping destroyed polling

Request

slow aborted offline recovered

History

URL changed going back

And your own JavaScript plugs in through compilers. Here a Google Map gets its center from the server:

<div class="map" up-data="{ lat: 50.9, lng: 7.4 }">
  <!-- chip: Map will appear here -->
</div>

up.compiler('.map', (element, data) => {
  var map = new google.maps.Map(element)
  map.setCenter(data)
})

The same pattern enhances existing tags, invents new elements, or mounts a whole React island.

Is Unpoly right for you?

There are two philosophies for building hypermedia-driven applications. htmx states its own beautifully:

Unpoly makes the opposite bet: the elements HTML already gave us are the right ones to make requests, because the whole web already knows what they mean. So instead of generalizing requests to any element, Unpoly makes links and forms more capable, with strong defaults for the cases every app hits.

Both approaches make sense. Small primitives give you maximum control and a minimal footprint. A higher-level layer gives you fewer attributes for common cases, with the edge cases already handled.

In production at