DEV Community

Cover image for Expo's Exact Wants Agents to Write Your App. I Have Doubts
Dishant Sharma
Dishant Sharma

Posted on

Expo's Exact Wants Agents to Write Your App. I Have Doubts

Expo put Exact on GitHub and eight days later it had 1,178 stars. One of the first comments on Hacker News, from a user called prmph, was two words: "Is this satire?"

I understand the question. Exact is a cross-platform app runtime written in Rust. You describe the interface in a small declarative language called Contract.

The data logic goes in TypeScript or Rust. It runs natively on the web, macOS, iOS, and Linux.

And the whole thing is built on the assumption that an AI agent will write most of the code.

That is what made the thread strange. People were not arguing about frame times. They were arguing about whether a framework designed for agents is a framework for humans at all.

What Contract actually is

Most tutorials tell you a DSL saves you boilerplate. Contract goes further. It removes the ability to write arbitrary code in the view at all.

No JavaScript in the markup. No I/O. Expressions have no side effects.

Effects only happen inside actions, as assignments, sends, or commands like focus(…).

The todo app in the README fits on one screen. Shapes, components, state, derive, resource, mutation, action, view. A bare node behaves like a bare div: display: block, box-sizing: content-box, flex-direction: row.

The compiler refuses CSS aliases and hands you the web's spelling instead. font-size, not size. background-color, not the background shorthand.

That last detail tells you a lot about who they are writing for. They are optimizing for a reader that will not remember the alias.

Now the honest part. A commenter called btown, who clearly reads compiler internals for fun, said his reaction to any DSL that has to carry "arbitrarily complex mathematical expressions" is "why???" He poked at the syntax crate and did not think it would scale to what real UIs demand.

That is the sharpest criticism in the thread. Nobody answered it well.

The speed claim

Here is a question people always ask about anything Rust-shaped. Is it actually faster, or does it just feel faster because it is new?

The README has numbers. Cold start to interactive first frame: 100 ms p50. Edit to present: 100 ms p50.

On the RealWorld Conduit benchmark, Exact's runtime was up about 300 ms before the React SSR build had hydrated. It used 26 KB of code against React's 81 KB.

Against Electron the gap is not subtle. Electron ships a browser. Exact on macOS draws with AppKit and a Rust layout kernel, and the app's JavaScript loads after the first pixel.

But the fair comparison is React Native, not Electron. React Native does not ship a browser either. Its real cost is the bridge and the reconciliation work, not download size.

Exact React Native Electron
UI rendering Compiled plan, native views JS tree reconciled to native Chromium
Web runtime ~20 KB n/a Chromium
First pixel Baked data, no JS JS boot JS boot

I could not find a single head to head benchmark against React Native. I looked. The speed story right now is architectural and self-reported.

The clock belongs to the agent

Here is the design decision i did not expect to like.

Exact exposes ten operations to an agent, the same on every host: tree, screenshot, tap, type, state, layout, logs, clock, prefer, perf.

The README explains the count: "There are ten on purpose: an agent API grows one reasonable addition at a time until no one can hold it in mind."

That sentence is the best writing in the whole repo.

And then the clock. Between two operations nothing moves.

Instead of sleeping until an animation finishes, the agent says clock +60000 or clock settle and reads the result. No timing flakes. No waits.

A test that needs a sleep is a test that will fail on someone else's laptop.

The evidence is thin but real. The README says a fresh agent built a todo app in about 57 minutes on a clean clone, and its tests passed on web, macOS, and the iOS Simulator. About 25 of those minutes were first builds.

Jayesh, writing on Medium, built a calculator with Cursor in 15 minutes, spent 2 minutes on tests, then got 10 seconds per UI change on a simulator. His first hour went to installing Rust, Bun, and an iOS simulator target. The app work was the short part.

What breaks

The first hour is setup. Rust, Bun 1.4.2 pinned exactly, Chrome, Xcode, Hermes. A first native build takes ten to fifteen minutes.

The open issues on the repo are more useful than the screenshots. Setup leaves Chrome marked MISSING on a Mac that has Chrome installed. A worktree in a folder with a different name fails native builds. Android compiles and runs, but "delivery and store packaging don't exist yet."

And this, stated plainly in the README:

Exact is pre-1.0 and changes daily. There is no API stability, no backwards compatibility, and no migration guide, by design.

"By design" is doing a lot of work in that sentence.


I keep a note file called frameworks i will not learn. QML is on it. Every year someone tells me QML is actually good, and every year i open a file, see the property bindings, and close it.

So when a commenter compared Contract to QML and said Qt "proven this approach works," my instinct was to disagree on principle.

Then i read the todo app again. Contract is much smaller than QML.

No property binding graph to reason about, no signal and slot machinery to learn. Just shapes, actions, and a view tree.

I still have not installed it. But i moved the note file.

The real talk

If you ship to the App Store next quarter, do not use this. No migration guide is a real cost, and you will pay it.

If you are a React Native shop with a working app, this is a research toy. It is not a migration path.

And if you think the "agent native" label is nonsense, you are not wrong to be suspicious. One commenter said the trend makes him "sympathize with the Butlerian jihad," which is the funniest sentence written about this release.

But agent native does not mean you cannot write it by hand. It means the docs, the compiler errors, and the test setup are built for a reader that never gets tired.

Whether that is good depends on who you think writes your code in two years. I genuinely do not know. I have been wrong about this twice already.

The part i keep thinking about

The 57 minute number is not what stuck with me. It is that a machine built the same app three times, checked it three times, and nobody had to sit and watch.

My first cross-platform app took a month and it still looked wrong on Android.

I do not know if Exact wins. The math expression criticism might sink it. And a framework that changes daily is not a framework you build a business on yet.

But someone finally built the boring part. The part where the tool can see its own work. That part is not going away.

Top comments (0)