@statorjs.dev

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

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.

statorjs.dev

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

Getting Started

Learn how to get started with @bomb.sh/tty

bomb.sh

bombshell@bomb.sh · 2w ago

exciting news! we've partnered with @frontside.com together we're bringing their work on clayterm into the ecosystem as @bomb.sh/tty, a high-performance wasm renderer for terminal apps and we're jointly contributing $400/mo to support maintenance of the underlying clay layout engine

🌶️ 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

Bild

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

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.

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

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.

statorjs.dev

🚀 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

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.

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

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.

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

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.

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

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.

statorjs.dev