5 ms·

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

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-native-devs 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.

pzo 3y ago
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 https://github.com/fzyzcjy/flutter_rust_bridge
- tracker1 3y ago
  Cool... was just thinking one could use flutter's web target with tauri's interop and host model.
madnirua 3y ago
Thanks.. This is a nice reference for an onboarding guide.. We could add a similar section to our documentation page https://slint.dev/docs https://slint.dev/docs
nologic01 3y ago
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.
- madnirua 3y ago
  Not sure why or who downvoted. We will add more detailed comparison in our documentation. Thanks.
- timeon 3y ago
  > (pressumably) Why do you suppose this in particular?
  - nologic01 3y ago
    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 https://news.ycombinator.com/item?id=36340925
    - ShadowBanThis01 3y ago
      People downvote perfectly reasonable questions or comments here plenty often. And even more pile on if you dare to call this infantile behavior out.
nu11ptr 3y ago
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)
- dist-epoch 3y ago
  > You get an API and ability to run client and server on different machines as well So like a web app.
  - nu11ptr 3y ago
    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.
- monroewalker 3y ago
  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.
  - nu11ptr 3y ago
    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).
    - monroewalker 3y ago
brabel 3y ago
Wow, that Flutter Doc page is beautiful... and seems fairly comprehensive, kudos to them.

pzo 3y ago

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 https://github.com/fzyzcjy/flutter_rust_bridge

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

madnirua 3y ago

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

nologic01 3y ago

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.

madnirua 3y ago
Not sure why or who downvoted. We will add more detailed comparison in our documentation. Thanks.
timeon 3y ago
> (pressumably) Why do you suppose this in particular?
- nologic01 3y ago
  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 https://news.ycombinator.com/item?id=36340925
  - ShadowBanThis01 3y ago
    People downvote perfectly reasonable questions or comments here plenty often. And even more pile on if you dare to call this infantile behavior out.

nu11ptr 3y ago

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)

dist-epoch 3y ago
> You get an API and ability to run client and server on different machines as well So like a web app.
- nu11ptr 3y ago
  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.
monroewalker 3y ago
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.
- nu11ptr 3y ago
  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).
  - monroewalker 3y ago

brabel 3y ago

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