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.
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."
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
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.
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.
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.
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.
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
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.
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 :)
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.
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.
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.
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.
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....
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
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.
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.
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...
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.
It doesn't run on Android either.
Well, if it doesn't support Windows or Android, it's only missing 74% of the global computing market. Technically cross-platform, of course.
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."
Yeah, I couldn't get past that either.
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
Slint is proprietary too unless you want to GPL your product.
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.
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.
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.)
In my experience, WPF/XAML is great for Windows, but soon as you move into x-platform territory with MAUI XAML, it's been a total and absolute mess.
Interested in what you find irksome about TSX?
JSX is terrible because of 2 shortcomings-
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.
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.
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.
[0]: https://react.github.io/jsx/
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.
> so you can’t have a class attribute
Because it's a thin wrapper directly translatable into a JS function call. `className` is JS
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
The world has moved away from JavaScript. With llm, native is easy and the best option even for a single developer.
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
Well, one can at least hope...
I converted a native iOS app to Android in 4 nights. Now every feature I add gets created in both simultaneously. Wild times.
Thank god if true, but dependence on LLMs is not great for the developers. At least good thing for the end user.
No JS here
So what's going to happen once the slop becomes too large for the context?
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.
Isn’t it free
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 :)
I made this one, called Budo : https://budo-platform.github.io/
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
Flutter. It is very mature as it came before the wave of AI slop and works everywhere without issue, especially mobile.
Why isn't Windows supported. Thr largest desktop platform out there?
Because it is an early alpha release maybe?
Or android
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.
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.
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.
Yeah, it's an early alpha they announced on twitter today.
Expo CEO estimated 2-3 months until production-ready
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.
Why isn't Android support there?
Presumably they’re focusing on a few platforms first. As they noted it’s coming though
They mention Android on the linked page. It's a work in progress, but further behind.
https://github.com/expo/exact/blob/main/host/web/glue.js
Amazing things are happening in this codebase.
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....
Wow, that is incredibly dense.
I don’t really get why you would ever want your source code formatted like that, with or without LLMs
Not even TS. Might as well just start having the agents write minified code from the start if it’s going to look like this…
Way ahead of you.
https://github.com/expo/exact/blob/main/host/web/capture.js
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
It's obvious what its game is
There is already an Exact 2? https://github.com/ccheever/exact2
No. ccheever/exact2 is the development upstream. expo/exact is Expo’s public release of that codebase
Makes sense. Though, now I wish git had some sort of feature to make this process easier.
Like... some way to "branch" out of the main development repo and make changes independent of it before "merging" it back in?
> new UI framework in 2026
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.
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.
If anyone is going to get it right - I'd bet on the expo team. They know these sharp edges and have been building for them for years.
Ooph that readme is sloppy as.
this tendency to prioritize agents over humans for new software DX makes me sympathize with the Butlerian jihad.
In what way does this worsen human DX?
The announcement thread covers ways it helps agents, and they sound like things that would help humans, too.
Funny. I just learnt about nsh.dev a few hours ago.
A new trend?
Am I having a slow morning or is this all but unintelligible?
You need to be fluent in Claudish to understand the README (and let's not even talk about the code)
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.
I was under the impression that Flutter was the future for this stuff...then again I am ignorant to mobile dev.
Funny name because anything "exact" is the last thing you'd expect from this everchanging base
Cool toy, but it's unclear when this will be stable enough for production use.
Is this satire?
Is this a serious question? Why would it be satire? Is it building something you don’t like or want? Say what you actually mean.
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.
> What does "agent native" mean?
https://github.com/expo/exact#1-agent-native defines it
> What does "agent native" mean?
Agent native is said once in this readme, following an immediate explanation and specific features.
> 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...