Hacker News new | past | comments | ask | show | jobs | submit login

The comparison sections are very confusing. It says you will compare your UI toolkit with, for example, Flutter and then there is no comparison there at all. I thought the site is broken on mobile, I tried different browsers, etc, because the comparison was just not there.

If you don't have any real content there because you don't want to start a flame war, you could try something like what the Flutter team did, they have an "onboarding guide" for XYZ developers that builds upon things you already learned in other frameworks and explains the key differences without coming off as hostile towards the other frameworks.

https://docs.flutter.dev/get-started/flutter-for/react-nativ...

I'm a Flutter developer by day and Rust enthusiast by night, and I'm looking for a "good enough" Flutter alternative that uses Rust.




This is what I do:

- Write the backend in Rust

- Write the UI in Flutter

- Tie them together using gRPC. You get an API and ability to run client and server on different machines as well

I looked at the flutter to rust bridge and started to play with it, but assuming your UI can withstand the slight overhead of gRPC I found it a simpler way to proceed (although I'm not that far in yet)


I have the same but I wouldn't recommend gRPC. It adds a ton of overhead and complexity that you don't want. Plus you have to deal with all the complexity of Protobuf and the fact that everything becomes `Option<>`.

Instead I wrote my own RPC system using Serde and Bincode. Communication is over stdio, that way you can support SSH access extremely easily (like VSCode remote).

Unfortunately it was for a company so the code isn't public, but there really wasn't much code to the RPC system at all since you don't need to worry about versioning, authentication, transport, etc. I write a very simple schema language, used Nom to parse it and generate Rust, Typescript and Dart code. The Rust code generation is trivial since you can just `#[derive(Serialize...]`. Typescript / Dart was a bit more complicated (you have to implement Bincode) but it's not very difficult really.

By far the most complex thing is trying to integrate with SSH. If you call `ssh` directly then you end up having to parse non-machine-readable prompts and errors and so on. But if you use a proper SSH library then you end up having to implement ssh-agent, read `~/.ssh/config` etc. yourself which isn't fun either.


This is interesting enough I want to look into it if nothing else than for the geek/cool factor, but the thing I like about gRPC is it gives me layer I can let my client consume as an API (although REST is likely sufficient for this). I actually have an internal API and then two little shim/wrapper layers over the top: one for gRPC and one for REST. My UI consumes the gRPC API. I also want my Rust server to have an independent lifetime from the UI so it can do work in the background. I suspect my use case is just a little different.

NOTE: I found this crate that would likely help with Dart codegen of message types: https://crates.io/crates/serde-generate. While stdin/out wouldn't likely work for me, I could use a TCP socket bound to localhost or named pipe as alternative for the transport piece.


I'm looking at something similar with Go as the backend. Why gRPC instead of a pipe? I started with that as well since it was really easy to set up but that comes with the caveat of requiring network permissions even though it's local to local communication.


Pros and cons: with a pipe it will be up to you to create your own message delimiters and protocol, so a pipe is somewhat lower level. You also limit comm. to just that machine, but that may be a pro if that is what you are looking for (omits need for things like username/password or locking to 'localhost'). Lastly, you do not gain an API for your users to consume (if that makes sense for your app - it doesn't always).


Protoc actually generates "writeDelimitedMessage" and "readDelimitedMessage" functions for each type. The only thing I needed to add was some buffering on the Dart side to ensure the full message was available. The Go side was able to read the stream and block until input became available


Interesting - so you are using protobuffer encoding over a named pipe?


Yes but just over stdin/stdout since I'm creating the backend as a subprocess. Not sure if it makes more sense to have the backend be the parent and the flutter app be the subprocess but this is working so far.


> You get an API and ability to run client and server on different machines as well

So like a web app.


Yes, nothing to stop you from substituting Flutter for your frontend of choice including a web-based SPA, but then you would need the gRPC-web extension to call gRPC from a browser. The Rust Tonic crate has this available for the server side.


Have you seen flutter_rust_bridge? I use that to write business logic in Rust, if I need to use Rust crates. I did that recently for a CRDT library called Automerge.


Not a Flutter Dev, but have you tried 'flutter_rust_bridge' [0]. Seems provide some interop between flutter and rust and looks like a popular and active project. I'm native mobile dev and just curious about this kind of interop myself. If it's seamless then looks like good balance to do mobile front-end in flutter and mobile backend in rust.

[0] https://github.com/fzyzcjy/flutter_rust_bridge


Cool... was just thinking one could use flutter's web target with tauri's interop and host model.


Thanks.. This is a nice reference for an onboarding guide.. We could add a similar section to our documentation page https://slint.dev/docs


Made a similar comment about the comparison pages, which is a simple and factual statement yet was downvoted immediately by (pressumably) people with a stake in the project. Does not reflect well...

Detailed and unbiased comparisons are extremely useful but also are hard (and costly) to do. Don't promise them if you can't deliver.


Not sure why or who downvoted.

We will add more detailed comparison in our documentation. Thanks.


> (pressumably)

Why do you suppose this in particular?


my lack of imagination as to what might be otherwise motivating HN members to "engage" in this way :-)

I mean I can't imagine anybody having an independent interest in the project (like I do) and actually thinking that the comparison provided was adequate.

As said in my original comment, this is an area where a sense of sub-optimal status quo is palpable and people search for some sort of rationalization of the various nascent possibilities and options. Just a few days ago somebody was talking "parallel futures" (in mobile context) [1]

[1] https://news.ycombinator.com/item?id=36340925


People downvote perfectly reasonable questions or comments here plenty often. And even more pile on if you dare to call this infantile behavior out.


Wow, that Flutter Doc page is beautiful... and seems fairly comprehensive, kudos to them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: