On the web, Exact is faster than any other fully featured web framework that I've found. Exact's performance is like a static website but with the full dynamic power of a framework like React.

Here's web performance on a Pokédex benchmark proposed by Nolan Lawson from Socket. nolanlawson.com/2026/10/28/t… Neck and neck with Astro and meaningfully ahead of Next.js and SvelteKit.

On the authoring, despite being a new framework that is not in the weights of any AI model, Exact already does surprisingly well -- producing a correct result faster than Next.js for about the same cost. A static site in Astro is still cheaper and faster but I think it's within striking distance if AI models learn Exact and it makes it into the weights.

The way you author UI in Exact is in a new language called Contract. Contract is designed from the ground up for AI agents.

Contract looks like Python -- indentation has meaning, fairly rigid about formatting, fairly sparse. And it is explicit and stron gly typed and pulls complexity forward into authoring like Rust. Your Contract code describes both your UI like you would in React an d also your state and data flow, the way you would with Redux or Zustand or TanStack Query.

Contract is a constrained language so it can be fully analyzed. A lot of the footguns that cause performance problems or make anal ysis hard with JS frameworks just don't exist in Contract -- you can't write recursive loops, useEffects, or arbitrary TypeScript/JavaScript. But you can efficiently express almost every common fixture of real UIs.

Since Contract is new, agents will just try guessing at its rules and syntax. Instead of filling up every context window by making your agent read a long manual, the Contract compiler returns useful error messages that teach your agent on-demand how to do what i t's trying to do. Targeted error messages are one of the cheapest ways to make an agen t efficiently read only the docs it needs.

In Exact, your agent has control over the clock which makes testing and prodding faster and easier. Instead of sleeping and hoping an animation has finished, the agent advances the clock then reads the result, so its screenshots and state reads aren't racing tim ers or transitions. This reduces the possibility space of things an agent needs to check on as it tries to figure out why something is happening or isn't. There are a bunch of things like this that make it easier for agents to build and debug.

Exact also gives agents the ability to inspect the state of your app and complete the feedback loop in a variety of ways -- capturing screenshots and videos, inspecting the abstract state of the UI tree, asking for layout properties, etc.

Because it knows, at compile time, everything about how your data is laid out and related, Contract can be surgical and efficient with updates. There is no virtual DOM or re-rendering or separate hydration. This is why Exact can deliver a static website as fast as Astro but then update it dynamically like React.

When you change Contract code, your app can update live in a few ms. It can be sent over the air for OTA updates. Through these properties of Contract, Exact gives you the speed of a Rust-based native solution with the iteration speed and dynamism of a web app.

For app logic that is deeper than UI in Exact, you can write either Rust or TypeScript. If you work at Shopify or Linear where th ere is a kind of religion around being pure native, you can write your whole app in Rust and not even ship a JS VM and everything is pure native. For most real apps, I've found it's actually more practical to write most business logic in TS.

You can also mix and match. Ex. You could write everything that you measure to be a hotspot in Rust and everything else in TS. Even if your first screen gets its data from TypeScript, Exact can draw the first frame without waiting for the JS VM.

I really do think it makes sense to write larger apps in TypeScript because your ability -- and your agents' ability -- to work o n and iterate on them pays off. I have a theory that this is one of the main reasons that the Claude Code CLI (TS) is a lot more polished and feels much better than the Codex CLI (Rust) right now. Either way, in Exact, you can always choose. Both Rust and TypeScript can run either on the main thread or another thread and you have control over that too.

Contract changes are mostly network bound. They take 10-20ms and generally preserve state. TypeScript changes happen in < 100ms typically. Rust updates get compiled to wasm and can be hot reloaded. On some native platforms, new dynamic libraries can be swapped in; where that's not supported, you can just run the wasm version of the new code until you rebuild.

Of course, you can also write code in Swift or Obj-C or Kotlin or HTML or other languages native to your target platform. Like pretty much every other framework, you can have escape hatches in Exact. You can carve out a rectangular view and take it over with you r own native code. But Exact gives you another level of control called "Access Hatches". Whenever the framework emits some kind of node on the target platform, say a UIKit UIView, you have access to it if you want, so you can write Swift code to attach a property or fill in a sync native callback, etc. One of the key goals for Exact is that you always feel like you have the precise control to get exactly the result that you want.

Here's an example -- the official Liquid Glass example app that Apple provides has a bug when you long-press a tile. The expanding tile gets clipped and flashes white when you release. In the Exact version, you have the control over each native element to be able to implement the correct behavior easily. It's a small detail but I built this framework for people who care about getting these kinds of details right (@JI was the one who noticed this).

There are two main things people care about with native performance: (1) smoothness/fps and (2) startup time. re: Smoothness. Here's Exact vs SwiftUI scrolling through the same rich content feed. You can see Exact holds 120fps and drops zero frames while SwiftUI drops down into the 30-50fps range and is extremely late on many frames.

It's close enough that it's hard to tell the difference visually but Exact slightly outperforms idiomatic raw UIKit on fps. This is possible because Exact handles layout and view recycling in a way that is more optimized than most UIKit implementations. With enough work/tokens, you can achieve the same performance with UIKit. But with Exact, you just get it right out of the box.

One of the reasons Shopify rewrote their mobile apps from React Native into native was to improve performance metrics like startu p time. Here's the new, optimized, native Shopify Shop app compared to the same thing in Exact. The Exact version is talking to the same GraphQL API and fetching the same data. (Yes, I'm sure Shopify could make their Swift app as fast to startup with some time and tokens.)