[HN Gopher] Show HN: Rust GUI Library via Flutter
___________________________________________________________________
Show HN: Rust GUI Library via Flutter
Hi, I made a bridge (https://github.com/fzyzcjy/flutter_rust_bridge
v2.0.0) between Flutter and Rust, which auto translates syntaxes
like arbitrary types, &mut, async, traits, results, closure
(callback), lifetimes, etc. The goal is to make a bridge between
the two, seamlessly as if working in one single language. Then, as
an example, I showed how to write Rust applications with GUI by
utilizing Flutter. That is discussed in the link in details. To
play with it, please visit the GitHub repo, or refer to the end of
the article for detailed folders and commands. When I first
released 1.0.0 years ago, it only contained few features compared
to today. It is the result of the hard work of contributors and me,
and many thanks to all the contributors!
Author : fzyzcjy
Score : 258 points
Date : 2024-08-11 02:55 UTC (20 hours ago)
(HTM) web link (cjycode.com)
(TXT) w3m dump (cjycode.com)
| polyaniline wrote:
| How does this compare to rinf?
| abound wrote:
| And then there's also crux [1], which is the same "write your
| mobile app business logic once in Rust", but instead of
| Flutter, integrates directly with native iOS/Android/Web UIs
|
| [1] https://redbadger.github.io/crux/
| oneshtein wrote:
| Tauri supports mobile platforms too. Sadly, it's not a first
| class citizen in Tauri 2.0 as promised.
|
| I tried both Flutter and Tauri. IMHO: Tauri is better,
| because it allows me to use existing web frameworks (or even
| plain Markdown + Pandoc!), to make web-pages, while handling
| business logic in type safe Rust.
| itohihiyt wrote:
| Isn't Dart type safe?
| oneshtein wrote:
| Dart is order of magnitude slower than Rust.
| mdhb wrote:
| If you're doing some super intensive data processing or
| have specialist use cases then yeah, sure feel free to
| write that part in Rust, C or whatever you like.
|
| That's literally what this package is about. Unlocking
| that use case for you although Dart also has bindings for
| Go, Java, Kotlin, C, and Swift so you can take your pick.
|
| But the reality is that Dart compiles down to native code
| on all platforms and is not going to be slower in any way
| that actually matters or is noticeable to users in the
| vast vast vast majority of scenarios and the productivity
| hit you take from moving to Rust or C from Dart is also
| an order of magnitude slower.
| itohihiyt wrote:
| I wasn't trying to be argumentative, and certainly rust
| is faster than dart, but if type safety is your main
| concern Dart/Flutter is less convoluted/complicated than
| rust+web frontend. In my opinion, obviously.
| fzyzcjy wrote:
| Thanks for the information, and I replied bubblebeard above
| about Tauri.
| fzyzcjy wrote:
| Yes, if someone needs to write UI using native Android/iOS
| code, Crux would be suitable. On the other hand, personally
| speaking, I prefer to write all code 1 time, but Crux seems
| to require to write the UI code 3 times for Android+iOS+Web.
| fzyzcjy wrote:
| The first image at the bottom of that post may be related to
| your question:
| https://www.reddit.com/r/rust/comments/191b2to/rinf_copies_a...
| Btw, why is your name green?
| operator-name wrote:
| Green usernames mean they're a new account! Here's a quote
| from the official FAQs:
|
| > What do green usernames mean? > Green indicates a new
| account.
|
| https://news.ycombinator.com/newsfaq.html
| fzyzcjy wrote:
| Thank you!
| burakemir wrote:
| Interesting! IIUC this is done using source-to-source
| translation? It is a bit hard to understand from the docs what
| technical approach is. The docs are clearly aimed at users and I
| find them impressive, well done. I'd be interested in knowing the
| approach and how it compares to wasm based Rust web frameworks
| before diving more deeply into it.
|
| One advantage of combining Rust with Flutter seems to be that
| Flutter is a whole framework already and one would be able to
| share code and data structures between server and client side.
|
| A comparison with other ways Rust
| fzyzcjy wrote:
| Thanks! Shortly speaking, the Rust code is parsed (e.g. "here
| is a function and there is a struct"), and then some Rust and
| Flutter code are generated. As for comparison, some pros and
| cons are discussed in the blog.
| tmpfs wrote:
| I have been using this to build an app[0] for the last couple of
| years and I want to say that it has been a pleasure to use, there
| are some wrinkles but overall I have been very happy with the
| experience.
|
| Upgrading from v1 to v2 was not too difficult and v2 is a
| significant upgrade with lots of useful features, massively
| improved codegen experience and support for tokio async were the
| big gamechangers for me.
|
| Writing all the app business logic in Rust and using Dart as the
| front-end works out really well. I know Flutter/Dart doesn't get
| much love here on HN but in my opinion I think it's much easier
| to reason about than a system like React which I think is the
| wrong level of abstraction compared to Flutter's render the
| entire widget tree approach.
|
| Massive thanks to @fzyzcjy for all the work on FRB, great job!
|
| [0]: https://saveoursecrets.com
| fzyzcjy wrote:
| You are welcome, and happy to hear it works for you!
| MrJohz wrote:
| > I know Flutter/Dart doesn't get much love here on HN but in
| my opinion I think it's much easier to reason about than a
| system like React which I think is the wrong level of
| abstraction compared to Flutter's render the entire widget tree
| approach.
|
| Could you expand on this a bit? My impression was that Flutter
| and React had relatively similar approaches to components, but
| I haven't had much experience with Flutter yet, so I'm
| interested to hear your experiences!
| mdhb wrote:
| I'm too lazy right now to get into all of the specifics but
| just wanted to drop a quick note to say that I've been doing
| web development since 1997 and the difference between React
| and Flutter is like day and night.
|
| It's genuinely hard for me to overstate the general quality
| of life improvements both from the developer experience and
| the overall quality of the apps I can produce in any given
| time frame.
|
| A big part of the reason for that is Dart is itself hands
| down the nicest language I've ever worked with. The team
| behind it got real serious when it comes to tooling and
| language design and everytime I have to go back to TypeScript
| I feel like I'm trying to run with a 50kg backpack on.
| satvikpendem wrote:
| They do have similar approaches, I'm not sure what the above
| commenter is saying as both work basically the same (with
| React class components at least). Flutter doesn't have hooks
| but they're addressing that via macros next year, and anyway
| today there are packages like flutter_hooks and ReArch that
| enable hook-like functionality in Flutter today.
| tmpfs wrote:
| At a basic level Flutter renders the entire widget tree and
| caches components that don't need to re-render rather than
| applying a diff of changes to the DOM.
|
| But it's really the Flutter/Dart API and widgets that make it
| much easier to work with, if I need to load some data
| asynchronously I use a `FutureBuilder`, if I need a stream of
| events I can use `StreamBuilder` etc. Compared to Reacts
| state, hooks, memo, effects etc. you end up with code that is
| far easier to reason about what is rendering when and why.
|
| Oh and the real killer feature is Flutters hot reload
| experience, it's easily the best DX I've seen for GUI work.
|
| As another comment mentioned it really is like night and day.
| I recommend giving it a try.
| MrJohz wrote:
| I don't quite understand the point about rendering, unless
| you mean it in the Angular sense (i.e. on every state
| update, the whole app gets rendered, and elements are
| updated to the new state during that render).
|
| But I can imagine that the API can be easier. I think React
| handles state fairly well, but as soon as that state needs
| to interact with things outside the React world (http
| requests, continuously updating data, etc) then the current
| abstractions don't quite feel right.
| beanjuiceII wrote:
| react and flutter are pretty much the same thing, i do
| both for a living i am not sure what this person is going
| on about
| nu11ptr wrote:
| React = one small piece of a very large required ecosystem
| (HTML + CSS + Javascript + NPM + React + Vite + ???)
|
| Flutter = a UI framework for mobile/desktop/web (Flutter +
| Dart)
|
| On top of the purpose built nature, nearly everything is a
| Widget, even layout/styling making it pretty easy to grok
| very quickly.
| amelius wrote:
| I personally prefer using many smaller components over
| using a large opinionated framework. But I'm not a big fan
| of React, so this could be better and worth a try.
| tensor wrote:
| It's less a "large opinionated framework" and more "fewer
| components overall. There is no HTML/CSS for example, it
| goes direct from Dart (equivalent to JS) to the Widget
| rendering system."
|
| Dart has its own build tools and package system that work
| well. You can still pull in dart libraries as you need
| them. Dart is also a much better language than JS. I
| can't tell you how many days I've lost to react/JS build
| tooling issues. A single problem can easily eat an entire
| day. With flutter/dart I haven't had a single issue like
| that.
| synergy20 wrote:
| flutter does a so so job on desktop and it's web version is
| wasm based.
|
| the job market for dart flutter is a drop while react is
| the lake.
|
| react with electron, react native, react itself together
| are still the only ones production ready cross platform GUI
| with widest adoption
| mdhb wrote:
| comments about job markets aside...
|
| The first and the third paragraphs really haven't been
| true for some time now.
|
| Flutter is absolutely production ready as a cross
| platform GUI.
| satvikpendem wrote:
| But, Flutter and React work the same way where UI is a function
| of state. In fact, Flutter started off imperatively but after
| React was released, they changed it to be declarative, and now
| Android via Jetpack Compose is changing to be declarative, all
| on the same general principle. I also use packages like
| flutter_hooks or ReArch which make encapsulating state much
| easier, I couldn't stand using initState and not forgetting to
| dispose for each piece of functionality.
| nu11ptr wrote:
| > I know Flutter/Dart doesn't get much love here on HN but in
| my opinion I think it's much easier to reason about than a
| system like React which I think is the wrong level of
| abstraction compared to Flutter's render the entire widget tree
| approach.
|
| Yeah I really like Flutter/Dart. I had less an issue with React
| itself than I did the whole HTML/CSS/Javascript ecosystem and
| tooling. Flutter is a breath of fresh air in that it is a
| purpose built ecosystem for UIs. You load the SDK and are ready
| to go with features like hot reload out of the box. No need for
| gamut of tools and to figure out how they all work together.
| Also, no need for HTML + CSS! I think the only reason it isn't
| more popular is because we have such a huge # of frontend devs
| already trained on HTML/CSS/JS, as Flutter is a lot simpler out
| of the gate, and much easier for traditional GUI paradigm
| people IMO.
| bmitc wrote:
| Flutter is not bad, but I hesitate diving into it based upon
| who controls it. Using a Google product feels like you're in
| constant threat of it just disappearing.
|
| It also still has all the remnants of mobile and fingers and
| not desktop and mouse. Support for improving this is non-
| existent in my experience.
| seabrookmx wrote:
| Why conflate Google's customer facing products with their OSS
| technology contributions? It seems a weird comparison to
| make, as if their sales and marketing departments are the
| ones behind technology decisions.
|
| Angular came out of Google and hasn't gone anywhere. Also
| GoLang.. even GWT was supported well past its prime and is
| now maintained by the community. What evidence is there that
| they abandon languages and frameworks?
| epcoa wrote:
| > Angular came out of Google and hasn't gone anywhere.
|
| I think you actually answered your own question.
|
| The difference is that Angular was already a hugely adopted
| and relatively simple piece of technology (the difference
| between a JavaScript framework and all the moving parts and
| pieces of Flutter/Dart is huge)
|
| Since the latter doesn't have anywhere near the investment
| outside Google it's not a fair comparison. The fear that if
| Google drops it, it will die are legitimate.
| neonsunset wrote:
| > Why conflate Google's customer facing products with their
| OSS technology contributions?
|
| In the .NET block down the street, we deal with this kind
| of nonsense almost daily :)
| https://news.ycombinator.com/item?id=41195650
| samstave wrote:
| Just want to say, your site is very aesthetically pleasing. I
| _hate_ blue websites (FB Blue) -- but the deep tones that SOS
| uses and contrasts are really appealing.
|
| So is the app, subscribed.
| nu11ptr wrote:
| Looks nice. What UI design system did you use here if I can
| ask?
| blopker wrote:
| While I don't see the advantage of writing UI in Rust vs Dart,
| I'm a huge fan of flutter_rust_bridge.
|
| The work fzyzcjy and the community have put into calling Rust
| code from Dart seamlessly is such an asset to Flutter apps. I
| remade the popular image compression app ImageOptim in Flutter
| over a weekend because webp wasn't supported. After a little pain
| in the initial setup, I was able to call mature Rust image
| libraries using flutter_rust_bridge and a small wrapper[0]. It
| even handled all the parallelism for me.
|
| The app ended up being more capable and faster than ImageOptim,
| largely just because of the Rust integration. Thank you fzyzcjy!
|
| [0]:
| https://github.com/blopker/alic/blob/main/rust/src/api/compr...
| fzyzcjy wrote:
| You are welcome, and I am happy to see it helps! When I
| initially develop flutter_rust_bridge, my personal usage
| scenario is quite similar to yours: using Rust for some high
| performance algorithms.
| sbt567 wrote:
| Well done! I've heard only good things about rust_flutter_bridge.
| Some questions though (more like flutter question), how bloated
| flutter is (i.e. final app size) compared to mobile native (Java,
| Swift?) for simple app? And how's the UI performance looks like?
| fzyzcjy wrote:
| For app size, it depends on your specific scenario, because
| e.g. Flutter automatically removes library code that is not
| used. I remembered (but the memory is blur) simple app has
| something like ~5MB. Btw remember to split .so file per abi.
| For UI performance, I personally find it quite good, and
| Flutter(Dart) is compiled to assembly code via AOT (instead of
| e.g. JIT or interpreted), which theoretically speaking is also
| fast. For both, I would suggest to make a demo for your
| specific case to have more accurate results. Also I guess
| ask/discuss on the Flutter community may help.
| bubblebeard wrote:
| Commendable effort! I'm currently using Tauri for a project
| myself and was wondering if anyone has any pros/cons between the
| two?
| fzyzcjy wrote:
| Thank you! I heard some people saying that, for apps using
| JavaScript, Tauri is replacing Electron and is popular
| nowadays, since Electron is very widely used. It seems Tauri
| cannot let Rust communicate with JavaScript very seamlessly
| yet, e.g. https://tauri.app/v1/guides/features/command/ seems
| to have mainly basic features. oneshtein mentioned below that
| Tauri does not support mobile as first class citizen yet as
| well. Looking forward to seeing Tauri's bridge to improve and
| supporting mobile better in the future!
| bubblebeard wrote:
| Thanks for the info! I will keep an eye on this for future
| projects, keen to try it out. I'm currently working on a
| project being converted from Electron to Rust/Tauri. I recall
| Flutter being discussed, but our frontend dev was more
| comfortable with React.
| fzyzcjy wrote:
| You are welcome and looking forward to it!
| bobajeff wrote:
| From what I can tell. I've not used Tauri and it's been years
| since I've tried flutter.
|
| Tauri currently has poor support for mobile and Linux (because
| of the state of WebkitGtk).
|
| Flutter uses Dart which is not widely used for anything else.
| Harder to learn as there is no MDN, w3schools or standard spec
| for it. Also Flutter Web has issues due to it's use of Canvas
| over the DOM.
|
| IMO, electron is still the way to go for cross platform apps.
| jurschreuder wrote:
| Isn't Flutter basically a way to use the C++ render engine from
| Chrome, with a "scripting" language most similar to Kotlin and
| Swift?
|
| Why not just use the Chrome render engine directly from Rust?
|
| Why all the extra steps?
| polyaniline wrote:
| There's too much infrastructure on top of the render engine to
| replicate. Flutter is backed by Google and has a fairly large
| ecosystem of community packages.
|
| See Freya - which uses Skia - the render engine Flutter used
| until a while back.
| ThePhysicist wrote:
| They used to be based on Skia but now they have their own
| renderer (Impeller). That said rendering is only a small part
| of a UI toolkit, there's a ton of other stuff e.g. how to
| interact with system libraries, integrate with UI paradigms
| (e.g. tray icons, gestures, responsiveness, widgets).
| imadj wrote:
| > Why not just use the Chrome render engine directly from Rust?
|
| This is what projects like Tauri (in Rust) and Wails (in Go)
| are doing[0][1]. Utilizing Webview to develop applications, but
| they still don't support mobile, Tauri mobile is in beta.
|
| Basically Tauri and Wails are on one side (HTML/CSS) trying to
| approach cross platform by supporting mobile platforms, while
| Flutter and Kotlin Compose Multiplatform started from the other
| side.
|
| So it depends on your needs, web-first or mobile-first, and
| what platforms matter to you. So far Flutter is in the lead
| offering the most polished experience when it comes to
| supporting all platforms (Web, desktop, iOS, Android).
|
| [0] https://github.com/tauri-apps/tauri
|
| [1] https://github.com/wailsapp/wails
| pjmlp wrote:
| Much better than reaching out to Chrome shells or Web widgets,
| kudos for the effort.
| fzyzcjy wrote:
| Thank you!
| j-krieger wrote:
| Flutter Rust Bridge is without a doubt the best FFI bridge I've
| ever used. It works like magic. I have no idea how it's done.
| fzyzcjy wrote:
| Thank you!
| webprofusion wrote:
| Cool, but the point of having stuff in Rust is to ideally have
| everything in Rust, or you're by definition not getting all the
| safety benefits of Rust.
| jenadine wrote:
| Dart is also safe.
| mtizim wrote:
| Not at all, pretty much all popular languages (except C/C++)
| are as safe as (safe) rust. The only safety rust brings to the
| table is memory safety, which most languages achieve with a
| runtime and a garbage collector, which have a performance
| tradeoff.
| CryZe wrote:
| You definitely also get a lot more thread safety out of Rust
| than most languages.
| wongarsu wrote:
| In three most narrow definition of safety I agree. But that's
| a very narrow definition. Rust does offer a lot more:
|
| - no undefined behavior
|
| - many classes of concurrency bugs prevented by the type
| system
|
| - standard library and much of the ecosystem makes invalid
| states unrepresentable. E.g. a String is always valid UTF8
|
| Those are things that are true to varying degrees for other
| languages. Dart does pretty well imho. But for example Java
| and C# offer memory safety but have very unsafe concurrency
| pjmlp wrote:
| Rust's concurrency is only safe in the very specific use
| case of threads trying to access common resources on the
| same memory space.
|
| It does nothing to prevent data races between processes, or
| concurrency errors between threads accessing resources that
| are external to the process.
|
| Scenarios quite relevant in distributed systems.
| ramon156 wrote:
| While dart is definitely not like rust, dart is a very safe
| language. I'd love a dart+rust project if the package ecosystem
| wasn't such a mess in dart
| nu11ptr wrote:
| I use Flutter for my desktop UI and Rust for my backend. However,
| I chose to separate the two using gRPC instead of the bridge.
| This allows me to be agnostic of language on both sides and I
| suspect gives me a cleaner interface for mocking the backend from
| my frontend. It also makes it easy to place the UI and backend on
| different machines giving a true client/server architecture. The
| con is likely that the interface is probably more verbose,
| however.
| nevi-me wrote:
| Do you run a gRPC service on the desktop where the UI runs, and
| connect the 2 via localhost?
| mdhb wrote:
| Not op but I'm developing an application with this exact
| approach as we speak, although my backend code is in Dart
| also.
|
| You can also do gRPC over Unix domain sockets too if you're
| sticking with desktop but overall I really like this approach
| as it makes it trivial for me to move from desktop app to web
| app with only some minor config changes.
| nu11ptr wrote:
| As one option, yes, the other option is to run them on
| different machines. App isn't done yet but the idea is that
| you are presented an option to either connect locally (if
| localhost detected) or remotely via auth on UI startup.
| duped wrote:
| If you do this please don't use localhost, the socket domain
| for IPC is AF_UNIX not AF_INET. Even Windows supports it.
| nu11ptr wrote:
| Then I would need two different mechanisms. Local and
| remote are both satisfied by TCP sockets, so this is
| easier.
| BodyCulture wrote:
| How is the a11y story with this? I did not find any info about it
| in the document, but I can not imagine anyone releasing a GUI kit
| in 2024 without extensive a11y support, so why not mention it?
| nsriv wrote:
| Do you mean in Flutter generally? I'd say it's very good, easy
| to build in on widget by widget basis, very easy to check and
| rest when running builds.
| danielvaughn wrote:
| Nice, I really enjoyed Flutter's approach to building UI, but I
| didn't really care for Dart all that much.
|
| In theory shouldn't it be possible to create a programming
| language specifically for UI? Something that can be interfaced
| with from any major programming language. Kinda like protobuf
| with its IDL format, but instead of defining data, it's declaring
| user interfaces. Is that a crazy or stupid idea?
|
| QT and XAML come to mind, but I believe QT is closed source
| (might be wrong about that), and XAML seems to have been dead in
| the water for a long time now (also might be wrong about that).
| Zelphyr wrote:
| I'm curious what you don't like about Dart? I thought I
| wouldn't like it but I've found it surprisingly nice.
| danielvaughn wrote:
| I don't have any well-considered opinions about it, moreso
| that on a gut level it felt like java or c#. It was a while
| ago that I tried it, and I can't recall the exact details.
| virtualwhys wrote:
| Off the top of my head:
|
| 1) Types on the left
|
| 2) Statement, not expression, based
|
| 3) No privacy modifiers (aka, underscores everywhere)
|
| 4) required semicolons
|
| 5) no language support for json (de)serialization, or, json
| boilerplate everywhere (yikes)
|
| I've tried to get into Flutter 3x now, and each time Dart has
| defeated me.
|
| Flutter is quite good though, so take the good with the bad,
| I just can't stomach Dart (yet).
| _bent wrote:
| you mean CSS?
| danielvaughn wrote:
| Kind of, but CSS is only 1/2 of a UI language, and it's
| specific to the web.
| Tmpod wrote:
| Qt has some commercial license only components, but the
| majority is open-source. In fact, the KDE Free Qt Foundation
| ensures that the framework is always available under
| GPL+LGPLv3.[0]
|
| Anyway, there are some languages specifically desgined for
| making UIs. Qt has one of those, QML[1]. It's a "simple"
| language made precisely for UI development, that can be wired
| to C++, allowing you to write business logic in a general
| language, while keeping UI focused.
|
| More interestingly, though, is Slint[2]. The language (and
| company behind it) was made by ex-QML devs which sought to
| improve the design, avoiding some pitfalls that QML ended up
| running into. It's core is written in Rust, but there are
| bindings for C++, JS and now Python too. They also have a focus
| on embedded devices, which ends up translating to always having
| good performance and memory footprint in mind, which is neat.
|
| One of Slint's dev is ogoffart:
| https://news.ycombinator.com/user?id=ogoffart
|
| [0]: https://www.qt.io/faq/tag/qt-open-source-licensing [1]:
| https://en.wikipedia.org/wiki/QML [2]: https://slint.dev
| danielvaughn wrote:
| Wow slint is almost exactly what I was imagining, thanks!
| neonsunset wrote:
| XAML is very much alive within Avalonia[0], Uno[1] and MAUI[2]
| (not to mention WPF) :)
|
| There is support and growing popularity for declarative UI
| defined in C#[3] and F#[4] instead though.
|
| [0]: https://docs.avaloniaui.net/docs/basics/user-
| interface/intro...
|
| [1]: https://platform.uno/docs/articles/getting-
| started/counterap...
|
| [2]: https://learn.microsoft.com/en-
| us/dotnet/maui/xaml/fundament...
|
| [3]: https://github.com/AvaloniaUI/Avalonia.Markup.Declarative
|
| [4]: https://github.com/fsprojects/Avalonia.FuncUI
___________________________________________________________________
(page generated 2024-08-11 23:00 UTC)