[HN Gopher] Flutter Desktop Isn't There Yet
___________________________________________________________________
Flutter Desktop Isn't There Yet
Author : invpt
Score : 158 points
Date : 2023-02-03 16:26 UTC (6 hours ago)
(HTM) web link (plei.one)
(TXT) w3m dump (plei.one)
| preommr wrote:
| 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?
| atentaten wrote:
| 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.
| mixmastamyk wrote:
| Wait till you hear about Kivy. It's a hard, decade+ long slog
| to get this right.
| mhoad wrote:
| 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.
| scarface74 wrote:
| 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.
| capableweb wrote:
| > 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?
| malkia wrote:
| Google Ads is written in Flutter - https://play.google.com/
| store/apps/details?id=com.google.and... - if you go
| download, skip the welcoming bits, and go to licensing
| you'll see lots of flutter libraries including flutter
| itself
| capableweb wrote:
| Right, when people say "Google's single biggest money
| maker" they're talking about Adwords, which is usually
| accessed via the web, not a Android app called "Google
| Ads".
| satvikpendem wrote:
| To be fair, it's all the same thing underneath, the Ads
| app is the same as AdWords on web. "Google's biggest
| money maker" isn't referring to either AdWords the
| website or the Ads mobile app, it's talking about the
| underlying ads product itself, ie what gets shown on
| websites, these are simply UIs over that.
| capableweb wrote:
| > the Ads app is the same as AdWords on web
|
| 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.
| satvikpendem wrote:
| By "same," I did not mean technologically; as I pointed
| out in my other comment, I know AdWords is made with
| AngularDart while the Ads app is made with Flutter.
|
| 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.
| satvikpendem wrote:
| Google AdWords is made with Dart, specifically AngularDart,
| not Flutter.
|
| Edit: yes, Google Ads the mobile app is made with Flutter.
| mhoad wrote:
| Sorry I was referring to the mobile apps not the web
| experience.
| satvikpendem wrote:
| Where does it show that the mobile app is in Flutter?
| mhoad wrote:
| Under the settings screen there is a software licenses
| section. In there.
| satvikpendem wrote:
| Neat, it says Powered by Flutter on Android. That's
| pretty cool.
| wiseowise wrote:
| > 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?
| kjksf wrote:
| In March 2021 there were 150 thousand Flutter apps in
| Google Play store.
|
| 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.
| wiseowise wrote:
| I meant in Google Ads. How much is the front end there
| anyway?
| [deleted]
| maxlamb wrote:
| To be fair, Flutter is now a close second to React Native,
| which is 7 years old.
| CharlesW wrote:
| 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.
| kitsunesoba wrote:
| 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.
| wg0 wrote:
| 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 wrote:
| > 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.
| twawaaay wrote:
| 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.
| dmitriid wrote:
| > 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
| [deleted]
| lta wrote:
| 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
| TobyTheDog123 wrote:
| 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.
| eberkund wrote:
| 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.
| izacus wrote:
| 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.
| satvikpendem wrote:
| 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.
| nicoburns wrote:
| That depends on what kind of controls though. Many apps
| will their own buttons, but most are using the native text
| input control (and often the native scroll for screens /
| screen transitions.
| kitsunesoba wrote:
| 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.
| tekkk wrote:
| 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).
| [deleted]
| IshKebab wrote:
| 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 wrote:
| 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.
| wiseowise wrote:
| They didn't create Dart for UI. It was dead and they shoehorned
| it into Flutter.
| kajecounterhack wrote:
| 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 wrote:
| Yeah it was an attempt to fix JS before JS improved a lot in
| recent years, and before TS took off.
| spankalee wrote:
| 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.
| satvikpendem wrote:
| The style of writing the UI code takes some time to get
| used to, but the composability is really nice. For example,
| if I want to center something, I use Center and it works as
| I predicted. If I want to change the opacity of something,
| I don't need to find the opacity property of a particular
| widget, I can just...use Opacity, and it'll work for
| everything.
|
| 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.
| zerr wrote:
| > 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 wrote:
| You can use Flutter as an imperative framework. Just ignore
| widgets (the reactive top layer of Flutter) and use the
| underlying imperative elements directly.
| zerr wrote:
| Well, I'd say the main value proposition of
| Qt/Delphi/wxWidgets/WinForms/etc... is a rich set of
| widgets/controls including its event handling and layout
| mechanisms. Is such stuff available in the imperative impl
| of Flutter?
| eddieroger wrote:
| > 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.
| satvikpendem wrote:
| 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
| maxloh wrote:
| > 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.
| satvikpendem wrote:
| Sure, not ten years ago though when it was first starting.
| Doesn't Jetpack Compose work similarly to Flutter in that
| it draws every pixel? If so, Kotlin native could be used
| there to bring it to web and desktop perhaps.
| nicoburns wrote:
| > 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.
| olliej wrote:
| No, the ability to JIT is not per framework (I'm unsure how
| that would work?), it's per process. Using JSC doesn't give
| you a JIT - now the JSC interpreter is very fast, so it's
| possible claims that they "need JIT" are incorrect (back
| when I worked on JSC it was a common belief from people
| that the JITs were magic fairy dust, and so would come in
| to anything with a data-less assumption that a JIT was
| needed), it's also possible that "react native" is using
| wkwebview in which case the content would be running in a
| separate web content process with a jit.
| nicoburns wrote:
| I don't think React Native is using WkWebView. But that
| the introduction of WkWebView which allows JIT was the
| source of my confusion. I was under the impression that
| JIT was enabled for any uses of JSC in iOS at that time.
| But it seems that is not the case.
|
| 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).
| kaba0 wrote:
| Java fits all the bills and Google already has ample
| experience/tooling working with it, including a very great
| java to js compiler.
| satvikpendem wrote:
| Java, again, is not ahead of time compiled, or at least did
| not have a good solution for that ten years ago. Even
| Android apps now run as AOT compiled apps with Android
| Runtime (ART), discontinuing the Dalvik VM.
| pritambarhate wrote:
| Java had AoT compilers for more than 20 years,
| https://en.wikipedia.org/wiki/Excelsior_JET
|
| If Google really wanted they could have wrote one.
| satvikpendem wrote:
| > _If Google really wanted they could have wrote one._
|
| Which they did, but for Dart instead.
| kaba0 wrote:
| Which has zero ecosystem and just reinventing the wheel.
| satvikpendem wrote:
| > _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._
|
| Replace TypeScript with Java above.
| kaba0 wrote:
| Why would you need to modify the language? Dart is the
| most basic managed language without any novel feature.
| There is zero reason why, say, java couldn't have been
| fitted for this particular niche.
| satvikpendem wrote:
| How will you convince the Java team to add things you
| want to make it work better for your framework? You could
| try adding them yourself but you'd be forking and making
| your own Java dialect at that point. They did that
| instead with Dart which they own.
| kaba0 wrote:
| What would you need for a framework that can't be
| implemented as a library? Will we recreate every language
| from scratch for the next logging, gui lib, web framework
| as well?
| satvikpendem wrote:
| For example, making an AOT compiler. Or adding other
| features. Or making the implementation more suited to
| client side apps. There are many things you can do to a
| language to make it easier for a specific use case. In
| the extreme, this is what DSLs are.
|
| 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.
| kaba0 wrote:
| Useful? Maybe. Yet you didn't give any language feature
| not found in literally any other managed language.
| satvikpendem wrote:
| All else being equal, it is still useful to have control
| over a language's development. It doesn't matter that
| Dart may or may not have features not present in other
| languages, as long as they can add them as necessary
| based on Flutter's development.
| never_inline wrote:
| > (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.
| sorokod wrote:
| _Center here, Container there_
|
| Is that really determined by Dart and not by how Flutter
| chooses to do things?
| satvikpendem wrote:
| No you're right, it's Flutter, they are misconstruing Dart
| and Flutter.
| sorokod wrote:
| True, just have a look at Stack Overflow questions tagged
| Dart, very few (being extra cautious here) are not flutter
| question.
|
| https://stackoverflow.com/questions/tagged/dart
| satvikpendem wrote:
| To be fair, looking at Kotlin would likely yield similar
| results, being mainly used for Android.
| strongpigeon wrote:
| 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?).
| dsabanin wrote:
| 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.
| themerone wrote:
| 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.
| satvikpendem wrote:
| To be fair, around a decade ago, Chrome wanted to add a
| Dart VM (Dartium) to which many vehemently protested, and I
| agree it would have been a bad move to have a browser
| essentially have its own language rather than JS, forcing
| other browsers to adopt it. From there though, we got a
| much better cross browser standards-based solution in the
| form of WASM, which is even more powerful since languages
| other than Dart could be used. This controversy is where I
| first saw the Dart hate, but it has grown into a nice
| language since, especially with Dart 3+ which introduces,
| records, patterns, and exhaustive pattern matching.
| strongpigeon wrote:
| Oh yeah I do remember that. I can see how some of that
| stigma lingers.
| tekkk wrote:
| 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.
| newZWhoDis wrote:
| Last I checked you can't even have enums with payloads/
| associated values.
|
| Garbage language
| strongpigeon wrote:
| You can since 2.17. Not sure if you're being sarcastic
| about this making it a garbage language.
| college_physics wrote:
| 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 wrote:
| Ages indeed. And how sad and frustrating. The best cross-
| platform app framework is one that I used in 1990.
| qualudeheart wrote:
| I don't know. I have a colleague who swears by it.
| kid-icarus wrote:
| [flagged]
| account-5 wrote:
| Why? I'd love to know what's so bad about it...
| wiseowise wrote:
| Covariant generics for starters.
|
| https://news.ycombinator.com/item?id=18517514
| strongpigeon wrote:
| It's not as pure, but I think from a usability point of
| view they made the right call there.
| account-5 wrote:
| Looks like I'm going to have to find out what generics are
| and then why they shouldn't be covariant!
| hbn wrote:
| 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.
| augusto-moura wrote:
| 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
| satvikpendem wrote:
| 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.
| mixmastamyk wrote:
| 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.
| moomoo11 wrote:
| 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.
| ss48 wrote:
| 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.
| kodah wrote:
| 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.
| kitsunesoba wrote:
| 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.
| satvikpendem wrote:
| 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.
| AnIdiotOnTheNet wrote:
| 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.
| MrOwnPut wrote:
| 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 wrote:
| > 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.
| lta wrote:
| I'm not sure we can blame either for the macOS support.
| synergy20 wrote:
| or,just use flutter these days
| canucker2016 wrote:
| 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 wrote:
| 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).
| mhoad wrote:
| Probably this one https://rive.app/
| qdot76367 wrote:
| 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.
| JediPig wrote:
| 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.
| parentheses wrote:
| 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.
| sfeng wrote:
| 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-sharma wrote:
| Hello, I'm from the Flutter desktop team. We're actively
| working on Windows ARM64 support, this should be coming soon!
| Stay tuned :)
| timsneath wrote:
| 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.
| satvikpendem wrote:
| I tried it, it's quite snappy compared to Electron, I assume
| because it's AOT compiled.
| whiplashoo wrote:
| 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.
| lpa22 wrote:
| i am greatful for Flutter if only to motivate the React Native
| team
| friedman23 wrote:
| 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 wrote:
| 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.
| friedman23 wrote:
| > I can see some apps needing to be native (ex: using AR/ML
| libraries where you need to squeeze everything out of the
| phone)
|
| 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.
| satvikpendem wrote:
| 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.
| miiiiiike wrote:
| 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 wrote:
| 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 wrote:
| The dreaded, 'closed due to inactivity' strikes again.
| killjoywashere wrote:
| 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 wrote:
| Do Rust and Go have good (complete) Desktop UI libraries yet?
| kjksf wrote:
| 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.
| IceWreck wrote:
| There is react native. Facebook pays for Android/iOS and
| Microsoft pays for Windows/macOS.
|
| Sadly no maintained Linux desktop app support.
| malkia wrote:
| 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.
| synergy20 wrote:
| not at all
| TobyTheDog123 wrote:
| 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.
| latchkey wrote:
| 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.
| layer8 wrote:
| 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".
| latchkey wrote:
| 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.
| layer8 wrote:
| The fact that it happens to fit your limited needs doesn't
| mean that it's suitable for general desktop development.
| mike_hearn wrote:
| Although true, HTML doesn't let you customize context
| menus or (easily) open multiple windows either, and UI
| interactions frequently lag, but it's used for general
| desktop development all the time. These issues seem to be
| more that describing something as for desktop development
| raises the bar fairly significantly in terms of expected
| feature set. That's reasonable, but we should be careful
| in describing something as unsuitable because it lacks
| things HTML also lacks.
| layer8 wrote:
| FWIW, I don't consider web applications to be a suitable
| replacement for native desktop applications, not the
| least because they lack support for desktop UI
| conventions, which do exist for a reason; although it is
| true that many people nevertheless make do with web apps.
| latchkey wrote:
| Flutter Desktop isn't the right environment _for you_.
| invpt wrote:
| 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.
| loic-sharma wrote:
| 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!
| never_inline wrote:
| 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-sharma wrote:
| Agreed! We will add support for window customization as part
| of the multi-window effort.
| dsabanin wrote:
| Do you have any pointers for someone who would love to
| contribute to Flutter and Dart as an open source
| contributor? Is there some guideline for what kind of
| contributions will be considered, areas where contributions
| are desired, etc?
| loic-sharma wrote:
| Please check the contribution guide: https://github.com/f
| lutter/flutter/blob/master/CONTRIBUTING....
|
| We strive to be an open community. Anyone can become a
| Flutter team member if they contribute frequently :)
| dsabanin wrote:
| Thank you! I think that's a great attitude and a key to
| the long-term success.
| timsneath wrote:
| We've got a guide here that covers some of these areas: h
| ttps://github.com/flutter/flutter/blob/master/CONTRIBUTIN
| G....
|
| 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...
| mdswanson wrote:
| I'll mark the "better tell Tim" about the HN article off
| my list. :)
| dsabanin wrote:
| Awesome, thanks!
| [deleted]
| invpt wrote:
| 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.
| livinglist wrote:
| Hi there, I have been a happy flutter user for quite some time
| now, keep up them good work!
| mhoad wrote:
| Same, contrary to some of the comments here I've had nothing
| but great experiences coming from a purely web background
| previously.
| synergy20 wrote:
| same here,keep up the great work.
|
| by the way dart is my favorite cross platform language
| nowadays beyond flutter.
| orangecat wrote:
| _dart is my favorite cross platform language nowadays
| beyond flutter_
|
| Yeah, it's very underrated. I find it nearly as
| expressive as Python with far better maintainability and
| performance.
| dr_kiszonka wrote:
| 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?
| davidkuennen wrote:
| 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-sharma wrote:
| 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.
| justeleblanc wrote:
| A community project? Flutter.dev literally says "Flutter is
| an open source framework by Google [...]" There is no list
| of sponsors on their webpage either, only a list of
| companies using Flutter. Google owns the logo and the
| trademark, controls the github repository, etc. Having
| contributors from other companies does not make the project
| into a community project.
| moomoo11 wrote:
| You're supposed to feel better, not ask questions.
| Besides they won't say anything that affects their own
| job security (nor should they imo).
| nileshtrivedi wrote:
| > Flutter is a community project
|
| A quick WHOIS search for flutter.dev and pub.dev domains
| tells me that this is not really the case.
| [deleted]
| plq wrote:
| Is there a CLA? Do I have to waive ownership of my
| contributions for my code to be merged? If yes then it's
| not a community project. Domain ownership has little to
| do with it. Look at who owns github.com :)
| satvikpendem wrote:
| CLAs are always a good idea if one is maintaining an open
| source project. I'm not going to track down every single
| contributor who made some small PR perhaps, just to make
| a license change.
| evol262 wrote:
| Why is your project changing the license, and why do you
| assume that contributors would still have done so under
| whatever license you're changing to?
| satvikpendem wrote:
| The license could change for any number of reasons,
| making a paid version, making it GPL, etc. With a CLA, I
| don't have to assume, I'm able to change it regardless,
| that's why for maintainers they are useful.
| timsneath wrote:
| 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.
|
| 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.
| easythrees wrote:
| Is Flutter open source?
| zmk5 wrote:
| Yeah it is under a BSD license:
|
| https://github.com/flutter/flutter
| dmitriid wrote:
| It's open source the way Chrome is open source: the
| source is there, but the development is ~100% by Google
| rishabhjain1198 wrote:
| Google Chrome is not open source, Chromium is.
|
| [Reference](https://en.wikipedia.org/wiki/Chromium_(web_b
| rowser)#:~:text....)
| satvikpendem wrote:
| Not 100%, at least 30% of PRs are done by outside Google
| contributors.
| davidkuennen wrote:
| Thank you! That's reassuring and I strongly believe that
| Flutter is the best option for developing cross platform
| apps right now.
| malkia wrote:
| Is impeler going to affect (in good way) the
| performance/latency on desktop too? (I think it's mostly for
| iOS now, right)?
| mhoad wrote:
| 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-sharma wrote:
| 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
| dsabanin wrote:
| 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!
| xdfgh1112 wrote:
| 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.
| scarface74 wrote:
| 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.
| malkia wrote:
| 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.
| hobofan wrote:
| 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.
| TobyTheDog123 wrote:
| 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.
| xutopia wrote:
| 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.
| azinman2 wrote:
| 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.
| robust-cactus wrote:
| 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 wrote:
| This. This was one of the reasons we ended up abandoning
| Flutter (the state of text editing was the other, super_editor
| notwithstanding).
| cbracken wrote:
| 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).
| nu11ptr wrote:
| 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?
| loic-sharma wrote:
| 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 :)
| nu11ptr wrote:
| 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
___________________________________________________________________
(page generated 2023-02-03 23:00 UTC)