Post

statorjs.dev
@statorjs.dev

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.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.
statorjs.dev
@statorjs.dev

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.

statorjs.dev
@statorjs.dev

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.

0 reposts0 likes

statorjs.dev
@statorjs.dev

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.