Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Async UI: A Rust UI Library Where Everything is a Future

wishawa.github.io

Post reply on HN
Print view View original

1–10 of 96 posts

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#2

Post by wishawa »

Hi HN! I've been working on Async UI for half a year now, and I think it is time I share it with everyone. The project is not even really usable yet (due to lack of implemented components and documentation), but I think the proof-of-concept is enough to demonstrate this new way of doing UI — a way that, I believe, is more suitable to Rust than existing UI framework designs.

P.S. My website is new, so if you find any readability or accessibility issue, please let me know!

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#3

Post by karmakaze »

wishawa wrote: post #2

Hi HN! I've been working on Async UI for half a year now, and I think it is time I share it with everyone. The project is not even really usable yet (due to lack of implemented components and documentation), but I think the proof-of-concept is enough to demonstrate this new way of doing UI — a way that, I believe, is more suitable to Rust than existing UI framework designs. P.S. My website is new, so if you find any…

I don't use Rust (yet) but was still curious how this looks-n-feels. I get a distinct React JSX vibe from it. I get that this is a very flexible way of building but at the same time I prefer having the component templates 'at the top' as in Vue rather than control flow. Even Vue is built from using builder control flow underneath so it's a different authoring environment vs different implementation. Another one that's interesting is Elm.

Best of luck and I'll be checking out where this ends up going.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#5

Post by wishawa »

lucasyvas wrote: post #4

This is wild to me... how does that login_form function work? If awaiting renders, then it can also return values?

You're right that components should intuitively pend forever. But with Async UI, the line between a component and a normal async function is blurry; our login_form eventually returns, so it is a normal async function, but it also renders something, so it is kind of a component...

Concretely the login_form function works by racing a render (a true, never-completing component) with a "listener" future that completes when the user submits their login. Once the listener completes, the race is over and the render future gets dropped. We can then return from login_form.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#7

Post by lucasyvas »

wishawa wrote: post #5
lucasyvas wrote: post #4

This is wild to me... how does that login_form function work? If awaiting renders, then it can also return values?

You're right that components should intuitively pend forever. But with Async UI, the line between a component and a normal async function is blurry; our login_form eventually returns, so it is a normal async function, but it also renders something, so it is kind of a component... Concretely the login_form function works by racing a render (a true, never-completing component) with a "listener" future that completes wh…

This pretty interesting - does it take inspiration from anything? I personally haven't seen anything like this.

It would also be great to see example code for that - it's the most significant part where I was looking for more information but couldn't find it.

Edit: A bit unrelated, but the tokio vs async-std split continues!

Edit 2: How does error handling work? Is check_login a component or regular request?

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#8

Post by wishawa »

lucasyvas wrote: post #7
wishawa wrote: post #5

Earlier quoted context omitted.

You're right that components should intuitively pend forever. But with Async UI, the line between a component and a normal async function is blurry; our login_form eventually returns, so it is a normal async function, but it also renders something, so it is kind of a component... Concretely the login_form function works by racing a render (a true, never-completing component) with a "listener" future that completes wh…

This pretty interesting - does it take inspiration from anything? I personally haven't seen anything like this. It would also be great to see example code for that - it's the most significant part where I was looking for more information but couldn't find it. Edit: A bit unrelated, but the tokio vs async-std split continues! Edit 2: How does error handling work? Is check_login a component or regular request?

The full example code is here: https://github.com/wishawa/async_ui/blob/main/examples/gtk-l....

(except for that invalid_login_popup is not a real popup because I haven't implemented popups yet)

I'll add a link to it in the blog post.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#10

Post by wishawa »

lucasyvas wrote: post #7
wishawa wrote: post #5

Earlier quoted context omitted.

You're right that components should intuitively pend forever. But with Async UI, the line between a component and a normal async function is blurry; our login_form eventually returns, so it is a normal async function, but it also renders something, so it is kind of a component... Concretely the login_form function works by racing a render (a true, never-completing component) with a "listener" future that completes wh…

This pretty interesting - does it take inspiration from anything? I personally haven't seen anything like this. It would also be great to see example code for that - it's the most significant part where I was looking for more information but couldn't find it. Edit: A bit unrelated, but the tokio vs async-std split continues! Edit 2: How does error handling work? Is check_login a component or regular request?

The async control flow is not directly inspired by anything. It is a cool side effect of using async for everything that I myself only discovered once I started writing examples.

Async UI as a whole is inspired by the simple fact that UI is an effect system[1], and async is also an effect system.

[1]: https://en.wikipedia.org/wiki/Effect_system

Re async split: Diversity promotes innovation :)

Re error handling: There's no real support yet. For now when I hit an error I just render nothing. I might add support for components returning Result in the future.

Post reply on HN