iiinova — where your digital self keeps evolving

Reposted by Chisel

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 Chisel

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

Reposted by Chisel

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 Chisel

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

Reposted by Chisel

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

Reposted by Chisel

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

Reposted by Chisel

Tony Sullivan @tonysull.co · 15/07/2026

StatorJS is the first major project I've used @chisel.build with for long term planning Its been a huge help so far especially tracking long term specs. Using md right in the repo as the roadmap, feature spec, and "why" behind the feature is more handy than I expected github.com/statorjs/stator/

github.com

GitHub - statorjs/stator

Contribute to statorjs/stator development by creating an account on GitHub.

021

Chisel @chisel.build · 20/04/2026

With long lived specs, the context of why a decision was made turns out to be way more useful than the context of what bugs exist(ed) ADRs also fill in a gap that docs often have. If you're using chisel docs with @astro.build Starlight (and you should!), your docs are often the what not the why

020

Chisel @chisel.build · 20/04/2026

If you saw our site a few weeks ago you may have noticed we had a `chisel issues` feature that has since been deprecated and removed from the early beta Why? Issues feel like the wrong granularity today if you're using #ai, and if you're using chisel.build we assume you're also using coding #llms

chisel.build

Chisel | The project brain for founders building with AI agents.

Chisel - Text-first tools for shaping information.

111

Chisel @chisel.build · 19/04/2026

With chisel.build we're going with the approach of building for the future you want Write docs and specs once not necessarily because they're as useful for #ai today as they are for humans, but because #llms should be able to use the same docs as humans if they're anything close to intelligence

chisel.build

Chisel | The project brain for founders building with AI agents.

Chisel - Text-first tools for shaping information.

152

Chisel @chisel.build · 10/04/2026

Markdown is markdown, and if its useful for #ai it should be useful for a human too Use chisel docs with @astro Starlight and you have one set of markdown for your public docs, local TUI for devs, and a CLI for #llms to fuzzy search for context

022

Chisel @chisel.build · 09/03/2026

Unexpected benefit when an LLM uses the same markdown as your public docs site: Claude seems to almost always keep docs up to date automatically 🤖 indiepub.dev/docs is powered by @astro.build 's Starlight. With chisel pointed at the same markdown files every new features gets docs right away

indiepub.dev

Welcome to IndiePub

An IndieWeb-focused Astro theme platform for technical self-hosters.

011

Chisel @chisel.build · 04/03/2026

Don't bother building an #mcp server for your CLI tool Build good `--help` documentation or a man page and call it a day! Do it right once and it doesn't matter who/what the end user is

000

Reposted by Chisel

Tony Sullivan @tonysull.co · 03/03/2026

The future of software development, or the history of online poker The future of software development is unknown, but the history of online poker has some pretty clear hints...and it doesn't look great. 🔗 tonysull.co/articles/the-future-of-…

351

Chisel @chisel.build · 02/03/2026

Stop building for #llms Build for humans and understand that, if useful, LLMs will figure out how to read your docs and run `--help`

011

Chisel @chisel.build · 26/02/2026

`chisel planning new` incoming 👀 Go from idea to plan to issues to final docs, all in a TUI powered by local markdown files Using an LLM? They can use the exact same files and APIs to keep everything in sync

000

Chisel @chisel.build · 24/02/2026

#llms sure seem happy with XML... Coming soon: `chisel context create "app routing"` Leverage SQLite FTS5 indexing of your own docs and issues to build a complete picture of the feature area you're working on

021

Chisel @chisel.build · 20/02/2026

Write (on your) Own Site, Syndicate Everywhere. WOSSE - the #posse for docs?

000

Chisel @chisel.build · 19/02/2026

Write once, document everywhere #posse meets #wode docs?

000

Chisel @chisel.build · 18/02/2026

Hello, World. We're building Chisel — terminal-native tools for organizing your work. Crafted for developers, structured for AI. Public alpha is live: chisel.build #rust #terminal #tui #buildinpublic

061