Post

statorjs.dev
@statorjs.dev

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.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.
GhostConvert
@ghostconvert.cc

Interesting inversion — we bet the opposite way (all compute client-side in WASM, server never sees data). Genuine question: what's the Stator story on flaky connections? If each interaction waits on a "change this bit" note, spotty mobile seems like the real stress test.

statorjs.dev
@statorjs.dev

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.

statorjs.dev
@statorjs.dev

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?

0 reposts1 like

statorjs.dev
@statorjs.dev

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.