Alpine.js x-data: A Surprisingly Capable State Manager

React taught a generation of developers that local state means useState, side effects mean useEffect, and that nothing reaches a browser without a build pipeline. For single-page apps with complex routing and deep component trees, those tradeoffs make sense. But most server-rendered pages need far less: a live-updating ticker, a few reactive inputs, maybe a toggle. Reaching for React there is overkill.

Alpine.js x-data packs state, computed properties, methods, and lifecycle hooks into a single HTML attribute, all reactive, with no build step. I use it in production on BudgetFlow.

The Pattern: One Attribute, Everything Included

BudgetFlow has an interactive article that compares your wealth to Elon Musk's in real time. A ticker counts his earnings per second, inputs let you adjust your own numbers, and computed values update instantly. This is the actual x-data block running it:

<ui-container
	x-data="{
		wealth_elon: 716000000000,
		wealth_you: 100000,
		income_you: 6000,
		return_rate: 0.05,

		coffee_price: 5,
		iphone: 1200,
		tesla_price: 40000,

		startTime: Date.now(),
		elapsedSeconds: 0,

		formatWithCommas(value) {
			return value.toString().replace(/\B(?=(\d{3})+(?!\d))/g, ',');
		},
		parseNumber(value) {
			return parseFloat(value.replace(/,/g, '') || 0);
		},
		updateInput(event, propertyName) {
			const rawValue = this.parseNumber(event.target.value);
			this[propertyName] = rawValue;
			event.target.value = this.formatWithCommas(rawValue);
		},
		init() {
			setInterval(() => {
				this.elapsedSeconds = (Date.now() - this.startTime) / 1000;
			}, 100);
		},
		get elon_annual_income() { return this.wealth_elon * this.return_rate; },
		get elon_secondly_income() {
			return this.elon_annual_income / (365*24*60*60);
		},
		get you_annual_income() { return this.income_you * 12; },
		get you_secondly_income() {
			return this.you_annual_income / (365*24*60*60);
		}
	}"
>

That single object literal contains state, computed properties, methods, and a lifecycle hook. You don't need imports, component files, or a class hierarchy.

Reactive Bindings

Alpine gives you a handful of directives that bind the DOM to your x-data object. The ticker that shows Elon's earnings since page load:

<h2 class="income-ticker">
	$<span x-text="formatWithCommas(
		(elapsedSeconds * elon_secondly_income).toFixed(2)
	)"></span>
</h2>

x-text evaluates the expression and sets the element's text content. Every time elapsedSeconds changes (every 100ms via the setInterval in init()), Alpine re-evaluates the expression and updates the DOM. There's no diffing algorithm or virtual DOM involved. Under the hood, it's a JavaScript Proxy watching for property mutations.

User inputs bind with @input (shorthand for x-on:input):

<input
	type="text"
	value="100,000"
	@input="updateInput($event, 'wealth_you')"
/>

Type a number, the method parses it, updates the reactive property, reformats the display. Every computed property that depends on wealth_you recalculates instantly. The comparison text at the bottom of the page updates without touching the server.

Computed Properties via Getters

Most people don't expect this to work, but JavaScript getters are fully supported inside x-data:

get elon_annual_income() { return this.wealth_elon * this.return_rate; },
get elon_secondly_income() {
	return this.elon_annual_income / (365*24*60*60);
}

These are derived values. Change wealth_elon or return_rate, and every getter in the dependency chain recalculates. In the template, you reference them like regular properties:

<span x-text="(income_you / elon_secondly_income).toFixed(2)"></span>

You skip useMemo, useCallback, and the dependency arrays that come with them. Getters give you the same result with less ceremony.

Now Do It in React

Same feature, for comparison, in React:

import { useState, useEffect } from "react";

function ElonComparison() {
	const [wealthElon, setWealthElon] = useState(716000000000);
	const [wealthYou, setWealthYou] = useState(100000);
	const [incomeYou, setIncomeYou] = useState(6000);
	const [returnRate] = useState(0.05);
	const [elapsedSeconds, setElapsedSeconds] = useState(0);
	const [startTime] = useState(Date.now());

	useEffect(() => {
		const interval = setInterval(() => {
			setElapsedSeconds((Date.now() - startTime) / 1000);
		}, 100);
		return () => clearInterval(interval);
	}, [startTime]);

	const elonAnnualIncome = wealthElon * returnRate;
	const elonSecondlyIncome = elonAnnualIncome / (365 * 24 * 60 * 60);
	const youAnnualIncome = incomeYou * 12;

	const formatWithCommas = (value) =>
		value.toString().replace(/\B(?=(\d{3})+(?!\d))/g, ",");

	const handleInput = (e, setter) => {
		const raw = parseFloat(e.target.value.replace(/,/g, "") || 0);
		setter(raw);
		e.target.value = formatWithCommas(raw);
	};

	return (
		<div>
			<h2 className="income-ticker">
				${formatWithCommas(
					(elapsedSeconds * elonSecondlyIncome).toFixed(2)
				)}
			</h2>
			<input
				type="text"
				defaultValue="100,000"
				onInput={(e) => handleInput(e, setWealthYou)}
			/>
			<span>
				{(incomeYou / elonSecondlyIncome).toFixed(2)}
			</span>
		</div>
	);
}

export default ElonComparison;

The behavior is identical, but look at what you're carrying now. Six useState calls, each producing a getter/setter pair. A useEffect with a cleanup function for the interval. JSX that needs compilation, a module that needs bundling, and a component that needs mounting into a DOM node managed by React's reconciler.

The Alpine version slots into existing server-rendered HTML. React demands ownership of the DOM tree it renders into.

Where Alpine Fits

Alpine is built for local, client-side interactivity that doesn't need a server round-trip. The kind of thing that would be a <script> tag in 2010 and a React component in 2020:

• Calculators and unit converters
• Toggle states (show/hide, tabs, accordions)
• Client-side filtering and sorting
• Form validation and conditional fields
• Animations triggered by user interaction
• Live tickers (like the earnings counter above)

All cases where data lives on the client and DOM updates are local. You're not making API calls or syncing server state.

Where It Doesn't Fit

Alpine has no component model, which means no props, no context API, no component tree. If you need two separate x-data scopes to communicate, you're reaching for $dispatch and custom events, which works but gets awkward fast.

Concretely: complex multi-step wizards with shared state across steps, data grids with virtual scrolling, drag-and-drop interfaces with undo/redo. These need a framework that manages component relationships. Alpine doesn't pretend to be that.

The Dream Team: Alpine + htmx

The reason this stack works is that htmx and Alpine own completely different responsibilities. htmx handles server state, Alpine handles client state, and they don't overlap.

When a user creates a budget in BudgetFlow, htmx sends a POST, the server responds with HTML, and htmx swaps it into the page. When that same user plays with the Elon Musk comparison widget, Alpine updates the DOM from local data. The two tools don't know about each other, and they don't need to.

React tries to own both sides. It handles server data through useEffect and fetch calls (or React Query, or SWR, or Server Components), local state through useState, and the DOM through its virtual DOM reconciler. That's a lot of machinery for an app where the server already renders the HTML.

The htmx + Alpine split works because it matches the actual boundary: some state belongs to the server, some belongs to the client. Both tools work by adding attributes to existing HTML instead of replacing it, which makes coexistence easy.