async_ui
composePPT
async_ui | composePPT | |
---|---|---|
7 | 3 | |
549 | 300 | |
- | - | |
8.4 | 1.8 | |
about 2 months ago | about 1 year ago | |
Rust | Kotlin | |
Mozilla Public License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
async_ui
-
A Proposal for an asynchronous Rust GUI framework
I'm very interested in seeing if using the commonly implemented forms of compiler support for async programming can also be well used for GUI programming. One wishawa[0] is also perusing this approach in Rust but I first came upon this idea from the crank-js[1] authors. It wasn't clear to me why that one never went anywhere. Was it failure with the approach or was React just a good solution in the space? I can say this though, there's something strikingly elegant about those initial samples of using JavaScript generators for components.
[0]: https://github.com/wishawa/async_ui
[1]: https://github.com/bikeshaving/crank
Not OP, but... I'd argue that async style event handling is even more readable then the traditional way of using callbacks. Take a look at this counter example in Async UI (a project I've been working on that's very similar to what OP purposes); my event handlers are all in the same place, and my state (the value variable) is a regular variable; no reactivity primitive needed.
-
What is the "idiomatic" approach to events/callbacks?
If you are doing ui events, then you can have a look at wishawa/async_ui.
-
Show HN: Async UI: A Rust UI Library Where Everything Is a Future
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...
- Async UI: a Rust UI Library where Everything is a Future
composePPT
-
30k lines of SwiftUI in production later
Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[4]) is infinitely more polished and has better tools than anything Apple has put out in all of SwiftUI's existence. Apple is bringing this upon themselves with their "major updates" concept for SwiftUI coming every other year, where components aren't even available on old versions of iOS. A UI toolkit is a library like any other, version it like a library and match patch releases.
[1] https://compose-web.ui.pages.jetbrains.team/
[2] https://github.com/JakeWharton/mosaic
[3] https://github.com/fgiris/composePPT
[4] https://github.com/googlemaps/android-maps-compose
-
Show HN: Async UI: A Rust UI Library Where Everything Is a Future
Today in "HN never used a reactive framework that is not React and is offended when UI is not written with Dear ImGui".
This is literally the exact style of SwiftUI and Jetpack Compose (down to the author having used the term fragment, I sure hope this isn't leftover trauma from being an Android developer), except written in Rust (hence having to deal with lifetimes in the middle, default parameters, lambdas being quite verbose and needing to move things, etc).
Not blocking the UI thread is mandatory if you ever want to make any kind of complex UI. If you're a web dev, well you only have one thread anyways, good luck, if you're on any other platform, interactions _cannot_ ever block the UI (unless you, yourself, update the UI to say it is blocked). Making this async is a good thing.
Stack traces are a problem, but then again they've been a problem in any remotely capable UI toolkit.
With ReactiveCell, it looks surprisingly similar to what Compose does, where modifying a State causes recomposition of everything observing it. Which means that it might be powerful enough one day to do the same things as Molecule (https://github.com/cashapp/molecule), or ComposePPT (https://github.com/fgiris/composePPT), where everything is a potential target and it interops really well with existing toolkits.
- GitHub - fgiris/composePPT: An experimental UI toolkit for generating PowerPoint presentation files using Compose
What are some alternatives?
Caliburn.Micro - A small, yet powerful framework, designed for building applications across all XAML platforms. Its strong support for MV* patterns will enable you to build your solution quickly, without the need to sacrifice code quality or testability.
android-maps-compose - Jetpack Compose composables for the Maps SDK for Android
molecule - Build a StateFlow stream using Jetpack Compose
crank - The Just JavaScript Framework
MoonZoon - Rust Fullstack Framework
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
rui - Declarative Rust UI library
rust-dominator - Zero-cost ultra-high-performance declarative DOM library using FRP signals for Rust!
Uno Platform - Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.