Re:Flutter: the good, the bad and the ugly
by hardwaresofton on Wednesday November 28, 2018 @09:12PM
(#18557515)
Sorry for the delay in response, I didn't see this. I think the problem is kind of endemic -- it's kind of like all the documentation and everything always starts from a Material component. Like if you look at provided scaffolds and you see CupertinoScaffold in the Widget Index[0], you might expect MaterialScaffold to be an option as well, but it's just "Scaffold". Little things like this indicate that you expect "MaterialScaffold" to be the default resting state. 99% of the time when I'm writing an app I have the design already and it may or may not be in material style or Cupertino style -- I personally would expect a framework to offer general tools first then the specializations. There are a bunch of other example of components that only really work correctly in the Material context. It's not a huge thing, and Google does have a pony in the race (which makes it easier for me to tinfoilhat about it), you have every right to push material as the default/make it easier to work with -- but I enjoy not having any such bias with Nativescript, even if it costs me slightly more work to get components that are stylistically coherent with either paradigm.
From an engineering standpoint I absolutely understand the automatic crash logging, it's good that you're able to get the user data. I think you guys are just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever be -- the average developer won't care. I don't know realistically how it could be improved without sacrificing that useful data, but maybe a notice @ install time? I just never saw any mention (I read through the docs, watched lots of video), and was surprised -- maybe the negative impression was amplified because I was having issues with flutter at the time. My thought/reaction at the time was that "Oh so a weird crash and you're sending the details back without me explicitly allowing it? classic google".
To wrap this up, I do want to thank you (I'm assuming you're on the flutter team) for the hard work -- drawing every pixel and building a composable, considered system to do that is very hard, and you've expanded the mobile development landscape, Flutter is unique in it's approach AFAIK, and I mention it any time I talk about the mobile dev continuum. Building flexibly to support multiple embedders is awesome and I'm sure flutter will go far.
From an engineering standpoint I absolutely understand the automatic crash logging, it's good that you're able to get the user data. I think you guys are just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever be -- the average developer won't care. I don't know realistically how it could be improved without sacrificing that useful data, but maybe a notice @ install time? I just never saw any mention (I read through the docs, watched lots of video), and was surprised -- maybe the negative impression was amplified because I was having issues with flutter at the time. My thought/reaction at the time was that "Oh so a weird crash and you're sending the details back without me explicitly allowing it? classic google".
To wrap this up, I do want to thank you (I'm assuming you're on the flutter team) for the hard work -- drawing every pixel and building a composable, considered system to do that is very hard, and you've expanded the mobile development landscape, Flutter is unique in it's approach AFAIK, and I mention it any time I talk about the mobile dev continuum. Building flexibly to support multiple embedders is awesome and I'm sure flutter will go far.
[0]: https://flutter.io/docs/reference/widgets