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!
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!
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.
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?
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.
> The fear that if Google drops it, it will die are legitimate
I'm not trying to argue against the fact it would die or not. I'm mainly trying to understand why people think Google would abandon it. Abandoning Google Reader and abandoning Flutter or GoLang are _not_ the same in my eyes, and I can't think of any cases where Google has abandoned a technology rather than a consumer facing product in this fashion.
In the .NET block down the street, we deal with this kind of nonsense almost daily :) https://news.ycombinator.com/item?id=41195650
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!
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.
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.
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.
Yes, that's basically correct:
>Calling setState notifies the framework that the internal state of this object has changed in a way that might impact the user interface in this subtree, which causes the framework to schedule a build for this State object.[0]
The `build` method rebuilds the entire widget tree. So "the whole app" does not necessarily get re-rendered, only whatever is in the same widget as the changed state or below it, although potentially that can be the whole screen. Flutter also uses an algorithm to detect unchanged widgets and reuse them,[1] but conceptually the whole thing is re-rendered on state change.
[0] https://api.flutter.dev/flutter/widgets/State/setState.html
[1] https://docs.flutter.dev/resources/inside-flutter#linear-rec...
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.
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.
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
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.
On the other hand I think flutter lost a lot of benefits comparing to 5 years ago - now we have stable better swift and swiftui and better kotlin with jetpack compose - those support also apple watch, macos, tvos, visions os, Google wear, Google TV and with current jetbrains compose desktops like windows is already stable.
React native and web ecosystem also improved a lot in the last year.
If I am remembering correctly the headcount on the Futter team literally changed by a single person.
Here are some actual real life numbers you can use if you want to gauge the health of the two projects:
1. https://github.com/facebook/react-native/pulse
2. https://github.com/flutter/flutter/pulse
Specifically Flutter’s 108 merged pull requests to React Native’s 1 and Flutter’s 330 closed issues to React Native’s 18.
Also note that this doesn’t even include their rendering engine which had another 90+ closed pull requests https://github.com/flutter/engine/pulse
The truth of the matter is that Flutter is actually is far better shape both from a technical and open source perspective.
The health of the two projects genuinely isn’t close at all. Comparing what they are actually both shipping in terms of features in the last year is two very very different stories.
Flutter monthly pulse: https://github.com/flutter/flutter/pulse/monthly "Excluding merges, 83 authors have pushed 451 commits to master and 461 commits to all branches" but:
1st engine-flutter-autoroll (bot with revisions autoroll): 185 commits
2nd zanderso (google employee): 25 commits
3rd ValentilVignal (contributor): 14 commits
in top 15 contributors for flutter you have also other bots such as: fluttergithubbot, auto-submit[bot], flutter-pub-roller-bot, dependabot[bot]
React Native monthly pulse: https://github.com/facebook/react-native/pulse/monthly "Excluding merges, 84 authors have pushed 437 commits to main and 575 commits to all branches"
1st cipolleschi (meta employee): 92 commits
2nd cortinico (meta employee): 83 commits
3rd NickGerleman (contributor): 45 commits
no bots in top 15 contributors
Also keep in mind React Native is based on React repo project. On top of that you have a lot of work by community in:
- expo https://github.com/expo/expo
- react native reanimated https://github.com/software-mansion/react-native-reanimated
- react navigation https://github.com/react-navigation/react-navigation
- react native skia https://github.com/Shopify/react-native-skia
All of those packages are highly maintained and are pretty used in all RN projects and considered standard.
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.
So is the app, subscribed.
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...
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.
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
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.
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).
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
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
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).
> What do green usernames mean? > Green indicates a new account.
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.
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.
[0] https://github.com/cunarist/rinf-status-report
[1] https://www.reddit.com/r/FlutterDev/comments/1dnwagk/flutter...
- 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
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.
I do agree it helps, but it isn't the improvement over other memory safe languages, that the Rust Evagelism Strike Force makes it to be.
Why not just use the Chrome render engine directly from Rust?
Why all the extra steps?
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).
See Freya - which uses Skia - the render engine Flutter used until a while back.