Sign in

statorjs.dev

@statorjs.dev
11 followers 4 following 29 posts
PostsRepliesMedia
statorjs.dev @statorjs.dev · 20/08/2026
Also along the way: .env loading with zero dependencies, signed cookies for auth handshakes, and live pages that hard-reload when they reconnect to a newer deploy. Every release has its story in the changelog 📝 docs.statorjs.dev/changelog/ 💻 pnpm create stator my-app
docs.statorjs.dev
Changelog
Release stories for @statorjs/stator — the arc of each minor. Per-package changelogs (the complete mechanical record) live in each package's own CHANGELOG.md.
010
statorjs.dev @statorjs.dev · 20/08/2026
2.5 itself adds the seam the CLI made necessary: boot.ts. defineBoot hosts server-lifetime work, query config at startup, run the poll or subscription that feeds your machines, tear down on shutdown. Boot is a source, not a controller. Policy stays in the machine, where it's testable.
210
statorjs.dev @statorjs.dev · 20/08/2026
The hand-written server.ts is gone. stator dev / build / start / check / test, with typed config in stator.config.ts. Our favorite part: stator build runs stator check first, a full server-stack typecheck, so a broken server import fails the build instead of shipping silently.
Screenshot of Stator's new build-time type checking errors
100
statorjs.dev @statorjs.dev · 20/08/2026
Middleware is a file, not config. middleware.ts covers every route by position, and the framework's security defaults always run first. Stator's built-in CSRF guard was the proving case: it's now crossSiteGuard(), first-party middleware alongside cors() and securityHeaders().
100
statorjs.dev @statorjs.dev · 20/08/2026
The security round: a machine can now declare events no client may ever send. serverOnly: ['CHARGE_APPROVED'] A forged approval is rejected at the wire, never processed as truth. The machine definition stays the complete list of what can happen, and now of who may cause it.
100
statorjs.dev @statorjs.dev · 20/08/2026
Confirmed: version numbers really are cheap 🏷️ #StatorJS 2.5 is out 🚀 five minors since 2.0. Each one small, but together they round out what production apps need: real security primitives, first-party middleware, and a CLI that owns the toolchain. statorjs.dev
statorjs.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
122
Reposted by @statorjs.dev
nate moore @natemoo.re · 14/08/2026
working with @frontside.com (@cogentdude.com and @jacobbolda.com) on this rendering engine has been stellar, and i'm thrilled they've joined the @bomb.sh core team. better together! tty is a smaller, faster, more powerful terminal rendering engine, and it's just the start bomb.sh/docs/tty
bomb.sh
Getting Started
Learn how to get started with @bomb.sh/tty
0115
Reposted by @statorjs.dev
Tony Sullivan @tonysull.co · 15/08/2026
🌶️ Server components don't have to be hard. It really doesn't have to be a big deal. Client code goes in a <script>. Period. No "use client;" pragma. No "/client" imports. No debating whether to "useServerProps". Browsers know <script>'s. Put client stuff there. @statorjs.dev #webdev #StatorJS
031
statorjs.dev @statorjs.dev · 11/08/2026
Why? Two-way binding wrote state through a side channel that skipped guards and types. In 2.0 the machine definition is the complete list of what can happen. pnpm create stator my-app --template registration Our codebase held exactly one two-way binding. Migration was one line ✂️
010
statorjs.dev @statorjs.dev · 11/08/2026
Forms without a binding layer: The input owns your draft, with cursor, IME, and undo all native. A typed event commits it, and a refused commit keeps your typing. Pre-fill is just server rendering: value and checked are attributes, and false renders absent. No echo loop to manage.
100
statorjs.dev @statorjs.dev · 11/08/2026
The same API everywhere: `<p>{read(cart, c => c.itemCount)}</p>` Server machine → updates the client by wire patch. Client machine in an island → updates by local subscription. The compiler routes it by where the machine lives. You stop thinking about which side you're on.
100
statorjs.dev @statorjs.dev · 11/08/2026
Stator 2.0 is out 🎉 🌶️ We removed two-way binding read() is now the only display primitive. Its the same in a server template or a client island - the compiler picks the right mechanism for each. Writes are typed events that machines declares and the compiler checks statorjs.dev #StatorJS #webdev
statorjs.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
194
statorjs.dev @statorjs.dev · 30/07/2026
Server-originated events round it out: dispatchToApp now lives on the app object, dev server included, so a payment webhook becomes a route that dispatches one typed event and every live page reading that machine updates. Full release notes: docs.statorjs.dev #buildinpublic #webdev #StatorJS
docs.statorjs.dev
Stator
A server-canonical web framework where state machines are the unit of composition and the DOM renders where its state lives.
020
statorjs.dev @statorjs.dev · 30/07/2026
APIs can be viewer-aware too. The with-auth example serves its notice board at /api/notices, where members see everything and visitors only the public notices. Identity comes from the session's own auth machine rather than the request, so there's nothing in a payload to forge.
100
statorjs.dev @statorjs.dev · 30/07/2026
Feeds fall out of the same idea. Name a route file rss.xml.ts and the .xml carries into the URL and the content type. The guestbook example ships one. The book machine that renders the page also feeds RSS readers and pushes live updates over SSE, all from one definition of the data.
100
statorjs.dev @statorjs.dev · 30/07/2026
A consumer API used to mean a second data path beside your pages. In 1.7 it's one route file: export a GET, read your machines, return a value, and Stator serves it as JSON with an ETag. What the page shows and what the API returns can't drift, they're read from the same state.
100
statorjs.dev @statorjs.dev · 30/07/2026
Stator 1.7 is out 🚀 Stator renders your pages on the server, straight from the state machines that hold your logic. As of today those same machines can serve your JSON API, your RSS feed, and anything else that speaks HTTP. No second data layer, nothing to keep in sync. statorjs.dev
statorjs.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
142
Reposted by @statorjs.dev
Tony Sullivan @tonysull.co · 28/07/2026
13 years later and I'm still building pivots, live tiles, and appbars. A Windows Phone-style weather app with flip tiles, a location pivot, the app bar and its drawer, everything rendered by the server, running on @statorjs.dev , the web framework I've been building. #webdev #StatorJS
341
statorjs.dev @statorjs.dev · 27/07/2026
Live pages heal in place. Kill the server under a live dashboard and bring it back — the SSE channel reopens and a full resync converges the DOM. Scroll, focus, and island state all survive. One attribute on <html> turns an offline banner into a CSS rule, not a component.
000
statorjs.dev @statorjs.dev · 27/07/2026
A tap on train wifi now lands. Every event carries an idempotency key. Network drops retry with backoff, and if the first attempt actually committed, the server replays the original response instead of applying it twice. A cart button that can't double-add, with no app code.
100
statorjs.dev @statorjs.dev · 27/07/2026
Loading states without state. While an event is in flight, the runtime marks the element: button[data-stator-pending] { opacity: .6 } One rule covers every button in the app. No loading flags, no disabled bookkeeping, and it clears correctly on every failure path.
100
statorjs.dev @statorjs.dev · 27/07/2026
🚀 Stator 1.6 is out Flaky-network resilience, built in: in-flight and connection state as data attributes, event POSTs that retry safely behind idempotency keys, and live pages that resync in place after a dropped connection — no reload. statorjs.dev #javascript #webdev #StatorJS
statorjs.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
141
statorjs.dev @statorjs.dev · 26/07/2026
Stator definitely isn't a good approach for anything entirely client side, including a P2P network for example - those are very interesting, just not the target use case we're going after.
010
statorjs.dev @statorjs.dev · 26/07/2026
We're basically throwing optimistic rendering out the window, whether that pans out is TBD! What do you mean exactly by the server never receiving data? Is the server never persisting state in a db, and if so what is it doing?
110
statorjs.dev @statorjs.dev · 26/07/2026
Yep, great question! We've tried various ways of dealing with conflict resolution over the years and every approach had its own gotchas. Instead of swimming upstream, we're accepting that losing connection to the server fundamentally leaves a user in a bad state.
120
statorjs.dev @statorjs.dev · 25/07/2026
Your data lives in a database on the server. Stator's bet: render the page there too. When data changes the browser gets a tiny note, "change this bit", instead of a whole app asking the server what's true. One program. No glue code to break. statorjs.dev #buildinpublic #webdev #StatorJS
statorjs.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
192
statorjs.dev @statorjs.dev · 24/07/2026
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.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
000
statorjs.dev @statorjs.dev · 24/07/2026
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.
100
statorjs.dev @statorjs.dev · 24/07/2026
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.
100
statorjs.dev @statorjs.dev · 24/07/2026
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.
100
statorjs.dev @statorjs.dev · 24/07/2026
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.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
131
statorjs.dev @statorjs.dev · 17/07/2026
Hello, World. We're building Stator — fine-grained reactivity that lives on the server. State machines hold your logic. Every event patches just the DOM that changed. No client app state (unless you really need it). Docs and demo are live: statorjs.dev #buildinpublic #webdev #StatorJS
statorjs.dev
Stator · the server-canonical JavaScript framework built on state machines
A web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.
192