Definitely interested in seeing how Flutter progresses, IMO it has the optimal architecture for developing native, x-plat iOS/Android UI (https://flutter.io/technical-overview/):
- High perf Skia based UI for pixel perfect rendering and high-level Material design widgets
- React inspired, productive development model
- Fast dev/iteration cycles with hot reloading
- Productive and high-performance Dart language, natively compiled (AOT on iOS)
- Enable native interop with underlying iOS/Android APIs
- Actively developed by Google
Overall I think it has a superior architecture to React Native where it will enable higher-perf native iOS/Android Apps in a single code-base but still enables a productive development model with Instant UI updates and hot reloading. I've done Java and Kotlin Android Apps as well as Obj-C and Swift iOS Apps but I find React Native's dev model a lot more productive.
Unfortunately I've run into a few issues with React Native that I've had to workaround which I've submitted repros to months ago but received no response from the React Native team except in the last couple of days where they've closed it without even looking at it because it didn't receive comments/activity from other devs. In the last 2 days React Native has closed 773 other issues because they consider it low priority:
This gives me low confidence that React Native will be a high quality platform with current low-priority issues lingering indefinitely so I welcome competition from Google with Flutter and will be anxiously looking forward to trying it out when it gets out of alpha.
It is sad but the name Facebook on any engineering project makes me think twice before considering adopting it.
Flutter looks like it could be really interesting framework.
Especially since it should allow to write apps for iOS, Android AND Fuchsia.
I am quite happy with kotlin on Android & Swift on iOS (and their respective native frameworks) but if Google publishes Fuchsia as Android's replacement with Flutter as its app framework, it could be an interesting switch :
Rewrite your app in Fuchsia. It is going to take a while of course BUT you are going to be able to publish the new on both Android & Fuchsia (in order to still support 'legacy' for a while)
I'm a huge fan of React Native, and I just finished my first project with it. But I have to agree, it seems that bugs don't get any attention. I've found and reported a few myself. My general impression is that Facebook needs to invest more resources in maintenance and bug fixes, and Microsoft needs to do the same for react-native-windows.
I had high hopes for flutter but gave up after a while. It feels like their design meetings were spent arguing about grammar and splitting hairs, rather than thinking about ergonomics and how people would use it.
Why do I need to care if something takes a `child: (single object)` argument or a `children: [LIST of objects]`?
Flutter would be better with JSX: JSX hides how the puzzle pieces fit together. I don't care if it takes a child or children; just make everything connect the same way.
React Native's Flexbox also beats how Flutter did things. Why do I need to memorize which objects take which styling arguments? You want to center items on the screen? Re-nest everything inside a Center object! You want a column or a row of elements? Use a Column/Row object!
For a framework that's trying to bill itself as a great tool for prototyping, it feels like I'm sifting through a mountain of minutiae. I was able to guess my way through a React Native app and be right 99% of the time. With flutter, my luckiest guess would lead me to an abstract base class... Then I'd have to dig around to figure out what the hell I need to use to make a view scrollable. Seriously:
I mean, if you're using IntelliJ or Visual Studio Code it automatically completes which argument something takes, it's hardly like you need to go around digging for that stuff. Personally, I think it makes sense to differentiate between something which takes one child and something which takes an array of children.
That's the first thing I thought too re JSX or something like that, it looks like they are trying to shoehorn Java and full OO into what is basically React, replacing JSX and json with a huge pile of different classes. Over-engineering and obfuscating in much the way GWT did back in the day. The web is the web, there is only the DOM guys, deal with it and move on.
Nice write-up. I've been popping my head on over to their project every few months to check out their progress. Something that's pretty cool is that they're using Flutter to write Fuchsia's UI [0].
My favorite thing about Flutter is that it looks like they took some heavy inspiration from React. If anyone reading this isn't familiarized with React, or they don't really "get it", I'd highly suggest reading the Removing User Interface Complexity, or Why React is Awesome [1].
One of the big problems with implementing a UI toolkit is having to re-implement everything relating to accessibility. Although it's totally understandable that they're still focusing on the core.
Something I'd be interested in seeing is how Dart and Flutter might affect battery life. I'd expect the stock UIs to be pretty well optimized by now, but I have no idea how Dart stacks up in performance.
One of the reasons we picked Dart was that is compiles to ARM (native) code. Dart has been pretty efficient for the project so far, but we haven't yet looked very deeply at battery life. Something to keep an eye on!
>Though Flutter doesn’t use the native UI widgets, it’s a cross-platform framework and has widgets for both Android and iOS. [...] On iOS, the biggest thing that stuck out to me was the scrolling. It didn’t quite feel right because of the physics, but I’m sure that would just require a little tweaking by the Flutter team.
Count me a skeptic. This is the same approach taken by Java's Swing (now JavaFX) toolkit and apparently it has exactly the same issues. Swing never felt quite right even after decades of tweaking.
I always liked wxWidgets for that, and other people MFC, but where wxWidgets failed for me was a simple text area editor, which underneath was sending messages to the Windows Control, and in order to retrieve the current line, it had to scan through the whole text buffer over and over... "Leaky abstraction"...
I also was "worried" (more than need to) - how people with disabilities, or special devices (non-standard pointer devices, like artists) would use Qt, as I thought there is no native support.
And yet, I was mistaken. Windows (and other systems) expose an "assistive" layer where you can explain to the underlying windowing system what is each thing that you draw, the text, etc. And Qt solved it.
Once we moved from MFC -> Qt, and removed other uses of wxWidgets, non-ui programmers started adding bits and pieces much easier in Qt (I'm not claiming Qt superiority), because all it took sometimes was to subclass, and repaint something, add button or two and create new control. With MFC that was hard, and with wxWidgets kind of tricky (solutions always ended up being "Windows" specific, not that we cared about Linux/OSX back then).
So that's why I love flutter, and it reminds of Unreal's internal UI used by it's editor.
At work I'm still struggling with GWT, XML ui binder files, and trying to componentize modules. With flutter, Qt, and I guess Unreal's UI it's much easier. Or with JUCE for that matter...
So I'm no longer against "custom" drawn UIs, as long as they expose their contents properly to the OS (and if this matters really).
Sorry for the long rant...
Oh, and I mentioned it someplace else - I love how IntelliJ uses Swing - it's much better from Eclipse (which is trying the exact opposite with it's own platform-"wrapping" ui-kit)... And just 10+ years ago I thought the opposite.
Nice article. The lack of native iOS looking components would be a deal breaker for me.
I wonder how stuff like navigation is built? If that's all in dart I'd be interested in seeing how the back stack looks in the hierarchy explorer. I.e are precious screens rendered still.
I agree, but I'd take it one step further actually. For me it doesn't cut it if the widgets just LOOK correct. I want them to BE correct. So, native widgets only please, no mimicking.
> Though Flutter doesn’t use the native UI widgets, it’s a cross-platform framework and has widgets for both Android and iOS
Hot-reloading and good performance are very attractive parts of Flutter, but they really should have reconsidered the decision to make their own UI widgets. When you use the native UI elements, you get that native look-and-feel for free, and you don't have to dump man hours into replicating that behavior. They could have a "UI backend" which calls out to the native UI elements for each platform. The great thing is that since they use these UI widgets natively on Fuchsia, they can use their existing code as just another backend on that platform without having to throw the work away.
That chat app demo they coded at the I/O 2017 presentation in under 400 LOC was pretty ridiculous (in a good way) considering all of the functionality it included. The demo code was run on an iOS and Android device and each used its respective look and feel.
Awesome stuff. And the license appears to be OK. The only thing that worries me is their language choice, for some people that would be too much new stuff in a single project i.e. too risky.
Finally, people outside Microsoft started to realize modern GPUs and high-resolution screens need a purposely-built GUI framework, designed for GPU rendering from the ground up. Especially on mobile platforms. MS did that in 2006 with the first release of WPF, and with WinRT/XAML they continue to pursue the approach.
This may be off-topic but I'm wondering if there is any chance to see cross platform and cross language toolkits any time soon. Something based on WebAssembly so that we don't have to worry or bash about programming languages. Dart is cool but should we all learn Dart now?
From a quick look at the sample code and a scrub through the video, it sounds a lot like JavaFX, especially when combined with the Kotlin TornadoFX extensions.
Relatively recent build of a custom widget toolkit? Check.
GPU accelerated 60fps compositing, render and animation layer? Check.
IntelliJ as the IDE? Certainly. Although JFX is perfectly usable from any Java IDE?
Cross platform including across iOS and Android? Check. (except JFX also does Mac/Win/Linux).
Fairly standard layout and box packing model. Check.
Material design? Via a third party company called Gluon, check.
Functional reactive design? Check.
Async/await? Yes, Kotlin has coroutines that integrate with JavaFX.
Hot reload? Actually yes, JVM+TornadoFX has some support for this, although it's not as slick as what Flutter can do ... the view you're working on will be sometimes be thrown out and rebuilt. But if you change your CSS or the behaviour of e.g. event handlers, then you can do hot reload.
There are some differences I see. Dart focuses more on AOT compilation. Another is immutable widgets in Flutter. That one I'm not convinced about at all.
> You can respond to events, like user interaction, by telling the framework to replace a widget in the hierarchy with another widget. The framework then compares the new and old widgets and efficiently updates the user interface.
No explanation for this odd design is provided. I suppose they believe it is self-evidently superior, but that seems like a lot of overhead for very little to me. After all, GUI is pretty much THE standard definition of a big pile of mutable state, and trying to pretend its not by just generating more garbage than a normal GCd toolkit would seems a little strange.
Flutter has stateful widgets too, and they can be arbitrarily nested with stateless widgets.
Stateless widgets are useful for static boilerplate that only changes when moving to a different screen, or when swapping out an entire subview. Supporting arbitrary mutations is extra coding that's unnecessary when it's not going to change anyway. Why implement it when you don't have to?
Note that even with entirely stateful widgets, if the whole layout changes, the whole subtree generally to be thrown out which also creates garbage.
>> You can respond to events, like user interaction, by telling the framework to replace a widget in the hierarchy with another widget. The framework then compares the new and old widgets and efficiently updates the user interface.
>No explanation for this odd design is provided.
I suspect that's to support how they provided both an iOS and Material design look and feel. For example, there isn't a single button widget with different styling. There's a CupertinoButton and a RaisedButton.
I also played with Flutter recently. Timeline: heard Kotlin announcement at I/O, went through some Kotlin exercises, wanted to compare with Flutter/Dart.
Dart feels somewhere in between JavaScript on the one hand and a more-static OO, GC'd lang w/type inference (like Kotlin!) on the other. You can probably look closely at some sample app code and start doing some basic stuff quickly if you've worked much with JS and something more static. (Further study seems worth it if you plan to do a lot, heh!)
As others note the UI model seems Reacty--you write "builder" methods that recreate a widget tree when things change, and something behind the scenes sorts out an efficient way to update the screen with just what really changed. I'm not hugely worried about performance: your UI rebuilds should be separated from your animations, and anyway, building your virtual widget hierarchy ideally shouldn't be too CPU intensive in the first place.
Hot reload is pretty great. I can't actually compare with "real Android" dev, but changes to my little app showed up in under a second in an Android phone, emulated or real. There were a couple surprising things about the basic libs, e.g. Flutter master only recently added a convenience object to bundle together a radio/checkbox and its associated label-stuff (RadioListTile).
The Flutter Gallery app is available on Google Play and its source is in the Flutter git tree. You can see a lot of the Material widgets implemented, including rich list types (e.g. tiles w/photos), pull-from-the-side drawers, top-of-screen tabs you can swipe through, bottom-of-the-screen nav bars etc. Even on iOS Google seems to follow Material guidelines a lot (or at least, the Daring Fireball guy complained that they do; I don't have iOS to check), so maybe it's the easiest fit if you're prepared to do the same. Someone who works on Flutter mentioned elsewhere in these comments that they're working on components that look more like the iOS-native ones, though.
Although Android Studio is _based on_ IntelliJ, you need to get actual IntelliJ if you want to use the plugin (Studio's component versions don't match the ones that the Flutter plugin works with, I think). Also, if you have Studio 3.0 canary installed (like to futz w/Kotlin, heh!), you need to either configure Flutter to look for the stable Studio 2.3's copy of Gradle (flutter config --gradle-dir=...) or just make sure 2.3 is located where the flutter tools look by default (~/android-studio for me on Linux). People working on Flutter helped some of us through this at https://github.com/flutter/flutter/issues/10236#issuecomment...
You get a lot of IDE-ish luxuries (as OP notes): Control-Space to offer identifiers, methods, or params available; autoformatting with dartfmt (right-click menu); lots of quick feedback when you mess something up.
Hixie (Ian Hickson) of the HTML5 spec works on Flutter which is kinda neat (he did RadioListTile just now! and there's a milestone on GitHub named 'Make Hixie Proud' haha :D). Outside of the tech specifics, Dart's an interesting creature in that it seems like it's got some key customers in Google (AdWords, so, like, the part that makes money) but comparatively little pickup outside. On Flutter GitHub you see people paying attention to outside-adopter issues (or even passerby issues such as my Gradle-version thing recently). There's apparently lots of tooling available publicly, e.g. a package manager (pub), dartfmt, IDE plugins, a playground (dartpad.dartlang.org) etc. Curious to see if there's any more pickup on the outside.
You can also use the Flutter plugin with the free, community edition of IntelliJ or with Webstorm. (But WebStorm does not have any Java or Android support.)
Also, the Dart plugin for VS Code is starting to add Flutter support. In that case you'd use the command line for hot reload.
While other big corporate entities have their own share of shut projects (no project is forever) the moment this project stops getting official Google support it will wither and die.
Maybe I am reading this wrong and we could have a Open Office/Libre Office situation.
If Google is developing Flutter so they can be more productive at developing their own flagship iOS/Android Apps than the chances it will be discontinued is quite low.
So whilst it's reasonable to hold off until they adopt it themselves and use it in their own deployed Apps, but once they do I'd be more confident in a commercially-sponsored Google project than an Indie OSS community led project. You just don't hear about the thousands of OSS projects being abandoned because they're from multiple Indie authors.
But I wouldn't trust a project with this large a scope without mega corporate backing. But I'd agree that if Google stops committing resources to Flutter than it will die despite being OSS'ed since it's too big to maintain without a well-resourced team.
Not all Google projects should be considered equal, if adoption is low and they don't have flagship Apps, high-profile initiatives or cost center's backing/funding the project then the project's future would be at risk if it doesn't become successful, but any project that is successful, has adoption or paying customers are very unlikely to discontinued, e.g. Angular, Firebase, Google Cloud Platform or any of their popular platforms, i.e. Chrome, Android, YouTube, etc have zero chance of being abandoned.
Wunderlist
Sunset
Games for Windows
Silverlight
Zune
Kin
XNA
PlaysForSure
Flight Sim
Expression Suite
SteadyState
Windows RT
Windows Phone 7
Forefront
Front Page
Money
Author here. I have a Nexus 6. I hadn't tried the Google Play app until today so my observations were based on the sample app that I had built and another Flutter app that's in the play store called Newsvoice. I was under the impression that the Flutter sample app was just a github repo, and I didn't go through the trouble of trying it out.
The Flutter app in the Google Play store does lag for me during the first run of most large animations (nav drawer open/close, shared transitions, etc.). The second time those animations are run, everything is smooth. There must be some sort of caching in place for animations.
As far as I could tell, everything else seemed to be fine. Scrolling performance was good, as were smaller animations like checkboxes and switches.
This feels like a bad idea. Let's write a platform on Dart which is esoteric in terms of usage and community and hope for the best? Seriously? The whole reason to do a framework is to make it big so it has a tons of community support. I just don't understand the point although it looks elegant.
[+] [-] mythz|8 years ago|reply
Unfortunately I've run into a few issues with React Native that I've had to workaround which I've submitted repros to months ago but received no response from the React Native team except in the last couple of days where they've closed it without even looking at it because it didn't receive comments/activity from other devs. In the last 2 days React Native has closed 773 other issues because they consider it low priority:
https://github.com/facebook/react-native/issues?q=label%3AIc...
This gives me low confidence that React Native will be a high quality platform with current low-priority issues lingering indefinitely so I welcome competition from Google with Flutter and will be anxiously looking forward to trying it out when it gets out of alpha.
[+] [-] on_and_off|8 years ago|reply
It is sad but the name Facebook on any engineering project makes me think twice before considering adopting it.
Flutter looks like it could be really interesting framework.
Especially since it should allow to write apps for iOS, Android AND Fuchsia.
I am quite happy with kotlin on Android & Swift on iOS (and their respective native frameworks) but if Google publishes Fuchsia as Android's replacement with Flutter as its app framework, it could be an interesting switch :
Rewrite your app in Fuchsia. It is going to take a while of course BUT you are going to be able to publish the new on both Android & Fuchsia (in order to still support 'legacy' for a while)
[+] [-] nathan_f77|8 years ago|reply
[+] [-] svdev|8 years ago|reply
In Flutter, everything is a nested pile of objects with too many APIs to keep track of. Take this example: https://github.com/flutter/flutter/blob/master/examples/stoc...
Why do I need to care if something takes a `child: (single object)` argument or a `children: [LIST of objects]`?
Flutter would be better with JSX: JSX hides how the puzzle pieces fit together. I don't care if it takes a child or children; just make everything connect the same way.
React Native's Flexbox also beats how Flutter did things. Why do I need to memorize which objects take which styling arguments? You want to center items on the screen? Re-nest everything inside a Center object! You want a column or a row of elements? Use a Column/Row object!
For a framework that's trying to bill itself as a great tool for prototyping, it feels like I'm sifting through a mountain of minutiae. I was able to guess my way through a React Native app and be right 99% of the time. With flutter, my luckiest guess would lead me to an abstract base class... Then I'd have to dig around to figure out what the hell I need to use to make a view scrollable. Seriously:
https://github.com/flutter/flutter/blob/c6b0f833af9e431df1e6...
Why?
[+] [-] tomatsu|8 years ago|reply
The IDE tells you what's needed and the latest version of the plugin automatically adds a list literal and places the cursor inside it:
https://groups.google.com/forum/#!topic/flutter-dev/LXafJQqS...
Personally, I think it makes sense to differentiate between exactly one and zero or more.
> Why do I need to memorize which objects take which styling arguments?
The IDE should do that for you.
[+] [-] gman83|8 years ago|reply
[+] [-] blikdak|8 years ago|reply
[+] [-] TheAceOfHearts|8 years ago|reply
My favorite thing about Flutter is that it looks like they took some heavy inspiration from React. If anyone reading this isn't familiarized with React, or they don't really "get it", I'd highly suggest reading the Removing User Interface Complexity, or Why React is Awesome [1].
One of the big problems with implementing a UI toolkit is having to re-implement everything relating to accessibility. Although it's totally understandable that they're still focusing on the core.
Something I'd be interested in seeing is how Dart and Flutter might affect battery life. I'd expect the stock UIs to be pretty well optimized by now, but I have no idea how Dart stacks up in performance.
[0] https://github.com/fuchsia-mirror/sysui
[1] http://jlongster.com/Removing-User-Interface-Complexity,-or-...
[+] [-] sethladd|8 years ago|reply
One of the reasons we picked Dart was that is compiles to ARM (native) code. Dart has been pretty efficient for the project so far, but we haven't yet looked very deeply at battery life. Something to keep an eye on!
[+] [-] fharper1961|8 years ago|reply
The CPU use seemed to be very similar to well behaving native apps.
[+] [-] fauigerzigerk|8 years ago|reply
Count me a skeptic. This is the same approach taken by Java's Swing (now JavaFX) toolkit and apparently it has exactly the same issues. Swing never felt quite right even after decades of tweaking.
[+] [-] yrio|8 years ago|reply
On the opposite, I think people generally like it.
I wonder why?
[+] [-] malkia|8 years ago|reply
I also was "worried" (more than need to) - how people with disabilities, or special devices (non-standard pointer devices, like artists) would use Qt, as I thought there is no native support.
And yet, I was mistaken. Windows (and other systems) expose an "assistive" layer where you can explain to the underlying windowing system what is each thing that you draw, the text, etc. And Qt solved it.
Once we moved from MFC -> Qt, and removed other uses of wxWidgets, non-ui programmers started adding bits and pieces much easier in Qt (I'm not claiming Qt superiority), because all it took sometimes was to subclass, and repaint something, add button or two and create new control. With MFC that was hard, and with wxWidgets kind of tricky (solutions always ended up being "Windows" specific, not that we cared about Linux/OSX back then).
So that's why I love flutter, and it reminds of Unreal's internal UI used by it's editor.
At work I'm still struggling with GWT, XML ui binder files, and trying to componentize modules. With flutter, Qt, and I guess Unreal's UI it's much easier. Or with JUCE for that matter...
So I'm no longer against "custom" drawn UIs, as long as they expose their contents properly to the OS (and if this matters really).
Sorry for the long rant...
Oh, and I mentioned it someplace else - I love how IntelliJ uses Swing - it's much better from Eclipse (which is trying the exact opposite with it's own platform-"wrapping" ui-kit)... And just 10+ years ago I thought the opposite.
[+] [-] malkia|8 years ago|reply
[+] [-] htormey|8 years ago|reply
I wonder how stuff like navigation is built? If that's all in dart I'd be interested in seeing how the back stack looks in the hierarchy explorer. I.e are precious screens rendered still.
[+] [-] sethladd|8 years ago|reply
We're adding more Cupertino (iOS-flavor) widgets. A few that we already have: spinner, toggle slider, button, alert. Check out the library (https://docs.flutter.io/flutter/cupertino/cupertino-library....) and let us know which ones you'd like to see next! https://flutter.io/issues
Thanks!
[+] [-] sandebert|8 years ago|reply
[+] [-] bschwindHN|8 years ago|reply
Hot-reloading and good performance are very attractive parts of Flutter, but they really should have reconsidered the decision to make their own UI widgets. When you use the native UI elements, you get that native look-and-feel for free, and you don't have to dump man hours into replicating that behavior. They could have a "UI backend" which calls out to the native UI elements for each platform. The great thing is that since they use these UI widgets natively on Fuchsia, they can use their existing code as just another backend on that platform without having to throw the work away.
[+] [-] bitmapbrother|8 years ago|reply
[+] [-] Const-me|8 years ago|reply
Finally, people outside Microsoft started to realize modern GPUs and high-resolution screens need a purposely-built GUI framework, designed for GPU rendering from the ground up. Especially on mobile platforms. MS did that in 2006 with the first release of WPF, and with WinRT/XAML they continue to pursue the approach.
[+] [-] themihai|8 years ago|reply
[+] [-] jeffjose|8 years ago|reply
[+] [-] mike_hearn|8 years ago|reply
Relatively recent build of a custom widget toolkit? Check.
GPU accelerated 60fps compositing, render and animation layer? Check.
IntelliJ as the IDE? Certainly. Although JFX is perfectly usable from any Java IDE?
Cross platform including across iOS and Android? Check. (except JFX also does Mac/Win/Linux).
Fairly standard layout and box packing model. Check.
Material design? Via a third party company called Gluon, check.
Functional reactive design? Check.
Async/await? Yes, Kotlin has coroutines that integrate with JavaFX.
Hot reload? Actually yes, JVM+TornadoFX has some support for this, although it's not as slick as what Flutter can do ... the view you're working on will be sometimes be thrown out and rebuilt. But if you change your CSS or the behaviour of e.g. event handlers, then you can do hot reload.
There are some differences I see. Dart focuses more on AOT compilation. Another is immutable widgets in Flutter. That one I'm not convinced about at all.
> You can respond to events, like user interaction, by telling the framework to replace a widget in the hierarchy with another widget. The framework then compares the new and old widgets and efficiently updates the user interface.
No explanation for this odd design is provided. I suppose they believe it is self-evidently superior, but that seems like a lot of overhead for very little to me. After all, GUI is pretty much THE standard definition of a big pile of mutable state, and trying to pretend its not by just generating more garbage than a normal GCd toolkit would seems a little strange.
[+] [-] skybrian|8 years ago|reply
Stateless widgets are useful for static boilerplate that only changes when moving to a different screen, or when swapping out an entire subview. Supporting arbitrary mutations is extra coding that's unnecessary when it's not going to change anyway. Why implement it when you don't have to?
Note that even with entirely stateful widgets, if the whole layout changes, the whole subtree generally to be thrown out which also creates garbage.
[+] [-] tyingq|8 years ago|reply
>No explanation for this odd design is provided.
I suspect that's to support how they provided both an iOS and Material design look and feel. For example, there isn't a single button widget with different styling. There's a CupertinoButton and a RaisedButton.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] twotwotwo|8 years ago|reply
Dart feels somewhere in between JavaScript on the one hand and a more-static OO, GC'd lang w/type inference (like Kotlin!) on the other. You can probably look closely at some sample app code and start doing some basic stuff quickly if you've worked much with JS and something more static. (Further study seems worth it if you plan to do a lot, heh!)
As others note the UI model seems Reacty--you write "builder" methods that recreate a widget tree when things change, and something behind the scenes sorts out an efficient way to update the screen with just what really changed. I'm not hugely worried about performance: your UI rebuilds should be separated from your animations, and anyway, building your virtual widget hierarchy ideally shouldn't be too CPU intensive in the first place.
Hot reload is pretty great. I can't actually compare with "real Android" dev, but changes to my little app showed up in under a second in an Android phone, emulated or real. There were a couple surprising things about the basic libs, e.g. Flutter master only recently added a convenience object to bundle together a radio/checkbox and its associated label-stuff (RadioListTile).
The Flutter Gallery app is available on Google Play and its source is in the Flutter git tree. You can see a lot of the Material widgets implemented, including rich list types (e.g. tiles w/photos), pull-from-the-side drawers, top-of-screen tabs you can swipe through, bottom-of-the-screen nav bars etc. Even on iOS Google seems to follow Material guidelines a lot (or at least, the Daring Fireball guy complained that they do; I don't have iOS to check), so maybe it's the easiest fit if you're prepared to do the same. Someone who works on Flutter mentioned elsewhere in these comments that they're working on components that look more like the iOS-native ones, though.
Although Android Studio is _based on_ IntelliJ, you need to get actual IntelliJ if you want to use the plugin (Studio's component versions don't match the ones that the Flutter plugin works with, I think). Also, if you have Studio 3.0 canary installed (like to futz w/Kotlin, heh!), you need to either configure Flutter to look for the stable Studio 2.3's copy of Gradle (flutter config --gradle-dir=...) or just make sure 2.3 is located where the flutter tools look by default (~/android-studio for me on Linux). People working on Flutter helped some of us through this at https://github.com/flutter/flutter/issues/10236#issuecomment...
You get a lot of IDE-ish luxuries (as OP notes): Control-Space to offer identifiers, methods, or params available; autoformatting with dartfmt (right-click menu); lots of quick feedback when you mess something up.
Hixie (Ian Hickson) of the HTML5 spec works on Flutter which is kinda neat (he did RadioListTile just now! and there's a milestone on GitHub named 'Make Hixie Proud' haha :D). Outside of the tech specifics, Dart's an interesting creature in that it seems like it's got some key customers in Google (AdWords, so, like, the part that makes money) but comparatively little pickup outside. On Flutter GitHub you see people paying attention to outside-adopter issues (or even passerby issues such as my Gradle-version thing recently). There's apparently lots of tooling available publicly, e.g. a package manager (pub), dartfmt, IDE plugins, a playground (dartpad.dartlang.org) etc. Curious to see if there's any more pickup on the outside.
[+] [-] skybrian|8 years ago|reply
Also, the Dart plugin for VS Code is starting to add Flutter support. In that case you'd use the command line for hot reload.
- a Googler working on Flutter plugin.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] sireat|8 years ago|reply
Alas, I stopped reading the moment I read it is being developed by Google despite the open-source nature.
Being developed by Google it means the chances of a project being discontinued are quite high: https://en.wikipedia.org/wiki/Category:Discontinued_Google_s...
While other big corporate entities have their own share of shut projects (no project is forever) the moment this project stops getting official Google support it will wither and die.
Maybe I am reading this wrong and we could have a Open Office/Libre Office situation.
[+] [-] mythz|8 years ago|reply
So whilst it's reasonable to hold off until they adopt it themselves and use it in their own deployed Apps, but once they do I'd be more confident in a commercially-sponsored Google project than an Indie OSS community led project. You just don't hear about the thousands of OSS projects being abandoned because they're from multiple Indie authors.
But I wouldn't trust a project with this large a scope without mega corporate backing. But I'd agree that if Google stops committing resources to Flutter than it will die despite being OSS'ed since it's too big to maintain without a well-resourced team.
Not all Google projects should be considered equal, if adoption is low and they don't have flagship Apps, high-profile initiatives or cost center's backing/funding the project then the project's future would be at risk if it doesn't become successful, but any project that is successful, has adoption or paying customers are very unlikely to discontinued, e.g. Angular, Firebase, Google Cloud Platform or any of their popular platforms, i.e. Chrome, Android, YouTube, etc have zero chance of being abandoned.
[+] [-] bitmapbrother|8 years ago|reply
Do you also avoid Microsoft products and services because of the chances of a project being discontinued are quite high?
https://en.wikipedia.org/wiki/Category:Discontinued_Microsof...
You can also add these to the list:
Or how about Apple?https://en.wikipedia.org/wiki/List_of_products_discontinued_....
[+] [-] on_and_off|8 years ago|reply
I would be curious to know what terminal the author uses. On my N6P, I can see a lot of dropped frames in the flutter demo app.
[+] [-] sethlopez|8 years ago|reply
The Flutter app in the Google Play store does lag for me during the first run of most large animations (nav drawer open/close, shared transitions, etc.). The second time those animations are run, everything is smooth. There must be some sort of caching in place for animations.
As far as I could tell, everything else seemed to be fine. Scrolling performance was good, as were smaller animations like checkboxes and switches.
[+] [-] xster|8 years ago|reply
https://github.com/flutter/flutter/wiki/Flutter%27s-modes
[+] [-] sebringj|8 years ago|reply
[+] [-] invalidname|8 years ago|reply
[+] [-] madeofpalk|8 years ago|reply
This is quite a claim...
Edit: It's customary to include a disclaimer you work for the product your spruiking FYI.
[+] [-] bitmapbrother|8 years ago|reply
The Codename One app gallery says otherwise.
[+] [-] dannyr|8 years ago|reply