Migrating from HTMX + Alpine to Datastar: A Field Guide

Migrating from HTMX + Alpine to Datastar: A Field Guide

Download PDF
Frontend

Summary

For about two years, my default stack for interactive server-rendered apps was HTMX for the network and Alpine.js for the sprinkles of client state. It worked. It also meant I was running two libraries that didn't know the other existed, and I was the glue holding them together.

I wrote about why I finally switched to Datastar. That post is the why. This one is the how. It's the guide I wish I'd had: a comprehensive, pattern-by-pattern map for moving an HTMX + Alpine app over to Datastar, with a bias toward Astro because that's where I live.

If you've got an existing app and you're wondering whether the migration is a weekend or a quarter, the short answer is: smaller than you think, and you can do it one feature at a time. Let's get into it.

Loading First, the mental model has to shift…
Loading Setup in Astro…
Loading The one syntax gotcha that will bite you…
Loading Mapping HTMX to Datastar…
Loading Mapping Alpine to Datastar…
Loading The Astro piece: SSR endpoints that stream…
Loading How to actually migrate: incrementally…
Loading The gotchas nobody warns you about…
Loading When you should *not* migrate…
Loading So, is it worth it?…
Loading The Migration Cheat Sheet…
Loading About Roger…

Do you like my content?

Sponsor Me On Github

Keep reading

Guide to datastar with Astro

Guide to datastar with Astro

Datastar is a hypermedia framework that gives you the backend reactivity of HTMX and the frontend reactivity of Alpine.js in a single, lightweight library. If you've been using HTMX and Alpine together, you know the dance: HTMX handles your server requests and DOM swaps, Alpine handles your client-side interactivity, and you're constantly context-switching between two different mental models. Datastar unifies both into one cohesive system using standard `data-*` HTML attributes and Server-Sent Events (SSE). ### One library to rule them all. In this guide I'll walk you through the building blocks of Datastar, show you how it compares to the HTMX + Alpine combo you already know, and demonstrate how to build interactive web applications with Astro on the backend. I will assume you're familiar with HTMX and Alpine.js concepts. Learn more on the official website at [https://data-star.dev](https://data-star.dev) and check out the [getting started guide](https://data-star.dev/guide/getting_started).

Read guide
GTM Engineering with Agents: A Field Guide to Automating the Funnel

GTM Engineering with Agents: A Field Guide to Automating the Funnel

Every go-to-market team is really running a handful of pipelines. Leads come in, get cleaned up, get scored, get worked, and either turn into revenue or quietly rot. Most of that work is mechanical, and most of it gets done by hand or by a tangle of point-to-point integrations that break the moment a vendor changes an endpoint. This guide takes the agentic approach the rest of the series is built on and points it straight at the funnel. The idea is simple: wrap every source you care about (your CRM, your enrichment providers, your email, your product analytics) as an MCP tool, then let small agents orchestrate the motions on top of them. Capture, enrichment, scoring, outbound, nurture, hygiene, forecasting, churn signals. One tool surface, many agents, each running on a schedule. It's hands-on. We build each motion as a small agent loop over MCP tools, wire them together with a cron, and put guardrails around the parts that can email a customer or overwrite a record. By the end you'll have a mental model for GTM as a system of agents, plus enough concrete patterns to start replacing the manual busywork on your own stack. It pairs with [MCP from Scratch](/guides/mcp-from-scratch) for the protocol and [Running the Fleet](/guides/running-the-fleet) for orchestration. This one is about pointing all of that at pipeline. _This is a living document and will be updated as the tools and patterns evolve._

Read guide