He a self important egotistic who's finally admitted he's been wrong the whole time and "discovered" what's been under his nose for over 20 years after all the people he kept shitting on did all the hard work to make Linux a fantastic option for dev work.
Because your app will work on all platforms and the rest of the billions of app users outside of this little niche-of-a-niche-of-a-niche forum just want to do whatever they need to get done on a app in their normal lives and don't even know what you are talking about when you say the app "sucks" because it doesn't use exactly the right rounded corners on a button or the listview scroll physics are exactly same as a "native" app.
Because you'll still want to support both OS's sooner rather than later and then you'll be re-inventing the wheel by rewriting all your code a second time on the other platform. Plus using Flutter from the start means you have the option of seeing a much wider world than just Android or iOS: you can build the same app for Linux, MacOS, Windows and the Web.
Dart being a GC'd runtime makes it quite hard to use for low latency audio applications, probably not as critical for audio input as output, but still potential issue, for more details see: https://github.com/dart-lang/sdk/issues/46943
>Codegen for json deserialization, data types, general slowdown in the analysis server at scale, the list feels long,
Those are clearly Dart critiques, sure Dart is not a perfect language, but I can tell you coming from Java and Kotlin that they have plenty of warts of their own, as does ObjC and Swift. On the other hand, Dart is still being very actively developed and improved so I have no doubt that in the future, it will be better than today, just as its sound null-safety now out classes Kotlin's NS implementation.
>but does anyone on the team use iOS full time
Not sure why you keep focusing on iOS and Flutters focus on Material. Sure you might feel the need to use iOS styled widgets but there are plenty of commercial apps built with Flutter that very happily base off of Material and you should note that the new rendering engine has been developed on iOS first to specifically address many of the valid perf issues that skia based engine has had on iOS and Metal.
>. On the outward facing apps this is definitely a matter of perception, I don't think I need to expand there.
After reading all your preceding posts and now this, you seem to want to imply something but not come out and say it. I know that Google have publicly announced Flutters use by Google Pay (https://flutter.dev/showcase/google-pay), if that's not a big enough app for you I'm not sure what would convince you.
>As a full time iOS user it's VERY obvious, you feel it and see it, my friend >literally deleted an app due to it after using it for seconds, it's not just a >vague complaint, it's highly perceivable.
This is my biggest pet peeve, anecdotally I hear a fair bit of this coming from mobile devs, especially with iOS devs who seem fixate on this, but guess who I've never heard this from in over decade in mobile dev: iOS users (and Android users) who are not devs. Literally never. Not a single non-dev person has ever mentioned it to me. Sure the complain about a million others things to do with phones, apps, you name it, it's amazing all the things people want to talk to you about when they find out you're a mobile app dev, but literally it's never about scroll physics being too fast or off.
Sure I'm very involved in the Flutter community and do it for my day job, so I can quite rightly be labelled as biased, but trying to be as objective as possible, on all measures I can think of, Flutter is a very successful open source project and simultaneously a very successful "commercial product" which is quite a rare feat to this day.
Finally on the topic of open source, I'd point out that unlike for instance AOSP (another huge Google project/product) Flutter is not developed in "throw it over the wall once a year" fashion but completely in the open, all work is done in the public repo, on public issue trackers, public design documents, roadmaps, etc. Its really quite exceptional in this regard and is really one of the big reasons why its really close to foundation/consortium style projects (think Apache, Eclipse, Linux, Rust) than a single-corp sponsored one.
Every language has spots of pain, of course, but the sticky points in Dart at scale don't feel like rough edges, they significantly effect workflow.
> you seem to want to imply something but not come out and say it
I have said multiple times not eating the dog food makes me weary, Google uses Angular a lot, why not Flutter? ...I think you need to read back I am well aware of Pay, this thread is about Stadia, the largest commercial Flutter project at google afaik, being killed. Pay is USA and India only.
> Not sure why you keep focusing on iOS and Flutters focus on Material
> This is my biggest pet peeve, anecdotally I hear a fair bit of this coming from mobile devs
> Not a single non-dev person has ever mentioned it to me.
I think you may be too deep in the Android space, I have heard this a ton. TBH I think many times the apps are wrapped webviews so scrolling works but other interactions feel off, but 100% non devs notice when iOS apps don't feel native.
It's not a binary choice between runloop with callbacks or threads, that's why you should probably take the time to learn about Erlangs actor model implementation, which Dart's Isolates also implement to some degree.
Really? In 2022 you still think this, when people had the option to use any language they wanted to on the server side and yet Node's popularity is clear for even the most blinkered rubyist or pythonista to see...
I've listened for decades while Python & Ruby advocates whined about how JS was terrible and should be replaced in the browser and yet when people had a choice on the serverside, they chose Node and proved you all wrong.
Android's equivalent to this is its Intent's and ContentProviders system, but I'm not sure you could use them in a pipe like way, plus most app authors have not chosen to implement the functionality in a meaningful way, outside of some quite old efforts such as the "Open Intent" suite of apps.
Also rewrites, especially just to change platform are often a very bad idea. But if you are writing a new app or radically reworking an existing app, using Flutter instead of Electron today would have some merit.
