Foldkit

Build faster. Understand what ships. Foldkit is a TypeScript frontend framework built on @EffectTS_. Created by @devinjameson.

[sam @samgoodwin89]

Inspired by @foldkit's story testing - Alchemy Domain lets you do the same but for the backend.

Test your service with the same language and mental model as you speak about it with your team.

[sam @samgoodwin89]

@filipfalcon added SSR support for @foldkit

[Devin Jameson @devinjameson]

Foldkit currently makes application architecture explicit. The new Blocks and Layers work will make application composition explicit, too.

The framework prescribes how you define each piece and, soon, how you connect them.

This makes frontend application composition a first-class concern! I think this will be one of Foldkit’s distinctive features.

[Anfi @anfi_ttv]

I wanted to build something with foldkit so decided to apply this to my recent problem of running out of ci minutes

I didn't want to pay for it, so I deleted my workflows and adopted gh signoff
https://t.co/WlZqH8qJNF

my agents use this now to run all the tasks on my remote dev box (macbook pro). It was pretty difficult to see what was going on though without github reporting statuses, so I vibed my own task runner dashboard

I think the results look pretty good and fit my needs as a solo developer who doesn't want to pay for ci

what do you think?

[Devin Jameson @devinjameson]

React → Foldkit: @Mapledotdev just made the switch.

The requirements:

- Port 287,000 lines of React code
- Keep the exact same UI (0px tolerance)

The result:

- Completed in 3 days
- Agent-friendly architecture
- Improved performance
- End-to-end tracing
- @EffectTS_ across the stack

My favorite excerpts from @makisuo’s blog post:

“The React app worked, but changing it had gotten expensive. Data on a page came from atom hooks, each with its own cache key and lifetime, and there were about 520 of those hook calls spread over 208 files. If you wanted to know what happens when someone switches org while a query is still running, you had to read every component on the page and work out the order they render in.”

“[In Foldkit,] there are no hooks and no component state, so the org-switch question has one answer, and it’s a single case in update. Foldkit’s Scene tests run update in Node without a DOM, so we can test that case directly.”

[Makisuo @makisuo]

Last weekend I moved Maple off React and onto @foldkit

100+ pages, 300k+ lines of React. Took me a few hours planning and building a validation harness, then 3 days with Claude to run the rewrite. The result is a 1:1 clone down to every. interaction and animation, with renders ~10% faster on average

It's been in production for a week and nobody noticed the switch

If you spend the time on a good validation harness, you can rewrite almost anything now

Wrote a bit more about why here: https://t.co/7HXvuTTy1K

[Devin Jameson @devinjameson]

Another @foldkit Blocks + Effect Layers preview is ready.

This round:
- Added a Block assembly boundary to reduce expensive TypeScript inference.
- More consistent API naming and better diagnostics.
- Updated guides for stable migrations and previous-preview upgrades.
- Optional tsrs editor setup, which has felt much snappier in Neovim. Useful if you still type code.
- More under the hood.

Thank you to everyone who contributed experiments, patches, and feedback. Your work helped shape this release.

Testing instructions and copyable agent prompts:
https://t.co/6qXgWzhd0U

[Devin Jameson @devinjameson]

If you have Anthropic, Grok, or other non-OpenAI tokens to burn, I could use some help!

I'm bumping up against a TypeScript performance challenge with Foldkit's Block composition API, currently in preview.

We're asking TypeScript to do a lot of inference, and some editor operations take several seconds after an edit.

We've found changes that improve performance (including API changes), but I'd love to retain the proposed shape if possible.

I've had Astra working on this at Max effort for the past day, and we still don't have a complete fix. Perhaps Fable 5.1 or another frontier model will be up to the task.

Or perhaps tsrs will rescue me?

This issue links to a reproducer, measurements, and the approaches my agents have already tried.

Thank you!

https://t.co/jKgj8r5exn

[Devin Jameson @devinjameson]

Foldkit 0.169.0 is out!

- New route transition helpers
- Better DevTools MCP discovery
- Fixes for lost keystrokes
- Portal and overlay fixes

Thanks @filipfalcon @TannerSDev @drobson03 @taras_korn and everyone else who contributed!

https://t.co/sutHyH5CJq

[Devin Jameson @devinjameson]

The latest @foldkit Blocks + Effect Layers preview is ready. I’ll keep refining it as feedback comes in.

What’s new:

- Simpler root setup: compose your application from Blocks, then pass the root ApplicationBlock to Program.make.
- Cleaner child OutMessage policies with better inference.
- Better support for optional children with keyed identities.
- Separate guides for migrating from stable and upgrading an earlier preview.

Installation instructions and copyable migration prompts are in the PR description.

https://t.co/6qXgWzhd0U

[Devin Jameson @devinjameson]

Rambling about the new Block composition model and TEA scalability and sharing some before/afters on the Foldkit docs site (which is a Foldkit app of course).

(Sorry bout the camera window positioning)

[Devin Jameson @devinjameson]

Foldkit’s Blocks + Effect Layers preview release is incoming. Should be ready within the next few hours.

(This is a test of whether 6.1 Sol gets it over the finish line or stalls waiting for user input. The user will be asleep.)

Preview status and installation instructions are in the PR description.

Feedback greatly appreciated!

❤️

https://t.co/6qXgWzhd0U

[Devin Jameson @devinjameson]

Goal is to get the preview release I’ve been teasing out tomorrow (Saturday). Posting for accountability :)

The new APIs will be good. The docs (for the preview release) will be unreviewed slop. Better to get it out though!

Quick overview:

The architecture will stay the same. The way you compose the pieces (Model, Message, update, view, Commands, Subscriptions, etc.) will change.

The new Block primitive replaces Submodel. Think of a Block as a mini Foldkit program. Parent Blocks bind child Blocks and define how they connect, like a socket and plug.

This streamlines a lot of the boilerplate you see in larger Foldkit applications. Block provides more explicit structure for how your application fits together, which feels very “Foldkit” to me!

Type inference is a lot better. Instead of repeatedly annotating Model and Message types, you define a Block in one place with its Model and Message Schemas, then use that to create the other pieces of the Block (update, view, etc.). It reads quite nicely!

Sharing the counter example here to give you a sense of the new APIs. This doesn’t show off all the cool new Block stuff, but it does (I hope) show how things have been streamlined.

There’s a lot more, but this message is already long and it’s nearly 2 AM, so I’ll leave it there for now. Thanks!

[Devin Jameson @devinjameson]

Foldkit + Cloudflare Workers docs

https://t.co/9HBkGe0m5m

[Mat Warger @mwarger]

@foldkit is next level - the whole CAFE stack is just an absolute dream to use with agents.

[Devin Jameson @devinjameson]

I think “clean code” is just a bad term. Overloaded, subjective, and purity-coded. One person’s clean code is another person’s slop.

What matters today is standardized, highly constrained architecture, where strong conventions enable agent productivity.

Your agent should never be deciding between several state management solutions, several UI libraries, several observability tools.

For a web application, just use @EffectTS_. Just use @alchemy_run. Just use @foldkit. I think this is the future. Let your agent run wild within a system that ensures architectural sanity and offers powerful, built-in observability, inspectability, and testing capabilities.

And there’s no reason agents can’t write code that’s inspectable and understandable by humans. We can have our cake and eat it, too.

In fact, verifiability is a requirement in many domains. I’ve worked in security and healthcare, and there’s no way I’m shipping code I can’t verify. I’m responsible if someone gets the wrong medication, or someone with a knife gets through a security checkpoint, because of my code.

[jem 💜🩵🩷 @sheherenow_]

🎛️ Foldkit Dials: a lil port of @joshpuckett's Dialkit to align with Foldkit/TEA

I made this a few days ago, but after making Pleat today everything is making sense: your tweakable params are centralized in your Model, and can be Styles themselves, or can be safely transformed into Styles downstream 🪄

https://t.co/2Pp2iRdtUH

[jem 💜🩵🩷 @sheherenow_]

🎨 Pleat is a library for algebraic style composition

https://t.co/eBwUIJIVbc

[joel ⛈️ @joelhooks]

curating Effect/Alchemy community highlights across channels https://t.co/Mfa8Q2z7Hj

[Devin Jameson @devinjameson]

Benefits of the CAFE stack (@Cloudflare + @alchemy_run + @foldkit + @EffectTS_) for building software with coding agents:

1. Agents invent less architecture. They focus on product-level execution within a well-defined architecture. You build faster, with more confidence. You focus on what makes your product unique.

2. Your codebase becomes semantically rich. Intent and meaning are explicit rather than left for future agents to infer. Each new agent spends fewer tokens reconstructing intent.

3. Tests read like executable behavioral specs. Expected behavior is easy to inspect, and both humans and agents can verify implementations against it.

4. Strong conventions result in remarkably legible AI-generated code. Agents do what you expect more often, with less steering. The codebase feels consistent and predictable.

5. Explicitness makes behavior clear. Unexpected magic has fewer places to hide. Diffs are easier to review. Yes, it’s more LoC, but who cares when you’re not writing it by hand?