Rendered at 06:40:46 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
scottpersinger 1 days ago [-]
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."
1ba9115454 24 hours ago [-]
Yeah, I couldn't get past that either.
23 hours ago [-]
btown 1 days ago [-]
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.
whazor 19 hours ago [-]
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.
Xirdus 1 days ago [-]
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.)
miffy900 2 hours ago [-]
yes I have- i learned WPF before React (back in 2011) and immediately fell in love with JSX - JSX is what XAML should've been from the get go. Same for razer syntax in blazor.
till this day you can't use linq to render a sequence of elements. Like people.Select(p => <div>{p.FullName}</div>);
it's such a shame XAML and Razer syntax haven't evolved.
jdthedisciple 24 hours ago [-]
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.
akoboldfrying 1 days ago [-]
Interested in what you find irksome about TSX?
halflife 1 days ago [-]
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.
whilenot-dev 23 hours ago [-]
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.
whilenot-dev 19 hours ago [-]
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?
halflife 17 hours ago [-]
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!
halflife 12 hours ago [-]
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.
satvikpendem 24 hours ago [-]
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.
halflife 20 hours ago [-]
I’m not talking about complex logic. Because simple conditions, iteration or switch statements are not supported with classic control flow.
troupo 24 hours ago [-]
> so you can’t have a class attribute
Because it's a thin wrapper directly translatable into a JS function call. `className` is JS
halflife 20 hours ago [-]
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
troupo 19 hours ago [-]
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"
halflife 17 hours ago [-]
Yes, it simplifies the engine, at the cost of developer experience. Like useMemo, that now is compiled in automatically with the new react compiler.
troupo 16 hours ago [-]
> 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.
halflife 12 hours ago [-]
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.
ricardobeat 21 hours ago [-]
`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.
I wish they'd stick with that for all properties though.
ricardobeat 19 hours ago [-]
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.
troupo 16 hours ago [-]
That is probably my bias showing, because I'd rather they adipted the JS property names for everything :) Less confusion
osullivj 23 hours ago [-]
Excellent point; this is exactly why I built a Forth runtime into my DSL. Expressions are resolved inter rather than intra frame render.
vmg12 1 days ago [-]
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
ogoffart 1 days ago [-]
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
satvikpendem 24 hours ago [-]
Slint is proprietary too unless you want to GPL your product.
pjmlp 22 hours ago [-]
Which is great, be allowed to earn as much as willing to give upstream.
Not paying for developer tools? No money as well.
ogoffart 21 hours ago [-]
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?
zoom6628 1 days ago [-]
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.
wahnfrieden 1 days ago [-]
Isn’t it free
tdhz77 1 days ago [-]
The world has moved away from JavaScript. With llm, native is easy and the best option even for a single developer.
ojr 1 days ago [-]
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
fodkodrasz 23 hours ago [-]
Well, one can at least hope...
jmathai 1 days ago [-]
I converted a native iOS app to Android in 4 nights. Now every feature I add gets created in both simultaneously. Wild times.
soon_to_be_sb 1 days ago [-]
Thank god if true, but dependence on LLMs is not great for the developers. At least good thing for the end user.
wahnfrieden 14 hours ago [-]
No JS required here
pjmlp 22 hours ago [-]
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.
wahnfrieden 1 days ago [-]
No JS here
cyberax 1 days ago [-]
So what's going to happen once the slop becomes too large for the context?
sirjaz 1 days ago [-]
Why isn't Windows supported. Thr largest desktop platform out there?
zdragnar 1 days ago [-]
Because it is an early alpha release maybe?
pjmlp 22 hours ago [-]
Not enough Claude tokens available, most likely.
kyriakos 1 days ago [-]
Or android
wumms 1 days ago [-]
[dead]
q4y2u35uk 1 days ago [-]
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.
gen2brain 22 hours ago [-]
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.
pjmlp 22 hours ago [-]
Nope, this is all AI.
jdthedisciple 24 hours ago [-]
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.
mastermage 24 hours ago [-]
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.
calgoo 22 hours ago [-]
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.
joshheitzman 23 hours ago [-]
It doesn't run on Android either.
fodkodrasz 23 hours ago [-]
Well, if it doesn't support Windows or Android, it's only missing 74% of the global computing market. Technically cross-platform, of course.
solarkraft 1 days ago [-]
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.
hysan 1 days ago [-]
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.
vmg12 1 days ago [-]
Yeah, it's an early alpha they announced on twitter today.
wahnfrieden 1 days ago [-]
Expo CEO estimated 2-3 months until production-ready
yewenjie 1 days ago [-]
Why isn't Android support there?
solarkraft 1 days ago [-]
Presumably they’re focusing on a few platforms first. As they noted it’s coming though
tyleregeto 1 days ago [-]
They mention Android on the linked page. It's a work in progress, but further behind.
justauserid 1 days ago [-]
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 :)
gen2brain 22 hours ago [-]
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.
childintime 17 hours ago [-]
Wow this is impressive.
ogoffart 18 hours ago [-]
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.)
Flutter. It is very mature as it came before the wave of AI slop and works everywhere without issue, especially mobile.
justauserid 14 hours ago [-]
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....
paulhebert 1 days ago [-]
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
miguelspizza 1 days ago [-]
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…
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
nstart 3 hours ago [-]
[dead]
lcnmrn 1 days ago [-]
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.
bayeslearner 1 days ago [-]
[flagged]
ltearno 1 days ago [-]
[flagged]
henry-hong 21 hours ago [-]
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.
No. ccheever/exact2 is the development upstream. expo/exact is Expo’s public release of that codebase
bakugo 1 days ago [-]
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?
sakesun 1 days ago [-]
Funny. I just learnt about nsh.dev a few hours ago.
A new trend?
doodlesdev 1 days ago [-]
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.
tevon 1 days ago [-]
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.
Culonavirus 1 days ago [-]
> 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.
egorfine 22 hours ago [-]
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.
mrbombastic 1 days ago [-]
this tendency to prioritize agents over humans for new software DX makes me sympathize with the Butlerian jihad.
wahnfrieden 1 days ago [-]
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.
smcleod 1 days ago [-]
Ooph that readme is sloppy as.
jacknews 1 days ago [-]
Am I having a slow morning or is this all but unintelligible?
hmry 1 days ago [-]
You need to be fluent in Claudish to understand the README (and let's not even talk about the code)
hollowturtle 22 hours ago [-]
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
brainless 1 days ago [-]
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.
eviks 1 days ago [-]
Funny name because anything "exact" is the last thing you'd expect from this everchanging base
wahnfrieden 14 hours ago [-]
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.
mplewis 1 days ago [-]
Cool toy, but it's unclear when this will be stable enough for production use.
orliesaurus 1 days ago [-]
I was under the impression that Flutter was the future for this stuff...then again I am ignorant to mobile dev.
prmph 1 days ago [-]
Is this satire?
jkahrs595 1 days ago [-]
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.
prmph 1 days ago [-]
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".
wahnfrieden 1 days ago [-]
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.
Agent native is said once in this readme, following an immediate explanation and specific features.
giancarlostoro 1 days ago [-]
> 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...
ricardobeat 21 hours ago [-]
> 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.
ltearno 1 days ago [-]
[flagged]
gib444 24 hours ago [-]
3 times now you've self promoted in this post. Perhaps submit your own HN post
"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."
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.
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.
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.
till this day you can't use linq to render a sequence of elements. Like people.Select(p => <div>{p.FullName}</div>);
it's such a shame XAML and Razer syntax haven't evolved.
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.
#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/
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.
> 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?
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:Anyway, thanks for the quick human exchange of opinions!
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.
Because it's a thin wrapper directly translatable into a JS function call. `className` is JS
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.
However angular, svelte, vue and more have a specific DSL for templating.
React opted for backwards compatibility at the time it came out, and never made the upgrade - you can write `class` in Preact.
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.
One difference is that Slint is more mature: it's been 1.x with a stable API since 2023
Not paying for developer tools? No money as well.
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.
I see these projects and feel as enthusiastic as reading the ingredients of a frozen pizza package.
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.
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.
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 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.
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
Amazing things are happening in this codebase.
I don’t really get why you would ever want your source code formatted like that, with or without LLMs
https://github.com/expo/exact/blob/main/host/web/capture.js
It's obvious what its game is
Like... some way to "branch" out of the main development repo and make changes independent of it before "merging" it back in?
A new trend?
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.
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 announcement thread covers ways it helps agents, and they sound like things that would help humans, too.
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.
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".
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
Agent native is said once in this readme, following an immediate explanation and specific features.
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...
> 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.