Platform views and especially Hummingbird are huge announcements. Wish the OP linked to the dev blog instead:
https://developers.googleblog.com/2018/12/flutter-10-googles...
Google's cross-platform Flutter UI toolkit goes 1.0
231–240 of 343 posts
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#232The widget layer of flutter is Skia which is written in C++ and Flutter apps compile to ARM binary (native) code. Someone else asked about whether a Flutter app can be ported to Linux; why not compile both the logic and the UI directly to WebAssembly?
There's Flutter desktop: https://github.com/google/flutter-desktop-embedding And web: https://medium.com/flutter-io/hummingbird-building-flutter-f...
Holy smokes! That's awesome! (I was aware of the desktop embedding, but also on the web... that's really cool)
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#233Earlier quoted context omitted.
Dart (the lang used in Flutter) already failed to gain traction in the web dev community and nobody seems to be maintaining it there.
Flutter is Dart's killer app, and don't think it's unmaintained. Dart 2.0 came out pretty recently with some much needed improvements, probably driven by Flutter.
Dart 2.1 is now available as well. So still kicking! :)
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#234I don't understand why we have to keep reinventing GUI toolkits and layout engines over and over again. Why can't this domain be smarter like Compiler world and build pluggable components? So something like, a react-engine that renders the recently changed display node. The react-engine is offered as an API/library layer, it could be run in browser where it works with DOM, it could be run in a desktop where it works…
It's one thing to draw some widgets. That's the "easy" problem (to borrow some AI jargon). It's totally another thing to specify how these widgets read and write the model in which the business logic is encoded. If you want to animate transitions between valid model states, it all gets ten times as complicated. And then when you try to make it performant by eliminating redundant redraws, it becomes an even bigger mes…
Thanks for your reply - it was a pretty insightful rebuttal.
Do you think in the future it might be possible for say Flutter to:
1. Refactor flutter into a layout engine and gui widgets
2. Provide the layout engine as an interface on all desktop OSes. Something like a standardized syscall like interface.
3. Anyone can implement a new GUI toolkit to this layout engine interface.
4. For desktop OSes, the number of styling options is less than full blown CSS capabilities(in HTML dom) and these options get compiled out, making execution of native apps GUI slightly faster than DOM apps. Basically, desktop GUI styling is a subset of DOM CSS styling.
5. We use a JSX like templating language to specify UI that either gets compiled to HTML or generates native GUI widgets.
Not sure all of my thoughts are 100% fleshed out but does this sound feasible in future?
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#235Does Flutter have easy modules for standard things like login, comments, payments etc. or does that involve writing separate server side code?
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#236Re: Google's cross-platform Flutter UI toolkit goes 1.0
#237Earlier quoted context omitted.
No one uses Dart. No one is going to switch from React or Vue to Flutter when they can't bring over their TypeScript skills and tooling. It was a stupid, arrogant decision on Google's par, end of story.
As someone who use Java a lot and don't favor Javascript I'm grateful there is Dart.
Typescript isn't JavaScript
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#238Google has a history of introducing products and then killing them. For developing mobile apps they currently support "vendor native" via Android Studio using Java or Kotlin, Progressive Web Apps, and now Flutter. Will Google really support all three over the long term?
I want to note that Dart and Flutter are being used for Fuchsia it seems like[0]. I'm pretty sure that Fuchsia is a big project Google is not going to abandon so Dart and Flutter are probably safe. There is the chance of them throwing it away maybe noting it as an experiment on the way to whatever they land on inside Fuchsia but the amount of developer ire they would draw is hard to imagine. [0]: https://9to5google.c…
Fuchsia is to Google as Tizen is to Samsung... something keep in the back pocket for a worst-case legal total war, but unlikely to see any real world use.
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#239Like I said yesterday "The road block for adoption will be Dart. Why they didn't just choose Typescript or go with native javascript is beyond me. No one uses Dart. It was probably the poorest design decision they could make." The comment from pzo points out an even worst of an adoption showstopper.
They won't stop pushing Dart, thanks to success of Go, yet another 'good enough for the job' mediocre (at best) language.
I would kinda even prefer Go. Learning Dart is really specific to Flutter, I wouldn't end up using it for anything else. Go is kinda useful.
I have played with Flutter before and liked it, but was annoyed about the lack of what are now called PlatformViews. I might give it another shot now.
I just wish I could consume it from a different language, Go, TypeScript.... C# even Kotlin. I don't love learning a language for a single purpose if I can help it.
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#240Does Flutter have easy modules for standard things like login, comments, payments etc. or does that involve writing separate server side code?
Combined with Firebase, yes, that's fairly easy to setup.