has a SwiftUI resemblance, nice :)
Only in small examples. This doesn't look that much like SwiftUI to me: https://github.com/wishawa/async_ui/blob/main/examples/web-t...
Show HN: Async UI: A Rust UI Library Where Everything is a Future
71–80 of 96 posts
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#72This is an interesting idea, but if you look at bigger examples, such as the todo-list example, the code is littered with `async` noise, calls to `borrow()`, and other fancy stuff like reducers. (A todo list is easily expressed in SwiftUI without much ceremony) Seems like scaling up to actual apps would be a mess. https://github.com/wishawa/async_ui/blob/main/examples/web-t...
That example is indeed pretty noisy, but partly due to my premature optimization. The operations of adding, editing, and toggling Todo items are all O(log N)[1]. Things could be simpler if I’d just take the O(N).
[1] O(log N) for “our” code. I don’t know what the browser’s rendering/layouting engine is doing.
In general Async UI will still be noisier than SwiftUI or React, but I hope only in the way that Rust is more explicit/verbose than other languages.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#73Earlier quoted context omitted.
> You can do the same with goroutines/green threads/virtual threads goroutines capture a lot more state than an async continuation/future. The same argument you made below against OS threads applies here too.
What state does a userspace thread have to capture in order to work that a coroutine doesn't?
A userspace thread captures full a stack context, a delimited continuation used in async programming captures only the referenced variables needed for the remaining computation. This is a strict subset of the userspace thread state.
For instance:
fn f() { var v1 = ..., var v2 = ...; g(v2); }
fn g(v2) { await; /* do something with v2 */ } // await is a context switch
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#74sigh how did we all survive before async UI... ¬‿¬
By lots of 'static and Rc.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#75It's 2.56 MB gzip!
The Todo example is 2.5 MB non-gzipped. About 600KB gzipped.
Still large, but it's because we're shipping a lot of code that we don't need. Mostly the APIs exposed by web_sys. Proper dead code elimination would bring it down a lot.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#76Looks a bit like concur JS
I must admit I've never seen Concur before!.The idea of using generator/async is pretty similar. The difference, as I understand, is that in Concur, you yield the widget and let the framework mount it, while in Async UI, you await the widget yourself.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#77Earlier quoted context omitted.
Are we talking about Rust or async/await syntax in the abstract? Async/await syntax is needed if you want to have a `with` block that managed resources across co-routine boundaries. Consider Python's `async with` which will create a resource that is freed when the co-routine leaves the execution context. This is distinct from Java's try-with-resources which doesn't work with async code. So anytime you use `try (Telem…
> Async/await syntax is needed if you want to have a `with` block that managed resources across co-routine boundaries. I don't see what is the connection between async/await syntax and managing resources. The `with` block is just another mechanism for managing resources - Go has the `defer` statement which runs the deferred function at the end of currently executing function block, providing the equivalent functional…
Ok, I thought you were saying callback hell is cool. But I think you're saying async-first is the way it should be and the runtime should handle it. Which is a good idea in most cases. I think Go is pretty awesome for this approach.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#78Could you compare it with Sycamore with a few bullet points? I feel like it is pretty close even though you don't see the async exposed? L
Sycamore works pretty similarly to React. See https://www.reddit.com/r/rust/comments/xvv49w/comment/ir6pw0... for how Async UI is different from React-style frameworks.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#79This is an interesting idea, but if you look at bigger examples, such as the todo-list example, the code is littered with `async` noise, calls to `borrow()`, and other fancy stuff like reducers. (A todo list is easily expressed in SwiftUI without much ceremony) Seems like scaling up to actual apps would be a mess. https://github.com/wishawa/async_ui/blob/main/examples/web-t...
That example is indeed pretty noisy, but partly due to my premature optimization. The operations of adding, editing, and toggling Todo items are all O(log N)[1]. Things could be simpler if I’d just take the O(N). [1] O(log N) for “our” code. I don’t know what the browser’s rendering/layouting engine is doing. In general Async UI will still be noisier than SwiftUI or React, but I hope only in the way that Rust is more…
Hmm, surely a SwiftUI todo list could be implemented using O(log n) operations with ease. Anyway I think that example might scare people off, so definitely try to simplify it if you can :)
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#80Looks a bit like concur JS
I must admit I've never seen Concur before!.The idea of using generator/async is pretty similar. The difference, as I understand, is that in Concur, you yield the widget and let the framework mount it, while in Async UI, you await the widget yourself.
isn't it better for the framework to mount it etc? seems like things might get out of control in large apps otherwise.