Ambitious. I’m sure they know what their problems are and how to solve them, as evidenced by the agent being able to control the UI’s timing (and it being mentioned so far up). Getting the agent to get interactivity right is pretty hard otherwise.
This is absolutely huge. If the Expo team can demonstrate that this development strategy is viable, we will finally see a resurgence of native applications and more efficient software, getting rid of the Electron bloat.
It's a long shot for now, though! There are lot of gritty nitty details they have to get right. One of the first issues I can imagine is this framework being great to use with Opus 5.5 but not good enough with i.e. Gemini 4 Argon or DeepSeek v4.1 Flash 1017, due to the overreliance on having AI models write the code.
It is weird. What does "agent native" mean? This looks like work that requires the use of agents to use properly.
Hence me thinking it is satire. Are we already at a point where libraries and frameworks are being written such that they require agents (from maybe paid frontier models) to properly use?
We live in strange times, if so.
Interestingly, I was just thinking of this problem today: how can I stick with react-like declarative UIs (like one I have developed myself) but yet have them abstracted over native UI frameworks of Apple, Android, even TUIs to produce native apps? What I would have expected is a fully deterministic runtime, compiler, or library approach to solving this, not an agent-driven "solution".
No, there's no requirement to use agents, and others are already building tools for manually working with Construct with a purpose-built editor.
Tools like Hyperframes have already demonstrated the value in catering to agentic-first dev while offering manual inspection and editing interfaces.
Agents aren't equally good at all languages/tools, and just having a lot of training data on one ecosystem isn't enough to optimize the experience. If you read the announcement thread from the CEO there are several points made such as formal safeties against invalid states and build error messages that token-efficiently teach the agent correct usage.
> Exact is a cross-platform application runtime. You describe your interface in Contract, a small declarative language, and you write your data logic in TypeScript or Rust. The Contract compiler turns the interface into a compact plan. On the web, that plan becomes one ES module over a ~20 KB runtime that drives the real DOM.
It's funny, I'm working on a few different compilers with Claude Code to experiment, and I had an epiphany this morning, we're entering an age in programming, where you could just create your own compiled language (or DSL) for your framework / application effortlessly, it can have whatever requirements you want.
I've also used Claude to help me make Mojo compile under Windows, since they haven't ported it yet, took less than you'd think, downside is the key thing about Mojo is not open source, so I could never port that myself, but at least basic Mojo programs compiled. Might have to try DMD on Apple Silicon next to see...
Since there are no releases, I assuming this is still a WIP? It would explain why they list Linux and then don’t have any screenshots of it next to the other platforms. How it works is kinda light on details. I’m interested to learn more about the under the hood aspects of how they are translating everything to the different native toolkits.
because these slop projects have a single dev. And if that dev happens to have a macbook, then that's that.
You can't have multi-platform support without external contributors, and of course you can't have external contributors when one dude is pumping out +2.5M LOC in a week.
Sure you can, check https://github.com/gen2brain/iup-go , from single dev on Linux that for a long time used VMs for testing, macOS in VM, iOS simulator in that VM (painful), etc. OK, several months ago I bought some old iPhone first, then one month ago I bought Mac mini M1, just for testing. It needed years though, not few weekends, but it is doable.
The world has not moved away from Javascript, why do people always prematurely call its death? It’s in clients and servers everywhere and npm downloads are at an all time high, facts over feelings
Immediate thought was the Contract reminds me of QML.
This Exact work looks great and I very much hope it succeeds. Qt has
Proven this approach works. Now if these folk at Expo can do it at a price that every dev can afford it will get much wider adoption than Qt.
The idea that agent can built and see it is very important and how I have been building my own GUI framework https://github.com/brainless/akar
I have been using an internal screenshot feature along with a dump of the component tree. Multi-modal LLMs can be used to read the screenshot and fix issues. The dump can be read by any text based LLM. I made my life much easier.
I saw the Blender UI based framework shared on HN the other day and this one today. I am not sure if I want to continue building my own (although all code is written by agents) or if I should switch. I can take inspiration from the two other frameworks and continue with my own.
Whenever I see a DSL where part of the DSL's responsibility is to have arbitrarily complex mathematical expressions, my reactions are (a) why???, (b) well, if they're going to do it, they should have a formal language specification with a derived lexer and parser, and (c) the product needs a robust stdlib with compatibility across build targets.
My understanding is that you arent supposed to write the entire UI in contract. You are supposed to write as much as you can with it and do the rest in js or rust
This is why I have strongly preferred JSX over any other UI DSL (specifically the typescript variant, TSX) I've tried.
It looks like a DSL, but it actually isn't - it's just regular javascript/typescript with a very thin 'declarative/markup' veneer. it basically tricks you into thinking you're writing a HTML-like UI-DSL, but it also just so happens to accept arbitrary JS expressions, because it is just regular JS.
Have you tried WPF and XAML (I guess it's Avalonia and XAML now)? Personally I find it the only good use of XML ever, but it's really, really good. Though I've learned the hard way to keep the advanced features to the minimum and do absolutely any and all calculations in the viewmodel (which, admittedly, excludes 75% of XAML features.)
1 - all logic needs to be written in 1 statement. That forces you to use nested ternaries, nullish operators, and array fns where simple workflow controls would read much better.
2 - it’s designed to render html but conflicts with JS and TS, so you can’t have a class attribute, and weird escape hatches around generic fns.
For 1, you're supposed to break up more complex logic like that into functions and variables, so that acts as a forcing function which works as intended. For 2, 99% of HTML is just fine, just className would be different but it's not a big deal in practice.
The rationale was to follow the DOM property names to avoid clashing with reserved keywords; not because mirroring JS was the goal. Data attributes for example have always been data-*, readonly, contenteditable in lowercase, mirroring HTML.
I know WHY it’s not possible, but that’s a design limitation of the parser being templating on top of JS, instead of a separate DSL with escape hatches for JS, like most other templating engines
It's not really a design limitation, as this way it simplifies the parser, the DSL, the templating... Basically everything. And your entire templating/parsing could be just "convert this to a function call"
> Yes, it simplifies the engine, at the cost of developer experience.
Given that its taken the world by fire and nearly everyone adopted JSX/TSX as the templating language, doesn't seem like developer experience suffered.
> Like useMemo, that now is compiled in automatically
A completely different beast, and this one definitely makes DX suffer.
If I understand you correctly, #1 is just plain wrong. JSX is transformed into standard ECMAScript[0]. You can store JSX-nodes in variables and pass them around however you like.
// this
<Box>
{
shouldShowAnswer(user)
? <Answer value={false}>no</Answer>
: <Box.Comment>
Text Content
</Box.Comment>
}
</Box>
// ...can be written like this
const answer = (
<Answer value={false}>
no
</Answer>
);
const comment = (
<Box.Comment>
Text Content
</Box.Comment>
);
const result = shouldShowAnswer(user) ? answer : comment;
<Box>
{result}
</Box>
In React at least, null won't render anything.
#2 is a known trade-off, and so marginal and well known that it's almost not worth mentioning it.
It’s not wrong, this is a limitation of JSX, every interpolation needs to be a statement.
Ofcourse you can split every control flow into separate component and combine them together finally, but that means exactly that - that every minute condition or iteration is deferred elsewhere. And it makes the actual render result hard to understand.
At this point I honestly don't know what you're on about...
> every interpolation needs to be a statement
Interpolation??? JSX extends the PrimaryExpression in the ECMAScript grammar. So yeah, every JSX element/fragment is an expression, not a statement. You can't seriously consider an ECMAScript expression a limitation?
> you can split control flow into separate component[s]
You do realize that none of the variables in the example above are components, do you? They are the result of JSX elements, and if we're talking React they'd be React elements.
> combine them together [...] makes the actual render result hard to understand
So, for you, a long ECMAScript expression is a limiting factor, but composing shorter, simpler expressions into a longer, more complex one is hard to understand. Even though in your comment above you wrote:
I may have mixed between expression and statement, however in JSX {} must return exactly 1 expression, so that limits the amount of code you can place there.
Your'e missing the point arguing about semantics of components or JSX elements, the point is that if you want to avoid control flow via expressions, you must destruct you template (however simple it may be) into tiny template fragments that makes it harder to understand the complete rendered picture.
Imaging if JSX could look like this:
<div class="container">
My list
@for(item in list) {
<h2>{item.name}</h2>
@if(item.loading){
<p>Loading...</p>
} @else if (item.error) {
<p>Error loading item</p>
} @else {
<p>{item.description}</p>
}
}
</div>
This is much easier than the suggested JSX approach:
It is important that the DSL syntax resonates with people reading the code and their experiences. Given the popularity of React I agree that JSX is great. This is what people's brains have been trained for and thus it would be easier for them to review.
But in the end this is a small syntactical difference (how it looks). You could have a custom code viewer that does these translations for you.
I've found Claude will default to that dense verging on minified style unless you tell it to write it in a way that humans can read and grok it. Even then it doesn't really comply
Does anyone know if the code in this file (or the others) is the direct output of the Agent or is this the output of another tool? I guess the other tool could be the 'Agent' but hoping my coworkers do not start having me review code in this dense format. Maybe we really are past the point of code needing human review at all IDK....
This looks really cool, but the "Claude speak" README is a bummer. I would like to understand the principles and architecture, but this isn't helping:
"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."
I prefer building native apps for each platform. Agent the match app behavior from one platform to another one and use native layout, controls, SDK, etc. I already built web, macOS and Android versions of the same app this way.
The design here is very similar to Slint (https://github.com/slint-ui/slint), which I work on: both are implemented in Rust, with a declarative UI DSL and its own compiler, logic in a host language (Rust, C++, JS or Python for Slint), pure reactive expressions, and tooling that lets agents inspect and drive the app.
One difference is that Slint is more mature: it's been 1.x with a stable API since 2023
Not really. Slint also has a royalty-free license, so you can make proprietary applications for free. So it’s GPL for open-source apps (including if your own code is MIT/Apache as they are compatible), and royalty-free for proprietary apps. Is that not enough?
At this point is there a cross-platform UI framework that one can just use? At least for simple or moderately simple apps? Even if it's not "all platofrms" but rather two separately: mobile and desktop. But being extremely lightweight is a pre-requisite. Googling about it takes
When I was making a simple vibe-coded app for a hobby group I am part of I finally went ahead with a static hosted web app because everything else quite complex and still used quite a lot of RAM (just for using the f/w).
I think the only better option as of now is – just write native code for each platform. I think the purest cross-platform UI frameowrk is the LLM itself :)
You can check https://github.com/gen2brain/iup-go , real native controls everywhere, powerful, same codebase for desktop and mobile apps (different layout though). I hope to release soon, after years in making it finally does everything that is planned. With proper documentation, 200+ examples, etc.
You do not have to use Go, of course C works, and there is a nice wrapper for C++. I have ported gVim, it was a good test that helped me optimize many things, but now I maintain and use it on my desktop with Qt, it is just too good to throw it away. Can also be used with WinUI, Cocoa, FLTK gVim is also nice and slick.
Slint might fit: it runs on desktop and mobile, and it’s lightweight enough to run on microcontrollers. You write the UI in a small declarative language, and the logic in Rust, C++, JS, TS or Python, depending on your preference. (I work on it.)
Granted all the justifiable hate for it, but it's not crossplatform if it doesn't run natively on Windows.
If it's just web then it's as crossplatform as vanillajs.
I say this bc I'd be genuinely interested in genuine crossplatform for my client audience of professionals and knowledge workers who, as it stands, are mostly (though not exclusively) Windows users and deserve nice applications.
I disagree on the semantics Cross Platform does not mean that it has to be Cross (Every) Platform. As long as it crosses multiple platforms it is Cross Platform. Other than that I agree with the sentiment.
I have had decent success with Flutter as the cross platform gui; the llm can query my android tablet, get screenshots, and can do the same on my linux desktop too. I copy the files to my macbook and can compile it there for macos as well. I dont really care about the app looking native, i care more about it working the same on all platforms and it does that well.
To me it looks like an "hallucinated" project, un-necessary boilerplate, tons of abstractions over abstractions, I did a first pass read and nothing makes sense. This is what happens when you assign much of the tasks to the clanker
The README immediately discourages me from ever learning about this project by immediately declaring that it is not a project for me, the developer, it's a project for "agents". Like, you did not even explain what is it, but you are already telling me to f off.
The part I like most is that the agent can see and test the app on every platform. In my experience the hard part of agent-written UI isn't writing it, it's the agent never looking at what it made. Curious how the Contract test files hold up once layout gets messy, e.g. long lists and keyboard insets on iOS.
yewenjie | 16 hours ago
solarkraft | 16 hours ago
tyleregeto | 14 hours ago
solarkraft | 16 hours ago
doodlesdev | 16 hours ago
It's a long shot for now, though! There are lot of gritty nitty details they have to get right. One of the first issues I can imagine is this framework being great to use with Opus 5.5 but not good enough with i.e. Gemini 4 Argon or DeepSeek v4.1 Flash 1017, due to the overreliance on having AI models write the code.
tevon | 15 hours ago
prmph | 15 hours ago
jkahrs595 | 15 hours ago
prmph | 15 hours ago
Hence me thinking it is satire. Are we already at a point where libraries and frameworks are being written such that they require agents (from maybe paid frontier models) to properly use?
We live in strange times, if so.
Interestingly, I was just thinking of this problem today: how can I stick with react-like declarative UIs (like one I have developed myself) but yet have them abstracted over native UI frameworks of Apple, Android, even TUIs to produce native apps? What I would have expected is a fully deterministic runtime, compiler, or library approach to solving this, not an agent-driven "solution".
wahnfrieden | 14 hours ago
Tools like Hyperframes have already demonstrated the value in catering to agentic-first dev while offering manual inspection and editing interfaces.
Agents aren't equally good at all languages/tools, and just having a lot of training data on one ecosystem isn't enough to optimize the experience. If you read the announcement thread from the CEO there are several points made such as formal safeties against invalid states and build error messages that token-efficiently teach the agent correct usage.
> What does "agent native" mean?
https://github.com/expo/exact#1-agent-native defines it
theultdev | 13 hours ago
Agent native is said once in this readme, following an immediate explanation and specific features.
giancarlostoro | 15 hours ago
It's funny, I'm working on a few different compilers with Claude Code to experiment, and I had an epiphany this morning, we're entering an age in programming, where you could just create your own compiled language (or DSL) for your framework / application effortlessly, it can have whatever requirements you want.
I've also used Claude to help me make Mojo compile under Windows, since they haven't ported it yet, took less than you'd think, downside is the key thing about Mojo is not open source, so I could never port that myself, but at least basic Mojo programs compiled. Might have to try DMD on Apple Silicon next to see...
hysan | 15 hours ago
[OP] vmg12 | 15 hours ago
wahnfrieden | 14 hours ago
mrbombastic | 15 hours ago
wahnfrieden | 14 hours ago
The announcement thread covers ways it helps agents, and they sound like things that would help humans, too.
sirjaz | 15 hours ago
zdragnar | 15 hours ago
pjmlp | 7 hours ago
kyriakos | 13 hours ago
q4y2u35uk | 10 hours ago
You can't have multi-platform support without external contributors, and of course you can't have external contributors when one dude is pumping out +2.5M LOC in a week.
pjmlp | 7 hours ago
gen2brain | 7 hours ago
tdhz77 | 14 hours ago
soon_to_be_sb | 13 hours ago
jmathai | 13 hours ago
wahnfrieden | 12 hours ago
ojr | 12 hours ago
fodkodrasz | 8 hours ago
cyberax | 9 hours ago
pjmlp | 7 hours ago
I see these projects and feel as enthusiastic as reading the ingredients of a frozen pizza package.
zoom6628 | 14 hours ago
This Exact work looks great and I very much hope it succeeds. Qt has Proven this approach works. Now if these folk at Expo can do it at a price that every dev can afford it will get much wider adoption than Qt.
wahnfrieden | 12 hours ago
mplewis | 14 hours ago
eviks | 13 hours ago
brainless | 13 hours ago
I have been using an internal screenshot feature along with a dump of the component tree. Multi-modal LLMs can be used to read the screenshot and fix issues. The dump can be read by any text based LLM. I made my life much easier.
I saw the Blender UI based framework shared on HN the other day and this one today. I am not sure if I want to continue building my own (although all code is written by agents) or if I should switch. I can take inspiration from the two other frameworks and continue with my own.
btown | 13 hours ago
From what I see in https://github.com/expo/exact/blob/main/contract/syntax/src/... and https://github.com/expo/exact/blob/main/contract/syntax/src/... - it's unclear this will scale to the levels of complexity that arbitrary UIs demand.
[OP] vmg12 | 12 hours ago
miffy900 | 12 hours ago
It looks like a DSL, but it actually isn't - it's just regular javascript/typescript with a very thin 'declarative/markup' veneer. it basically tricks you into thinking you're writing a HTML-like UI-DSL, but it also just so happens to accept arbitrary JS expressions, because it is just regular JS.
Xirdus | 10 hours ago
jdthedisciple | 9 hours ago
akoboldfrying | 10 hours ago
halflife | 10 hours ago
1 - all logic needs to be written in 1 statement. That forces you to use nested ternaries, nullish operators, and array fns where simple workflow controls would read much better.
2 - it’s designed to render html but conflicts with JS and TS, so you can’t have a class attribute, and weird escape hatches around generic fns.
satvikpendem | 9 hours ago
halflife | 5 hours ago
troupo | 8 hours ago
Because it's a thin wrapper directly translatable into a JS function call. `className` is JS
ricardobeat | 6 hours ago
React opted for backwards compatibility at the time it came out, and never made the upgrade - you can write `class` in Preact.
troupo | 4 hours ago
I think they opted for what these properties are actually called in Javascript: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
I wish they'd stick with that for all properties though.
ricardobeat | 4 hours ago
troupo | an hour ago
halflife | 5 hours ago
troupo | 4 hours ago
halflife | 2 hours ago
troupo | an hour ago
Given that its taken the world by fire and nearly everyone adopted JSX/TSX as the templating language, doesn't seem like developer experience suffered.
> Like useMemo, that now is compiled in automatically
A completely different beast, and this one definitely makes DX suffer.
whilenot-dev | 8 hours ago
#2 is a known trade-off, and so marginal and well known that it's almost not worth mentioning it.
[0]: https://react.github.io/jsx/
halflife | 5 hours ago
Ofcourse you can split every control flow into separate component and combine them together finally, but that means exactly that - that every minute condition or iteration is deferred elsewhere. And it makes the actual render result hard to understand.
whilenot-dev | 4 hours ago
> every interpolation needs to be a statement
Interpolation??? JSX extends the PrimaryExpression in the ECMAScript grammar. So yeah, every JSX element/fragment is an expression, not a statement. You can't seriously consider an ECMAScript expression a limitation?
> you can split control flow into separate component[s]
You do realize that none of the variables in the example above are components, do you? They are the result of JSX elements, and if we're talking React they'd be React elements.
> combine them together [...] makes the actual render result hard to understand
So, for you, a long ECMAScript expression is a limiting factor, but composing shorter, simpler expressions into a longer, more complex one is hard to understand. Even though in your comment above you wrote:
> simple workflow controls would read much better
What's your alternative?
halflife | 2 hours ago
Your'e missing the point arguing about semantics of components or JSX elements, the point is that if you want to avoid control flow via expressions, you must destruct you template (however simple it may be) into tiny template fragments that makes it harder to understand the complete rendered picture.
Imaging if JSX could look like this:
This is much easier than the suggested JSX approach:whazor | 4 hours ago
But in the end this is a small syntactical difference (how it looks). You could have a custom code viewer that does these translations for you.
osullivj | 8 hours ago
brainless | 13 hours ago
fudged71 | 12 hours ago
bakugo | 9 hours ago
Like... some way to "branch" out of the main development repo and make changes independent of it before "merging" it back in?
sakesun | 12 hours ago
A new trend?
bakugo | 12 hours ago
Amazing things are happening in this codebase.
paulhebert | 11 hours ago
I don’t really get why you would ever want your source code formatted like that, with or without LLMs
miguelspizza | 10 hours ago
bakugo | 9 hours ago
https://github.com/expo/exact/blob/main/host/web/capture.js
gib444 | 9 hours ago
It's obvious what its game is
Sn0wCoder | 9 hours ago
scottpersinger | 11 hours ago
"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."
1ba9115454 | 8 hours ago
lcnmrn | 10 hours ago
Culonavirus | 10 hours ago
lol
> cross platform - no windows, no android
lol
Yeah I don't think so.
I could vibe code all of this myself if I wanted to. But I don't, because I value my time.
I can just vibe code the actual apps and be fine.
jacknews | 10 hours ago
hmry | 9 hours ago
ogoffart | 10 hours ago
One difference is that Slint is more mature: it's been 1.x with a stable API since 2023
satvikpendem | 9 hours ago
pjmlp | 7 hours ago
Not paying for developer tools? No money as well.
ogoffart | 6 hours ago
justauserid | 9 hours ago
When I was making a simple vibe-coded app for a hobby group I am part of I finally went ahead with a static hosted web app because everything else quite complex and still used quite a lot of RAM (just for using the f/w).
I think the only better option as of now is – just write native code for each platform. I think the purest cross-platform UI frameowrk is the LLM itself :)
ltearno | 9 hours ago
You choose your langage: js, lua, webassembly. You can also make native apps but not documented yet.
It runs on linux, macos, windows, android and the web (ios to come).
- immediate mode 2d - website style 3d - audio, midi, storage, etc - llm ready
satvikpendem | 9 hours ago
gen2brain | 7 hours ago
You do not have to use Go, of course C works, and there is a nice wrapper for C++. I have ported gVim, it was a good test that helped me optimize many things, but now I maintain and use it on my desktop with Qt, it is just too good to throw it away. Can also be used with WinUI, Cocoa, FLTK gVim is also nice and slick.
childintime | 2 hours ago
ogoffart | 3 hours ago
orliesaurus | 9 hours ago
smcleod | 9 hours ago
jdthedisciple | 9 hours ago
If it's just web then it's as crossplatform as vanillajs.
I say this bc I'd be genuinely interested in genuine crossplatform for my client audience of professionals and knowledge workers who, as it stands, are mostly (though not exclusively) Windows users and deserve nice applications.
mastermage | 8 hours ago
joshheitzman | 8 hours ago
fodkodrasz | 8 hours ago
calgoo | 6 hours ago
hollowturtle | 7 hours ago
egorfine | 7 hours ago
ricardobeat | 6 hours ago
> Names are CSS's, because names are what you write
> Unsaid presentation is the platform's
Very enlightening /s
I’m all for AI assisted development but please write/review your documentation.
henry-hong | 6 hours ago