It almost doesn't matter what it is.
If you've used any Google OSS project seriously you're going to come across an obvious defect and run to GitHub to open an issue. But, there's already an open issue for the problem.. And it's been open for almost as long as the project has existed.
It will have an inscrutable priority and day after day new comments will pop up saying "Hey, I'm having this issue too. Can I contribute a fix?" But, a pull request with a fix has sat, unreviewed, for almost as long as the issue has been open.
And then it comes: "This issue has been automatically closed due to inactivity."
They're both UIs viewed on a screen that you interact with by pointing and clicking, but the similarities end there. The entire output of this cross-platform effort has been awkward applications that run everywhere but feel right nowhere. It's sad that even Apple has fallen victim to this idea that with their horrible Catalyst apps. Though I understand why the sales pitch of "one codebase" makes management of so many companies salivate.
In onboarding to the tooling, there are so many paper cuts that it's not really a "I'll try this out for fun" thing like e.g. Next.js is, that you would recommend to your co-workers.
I tried it out for desktop, where I found it okay-ish (but lacking in desktop-related libraries, as the article points out), and for web, where the debugging experience compared to web-native solutions really takes a hit due to the lack of DOM.
Indeed, multi-window support is absolutely missing right now, but it's the Flutter's team top priority. Context menus are now available with 3.7.
Generally, I found Flutter/Dart easy to pick up and build a quality desktop app with ease. Currently, I am not convinced that it can be used for performance-critical apps yet without a lot of developer effort and experience (there is, for example, Rows, an Excel clone built with Flutter). However, it works for building general-purpose apps on desktop, without messing with the native toolkits that are in a strange place, especially on Windows.
For me the best use of desktop is testing mobile apps without having to use my phone or an emulator. It works really well.
It's a Spotify music player that turns your device into a jukebox at https://getjukelab.com/.
As a hobbyist I couldn't imagine getting this far on 3 different platforms if I had to go native. My favorite surprise is how much faster doing dev, deploy and QA on the web target is, vs doing mobile dev and release. I can deploy to the web 5 times a weekend, and batch those up to do monthly mobile releases.
I tried Flutter Desktop but hit an immediate show stopper that the flutter Spotify SDK doesn't support it. There's no "Mac Spotify SDK", so it would have to wrap the web one somehow. All the UI bits worked as expected.
But watching the trajectory of Flutter and the community over the past couple of years I'm cautiously optimistic it'll get good.
Why are 3D, game engines, and WASM more important than good JSON serialization, improved runtime safety (removing "late"), multi-window support, extension structs, webview support, exhaustive maps, and other core issues?
I really don't understand these priorities.
Here's my quick criteria for whether I should use a new framework for my app:
- look at other apps that are using that framework, esp. the signature/first class app touted as a consumer by that framework
- how similar is my app to that signature/first class app?
- if my app has similar UX/UI usage then the dev experience will be much smoother/easier/doable
i.e. for React Native: does my app behave like Facebook? If not (say, an action game as an obvious typical non-usage scenario), there be dragons...
for mature, stable frameworks like native mac OS<=9, macOS, Win32, most GUI apps are straight forward, it's when you push the limits of the UI where things will hit hurdles.
So what's the signature/first class app for Flutter Desktop?
1. I write in Rust, so my plan was to write the UI in flutter and use the rust/flutter bridge so I can write most of the client code in Rust. Gets around _some_ of the lack of flutter libs by using Rust ecosystem instead (but not for the UI itself)
2. There is a new lib out called platform ui that wraps mac/windows/linux UI transparently (it is just a wrapper that wraps fluent ui and macos UI libs, etc). Not sure how well it works, but might worth a shot and gets closer to native l&f for desktop
Corporate wise , nah, its fine, Jank effects heavy animations. Even then the 3-4 encounters was fixed by some smart resource usage. We are trying the 3.7 solution. If not, then stick with the idea don't try to animate the animation.
Desktop ready? Corporations yes. Make the next unreal 5.x game with it? nope.
NOTHING IS THERE YET
“There” is Utopia.
“There” is a language being ergonomic, ubiquitous, fast and with libraries that are awesome!
That is too much to expect.
We've been telling Dart team our complaints but they have been unaddressed for over 8 years now. At this point, some other thoughts include applying a garbage collection cycle and have them replaced by Carbon team or Golang team.
Perhaps get a new product manager, someone that will listen to the grieving (& dying) dart community.
late edit: 5-10 years ago people were complaining about these languages having issues binding databases, network protocols, etc.
I'm sympathetic to the points made, but as someone who has not used Flutter, I really do not have a sense of what the tooling and output is like based on this short piece.
I has saved me and my team countless months so far in time to ship a truly cross platform product and I'm sure there are many others like us who feel the same.
If your use case requires these specific issues to be sorted, then it is great to know about them in advance. Nothing is perfect and every single app across every single framework is going to need to make trade offs.
If I needed text selection to be faster than what the built in component offers, I'd just develop my own component or spend some time debugging why the existing component is slow. Flutter itself doesn't prevent you from doing this.
If I needed multiple monitor support in my app, I'd probably not write it in Flutter because I looked at my app requirements in advance and realized that it doesn't support that.
The rest of the post seem to revolve around not having enough built-in ways of doing things. Again... you can't expect someone else to write your code for you and then call the whole framework lacking.
For the note: Sciter is an embeddable HTML/CSS/JS UI engine. For desktop and mobiles. By feature set it overlaps 96% with Flutter. It differs in ideology and implementation significantly though.
Not clear why Dart is used in Flutter. By architecture and feature set Dart is almost Java. Why the Dart then? My guess is this is an attempt to simply replace Java on Android without changing existing UI paradigms. Yes/No ?
1. Desktop-first vs. Mobile-first development
Desktop UI is windowed one - UI may consist of multiple desktop windows: frame, dialog and popup windows. There is also a concept of "kiosk mode" in Desktop UI - single window spanning whole screen.
Mobile UI is a windowless thing - UI canvas spans whole device surface. As you see Mobile UI is Desktop UI in Kiosk Mode - Mobile UI is a subset of Desktop UI.
Transition of large subset system to superset system is quite hard. On top of my mind I cannot tell any success stories of that. Anyone?
2. Separation of concerns
95% of UI development these days is a Web UI that uses three pillars: HTML as a semantic UI declaration, CSS as a style declaration of UI states and JS as declaration of event flows and UI state transformations. Essentially script is a definition (declaration, again) of flows/routes - how output of one native function is connected with input of other native function.
These three pillars, their purposes, are so different that their syntaxes should be different. Attempt to combine all these definition in single language is doomed to fail. If in doubts then look at WPF.
3. Notes on language-behind-UI...
Simply put: don't do ray tracing in language-behind-UI. But! Such a language shall have simple mechanism of adding high performant functions. There are good languages that are specifically designed for performance: C, C++, D, Rust, Zig, WebAssembly, etc. You just need convenient mechanism to expose those functions to runtime of language-behind-UI. Like here: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...
You need JITs, compilation, fat VMs and runtimes, strong types only if your language is the only mean to define algorithms in whole application. But expect that your code will always be sub-optimal - neither enough performant nor super flexible.
I don't have particular issue with the heavy OOP paradigm but the fact you have to write so much boilerplate feeling code (Center here, Container there) you'd imagine you could have simplified it a lot more. The documentation itself also seems like it could be improved. And some little things here and there, like the constructor syntax. I dislike semicolons as well, to me they're just busy work.
Idk, you'd think an org like Google had the resources and the talent to make something truly amazing. Guess it just shows money can't buy everything. The tooling however is quite amazing. Being able to make cross-platform apps so simply is pretty awesome (React native was a pain in the butt the last time I tried it).
Here are some updates from our side:
1. Custom context menus - We just added this feature in Flutter 3.7, which was released two weeks ago. Please give this a try and let us know what you think!
2. Multi-window - This is a high priority for the Flutter team, we have several engineers working on this project currently. Here's a video that gives an early preview on multi-window support: https://www.youtube.com/watch?v=vtB-teu57vw
Feel free to let us know if you have additional feedback; this helps us prioritize on what's most valuable for our community!