Earlier quoted context omitted.
I have not. I didn’t want to put the time into learning the .NET stack and C# because I am from a .NET town and did not want to get stuck here. What're your thoughts on it?
I'm a native dev that is aggressively against the JS-based hybrid frameworks, and I will do every project in Xamarin from now on after working in it for a greenfield project. It's the best option out there until Kotlin Native gets legs.
Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
251–260 of 467 posts
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#252Earlier quoted context omitted.
Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.
Just using the GPU isn't enough. On iOS and macOS you have a compositor that has exclusive access to the display that native widgets will use. If you do all the rendering yourself on the GPU, you'll incur an extra hidden full window blit on the compositor side, which is definitely noticeable, especially in power efficiency.
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#253Earlier quoted context omitted.
I don't think anyone has a definite answer, not even Google itself. Google placed several bets on different technologies and community will ultimately decide which of them is the winning one. Personally I think native Android (Kotlin) and iOS (Swift) development is here to stay. I have tried many cross-platform frameworks and on any non-trivial mobile app, all of them cause more problem than they solve.
> all of them cause more problem than they solve I know what you mean. But have you tried flutter? Try it and you might change your opinion just like me.
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#254Earlier quoted context omitted.
(I'm the Flutter TL.) According to today's benchmark numbers, we're at 4414KB on Android and 8572KB on iOS (IIRC, iOS encrypts before compressing so it can't get as good a compression). This is for our Hello World test app ( https://github.com/flutter/flutter/blob/master/examples/hell... ), which is more or less the smallest app you can imagine building with Flutter unless you bypass the entire framework and only use…
Hmm, encrypting before compressing seems like a pretty strange decision. How does that happen?
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#255Earlier quoted context omitted.
Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.
It does cost more in developer hours though. Every update to every emulated UI requires an update on your end. There will be a lag between that update where apps will be noticeably different than native. Can you honestly guarantee Flutter will always keep up with all the environments you plan on targeting? Will Windows, MacOS, iOS, and Android always look and feel the same? That seems like a lot more work to maintain…
In practice, we've found many apps these days don't even try to use the OEM UI style. Instead, they make "branded apps" with very customized widgets. Flutter really shines at this; it's very easy to make custom widgets. (Indeed, all our widgets, including the ones that look like OEM widgets, are just "custom widgets"... it's because it's so easy to make high-quality custom widgets that we're able to make OEM-like widgets so quickly.)
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#256Earlier quoted context omitted.
It is, but I trust a Google team to get that to work at least passably well.
As someone who is highly discerning of small UI issues, Flutter on Android implements the UI controls extremely well to my eye. (Accessibility not so much unfortunately, but that is a work in progress.)
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#257I cannot wait to switch from having to use a compile-to-JS toolchain to a compile-to-Dart-to-JS toolchain in order to get a language with a good type system. I'm hopeful Dart will get better given what I've seen and what a member of the Dart team mentioned in a thread a few weeks ago, but right now it's still nothing that gets close to the ancient ML. Would be nice if they learnt a few things from Facebook or Microso…
Look at Blazor. It's C# that compiles to Webassembly. None of the JS nonsense required!
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#258Earlier quoted context omitted.
We're not quite there yet unless you have a high tolerance for pain, but in the coming year we should in a good place to support that kind of thing.
pain: bugs or performance, or both? ;-)
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#259This is flash. You can't do anything in it that fills like the web - no copy paste, right clicking causes things to happen. I don't expect games like this to have links and proper bookmarkable urls, but I doubt it'll work as expected if it did.
This is the epitome of the problem with flutter - it re-implements the UI, creating an experience that is just close enough but not good enough. And no matter how many smart people and an insane amount of resources they put into it, it'll never be good enough.
There's a reason why flash died out, and it's not only apple. It was dropped for making interactive website long before apple killed it - it doesn't work well with the web.
Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
#260Anyone using Flutter with windows 10? It's been a pain to get the emulators to work - having to changes some Bios config and all.