Flutter desktop isn’t there yet

https://plei.one/blog/flutter-desktop-not-there-yet/

by invpt • 3 years ago

215 231 3 years ago

lpa22• 3 years ago

i am greatful for Flutter if only to motivate the React Native team

friedman232• 3 years ago

One single platform for cross platform development is enough motivation and react native has improved a lot in the past year.

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.

makestuff• 3 years ago

I can see some apps needing to be native (ex: using AR/ML libraries where you need to squeeze everything out of the phone). However, for most apps I use, they could easily be mobile optimized websites wrapped in an app.

satvikpendem25• 3 years ago

Indeed, as a solo developer, Flutter is a godsend to be competitive with others in the market who already have integrations with a bunch of platforms.

xdfgh1112• 3 years ago

Multiple windows is on the roadmap and high priority.

For me the best use of desktop is testing mobile apps without having to use my phone or an emulator. It works really well.

scarface742• 3 years ago

That’s because the Android emulator sucks for development.

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.

malkia5• 3 years ago

Docking would be nice to have too! like what MSVC or Qt has (built-in in Qt is not that great, but Visual Studio is one to follow). It's a must for content creators with multiple monitors, especially if they want the layout to be preseved from session to session or create different layouts (e.g. how and where the windows are, what is docked in which other, etc) for other people as templates.

xutopia• 3 years ago

His point stands for me as well. I saw a lot of huge potential for cross-platform mobile development but desktop feels like a bad port of a mobile app rendered on desktop.

preommr• 3 years ago

Flutter is going to be 5 years old soon. It's not even the leading solution for cross-platform development for mobile let alone desktop. It's great to be positive and supportive but realistically, if someone had to bet months of dev work on building something non-trivial - would they really choose flutter?

mhoad6• 3 years ago

It’s hardly some toy SDK that is only suitable for MVPs. Google’s single biggest money maker Ads is built with it. It’s hardly a Google specific thing either there are a number of mega sized players also strongly betting on it for some fairly mission critical stuff if I understood correctly.

wiseowise3• 3 years ago

Google’s single biggest money maker Ads is built with it.

If Flutter disappeared tomorrow nobody would even notice it. How much functionality do you think is there?

scarface742• 3 years ago

You realize that even Google doesn’t use Flutter in their cross platform consumer apps.

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.

capableweb3• 3 years ago

Google’s single biggest money maker Ads is built with it

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?

satvikpendem25• 3 years ago

Google AdWords is made with Dart, specifically AngularDart, not Flutter.

Edit: yes, Google Ads the mobile app is made with Flutter.

maxlamb• 3 years ago

To be fair, Flutter is now a close second to React Native, which is 7 years old.

atentaten• 3 years ago

I'm betting the farm on Flutter. I'm building a relatively complicated app that's integrated with native C code on iOS and Android. Before I decided to go with Flutter/Dart, paradigms that I knew nothing about, I experimented with all of the major frameworks. React Native, Expo, Ionic, Capacitor, etc. I chose Flutter because it had the best performance for what I was doing around high-performance audio. Flutter is allowing me to continuously move forward and make real progress as a solo dev. I'm finding the DX better than React Native. I'm going to need to make a related tvOS app as well, but not sure how well Flutter can support it.

mixmastamyk2• 3 years ago

Wait till you hear about Kivy. It's a hard, decade+ long slog to get this right.

gfarah• 3 years ago

Our team choose flutter 3 years ago, we currently serve 2 million users. I attribute a big part of our success to Flutter and the flexibility it gave us as a growing startup.

CharlesW• 3 years ago

For me, Flutter mobile isn't there yet either. I can see where it might be great for games with completely custom UIs, but I find the uncanny valley of pretend native controls a very uncomfortable place to be.

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.

eberkund• 3 years ago

Isn't what you're describing basically React Native? I think the Flutter devs wanted to try a different approach to address what they felt were the shortcomings of React Native which brings along its own set of tradeoffs.

twawaaay• 3 years ago

Every technology is a set of tradeoffs, including Flutter.

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.

dmitriid4• 3 years ago

Users do not necessarily care if the application looks pixel perfect

They do care. They just don't know the words "pixel perfect".

However, everything is an improvement over the standard state of corporate UIs

cxr5• 3 years ago

For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care

Have you measured it, or did you stop after the Form A Hypothesis step?

izacus• 3 years ago

Sure, but most common mobile apps ARE completely custom UIs which insist on their own branding and look. The UI designers usually really hate if they have to use standard components and are unable to express themselves.

Flutter just recognises that.

satvikpendem25• 3 years ago

Agreed, most apps I use already don't use native controls, like Slack, Discord, Spotify etc, and I don't want my apps to do so either since I have a custom design. I think people on HN think users care about platform UI when we see that most users really don't notice or care.

kitsunesoba3• 3 years ago

On iOS it's not too difficult to build a fully custom UI with just UIKit. You want a totally custom button? No problem, don't fight the styling inherent with UIButton, just subclass its parent class UIControl instead which is a blank canvas, but still gets you 90% of the perks of a standard UIButton with minimal effort. It's pretty easy to write entirely custom widgets with unique behaviors too.

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.

kitsunesoba3• 3 years ago

I don't think it's necessarily an error to reimplement widgets, with a caveat — the reimplementations need to be good. Really good, at least as good as native widgets and preferably better. An example of this is Sublime Text/Merge, which feel excellent despite being built with a bespoke UI framework.

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.

lta2• 3 years ago

I thank the flutter team very very much for not using JS. We're already overflown with this stuff and a bit of variety and competition cannot hurt.

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

TobyTheDog1235• 3 years ago

You're definitely not alone in this. One of the core reasons my team chose Flutter was the fact we would not have to spend much time setting up development environments and making sure we were always using the latest and greatest framework.

cxr5• 3 years ago

I personally dislike the whole JS ecosystem

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

wg0• 3 years ago

Someday maybe they can switch the embedding shells to not draw but instantiate the native controls. That'll be really game changer.

This attempt to draw every single control is too much effort with apparent inconsistencies.

deergomoo• 3 years ago

I find the uncanny valley of pretend native controls a very uncomfortable place to be

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.

miffy900• 3 years ago

I don't understand why Flutter's creators are so seemingly religious about Dart

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.

killjoywashere• 3 years ago

I feel like this is similar the conversations we heard about Rust and Go 5-10 years ago.

late edit: 5-10 years ago people were complaining about these languages having issues binding databases, network protocols, etc.

amelius• 3 years ago

Do Rust and Go have good (complete) Desktop UI libraries yet?

kjksf2• 3 years ago

I don't know about Rust but Go doesn't.

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.

malkia5• 3 years ago

Coworker of mine is using Fyne (for Go). So far the one issue that was found was the use of OpenGL, which on certain video cards, on Windows, in a remote-desktop session may not work (it works if you have NVIDIA drivers for example), or if you force `mesa` software rendering on top.

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.

synergy205• 3 years ago

not at all

munificent9• 3 years ago

For Rust, the existence of https://www.areweguiyet.com/ suggests "no".

latchkey3• 3 years ago

It is great to point out things that need improvement, but going so far as saying 'it isn't there yet', seems extreme.

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.

invpt2• 3 years ago

I guess I'm thinking of Flutter's desktop support in relation to how it is on mobile. Flutter mobile does have a lot of built in stuff.

layer83• 3 years ago

I’m sorry, but not supporting multiple windows (not monitors!) in a single process, and not supporting bog-standard desktop features like context menus, rightfully qualifies as “not there yet”.

latchkey3• 3 years ago

It really depends on what the app you're developing requires. My app is just a few buttons for inputting data. I don't need context menus, multiple monitors or text selection. Thanks for the downvote though.

hbn• 3 years ago

The more "solutions" that are developed for desktop + mobile cross-platform applications, the more I see highlighted how different the paradigms are, and how the streams really shouldn't be crossed.

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.

MrOwnPut• 3 years ago

That's nice if you have the funds and time for that. Fully native is ideal.

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.

temporal828• 3 years ago

Qt vs WxWidgets all over again.

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.

ss48• 3 years ago

I largely agree with this when the application will be used heavily on each platform. I think desktop + mobile cross-platform does work when one platform is primary and the second secondary (ex. IOT devices). You can then have an interface primarily focused for an embedded application, and then when data transfer or settings for the embedded device needs to be configured, configuring it from the desktop is easier, and having a similar interface all around is beneficial.

satvikpendem25• 3 years ago

If you have the money, make everything native, but until then I can build a Flutter app that works on 6+ platforms for the price of one, which is a real competitive advantage for a solo developer running a startup.

mixmastamyk2• 3 years ago

One thing I learned though... if you say are going to deploy on say, Android, you are not getting away from its dev toolchain and API if you want to do anything non-pedestrian. Same for iOS and possibly Windows.

So you often end up really having to learn N+1 platforms.

kodah• 3 years ago

Fully native isn't especially realistic. At the risk of sounding like a broken record, general purpose tooling written by a small team can't support multiple native UIs.

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.

satvikpendem25• 3 years ago

I'm using flutter_rust_bridge, it works pretty well. However, I do like Dart due to a few features it has, like code generation so that I can build my own language features if I want to, I use that pretty extensively.

kitsunesoba3• 3 years ago

Having worked on projects for both mobile platforms with small teams, I find that cross platform UI frameworks only really make sense for somewhat simplistic apps. The more involved the app in question is, the more these frameworks incur overhead with the extra surface area for bugs to occur on which is multiplied by the number of supported platforms.

The story on desktop is a little better but the same principle applies to some degree.

augusto-moura• 3 years ago

Well, web designing does blur the lines. You can easily create a website that is both desktop and mobile friendly by implementing responsive design. Translating that to a native experience seems to be the problem

moomoo112• 3 years ago

The point of seriously (key word) using x platform tools is to ship fast and solve customer problems.

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.

AnIdiotOnTheNet• 3 years ago

I wonder how many people Maxis employed when they made Sim City 2000? Because it had a native UI for every platform it was ported to that had a windowing and widget toolkit.

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.

optymizer• 3 years ago

I think Flutter is the best option right now to release your idea on mobile, web and desktop platforms yourself without hiring additional people. The only other realistic option I know of is to use web tech. Are there other good options for single devs?

SebastianKra• 3 years ago

You only need to look to SwiftUI to realize that this is false.

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.

hobofan• 3 years ago

I most recently tried out Flutter about a month ago and "not there yet" feels like my overall experience. Sadly for a project of Flutter's age one has to wonder whether the "yet"-phase will ever end (just like some libraries are bound to always be buggy due to their architecture, while others feel smooth).

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.

TobyTheDog1235• 3 years ago

We actively use Flutter and tend to agree with this sentiment, with the caveat that we believe it absolutely can get there (and I believe a lot more in Google's ability to stay relevant than Facebook's, even with ChatGPT in the mix).

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.

azinman2• 3 years ago

I’m surprised anyone would trust their UI core technology to be something from Google. They kill projects left and right, and that was before the layoffs.

tekkk3• 3 years ago

To me as someone who recently got into Flutter to make a side-project (mobile game) the most glaring problem isn't the lack of ecosystem or little UI issues the author mentions but the language itself. You had a green field to make the best programming language for creating UIs and you made Dart? Like what.

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).

wiseowise3• 3 years ago

They didn’t create Dart for UI. It was dead and they shoehorned it into Flutter.

spankalee• 3 years ago

Considering that Dart was made to run in browsers, they did in fact.

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.

kajecounterhack• 3 years ago

To be fair it’s not a bad choice for UI: supporting both AOT and JIT speeds up the dev loop and allows compiled performance + hot reloading in dev, which is good for UI development.

gedy• 3 years ago

Yeah it was an attempt to fix JS before JS improved a lot in recent years, and before TS took off.

satvikpendem25• 3 years ago

They've answered why Dart many times. It's a language that fits their needs, since it has JIT, AOT, compilation to JS and now WASM. Back then there weren't many languages that could do all that, and even today there aren't many. Kotlin (and other JVM languages) and TypeScript (and other compile-to-JS-only languages) are already out since they are not AOT, only JIT even now.

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.

https://www.youtube.com/watch?v=xqGAC5QCYuQ

nicoburns3• 3 years ago

since Apple does not allow JITted code apparently (not sure how React Native gets around this then)

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.

kaba06• 3 years ago

Java fits all the bills and Google already has ample experience/tooling working with it, including a very great java to js compiler.

maxloh• 3 years ago

Kotlin (and other JVM languages) and TypeScript (and other compile-to-JS-only languages) are already out since they are not AOT, only JIT even now.

There is Kotlin Native now.

zerr2• 3 years ago

so much boilerplate feeling code (Center here, Container there)

That's Flutter, the framework. I like Dart and I wish some conventional imperative Qt/Delphi-like GUI toolkit was available for it.

chairhairair• 3 years ago

You can use Flutter as an imperative framework. Just ignore widgets (the reactive top layer of Flutter) and use the underlying imperative elements directly.

sorokod2• 3 years ago

Center here, Container there

Is that really determined by Dart and not by how Flutter chooses to do things?

satvikpendem25• 3 years ago

No you're right, it's Flutter, they are misconstruing Dart and Flutter.

strongpigeon3• 3 years ago

I’m not sure why the Dart hate honestly. It’s a pretty solid language in my opinion and I like the direction they’re taking (non-nullable, record, pattern matching). The ecosystem is weak for sure, but that’s not a gripe on the language itself.

I’m curious what do you dislike about it apart from semi-colons and the constructor syntax (which seem fine to me?).

themerone• 3 years ago

It gets the hate because it comes from Google and it was originally marketed as a JavaScript replacement.

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.

dsabanin5• 3 years ago

Exactly, after JVM world I'm especially loving reified generics. Being able to access type information on generics at runtime is very helpful. Plus developer experience for working with DartVM and Flutter is crazy good.

tekkk3• 3 years ago

Okay I guess I should provide more details. Constructor syntax fine? Jesus how come you can't use the constructor parameters as the default values but have to either resort to using `late` or that weird `: {}` after constructor like in C++, can't remember how it was. I just added `late` and thought whatever. Probably there are nuances I've missed but how come you had to reinvent that - thought it should be intuitive from the get-go.

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.

newZWhoDis3• 3 years ago

Last I checked you can’t even have enums with payloads/ associated values.

Garbage language

IshKebab• 3 years ago

I think you give Dart too little credit. Consider the other popular languages of today - Python, JavaScript, C++. Dart is far nicer than those. I'd say it is nicer than Go too.

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.

MrDresden• 3 years ago

Declarative UI has arrived on Android via Jetpack Compose. So there is no need to create new UI in XML anymore.

The abiliy to share the codebase between platforms is much bigger draw rather then the way that the UI is written.

never_inline2• 3 years ago

(Center here, Container there)

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.

eddieroger• 3 years ago

Idk, you'd think an org like Google had the resources and the talent to make something truly amazing

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.

college_physics• 3 years ago

The basic functionality of the typical UI hasnt changed for ages. Yet technologies keep churning. There is probably a better way but apparently people are not incentivised to find it.

intrasight• 3 years ago

Ages indeed. And how sad and frustrating. The best cross-platform app framework is one that I used in 1990.

bbkane• 3 years ago

This is a strange take for me- people are CONSTANTLY trying to find new, better ways to do UI. Elm, React, DearIMGUI, Flutter, and Xilem are some of the more well-known fairly recent libraries.

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

robust-cactus• 3 years ago

Another one, desktop webviews don't exist either. Everyone does something custom right now and there's an epic vent fest in one of their GitHub issues. This causes about 1 new package to get released every few months too that tries to address it.

arunbahl• 3 years ago

This. This was one of the reasons we ended up abandoning Flutter (the state of text editing was the other, super_editor notwithstanding).

loic-sharma7• 3 years ago

Hello, I'm from the Flutter desktop team. We're actively working on adding platform views to desktop, which will allow you to embed web views into your Flutter application. Stay tuned :)

cbracken• 3 years ago

Hey there - Flutter team member here. Support for integrating arbitrary non-flutter views/widgets (referred to as PlatformViews in Flutter terminology) is something we're actively working on at the moment, once we've got them landed, web views and video player support are top of our list in terms of views to add support for. We know people can't wait for this to land, and believe me, I can't wait for it to land either :)

PlatformView support is one of our top desktop priorities this year (along with multi-window support).

nu11ptr2• 3 years ago

Haven't used, but seems to be available as a community package:

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?

sfeng• 3 years ago

I recently tried to use Flutter to develop a Windows desktop app, and I hit a wall. Unfortunately I'm using an arm64 machine, and I ran into enough mysterious errors that I just gave up.

loic-sharma7• 3 years ago

Hello, I'm from the Flutter desktop team. We're actively working on Windows ARM64 support, this should be coming soon! Stay tuned :)

timsneath3• 3 years ago

A good example of Flutter desktop is https://rive.app/downloads - curious on others' thoughts of how that compares to Electron or other choices that are out there.

satvikpendem25• 3 years ago

I tried it, it's quite snappy compared to Electron, I assume because it's AOT compiled.

rileyphone• 3 years ago

Probably moreso avoiding the DOM, Javascript JITs are very fast.

loic-sharma7• 3 years ago

Hello, I'm from the Flutter desktop team. Thank you for the excellent feedback, this is truly invaluable.

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!

livinglist• 3 years ago

Hi there, I have been a happy flutter user for quite some time now, keep up them good work!

mhoad6• 3 years ago

Same, contrary to some of the comments here I’ve had nothing but great experiences coming from a purely web background previously.

malkia5• 3 years ago

Is impeler going to affect (in good way) the performance/latency on desktop too? (I think it's mostly for iOS now, right)?

mhoad6• 3 years ago

The plan AFAIK is to make it the default everywhere but they are just rolling out each platform in some kind of prioritised order.

loic-sharma7• 3 years ago

Yup, but we're focused on mobile first as these are the most resource constrained platforms. We're also experimenting with 3D support in Flutter using Impeller. Check out these demos from Flutter Forward: https://youtu.be/zKQYGKAe5W8?t=6955

You can learn more about Impeller here: https://www.youtube.com/watch?v=gKrYWC_SDxQ

invpt2• 3 years ago

That's great to hear! When I get the chance, I'll update the article to note that custom context menus are actually supported now.

dsabanin5• 3 years ago

Thank you for the great work! Flutter and Dart are awesome and keep getting better. I'm coming from the land of Scala, Erlang, Clojure, TypeScript, and I'm loving the general approach to the engineering and design that Flutter and Dart teams have. Kudos!

davidkuennen2• 3 years ago

First of all: Thank you for your outstanding work!

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.

loic-sharma7• 3 years ago

Google's Flutter team was affected by layoffs and we lost some wonderful folks. However, the number of Googlers working directly on Flutter has grown substantially in the last year.

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.

never_inline2• 3 years ago

Last time I used flutter for desktop, setting custom window size required an external package. I think it's a significant use case for many people.

loic-sharma7• 3 years ago

Agreed! We will add support for window customization as part of the multi-window effort.

dr_kiszonka• 3 years ago

Hi! I was wondering about the coexistence of Flutter and Kotlin in Android development. Is there any good write-up to help devs to choose between them depending on the use case?

account-5• 3 years ago

Not who you want an answer from but for me if I was writing an android only app I'd go for kotlin, if I wanted android, iOS, desktop, and web I'd go dart/flutter.

parentheses• 3 years ago

Not being troll-y, but …

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.

qdot76367• 3 years ago

As someone shipping an app across all desktop and mobile platforms with flutter, binding it into a native rust library, I absolutely adore it. It does what I need and is fairly reliable about it everywhere, while keeping build systems and everything else mostly managed for me. As the post mentions, it’s not a panacea, but for someone who needs a good-enough solution, it’s been great.

Winsaucerer• 3 years ago

What are you using to do the rust bindings?

nu11ptr2• 3 years ago

A couple of thoughts (doesn't address all the concerns):

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

https://pub.dev/packages/platform_ui

qualudeheart• 3 years ago

I don’t know. I have a colleague who swears by it.

miiiiiike• 3 years ago

If there's anything I've learned from using Google projects it's this: It's not going to get fixed.

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."

mda• 3 years ago

Well it seems there are 11K open issues and 66K closed issues in their github page.

So maybe some issues got fixed at least?

phist_mcgee• 3 years ago

The dreaded, 'closed due to inactivity' strikes again.

eptgrant• 3 years ago

Agreed, still unable to take a high res photo from any device using their own camera plugin.

https://github.com/flutter/flutter/issues/58163#issuecomment...

Sighhh. Maybe one day.

lern_too_spel• 3 years ago

You haven't really used a Google open source project unless you've filed a bug, had it assigned, had it automatically closed after months of inactivity by some PM cleaning possibly obsolete bugs, reopened the bug, rinsed, and repeated for a decade.

JediPig• 3 years ago

I have 2 LOB on the desktop. Is Jank an issue? Only to those who have 100+ refresh rates.

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.

TobyTheDog1235• 3 years ago

I've been very disappointed with the direction of Flutter recently, but I still do stand by it and will always choose it over the GatsreminextstroJS framework for VuengulembereactelteJS.

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.

whiplashoo• 3 years ago

Last year, I built a desktop app with Flutter with native-looking UI, for both macOS and Windows: https://blog.whidev.com/native-looking-desktop-app-with-flut...

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.

kidfiji• 3 years ago

Not having any experience at all using Flutter, nor do I have any interest in doing so - just wanted to say that your blog article was a fun read. Thank you for sharing! :)

canucker2016• 3 years ago

Not surprising.

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?

iamsanteri• 3 years ago

This is exactly why even after I made the decision, I’m still somewhat hesitant on learning Django. With RoR it’s a different story, but Django is a bit weird in this regard (users, references, popular applications).

mhoad6• 3 years ago

Probably this one https://rive.app/

_jezell_• 3 years ago

I think the guys at Rive would disagree with this sentiment. https://twitter.com/FlutterDev/status/1288494688115126273

freedsoftware• 3 years ago

This article really needed to be longer and have some illustrations. What's the point of publishing an essay about interface design without including any graphics?

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.

nzoschke• 3 years ago

I LOVE Flutter for a web / iOS / android side project.

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.

throwing_darts• 3 years ago

I've written a few Flutter apps. The problem is dart is just not a good language and not something you'd want to use in 2023.

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.

sngz• 3 years ago

The Flutter team should consider unpegging from dart and utilize JavaScript/Typescript, Kotlin, or Swift.

why would they do that, dart is better than all those languages except for maybe swift.

c-smile• 3 years ago

2 cents from Sciter developer...

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.

anonygler• 3 years ago

It’s been 5 years since I left my Dart team at Google. Still shocks me how slowly that world moves. There’s just no sense of urgency when AdWords revenue showers you with unlimited sums of money.

domber• 3 years ago

Ok, it's isn't "there" just yet, so what? They are working on it and doing a great job so far. It's not perfect, but nothing is.

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.

Flutter desktop isn’t there yet

Related Stories