Flutter

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
8,356
#1
Anyone else watch the flutter live event last night? Looks very exciting, I know what I'll be doing this month, writing a flutter app!
Flutter 1.0 is out and looking good.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,918
#2
Anyone else watch the flutter live event last night? Looks very exciting, I know what I'll be doing this month, writing a flutter app!
Flutter 1.0 is out and looking good.
Far too many compromises:
  • You can build something to be cross platform, but you end up with a crap (i.e. not natural) UX for the device. IMO it sacrifices far too much UX to provide the developer with hot coding, ...
  • Essentially it's a competing solution to React Native and Electron and not able to compete 1 on 1 with native builds: C#, Java, Kotlin or Swift.
Widgets:
Are messy in the code and not easy to work around performance bottlenecks. As much as they say it's fast; it's very slow in comparison with down to metal performance with e.g. Swift code. Basically you can write some run of the mill apps, but anything more serious you're going to bump into its limitations.

Dartlang:
Their choice to use Dart is just weird i.e. the language that was rejected by the dev community at large and was generally considered dead; a language that today still offers none of the syntactic and generic affordances of Kotlin or Swift -- in many ways it's just an older version of Java, and for a "new" language late to the game that's not something to celebrate.
 

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
8,356
#3
Far too many compromises:
  • You can build something to be cross platform, but you end up with a crap (i.e. not natural) UX for the device. IMO it sacrifices far too much UX to provide the developer with hot coding, ...
  • Essentially it's a competing solution to React Native and Electron and not able to compete 1 on 1 with native builds: C#, Java, Kotlin or Swift.
Widgets:
Are messy in the code and not easy to work around performance bottlenecks. As much as they say it's fast; it's very slow in comparison with down to metal performance with e.g. Swift code. Basically you can write some run of the mill apps, but anything more serious you're going to bump into its limitations.

Dartlang:
Their choice to use Dart is just weird i.e. the language that was rejected by the dev community at large and was generally considered dead; a language that today still offers none of the syntactic and generic affordances of Kotlin or Swift -- in many ways it's just an older version of Java, and for a "new" language late to the game that's not something to celebrate.
Did you watch the event? It actually looks pretty amazing and the apps are running perfectly on my android phone.
 

Spacerat

Senior Member
Joined
Jul 29, 2015
Messages
872
#5
I think there is no substitute for native on the various platforms. Cross platform tools like this are very good for demos, concept demonstrators and prototypes.
 

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
8,356
#6
I think there is no substitute for native on the various platforms. Cross platform tools like this are very good for demos, concept demonstrators and prototypes.
Watch the presentation, I think you might be surprised. It's unlike other cross platform tools, though you are correct, at least for now, you may need to do some native development even when using flutter.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,918
#7
Did you watch the event? It actually looks pretty amazing and the apps are running perfectly on my android phone.
Yes, but I've also beta tested it for a few months; so my summary covers my conclusion.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,918
#9
Ah, well in that case I can't really contradict you as I'm only just starting to play with it now
It really depends on your project; for small to medium builds I think it could fly; but still expect some pain trying to tweak performance with the widget model; design arrangements can have huge performance impacts, but most can be overcome with support.

For mainstream and corporates Apps I still prefer native, here's some information if you didn't already have it.

Microsoft:
  • Xamarin forms is a similar concept to flutter, but not not a widget system, hence many of the Flutter concerns are not relevant; and you have the option of developing in F# or C# or both; both languages are syntactical more advanced than Dart.
  • You can also choose build native only; Microsoft has created an extensive set of .Net wrappers for all the iOS and macOS APIs and for the most part these are inline with the Objective-C API documentation.
  • Xamarin / C# doesn't have anything in the hot loading space, but I'm sure that's just a matter of time.
  • Cross platform solution covers Windows, iOS, macOS, tvOS, Android and Linux.

Apple:
  • Language options are Objective-C, Objective-C++ and Swift; but you can also quite access the APIs from C and C++ ( except Swift APIs backward compatibility is restricted for now to C ).
  • No cross platform option for UX; but server options are officially supported on Linux and UX is limited to macOS, iOS, tvOS, watchOS.
  • Something very close to hot loading development can be achieved with Swift playgrounds, for all Swift's UX platforms.
  • Windows compiler support for Swift is in progress, and with Google's choice last year to use Swift for tensorflow; they have also been advertising for resources to lead a team to complete the Windows build of the Swift compiler.
  • Windows UX API support from Swift is unknown at this stage,
 
Last edited:

Tander

Executive Member
Joined
Jun 8, 2008
Messages
5,101
#10
It really depends on your project; for small to medium builds I think it could fly; but still expect some pain trying to tweak performance with the widget model; design arrangements can have huge performance impacts, but most can be overcome with support.

For mainstream and corporates Apps I still prefer native, here's some information if you didn't already have it.

Microsoft:
  • Xamarin forms is a similar concept to flutter, but not not a widget system, hence many of the Flutter concerns are relevant; and you have the option of developing in F# or C# or both; both languages are syntactical more advanced than Dart.
  • You can also choose build native only; Microsoft has created an extensive set of .Net wrappers for all the iOS and macOS APIs and for the most part these are inline with the Objective-C API documentation.
  • Xamarin / C# doesn't have anything in the hot loading space, but I'm sure that's just a matter of time.
  • Cross platform solution covers Windows, iOS, macOS, tvOS, Android and Linux.

Apple:
  • Language options are Objective-C, Objective-C++ and Swift; but you can also quite access the APIs from C and C++ ( except Swift APIs backward compatibility is restricted for now to C ).
  • No cross platform option for UX; but server options are officially supported on Linux and UX is limited to macOS, iOS, tvOS, watchOS.
  • Something very close to hot loading development can be achieved with Swift playgrounds, for all Swift's UX platforms.
  • Windows compiler support for Swift is in progress, and with Google's choice last year to use Swift for tensorflow; they have also been advertising for resources to lead a team to complete the Windows build of the Swift compiler.
  • Windows UX API support from Swift is unknown at this stage,
Agreed there.
There is no replacement for native apps. We are not going to switch our apps to Flutter. they will stay with Swift and Java/Kotlin
For smaller apps yeah I guess you could use this and 'get away' with it.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,918
#11
Last edited:

John_Phoenix

Well-Known Member
Joined
Jul 8, 2017
Messages
347
#12
Build native, as DROID says, a layer on top of native is generally easy to start with, great to spin up a simple app, but once you start using multiple low level features and states things can get hairy. Not to mention speed. Native will always be faster, or at least as fast as the native binaries. If android decides to ship a crappy implementation of a lib, you're pretty much stuck with it. No amount of 3rd party layering is going to help that.

A great example of this is xslt in chrome. libxslt is old, unmaintained and only supports xslt 1.0

Dart, is like actionscript, works great in a specific environment. And yes AS was closed source, and yes dart is more open, and feature rich. But until chrome ships natively with dart binaries in the consumer version, dart cannot gain traction.

I'd love to see dart become a viable alternative to js. Cause webassembly is really not bringing the goods.
 

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
8,356
#13
Build native, as DROID says, a layer on top of native is generally easy to start with, great to spin up a simple app, but once you start using multiple low level features and states things can get hairy. Not to mention speed. Native will always be faster, or at least as fast as the native binaries. If android decides to ship a crappy implementation of a lib, you're pretty much stuck with it. No amount of 3rd party layering is going to help that.

A great example of this is xslt in chrome. libxslt is old, unmaintained and only supports xslt 1.0

Dart, is like actionscript, works great in a specific environment. And yes AS was closed source, and yes dart is more open, and feature rich. But until chrome ships natively with dart binaries in the consumer version, dart cannot gain traction.

I'd love to see dart become a viable alternative to js. Cause webassembly is really not bringing the goods.
It compiles into native code, I think? Anyway I'm going to give it a go. I already do native android development so it's not one or the other. There is no way I'm going to buy a mac and learn swift and write my apps twice, so flutter is appealing to me for that reason. The flutter apps I've downloaded are fast and responsive and look good.
 

John_Phoenix

Well-Known Member
Joined
Jul 8, 2017
Messages
347
#14
It compiles into native code, I think? Anyway I'm going to give it a go. I already do native android development so it's not one or the other. There is no way I'm going to buy a mac and learn swift and write my apps twice, so flutter is appealing to me for that reason. The flutter apps I've downloaded are fast and responsive and look good.
Then absolutely go for it. Might be a cool learning experience as well as a new tool in your belt. Best of luck :)
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,918
#15
It compiles into native code, I think? Anyway I'm going to give it a go. I already do native android development so it's not one or the other. There is no way I'm going to buy a mac and learn swift and write my apps twice, so flutter is appealing to me for that reason. The flutter apps I've downloaded are fast and responsive and look good.
You'd still need a mac to build for iOS and macOS, Flutter doesn't overcome that and neither does React Native, Xamarin or Electron. Whislt you can do some of the coding on a Windows PC, the final compilation and submission process for Apple's OS requires Xcode and iTunes Connect and they're only are available on a mac.
https://flutter.io/docs/deployment/ios

Naturally during the development process it would also be tough going if you couldn't perform any on device testing and that too would require a mac. Plus you can write platform specific integration code to work around limitations of the current Flutter SDK, but this code would be either in Objective-C or Swift.
https://flutter.io/docs/development/platform-integration/platform-channels
The same btw applies to Android, for platform specific integration code, you also do that in Java using Android SDKs or Kotlin.
 

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
8,356
#16
You'd still need a mac to build for iOS and macOS, Flutter doesn't overcome that and neither does React Native, Xamarin or Electron. Whislt you can do some of the coding on a Windows PC, the final compilation and submission process for Apple's OS requires Xcode and iTunes Connect and they're only are available on a mac.
https://flutter.io/docs/deployment/ios
.
Sure, but I know enough people with macs to do the final submission from. Still, even if I end up buying an old second hand mac, it avoids having to write the app twice

Naturally during the development process it would also be tough going if you couldn't perform any on device testing and that too would require a mac. Plus you can write platform specific integration code to work around limitations of the current Flutter SDK, but this code would be either in Objective-C or Swift.
https://flutter.io/docs/development/platform-integration/platform-channels
The same btw applies to Android, for platform specific integration code, you also do that in Java using Android SDKs or Kotlin.
I guess I'll soon find out what I can and cannot achieve without writing any native code. I know sometimes channels need to be created to call native code but even if I can write the majority of the code once instead of twice it would be worth it. You're a real negative Nancy when it comes to this aren't you? Anyway since you already took the time to try it and test it, over many months, I'm not sure why you're trying so hard to discourage me from doing the same.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,918
#17
Sure, but I know enough people with macs to do the final submission from. Still, even if I end up buying an old second hand mac, it avoids having to write the app twice


I guess I'll soon find out what I can and cannot achieve without writing any native code. I know sometimes channels need to be created to call native code but even if I can write the majority of the code once instead of twice it would be worth it. You're a real negative Nancy when it comes to this aren't you? Anyway since you already took the time to try it and test it, over many months, I'm not sure why you're trying so hard to discourage me from doing the same.
Who says I'm discouraging you, that's all in your head.
You incorrectly stated that you didn't want to have to buy a mac to code for Apple's OS, I simply corrected you on that.

Ps. Grow up, most advice is not nefarious.
 
Last edited:

C4Cat

Executive Member
Joined
Nov 9, 2015
Messages
8,356
#18
Who says I'm discouraging you, that's all in your head.
You incorrectly stated that you didn't want to have to buy a mac to code for Apple's OS, I simply corrected you on that.

Ps. Grow up, most advise is not nefarious.
ok, didn't see any advice but ok mr grown up
 

Johnatan56

Honorary Master
Joined
Aug 23, 2013
Messages
24,553
#19
Hummingbird still isn't "properly" released.
Google IO is set to bring an update announcement about Hummingbird, but a reddit post from a bit ago just states that they have been working on still adding more features rather than optimizations:
https://www.reddit.com/r/FlutterDev/comments/b3oebv
virtualistic

61 points · 1 month ago

(disclaimer: I'm on the Flutter team working on the Web runtime, and also the author of the aforementioned blog post)
It is still very early to talk about performance and code size. We have been focusing on rendering correctness, accessibility, text editing, and other essential features. We have done near zero amount of code size optimizations, although we do keep an eye on runtime performance all the time.
Having said that, from some ad hoc sampling of code size we've found that the dart2js compiler does a remarkable job at dead code elimination (a.k.a. tree-shaking). The Flutter Gallery, which uses almost every widget in Flutter's widget library, compiles and gzips into ~500KB (although we keep adding more demos to it, so it may grow). The "hello world" app is ~130KB, so tree shaking is very effective at eliminating unused code. Again, this is what we get out-of-the-box. These numbers will probably shrink as we begin optimizing for code size, but also as Flutter adds more features they may grow. Finally, it will largely depend on the API surface your app uses, as that dictates how much code dart2js can eliminate.
Also worth mentioning this announcement from the compiler team: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/dpUkC2ZMTBo
That compiler team announcement is that they're dropping ES5 support.

Hummingbird is still pretty large, but people are expecting them to set up a cache for users, so if a user has accessed it on any site/page, user will only load the application code any other time.


I'm really wanting to mess with Hummingbird, but can't see the point for anything I use. Currently playing around with Vue + Laravel.
 

John_Phoenix

Well-Known Member
Joined
Jul 8, 2017
Messages
347
#20
Hummingbird still isn't "properly" released.

That compiler team announcement is that they're dropping ES5 support

I'm really wanting to mess with Hummingbird, but can't see the point for anything I use. Currently playing around with Vue + Laravel.
Yeah, the app market is crazy saturated, when you get tired of php, apache and sql, I invite you to try nodejs socket.io and some rxjs / react.

Setup correctly, it smokes laravel on the be and a api driven fe is pretty incredible. Failing that python is rad too.

React native for apps maybe?
 
Top