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."
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.
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.
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.
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:
The suggested JSX approach depends on the example you just made up, and EMCAScripts statements are enough, there's no need to redefine them in JSX.
<div class="container">
My list
{
list.map((item) => {
let text = null;
if (item.loading) {
text = "Loading...";
} else if (item.error) {
text = "Error loading item";
} else {
text = item.description;
}
return (
<>
<h2>{item.name}</h2>
<p>{text}</p>
</>
);
})
}
</div>
or (btw, I have never seen somebody creating a component for a list)
function Item({item}) {
let text = null;
if (item.loading) {
text = "Loading...";
} else if (item.error) {
text = "Error loading item";
} else {
text = item.description;
}
return (
<>
<h2>{item.name}</h2>
<p>{text}</p>
</>
);
};
<div class="container">
My list
{list.map(item => <Item item={item} />)}
</div>
I still don't see any limitation. The @statement-things don't read better either.
Anyway, thanks for the quick human exchange of opinions!
In my suggestion I demonstrated a theoretical approach to how I think JSX shouldve been done.
JSX eventually is not a templating engine, it’s just sugar over createComponent/createElement functions, and thats its downside, we are creating html components that need templates to render.
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.
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.
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.
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 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?
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 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
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.
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.
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.
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.
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.)
I come from Android so had early exposure to Flutter. It used to draw every single pixel of the UI on every platform. Felt kinda weird. I guess the point of native UI is to use native UI controls offered. Though I must say that is much better than react native and electron, still. I will check it again. Thanks for reminding.
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
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 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.
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 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.
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
I don’t understand all the comments mocking this for not supporting windows and android. It’s a pre-alpha and those platforms are on the roadmap with partial progress.
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...
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.
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.
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.
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/
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:
> simple workflow controls would read much better
What's your alternative?
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:
This is much easier than the suggested JSX approach:The suggested JSX approach depends on the example you just made up, and EMCAScripts statements are enough, there's no need to redefine them in JSX.
or (btw, I have never seen somebody creating a component for a list) I still don't see any limitation. The @statement-things don't read better either.Anyway, thanks for the quick human exchange of opinions!
In my suggestion I demonstrated a theoretical approach to how I think JSX shouldve been done.
JSX eventually is not a templating engine, it’s just sugar over createComponent/createElement functions, and thats its downside, we are creating html components that need templates to render.
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.
I’m not talking about complex logic. Because simple conditions, iteration or switch statements are not supported with classic control flow.
> so you can’t have a class attribute
Because it's a thin wrapper directly translatable into a JS function call. `className` is JS
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. Like useMemo, that now is compiled in automatically with the new react compiler.
> 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.
There are many reasons why JSX is popular, react being the biggest one, where subsequent frameworks wanted to leverage people’s knowledge.
However angular, svelte, vue and more have a specific DSL for templating.
`class` is a valid property name in JS, since ES5 (2009).
React opted for backwards compatibility at the time it came out, and never made the upgrade - you can write `class` in Preact.
> React opted for backwards compatibility
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.
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.
That is probably my bias showing, because I'd rather they adipted the JS property names for everything :) Less confusion
Excellent point; this is exactly why I built a Forth runtime into my DSL. Expressions are resolved inter rather than intra frame render.
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 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.
Which is great, be allowed to earn as much as willing to give upstream.
Not paying for developer tools? No money as well.
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?
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
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 required here
Sadly, the world has moved away from coding in itself.
I see these projects and feel as enthusiastic as reading the ingredients of a frozen pizza package.
No JS here
So what's going to happen once the slop becomes too large for the context?
Why isn't Windows supported. Thr largest desktop platform out there?
Because it is an early alpha release maybe?
Not enough Claude tokens available, most likely.
Or android
[dead]
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.
Nope, this is all AI.
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.
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.
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.
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
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.
Wow this is impressive.
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.)
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.
I come from Android so had early exposure to Flutter. It used to draw every single pixel of the UI on every platform. Felt kinda weird. I guess the point of native UI is to use native UI controls offered. Though I must say that is much better than react native and electron, still. I will check it again. Thanks for reminding.
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
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.
[flagged]
[flagged]
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.
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?
Funny. I just learnt about nsh.dev a few hours ago.
A new trend?
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.
> 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.
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.
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.
Ooph that readme is sloppy as.
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)
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
I don’t understand all the comments mocking this for not supporting windows and android. It’s a pre-alpha and those platforms are on the roadmap with partial progress.
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.
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.
I was under the impression that Flutter was the future for this stuff...then again I am ignorant to mobile dev.
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...
> Layout is CSS's, because a person can't see a layout default, only its result
> 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.
[flagged]
3 times now you've self promoted in this post. Perhaps submit your own HN post
Thanks, I flagged all the comments