Guide to datastar with Astro

Guide to datastar with Astro

Summary

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 and check out the getting started guide.

Loading Why Datastar?…
Loading The Core Idea…
Loading Installing Datastar…
Loading Frontend Reactivity…
Loading Backend Actions…
Loading Patching Elements…
Loading Patching Signals…
Loading Forms & Two-Way Binding…
Loading Indicators & CSS Classes…
Loading Using Datastar with Astro…
Loading Comparison Cheat Sheet…
Loading About Roger…

Do you like my content?

Sponsor Me On Github

Keep reading

Migrating from HTMX + Alpine to Datastar: A Field Guide

Migrating from HTMX + Alpine to Datastar: A Field Guide

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](https://rogerstringer.com/blog/why-im-migrating-from-htmx-alpine-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.

Read guide
AI Project Management: Shipping Software When Agents Write the Code

AI Project Management: Shipping Software When Agents Write the Code

Something strange happened to my job this year. The typing got cheap. An agent can turn a paragraph of intent into a working pull request while I refill my coffee, and yet the projects did not get faster. Not really. More code shipped, more PRs merged, and somehow the same features took roughly the same number of weeks to actually land. That gap is what this guide is about. When machines write the code, the scarce thing is no longer the writing. It's the specifying, the slicing-up, and the reviewing. Project management stopped being about handing out work and started being about feeding agents instructions clear enough that their output is worth keeping, then catching the parts that aren't. I've been running this way for a while now: specs before code, work cut into agent-sized pieces, a small fleet on separate worktrees, and a review loop that assumes the machine got something subtly wrong. This is the playbook I wish someone had handed me. It covers spec-driven development, decomposition, acceptance criteria an agent can test against, parallelism without chaos, the review loop, governance for code you didn't write, and the handful of metrics that tell you whether any of it is actually working. It's written for engineers and tech leads who already use agents to write code and want to run real projects with them, not demos. _This is a living document and will be updated as the tools and the workflows keep evolving._

Read guide