# Day 12: Power-User Showcase — Pragmatic Systems That Feel Slightly Impossible

**Onboarding track:** Alpine.js + htmx, co-equal architecture  
**Verified baseline:** Alpine.js 3.15.12 and htmx 2.0.10 (stable)  
**Verification date:** 2026-07-19  
**Compatibility boundary:** htmx 4.0.0-beta5 is a prerelease line and is not the syntax baseline for these lessons.

## Purpose

Serve as a teaser for the unexpected power of disciplined Alpine and htmx composition. The examples are intentionally ambitious, but remain business-oriented, server-authoritative, progressively enhanced, and explainable.

## How to use this document

Budget a working day. Read the lessons in order, type the examples instead of copying them blindly, perform every mini-task, and finish the exit exercise without looking at the answer notes. The examples use a fictional server-rendered operations application, but the ownership rules are framework-neutral.

A successful day ends with three artifacts:

1. working markup or a small runnable page;
2. written ownership notes for each state value and DOM region;
3. answers to the comprehension check.

## Learning outcomes

You will be able to:

- compose many small, independently owned capabilities into one sophisticated workflow;
- build interfaces that feel application-like without a global client entity store;
- combine local-first interaction, server-settled truth, OOB projections, semantic events, history, polling, and JavaScript islands;
- recognize when a “bonkers” effect is actually several simple contracts;
- preserve debuggability while increasing power.

## 1. The paradox

The most surprising Alpine + htmx systems are not powered by one giant abstraction. They are powered by strict limits:

- server owns durable truth;
- htmx owns server communication and HTML installation;
- Alpine owns temporary local interaction;
- URLs own meaningful locations;
- controls carry submitted values;
- OOB swaps update related server projections;
- semantic events request or announce;
- plain JavaScript owns specialized rendering;
- every DOM region has one writer.

The “magic” is composition.

## 2. Showcase A: server-backed command palette

Imagine pressing `Ctrl+K` anywhere in an operations application.

Alpine owns:

- open/closed state;
- keyboard shortcut;
- active result index;
- focus;
- local query draft;
- selection highlight.

htmx owns:

- debounced server search;
- cancellation of stale requests;
- installation of result HTML.

Server owns:

- permissions;
- command availability;
- result ranking;
- route destinations.

URL owns the destination after activation.

### Stable shell

```html
<section
    x-data="commandPalette"
    @keydown.ctrl.k.window.prevent="open"
    @command-palette-close.window="close"
>
    <dialog x-ref="dialog" aria-labelledby="command-title">
        <h2 id="command-title">Command palette</h2>

        <form
            action="/commands"
            method="get"
            hx-get="/commands"
            hx-trigger="input changed delay:150ms from:#command-query"
            hx-target="#command-results"
            hx-sync="this:replace"
        >
            <input
                id="command-query"
                name="q"
                x-model="query"
                x-ref="query"
                autocomplete="off"
            >
        </form>

        <div
            id="command-results"
            @keydown.arrow-down.prevent="move(1)"
            @keydown.arrow-up.prevent="move(-1)"
            @keydown.enter.prevent="activate"
        >
            <!-- server-rendered, permission-filtered commands -->
        </div>
    </dialog>
</section>
```

The server returns links with real `href` values. htmx may boost navigation. Alpine never owns the command catalog.

### Why it feels wild

The palette has application-grade keyboard behavior and instant local presentation, but every result remains a server-authorized hypermedia control.

## 3. Showcase B: bulk-action transaction cockpit

A user selects 300 visible records, previews impact, confirms, submits one command, receives server validation, and sees five related projections update.

Alpine owns:

- temporary selection;
- toolbar visibility;
- local estimated count;
- confirmation dialog;
- reversible highlight.

Native controls own:

- submitted selected IDs;
- selected action;
- confirmation token.

htmx owns:

- submission;
- disabling;
- synchronization;
- primary replacement.

Server owns:

- permission per record;
- final eligible set;
- transaction;
- conflicts;
- audit log;
- canonical results.

OOB swaps update:

- result table;
- selected segment summary;
- outstanding total;
- audit activity count.

A fact event:

- closes confirmation;
- clears local selection;
- shows toast.

### Control bridge

```html
<section x-data="bulkSelection">
    <form
        id="bulk-action-form"
        action="/expenses/bulk"
        method="post"
        hx-post="/expenses/bulk"
        hx-target="#expense-results"
        hx-swap="outerHTML"
        hx-disabled-elt="find fieldset, find button[type='submit']"
        hx-sync="this:replace"
    >
        <fieldset>
            <input
                type="hidden"
                name="selected_ids"
                :value="selectedIds.join(',')"
            >

            <select name="action">
                <option value="approve">Approve</option>
                <option value="return">Return</option>
            </select>
        </fieldset>

        <button
            type="button"
            @click="openConfirmation"
            :disabled="selectedIds.length === 0"
        >
            Review <span x-text="selectedIds.length"></span> selected
        </button>

        <button
            x-ref="submit"
            type="submit"
            hidden
        >
            Submit
        </button>
    </form>

    <!-- local confirmation UI -->
</section>
```

Before dispatching the command, Alpine ensures the hidden control is current. The server ignores the client’s estimated eligibility and recalculates.

Response:

```html
<section id="expense-results">
    <!-- canonical rows and validation/conflict messages -->
</section>

<section id="expense-summary" hx-swap-oob="outerHTML">
    <!-- canonical totals -->
</section>

<span id="pending-count" hx-swap-oob="outerHTML">18</span>

<section id="audit-preview" hx-swap-oob="outerHTML">
    <!-- latest related audit entries -->
</section>
```

Header:

```http
HX-Trigger-After-Swap: {"bulk-action-completed":{"processed":282,"rejected":18}}
```

This feels like a client transaction engine. It is actually native controls, one server transaction, returned HTML, OOB projections, and one fact.

## 4. Showcase C: live incident command center

The page shows:

- live incident state;
- responders;
- timeline;
- command forms;
- local panel layout;
- a high-frequency telemetry chart;
- alerts;
- route-backed incident selection.

Ownership map:

| Capability | Owner |
| --- | --- |
| incident truth | server |
| route `/incidents/42` | URL/server |
| timeline HTML | htmx SSE or polling |
| responder count | OOB |
| local panel expansion | Alpine |
| muted alert preference | Alpine/browser storage |
| telemetry drawing | JavaScript island |
| telemetry snapshot label | server/htmx |
| toast presentation | Alpine |
| command authorization | server |

### Stable shell with multiple interiors

```html
<main x-data="{ timelineOpen: true, detailsOpen: true }">
    <section id="incident-status">
        <!-- primary server state -->
    </section>

    <aside x-cloak x-show="timelineOpen">
        <div id="incident-timeline">
            <!-- streamed/polled server HTML -->
        </div>
    </aside>

    <section x-ignore id="telemetry-chart">
        <!-- specialized renderer -->
    </section>

    <section x-cloak x-show="detailsOpen">
        <div id="incident-details"></div>
    </section>
</main>
```

One server event can update status and responder count, emit an alert fact, and send low-frequency chart metadata. The chart’s high-frequency samples use a specialized channel and renderer.

### Why it feels wild

The interface is live, stateful, navigable, and multi-region, yet no single client store tries to reconcile the whole incident.

## 5. Showcase D: optimistic-enough inventory allocation

A warehouse planner drags provisional allocations between orders.

Local behavior:

- drag ghost;
- keyboard reorder;
- provisional totals;
- conflict highlighting;
- reversible layout.

Submission:

- hidden named controls contain proposed order;
- htmx submits the completed proposal;
- `hx-sync` prevents contradictory overlapping proposals.

Server:

- validates inventory, locks, priorities, permissions;
- returns canonical allocation;
- identifies rejected moves;
- emits `allocation-settled`.

Flow:

```text
Alpine provisional move
    -> named controls updated
        -> allocation-commit-requested
            -> htmx POST
                -> server transaction
                    -> canonical board HTML
                    -> OOB capacity totals
                    -> allocation-settled fact
                        -> Alpine clears provisional markers
```

This is optimism without transferring authority.

Requirements:

- provisional state is visually distinct;
- keyboard alternative exists;
- rollback is automatic through returned HTML;
- repeated activation is controlled;
- conflict response explains rejected moves;
- no silent assumption that the server accepted the drag.

## 6. Showcase E: self-reconfiguring workflow console

A multi-step server workflow can return a different component shape at every step:

1. search and select a customer;
2. reveal local comparison controls;
3. submit a server choice;
4. return an authorization challenge;
5. poll a background calculation;
6. display a review form;
7. complete and update several projections.

A stable Alpine shell may retain:

- current panel visibility;
- help disclosure;
- local density;
- focus policy.

The htmx interior may transform from form to challenge to progress to review to result.

No client state machine must mirror every server step. The installed HTML is the workflow’s current representation.

## 7. The capstone: “one-page operations brain”

Build a page containing:

- route-backed record explorer;
- `Ctrl+K` command palette;
- active search with cancellation;
- bulk local selection;
- server-settled bulk action;
- remote dialog validation;
- OOB totals and counts;
- toast center;
- polling export job;
- isolated chart;
- history and direct routes;
- keyboard and focus policy;
- no global entity store.

The point is not to maximize attributes. The point is to keep every feature a small contract.

## 8. Capstone architecture map

```text
URL
  /operations?q=late&segment=enterprise&record=42

SERVER PAGE
  canonical route, permissions, complete HTML

ALPINE SHELLS
  command palette
  filter disclosure
  bulk selection
  remote dialog
  toast center
  local layout preferences

HTMX TARGETS
  #operation-results
  #record-details
  #dialog-body
  #export-job
  #incident-timeline

OOB TARGETS
  #result-count
  #financial-summary
  #unread-count

JS ISLANDS
  #telemetry-chart

EVENTS
  command-palette-close
  bulk-action-completed
  record-saved
  export-completed
```

No arrow should point to two authoritative owners for the same state.

## 9. “Bonkers” composition rules

### Rule 1: multiply capabilities, not authorities

Ten small components are safer than one universal store.

### Rule 2: returned HTML is a state machine representation

A server workflow can advance by returning the next complete component.

### Rule 3: local shells can outlive many server representations

A dialog, drawer, palette, or workspace can remain stable while its interior changes repeatedly.

### Rule 4: one transaction may have several authoritative projections

Use bounded OOB swaps.

### Rule 5: one fact may have several local listeners

A saved record may close a dialog and add a toast, provided listeners own only presentation.

### Rule 6: specialized islands are allowed

A chart or editor does not require converting the whole product into a client SPA.

### Rule 7: history keeps the system honest

Every meaningful location still works directly.

## 10. Failure containment

A sophisticated composition should degrade locally.

- command search failure does not destroy page state;
- bulk validation returns usable rows and messages;
- toast failure does not conceal the canonical result;
- chart failure does not remove server status text;
- polling failure exposes retry;
- modal validation does not close the modal;
- history restore can request the server;
- one widget teardown does not leak across pages.

Avoid a single global event bus or store whose failure disables the product.

## 11. Performance reasoning

Use the smallest proportionate mechanism:

- local show/hide: Alpine;
- server list: htmx fragment;
- related count: OOB;
- 2-second status: polling;
- sparse server pushes: SSE;
- high-frequency graphics: specialized renderer;
- navigation: URL;
- large client algorithm: isolated module.

Measure before adding morphing, preservation, prefetch, or streaming.

## 12. Power-user review questions

Before approving an advanced feature:

1. Can every state value name one authority?
2. Can every region name one writer?
3. Does every request have a route, target, response root, and race policy?
4. Does every event have one documented meaning?
5. Are OOB updates directly related?
6. Does every Alpine shell have a refresh test?
7. Does every external resource have cleanup?
8. Do direct URLs work?
9. Is focus predictable?
10. Can the server reject every optimistic assumption?
11. Can one failed component degrade independently?
12. Is a JavaScript island isolated rather than contagious?

## 13. Day lab: build the impossible-looking demo

Implement a reduced “operations brain” with:

- command palette;
- active search;
- selected rows;
- bulk approve;
- updated summary via OOB;
- remote validation dialog;
- success toast;
- export job polling;
- one simulated chart island.

Required proof:

- disable JavaScript and use the core search and submit routes;
- throttle network and demonstrate race safety;
- force validation and conflict;
- navigate Back/Forward;
- replace components repeatedly and inspect cleanup;
- show that no Alpine store contains server entities;
- show that each pushed URL works directly.

## Mini-tasks

### Task A: decompose apparent magic

Take a flashy workflow and list the small contracts that create it.

### Task B: reject authority creep

Find where a proposed global store duplicates server truth.

### Task C: choose transport

Choose polling, SSE, normal request, OOB, event, or JavaScript island for ten example updates.

### Task D: chaos test

Inject slow, failed, duplicated, and out-of-order responses. Record which owner restores correctness.

## Comprehension check

1. Why can a server-rendered workflow avoid a client state machine?
2. What makes a stable shell powerful?
3. How can one transaction update many projections without a client store?
4. What is “optimistic enough”?
5. Why should event facts remain small?
6. When is a JavaScript island the right escalation?
7. What role does history play in advanced systems?
8. Why is failure containment easier with explicit boundaries?
9. What creates the appearance of “magic”?
10. What is the non-negotiable rule at power-user scale?

## Cheat sheet

```text
COMPLEX UX != ONE COMPLEX OWNER

stable local shell
+ authoritative server interior
+ real controls
+ race-safe requests
+ bounded OOB projections
+ semantic facts
+ route-backed state
+ isolated specialized widgets
= application-grade behavior without duplicated authority
```

## Exit exercise

Write the architecture for a “financial close command center” that supports route-backed period selection, live job status, local comparison tools, remote approval dialogs, bulk actions, OOB financial totals, auditable server outcomes, keyboard command palette, and a specialized chart. Make it look outrageous. Keep every contract boring.

## Exit criteria

You complete the series when you can design an interface that feels far more dynamic than its architecture is complicated—and explain every line by state owner, DOM writer, request contract, lifecycle, event, and failure path.

## Official reference shelf

Use these as the authority when a project version or behavior is uncertain:

- Alpine.js documentation: https://alpinejs.dev/
- Alpine.js directives: https://alpinejs.dev/directives/
- Alpine.js `Alpine.data()` lifecycle and `destroy()`: https://alpinejs.dev/globals/alpine-data
- htmx 2.x documentation: https://htmx.org/docs/
- htmx 2.x reference: https://htmx.org/reference/
- htmx 2.x events: https://htmx.org/events/
- htmx 4 migration guide: https://four.htmx.org/migration-guide-htmx-4/

> Version note: These exercises use htmx 2.x event names such as `htmx:afterSwap` and `htmx:afterSettle`. htmx 4 changes event naming and several defaults. Do not mechanically port the examples without the migration guide.