Rinf vs flutter_rust_bridge

[qwerty108109]

What are the main differences between these packages?

[temeddix]

Though Rinf and flutter_rust_bridge look similar, Rinf is relatively new and includes many improvements. Let me list a few important aspects:

• It only takes about about a minute or two to fully setup your app. With Rinf, you don't have to mess around with sensitive build files such as Cmake, gradle, podfile, XCode, etc... like flutter_rust_bridge, it just compiles out of the box. I can say that this is the biggest difference.
• Rinf is reliable in the long-run, say, many years. All of Rinf's components(Rust, Flutter, Protobuf) are backed by huge communities, so we don't have to worry about those supports being suspended someday. flutter_rust_bridge had many months of halt because the complex codegen mechanism requires core maintainers' hand, thus leaving the users with outdated dependencies and logics. Rust's ecosystem is evolving, and sometimes we need to adapt to the new trend(Such as wasm32-wasi for the web). Because flutter_rust_bridge's codebase is quite complex, it is not really easy for them to adapt to the change of the ecosystem. Rinf provides rinf template --bridge command, which easily lets you adapt to the newest status.
• Rinf is not a bulky framework that requires you to install so many additional dependencies and use complicated CLI commands, and you can just focus on your code using your preferred Flutter and Rust libraries. If you use flutter_rust_bridge, installing side dependencies and memorizing CLI command can be a burden. There are also very many unnecessary dependencies with flutter_rust_bridge, such as anyhow, that you don't really need in your app.
  • 
• Rinf is well maintained. Our automated workflows including build tests are always kept passing, thanks to the main branch protection rule. This is not the case for flutter_rust_bridge, where GitHub actions are unconsciously accumulated and gotten out of hand, leaving CI broken for many months only to make contributors fix them(to merge a simple PR!). I've noticed that maintainers are bypassing CIs and directly pushing to the main branch at flutter_rust_bridge.
  • - Rinf
  • - flutter_rust_bridge
• Rinf is well documented and the guides are easy to read. We try to keep things minimal(yet powerful). You might get a sense of this as soon as you compare the docs...
  • Rinf: https://rinf-docs.cunarist.com
  • flutter_rust_bridge: https://cjycode.com/flutter_rust_bridge/
  • 
• Efficient: With Rinf, there's no memory copy when sending native data(which is also kind of true for flutter_rust_bridge), but there's also no hidden threads and web workers with memory overhead. We provide async system instead of threads, which is very useful when you need more than a few thousand concurrent tasks(such as network IO). This also leads to better web browser support, because you don't need to pass data between web workers that don't share memory as RustOpaque(of flutter_rust_bridge). Just using once_cell is enough.
• Logical API: You declare RESTful messages, not functions for APIs, which provides greater stability. Messages are type-safe and flexible because it's powered by the well-known Protobuf serialization. flutter_rust_bridge does provide flexible function calls, but because it's quite complicated you cannot predict which part is supported well or not. For example, some people had to make a pull request to flutter_rust_bridge and also its dependency allo-isolate only to send some simple Vec<bool> to Dart because it wasn't supported until recently. Also, advanced types like SyncReturn don't work on the web, but things like those were not documented. There are many pitfalls here and there.
• File-based messages: With Rinf, there's no more headache from extremely big api.rs file that hinders readability. Even defining hundereds and thousands of API endpoints between Dart and Rust is easy and clean.
• Convenient debugging: All the debugging functionalities are provided by default, without the need for dealing with browsers or mobile emulators. flutter_rust_bridge suggests that you should create your own functions for that, which is an additional work.

EDIT: This description was written based on FRB v1, but things might be different on v2.

[ig-garcia]

There may be some difference though. In my case I want to do a Rust call from Flutter as a Future. It seems like Rinf is more oriented towards Streams. Can I perform a call as a Future without having to pass some id to tell apart the interaction?
Thanks in advance.

[temeddix]

Good question. Unfortunately no, since Rinf was made for storing the state alongisde business logic at the Rust side. Rinf is based on a philosophy that it's better to separate Rust's ownership and Flutter's GC system.

That's why Rinf only has message-driven event-based system.