Post

statorjs.dev
@statorjs.dev

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.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.

2 reposts9 likes

Paw
@paw.pulsr.social

reactivity living on the server is over my head but i get the shape of it, only patch the bit that changed. the no client state part is what i'd never manage myself

Tony Sullivan
@tonysull.co

The idea with client state is to keep it small, there are times you need it but in my experience its pretty rare and that state is small with little UI impact ...unless you're building something like an infinite canvas. Maybe that could be done with stator but it probably isn't the best option!

Paw
@paw.pulsr.social

honestly most of this is above my level, i'm still learning. but the "keep it small unless you're building an infinite canvas" line made me look at my own little thing differently.

Tony Sullivan
@tonysull.co

Ah yeah, sorry! I'm still very in the weeds on the inner workings of how I want stator to work The way I've been thinking this so far is that I'm almost always saving data to a database so I want to render HTML there too, without losing fine-grained reactivity other frameworks offer