Flutter desktop isn’t there yet
plei.one
plei.one
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!
And sorry to ask this here, but how have the recent layoffs affected the flutter team?
We're using flutter as our main framework for our app and it's quite important.
The layoffs have sparked some fears that flutter development might slow down.
Please keep in mind that Flutter is a community project. Google is one of Flutter's many sponsors, many of our contributors are from other companies.
A quick WHOIS search for flutter.dev and pub.dev domains tells me that this is not really the case.
It's open source software, developed in the open under a permissive license. You don't have to work for Google to have contributor access or the right to approve others contributions. Google kindly sponsors a fair amount of infrastructure (testing labs, etc.) and pays for a lot of people to work on Flutter. If that doesn't meet your definition of "community", then fair enough -- but the spirit that we work under is that the "Flutter team" is everyone who contributes code.
However, it's not a community project, by any definition of community, because there is a power imbalance between Google and other contributors. Accepting patches or even allowing non-Google people to accept patches from anyone is not enough.
> There is a CLA, so that folk can attest that contributions are theirs, and that they're free to be used by others, and that everyone who uses Flutter can feel comfortable that there are no patent or IP rights reserved by contributors.
No, there is a CLA so that Google keeps the ability to relicense future Flutter releases however it seems fit.
Of course everybody owns their own contributions, git log clearly shows who owns what. BSD license already assures that they are free to be used by others, and if patents were a concern, AFAIK the Apache license would've been a better option (IANAL). You don't need a CLA for any of that.
Users and contributors are bound by the BSD license. Google however gets special treatment:
""" Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. """
I hope the power imbalance is clear this time?
Again, it's great that Google develops open source software under a permissive license. Mad respect. I'd happily sign the CLA were I to send code to Flutter. I'm also not saying that Google shouldn't have a CLA, I fully understand, and maybe I'd do the same (maybe not). But let's call it what it is.
> but the spirit that we work under is that the "Flutter team" is everyone who contributes code.
Sorry but you sound like that boomer SMB owner who keeps saying "we are a family".
Flutter is unquestionably designed mobile-first, with everything else a distant second. Flutter may be the best option for developing cross-platform mobile apps right now (I don’t know), but if you care about web or desktop, it’s not a particularly good choice. Things based on web tech are very likely to be better.
[Reference](https://en.wikipedia.org/wiki/Chromium_(web_browser)#:~:text....)
That is, fixing minor bugs or translation strings vs adding new web APIs etc.?
For a lot of first-time contributors, improved documentation and added tests are a great way to dip toes into the water. We also have a 'good first contribution' tag on our issues log that might be a source of inspiration: https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Ai...
We strive to be an open community. Anyone can become a Flutter team member if they contribute frequently :)
by the way dart is my favorite cross platform language nowadays beyond flutter.
i've learned at least a half a dozen languages over the years, and dart is now my favorite. so much so that i am converting existing projects to it. for example, i have a series of scripts i wrote, in python, to automate away the boring parts of my job, which i am now converting to dart. at this point, for me, trying to get anything done in python is like wading through molasses. (like, why does almost any change to a python implementation file cause you to also have to revisit the imports section? ugh, i hate that so much.)
my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance. programming is thinking, and i really don't like you dictating the way i ought to think. (yeah, i know you won't do it, but that's my big one.)
my second big change would be to allow me to implement a big dart class in two or more implementation files. the business logic in the flagship flutter app i maintain is getting unbelievably complicated, and large chunks of it cannot be moved out of the one object it is in, due to inheritance reasons.
Yeah, I get that. In personal projects, there's something to be said for just Having It Your Way. But the formatter is focused on ecosystem level improvements where configurability is an anti-feature.
> my second big change would be to allow me to implement a big dart class in two or more implementation files.
You can sometimes accomplish that by moving chunks of methods out into seperate mixins and mixing them into your class. I think mixins are generally underused in Dart. But if that doesn't work, the proposal for augmentation libraries would probably help:
https://github.com/dart-lang/language/blob/master/working/au...
I'm glad you're enjoying Dart!
I use dart for scripting as well, which works really well.
For deployment I wonder if Dart can be made a little like Go (or C/C++): to build into a single static executable instead of depending on system C shared libraries.
I gave up on Go and embraced Dart, so the `dart build` and `static binary` are kind of what I missed from Golang when started with Dart.
It's "dart compile":
$ dart compile --help
Compile Dart to various formats.
Usage: dart compile <subcommand> [arguments]
-h, --help Print this usage information.
Available subcommands:
aot-snapshot Compile Dart to an AOT snapshot.
exe Compile Dart to a self-contained executable.
jit-snapshot Compile Dart to a JIT snapshot.
js Compile Dart to JavaScript.
kernel Compile Dart to a kernel snapshot. dart_build ()
{
[[ -f pubspec.yaml ]] || return;
DART=$(grep ^name pubspec.yaml | awk '{print $2}');
dart pub get;
dart compile exe bin/"$DART".dart
}Yeah, it's very underrated. I find it nearly as expressive as Python with far better maintainability and performance.
You can learn more about Impeller here: https://www.youtube.com/watch?v=gKrYWC_SDxQ
But in watching the flutter announcement video https://youtu.be/Nu5m1FiS5X4?t=60 (timestamped link) on the screen as menus are opening and the mouse cursor is shown selecting different items, there is... a very perceptible stutter and lag. What is that due to?
* A video on YouTube...
* Of a livestream...
* Of a video made by a separate video production team...
* Based a slideshow (probably Google Sheets)...
* Containing a pre-rendered video...
* Of a screen recording...
* Of a Flutter desktop app.
Any and all of those can introduce latency or lag in the video. It's a great form for showing users features, but probably not a great way to evaluate UI performance, unfortunately.
this just makes me think of the fact that this sort of thing would absolutely never fly at Apple. And I really, really want to say that is shouldn't fly at Google either. They're spending what, 400k on the median developer annually? Have standards, make them have some sense of responsibility and respect for their craft so they don't do this. I mean, like come on, one of the main value propositions for someone considering Flutter as opposed to RN is the fact that it isn't transpiled, there is thus an expectation for widget performance to be basically be similar to that of native code -- well, this is exactly where you proudly and loudly showcase this -- in an announcement video. Widget performance should be absolutely flawless in the presentations.
But all that said, no I don't think that's what's going on here. The things shown right thereafter are stutter free. I think this is a quirk with Flutter. While for mobile/desktop it compiles to native code, for web it does transpile to JS and I think that's perhaps what is being shown there. Though I would think if they wrap it in some sort of wasm the lag wouldn't be perceptible.
It just really grates me that in this day and age this is the reality of UI. If you'd told me 10 years ago that a simple menu shown in a major UI toolkit announcement by the main web player would have these kinds of problems I'd have assumed you were just bad at telling jokes. It also makes me sad because I want Flutter to succeed but seeing these kinds of missteps gives me a pause.
edit: I see now that you're a googler, I'd have phrased it differently if I'd known. Cheers.
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."
So maybe some issues got fixed at least?
But, I doubt that can scale. I imagine there's some happy place sitting near semi-automated "duplicate" recognition, and a voting system, to give the users a voice. Closing due to inactivity is never a happy place (unless it's sitting waiting for required user feedback maybe).
https://github.com/flutter/flutter/issues/58163#issuecomment...
Sighhh. Maybe one day.
Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don't understand why Flutter's creators are so seemingly religious about Dart and reimplementing OS UI capabilities.
For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care if the application looks pixel perfect (but, still, Flutter is definitively an improvement from Oracle Forms :)
What users and the management does care, on the other hand, is that the features can be delivered quickly and on multiple platforms.
They do care. They just don't know the words "pixel perfect".
However, everything is an improvement over the standard state of corporate UIs
Have you measured it, or did you stop after the Form A Hypothesis step?
Flutter just recognises that.
It's a bit more messy to do that with Android Framework, and because of that I see more of an argument for using Flutter there than on iOS. Jetpack Compose seems to be a lot better in that regard though.
I personally dislike the whole JS ecosystem with a passion, and feel I'm not alone in this, so having an alternative is warmly welcome
The only real way to escape this at all is to settle on the browser as your runtime, so there's a certain irony to what you're saying.
1. Installing Flutter 2. flutter create 3. flutter run
Instead of installing/configuring/setting-up npm, typescript, eslint + rules, react + rules + types, prettier, react-native-web + rules + types, a rendering framework + rules + types, webpack, jest, and whatever else.
You do, basically, get it for free.
Again, it's definitely not free (or "basically" free, either). Step 1 negates that statement. You have to set up a development environment. It takes some non-zero amount of effort.
In contrast, the browser is already there. It already runs JS. You don't have to do anything to make that happen[1]. And in saying it takes nothing, that's not merely "basically" nothing; it's literally nothing.
> Instead of installing/configuring/setting-up npm [and a bunch of other crap]
What if I told you that while you're free to opt for doing any/all of those things, none of it is actually necessary, let alone a good idea? (Or point out that TypeScript is not even JS, for that matter?) That you're totally allowed to ignore the GitHub busyworkers and write actual (i.e. straightforward, standards-compliant) JS—in contrast to much of what's available for NPM/NodeJS, where you are most often encouraged to write "JS" that's incompatible with what's in the standard (and what the browser makers actually implement)?
1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>
There is a reason people made these countless frameworks and solutions, but the benefit Flutter provides is it's an out-of-the-box fix, and yeah, installing some software and running two commands is an out-of-the-box fix.
In addition, the entirety of your argument just flat-out ignores the cross-platform aspect of it, targeting only the browser instead of mobile and desktop platforms as well.
> You have now transitioned from saying that you don't have to spend as much time to set up a development environment to saying that it is pretty much free, which is even odder still.
I truly don't understand this odd exercise in linguistic gymnastics, as these are both simultaneously and entirely true. You can resolve this yourself.
And yes, it's still (basically) free.
Nope.
> This is the oddest argument of all (I can use that word too)
Oh, boy. That sounds bad. I guess it's a good thing that's an argument I'm not making it, then! (Also: I didn't use that word, FYI.)
Are you sure? The "whole JS ecosystem" you're aware of is likely to be the trendy (e.g. NodeJS+NPM) one*, which bears indicators at just about every turn that many/most of the folks working in it don't actually like the language themselves which results in lots of their energy being spent trying to fight with it which in turn produces the sorts of things that I'm guessing you like least. (For example: `package.json` is a tastemakers' invention and didn't appear anywhere in the spec.) This gives a skewed impression of what JS really even is; the dominant culture you see on GitHub is not the inevitable outcome of settling on a decision to standardize on JS.
(This isn't to say that the suggestion from the original comment you're replying to was a realistic/reasonable one in context.)
* in other words, not the "whole" JS ecosystem—you probably aren't looking at use of JS in, say, Gnome for example
I think Dart's history might be relevant here. Flutter was unveiled at a 2015 Dart programmer conference (https://www.youtube.com/watch?v=PnIWl33YMwA) and it was originally called Sky. Dart doesn't exist because of Flutter, it's the other way around.
Dart was originally intended to be a replacement for Javascript back in 2011, but it utterly failed to gain any adoption because about a year later in 2012, Typescript came out. Typescript being a superset of JavaScript I think completely destroyed any chance Dart could catch on for its original web development goals, since you didn't have to dump JS entirely, just rename .js to .ts and gradually start type-hinting code. Even within Google, they abandoned Dart for Angular and went all in with Typescript.
In a way it's refreshing to see Google re-tool an existing language, rather than invent a whole new langauge for cross platform app development, seeing how often as a company, they kill off projects quickly and start whole new ones.
This rarely happens though, and I wonder if it may have to do with the limitations of the technologies often chosen to do the implementing with, or if it's more of a philosophical thing with the projects in question not holding themselves to high enough of a bar.
Me too, and I’m surprised how okay with it people seem to be. What are the odds that Google to continue to support the latest platform UI changes? What about five years from now? How much effort is it to get good accessibility support vs native controls, and how likely are developers to do that?
The whole approach seems wholly dependent on Google continuing to give a shit, and as we’re all aware they don’t have the best track record there.
This attempt to draw every single control is too much effort with apparent inconsistencies.
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.
But I don't agree cross-platform can't feel "right". Flutter's approach it can't. React Native's it can. Qt vs WxWidgets all over again.
If I had to duplicate my codebase for each platform and learn each IDE/language just to continue my app, it would never exist.
I solely created and maintain the iOS app, the Android app, and the web app for my company and for my side projects thanks to React Native.
I can extend any native api or view, I can learn middle out for each platform.
I can abstract and swap out any file or conditionally style based on platform.
I developed the web app first using React Native Web. It took me a month to get the iOS and Android app released to the store.
No Ionic or web wrapper crap needed... The one thing is getting the React stack and tooling just right.
So it's Expo or devote quite a bit of time in the beginning to your stack.
Not sure how to interpret. Pro Qt or pro wx? I'm assuming the latter.
But I don't even agree. Qt is/can lay claim to native as much as anything else on desktop Linux/BSD. The quality of the Windows emulation has always been excellent as far as I'm concerned, at it's been pretty goodish on Mac.
But I've never seen a perfect cross platform library that targets Mac.
wxWindows may use system drawing at the low level, but those that have been in this for years know what's up: it's just an unholy messy quasi-MFC (Microsoft Foundation Class) looking thing - the model is inherently MS Windows from 1994. This is not magically going to work well as a Cocoa app just because it uses NSViews under the hood. And although the simple controls may use the OS, all the complex ones have tons of internal design. Like this is optimizing the wrong thing - as a normal person I probably care more about the look and feel of the tree view, whereas only the weirdos on here are going to get bent out of shape that some button text is a few pixels off - getting both right is nice, but only hitting the last one is pointless.
I've never seen a nontrivial wxWindows app that would fool anyone on MacOS. Qt can get much closer if you work at it a bit. So in practice I would say you can do better with Qt for the major desktop targets.
These are all compromises. And native hardly means anything these days. Yes Windows has what has been retconned as WinForms, but otherwise, the UI LnF of Mac OS is a constantly moving target and Windows has never been as consistent as people seem to believe. Linux/Desktop Unix - lol.
What often works for me is something like Wails, but it has its limitations. For instance there's no multi-window functionality there either, and while the new Wails supports more OS integrations there's still some aspects that need improvement to compete with native UI.
I'd love to try Flutter, but frankly I don't want to write "backend-ish" code in Dart. There's some projects to be able to build UIs in Flutter and have processing done by a separate language that all gets bundled as one, but they're mostly hobby projects.
The story on desktop is a little better but the same principle applies to some degree.
I can see the HN headline now...
"Rust support added to Flutter [34,432 karma]"
So you often end up really having to learn N+1 platforms.
If the particular experience you want isn’t supported, creativity is required to either:
A) use an alternate experience. Users literally don’t care as long as their problem is solved. They don’t care if it’s using X api or multi window or whatever. Just use tabs for all they care.
B) build the experience as a lib and maybe open source it
Anything else is for hobbyists.
SwiftUI has a lot of problems, but Apple has done great work building components and paradigms that adapt to the target device.
For example, check out how forms are defined: https://developer.apple.com/videos/play/wwdc2022/10052/
Defining an interface this way saves time for developers and provides consistency to users who use apps across different devices.
I just can't help but think that either programmers today have abstracted themselves into a lot more work than need to do, or they're just significantly less capable over all than the programmers of old.
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.
That being said, they have a lot of work to do.
- I'm not a big fan of Dart's overall composition - "late" seems lazy and error-prone - Dependency on code generation for simple things like JSON serializers/deserializers - All the other issues people have mentioned in this thread.
Luckily my team is investing a lot in our developer tooling, so we can lint/codegen a lot of the stuff away, but it's certainly a sign of it not being there yet.
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.
Edit: yes, Google Ads the mobile app is made with Flutter.
https://9to5google.com/2021/10/10/google-ios-apps-native/
And just because “mega sized players” are betting on it has never stopped Google from abandoning projects before.
You mean Google Adwords right, the admin panel? I can't see any evidence of that, nor is it listed at https://flutter.dev/showcase, where you get this from?
Clearly not, the AdWords on the web is rendered using the DOM, while a Flutter application will be rendered via a canvas DOM element.
You can try this yourself by opening up the inspector.
Where the ads are mostly shown, is also built using normal (in the web sense) DOM elements, either images or text, rather than Flutter canvas elements.
By "same," I meant they are equivalent in functionality (or nearly so, based on the differences between larger and smaller UI sizes). Both AdWords the Website and Ads the Mobile App are all part of the same Google AdWords the Product.
If Flutter disappeared tomorrow nobody would even notice it. How much functionality do you think is there?
In May 2022 - 500 thousand.
See: https://www.nomtek.com/blog/flutter-app-examples
Today: I'm too lazy but you can google for more up-to-date stats.
"nobody" is gigantically wrong.
Flutter is extremely popular in mobile.
Web and desktop support is behind but it'll improve and popularity of Flutter on desktop and web will grow too.
PlatformView support is one of our top desktop priorities this year (along with multi-window support).
https://pub.dev/packages/desktop_webview_window
Edit: on 2nd glance perhaps this doesn't embed into the widget tree but is always its own window?
For me the best use of desktop is testing mobile apps without having to use my phone or an emulator. It works really well.
There has never been an iOS “emulator” for development. When you built your code to test on the desktop, it was compiled to x86 and used x86 version of the iOS framework.
Of course now that Macs use ARM chips, it’s a moot point.
See https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g... for an overview of UI libs in Rust.
See https://www.cmyr.net/blog/gui-framework-ingredients.html for a great overview of some of the challenges making a GUI library
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.
The entire concept of developing the same app multiple times for different platforms is just so mind numbingly dumb. 3x the engineering team, 3 different platforms with all their different idiosyncrasies. The impossibility of maintaining feature parity across all three platforms. 3x the testing and debugging.
I agree but all that's needed there is an escape hatch with some way for the non-native interface to interact with the native code.
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.
The Flutter team should consider unpegging from dart and utilize JavaScript/Typescript, Kotlin, or Swift.
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.
why would they do that, dart is better than all those languages except for maybe swift.
late edit: 5-10 years ago people were complaining about these languages having issues binding databases, network protocols, etc.
And probably never will. There are a bunch of projects but they are not very good or complete.
The problem is that "good" requires massive amounts of work that is beyond the capacity of single person / small team of volunteers i.e. typical open source project.
Which is why Flutter (and Electron) are the only reasonable technologies for desktop apps that I see today (and in the future).
They get majority of investment from other place: 99.99999% investment in Electron is investment in Chrome.
99% investment in Flutter Desktop is investment in Flutter Mobile.
Flutter Desktop and Electron will continue to benefit from massive investments in Chrome and Flutter Mobile. No other project building desktop UI can come anywhere close this level of investment.
Sadly no maintained Linux desktop app support.
These little details are usually not a concern, until they become a sudden requirement. Another one is Accessibility, which actually helps in other ways - you can automate UI test, or just automate things through it without relying (to a degree) on the kit's framework. In a way it serves to prove that the UI toolkit does diligent job of presenting it's widgets to a Reader.
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.
0. Dart
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...
If to consider #2 then such simple thing as JavaScript language and VM are quite adequate to the task. Language-behind-UI do not need to be that performant, but it must be flexible. I may express un-popular opinion but language-behind-UI should be typeless.
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.
4. Conclusion
Flutter should be something Sciter-alike :) - use [X]HTML/JSX, CSS and some already well known language-behind-UI. JavaScript is the natural choice. If needed you should be able to use native UI components - like in Sciter you can use existing HWND based and windowless native components inside your UI. It may not follow Web UI model on 100% (that's impossible) but to be conceptually close so developers can reuse their skills. Web UI model is conceptually close to Mobile one - whole applications UI is constrained inside single window.
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).
More importantly, it was a Google language that they could mold for their own needs, not so possible if it's an outside language like TypeScript. For example, early on, they asked the Dart team to create an AOT compiler since Apple does not allow JITted code apparently (not sure how React Native gets around this then), or maybe it didn't back then, and the Dart team was able to do it successfully for the Flutter team. Try asking the TypeScript team to do the same, it's next to impossible.
For what it's worth, Dart 3+ introduces more functional parts like records, patterns, and exhaustive pattern matching so you can use it in a functional style if you want once that ships. There is also fpdart, for full functional support, and for brevity of code, since Dart has the ability to generate code via macros (with build_runner), you can also use packages like functional_widget, flutter_hooks etc to achieve a very functional code style as well, React-like.
This is a great podcast/video episode on how Flutter came to be, from the early days to now, and how it used JS in the beginning but it didn't serve their needs, as well as how it used to be more imperative until a declarative React-like model was then made.
With React Native you have two options. Use Apple's own JavaScriptCore engine which has special JIT permissions, or use Meta's Hermes engine which runs as a bytecode interpreter.
In either case you can always drop down to native code (Swift/Objective-C (iOS), Kotlin/Java (android), or C/C++ (any platform)) which can be used for anything compute heavy.
So the situation with React Native is that you can either use JSC, Hermes (or I believe V8 in jitless mode). All of which are interpreters. On Android you can of course use JIT (with either JSC or V8).
There is Kotlin Native now.
If Google really wanted they could have wrote one.
There are AoT compilers for Java, but I'm not aware of any successful widely-used ones. Java and the Java ecosystem rely pretty heavily on class loaders and reflection which make AoT compilation very difficult. Java in its bones is designed to be a JIT VM language and you'll always be going against the grain if you try to statically compile it.
Dart was also initially designed to be a JIT VM language (by the same folks who made the HotSpot JVM) but without many of the pitfalls in Java that make AoT hard, and over time we have deliberately evolved the language (in breaking ways!) to make it much more amenable to static compilation.
Languages are not all interchangeable and some languages are better suited for certain implementation strategies than others.
> Languages are not all interchangeable and some languages are better suited for certain implementation strategies than others
Sure, but I don’t claim to replace SQL or Prolog with Java, but a regular old managed language which has zero unique features that would give it a reason to exist.
Which they did, but for Dart instead.
Replace TypeScript with Java above.
I don't understand why you don't understand that having first class control over a language's development is a useful thing to have.
I’m curious what do you dislike about it apart from semi-colons and the constructor syntax (which seem fine to me?).
While stating itself to be statically typed you can also shoot yourself in the foot by simply using `as Type`, similar to TypeScript. Because that just assigns it to a type and doesn't cast it like you do it in say Rust.
The extreme use of classes with `abstract class` and whatnot feels kinda 90's to me, just a lot of abstractions and for what? Just feels unnecessarily complicated for something seemingly simple.
Maybe it's just little too enterprisey for my taste. Maybe that's it. I'm glad they are taking steps to improve it, I think making it more functional would help it. Even just to distinguish it from the other OOP languages.
And how come simple state management seemed so difficult as well? I tried using my tried and true MobX which is implemented for Dart as well but was disappointed in its complexity and the fact it requires you to run a code generator to wrap your classes with observables. What? Insane.
This is a really good question. The reason is that it ensures that you can never see a field before it's initialized. In Java, you might think that you'll never observe a final field before it's been initialized but not so! In the constructor, you can call a method on `this` even before all fields have been definitely initialized. Inside that method (which might be overridden!), you can then read the field. It will be default initialized.
This means every time you create an object in Java, some extra code is running to default initialize all the fields just in case they get read before they're actually initialized. (I assume in some cases the compiler can prove it's not needed and eliminate it, but not in the general case).
It also means that the type system can't rely on fields being initialized for static safety. That in turn means that the compiler can't optimize based on that fact.
In Dart with the constructor initialization syntax, it's not syntactically possible to access any state on a new instance until after every single one of its initializers has run. That means that, in concert with null safety, if you have a non-nullable field, the compiler knows it will never ever be null and then can generate smaller, faster code based on that guarantee.
I agree the constructor initializer syntax is annoying and I wish we had something better, but it's there for a reason. Also, in practice, you often use `this.` or `super.` on the constructor parameters and avoid the initializers entirely.
> While stating itself to be statically typed you can also shoot yourself in the foot by simply using `as Type`, similar to TypeScript. Because that just assigns it to a type and doesn't cast it like you do it in say Rust.
An "as" expression is fully sound and will throw a runtime exception if the value isn't a valid instance of the cast type.
> The extreme use of classes with `abstract class` and whatnot feels kinda 90's to me, just a lot of abstractions and for what?
You don't have to use classes if you don't want to. You can define functions and variables all at the top level and write in a completely procedural or functional style if that's your jam. Some of the Dart packages I maintain are mostly functions.
> I think making it more functional would help it.
We're getting there. It's always had anonymous functions, closures, and plenty of higher-order functions in the collection API. We're adding pattern mataching and exhaustiveness checking now which should let you program in an algebraic datatype style.
Additionally, the first unoptimized compiler resulted in "hello world" having a gargantuan amount of JavaScript code. That left the language with a hard to shake stigma.
Garbage language
I want to define
enum UserState {
case loggedOut
case loggedIn(user: User)
}
where User is itself a struct with props like email/id/Etc
Then, I want to be able to switch on said enum, so that my code can take a UserSession state stream and switch over each case to react accordingly. This gives me compiler - enforced case handling completeness everywhere my enum is consumed which is amazing for code reliability.
This is trivial in Swift or any real language, but with Dart and the stupid flutter bloc model you seemingly can’t do this and end up with these huge if cast chains to send messages.
If I’m wrong and things have changed for the better please let me know, it was my biggest issue with dart/flutter
I need to add complex objects, sometimes multiple. Swift lets you do this easily.
I'm not sure what you mean about boilerplate. The way you create UIs in Dart is one of the main draws of Flutter. Would you rather Android's XML? Or QWidget?
The language design is not an issue with Flutter. Flutter's issues are mainly ecosystem size and performance.
The abiliy to share the codebase between platforms is much bigger draw rather then the way that the UI is written.
Usually, it's a sign that you refactor something to a separate StatelessWidget or at least a function.
If you're coming from web dev, you will be used to having all this container, padding, center, column code in CSS. Now you have it in UI. But on the flip side, this has its flexibility. You can usually refactor the styling part out of the actual widget if you want.
For me the big problems with flutter are state management and platform interop. Yet it's nicer than most other options for developing UI.
The APIs the OP are complaining about are Flutter's not Dart's. Flutter tried to do a vdom-like thing that also included styling on top of regular function call syntax and it is... what it is.
This style is a way to have (extreme) composition over inheritance, which apparently was very useful for the framework authors who mentioned that they didn't need to keep reimplementing opacity for example for every single widget.
That's Flutter, the framework. I like Dart and I wish some conventional imperative Qt/Delphi-like GUI toolkit was available for it.
Is that really determined by Dart and not by how Flutter chooses to do things?
One would think that, which is why I struggle to believe Google is really invested in Flutter's success. They keep it alive and talk about it, but I wonder how much they actually care about it.