Post

statorjs.dev
@statorjs.dev

Stator 1.4 is out 🎉 Stator keeps your app state on the server — the browser just gets tiny DOM patches. New: defer() for slow APIs — fetches run in parallel and the page arrives complete. And live lists that update one field at a time. statorjs.dev #StatorJS #webdev

statorjs.devStator · the server-canonical JavaScript framework built on state machinesA web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.

1 repost3 likes

statorjs.dev
@statorjs.dev

Ever built a page that's mostly loading-state plumbing? With defer() you write the fetch and an HTML arm for the result. Every defer on the page runs in parallel - three slow APIs cost you the slowest one, not the sum. Failures get a fallback you wrote. No spinners to manage.

statorjs.dev
@statorjs.dev

Yes, today the page waits for the slowest defer. That's deliberate - it means a missing product can still be a real 404. Skeleton-then-stream is already designed as a drop-in: an optional pending arm on the same call, no rewrites. The plumbing shipped in 1.4.

statorjs.dev
@statorjs.dev

Ever had a live list flicker, or eat someone's focus mid-type? Stator rows update one field at a time. A vote comes in - the count and the bar move, nothing else does. Someone can be typing in one row while the rest keep updating around them.

statorjs.dev
@statorjs.dev

Demo time: use `npm create stator` to clone our live poll demo and open it in two tabs and vote. The other tab just updates. No websocket code, no client state to sync, no cache invalidation — the server already knows exactly what changed. Demo and docs: statorjs.dev

statorjs.devStator · the server-canonical JavaScript framework built on state machinesA web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.