<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: jbrownson</title><link>https://news.ycombinator.com/user?id=jbrownson</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 14 Jun 2026 23:16:13 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=jbrownson" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by jbrownson in "The state of building user interfaces in Rust"]]></title><description><![CDATA[
<p>Everyone seems to be converging on React/Elm arch for UI. I saw a paper years ago for incremental lambda calculus (<a href="https://inc-lc.github.io" rel="nofollow">https://inc-lc.github.io</a>) that I feel addresses the fundamental problem here more honestly. It's mostly intended for optimizing repeated computations after small changes to the inputs, but I think it applies nicely to UI. Our data model needs to be a change structure along with our UI model. We write a function from our data model to the UI model just like React, but we also get a function from deltas on the data model to deltas on the UI model. The main thing missing that we would need for UI is since we get a stream of deltas on both the data model and UI model (scrolling, selecting, etc) we need to merge them.<p>This way we don't have to zipper together each "frame" of the output tree trying to figure out which bit goes to which other bit, we get an explicit delta saying "the 5th thing got deleted". You do probably need a language with HKT for this.<p>I mentioned this to Phil Freeman years ago and he did a prototype in Purescript, but I haven't seen it anywhere else: <a href="https://github.com/paf31/purescript-purview" rel="nofollow">https://github.com/paf31/purescript-purview</a><p>Another thing I'd like to see is a _truly_ immediate mode framework where each widget is a pure function to render it given its state, and it's up to the user to manage the UI state (scroll position, text cursor location, etc), you can mix it in with/ your data model, or whatever. Even egui/etc aren't truly immediate as they need to keep some sort of stable identity for events, UI state and focus. You could of course build a React like thing on top of that, but it would be helpful to have that for experimentation with wildly different state models without having to reinvent the text box and everything yet again. I've started some experimentation w/ this in Haskell and it's going well so far.</p>
]]></description><pubDate>Sun, 14 Jun 2026 04:58:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=48524321</link><dc:creator>jbrownson</dc:creator><comments>https://news.ycombinator.com/item?id=48524321</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48524321</guid></item></channel></rss>