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)
GWT had its purpose. You need to remember that it was released before jquery was a thing. And also to realize it was the first (was it?) framework to push the large single page apps that worked in all browsers. It was created so Google could make the AdWords and Adsense UIs.
Today's AdWords UI uses AngularDart. So they've moved away from GWT. But 11 years ago the JavaScript landscape was very different.
[I work for Google, but I was doing GWT dev for 4 years before joining]
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:
Nothing wrong with doing any of it, as long as its a dependency you can manage while also maintaining productivity... but such is the life of a Javascript developer.
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.
> Personally, I think it makes sense to differentiate between something which takes one child and something which takes an array of children.
Could you please explain this - it doesn't make sense to me.
To me it seems clearly and unambiguously true that a single child is not a special case vs multiple children, but rather just a list of children that is 1 long. I can't think of any cases where handling both as an array would possibly have you write worse code.
Take the Container class in Flutter, it can only take a single Widget as a child. Having to write a list of children that is 1 long every time I use a container doesn't make sense to me, and to me seems confusing as it will lead to people trying to add more items. I don't know, that's my opinion, maybe I'm wrong :)
Hmm, perhaps it's me not understanding the flutter paradigm, but if something only accepted a single child, I would stop calling it a child and start calling it a more precise name. Like perhaps contents in the case of a container?
Sounds like they took that from Android where IIRC a scrollview could only take one child. Coming from Win32 Android, back in the G1 days, always had its own idiosyncrasies.
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.
Perhaps because Qt occupies a couple of niches that don't have a particularly entrenched native look and feel or are not very widely used.
Home entertainment systems, in-vehicle entertainment systems, kiosks, medical devices, avionics, Linux desktop apps, printer displays, navigation systems, industrial equipment controls, these are the sort of things that Qt is mostly used for.
Do you use a Qt desktop or mobile app on a day to day basis? The only Qt app I have ever used is QtCreator. It's a good development environment, but the look and feel is definitely a bit weird.
Simplest way to verify, launch visual studio 2015, press Tools/Spy++, in Spy++ find the visual studio’s main window, you’ll see that Win32 thinks visual studio is a single window with no children, with class starting with “HwndWrapper[DefaultDomain;”
Unlike that, Spy++ itself uses Win32 (wrapped by MFC but it doesn’t matter) for GUI, you’ll see these SysTreeView32, msctls_statusbar32 and other native controls there.
I stand corrected - thank you. I don't have a windows machine anymore but as you said spy++ can tell you all you need to know. Hilarious to still see hungarian (hwnd - handle to a window).
While interop is indeed available if you need to consume a Win32 control (not without limitations but generally works), by default WPF doesn’t use native controls. Instead it paints stuff on GPU with Direct3D 9, and on top of that implements its own markup, styling, layout, animation, behaviors, composition, etc…
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.
Not only that but if you reimplement the widgets then your always playing catch up when they change. It's better to just use the platform's 'primitive views' then constantly reinventing a wheel that looks similar. Someone else also mentioned accessibility which to me is a deal breaker if your app doesn't match a native apps accessibility.
Is there any such toolkit? What exactly is "platform's 'primitive views'"? Usually the "native" implementations are actually bindings to the native APIs which require heroic courage(a lot of manual tweaking), not to mention that you still need to catch up/update your bindings when these APIs change.
I would say that there is. Both Xamerian and React Native use the platforms Native views: UIView on iOS and View on Android. I agree that they are just bindings but that is easier then having to reimplement them as they all have small quirks especially when accessibility comes into play. I can't speak of Xamerian but I've written some of those Native bindings for React Native and would not call it requiring 'heroic courage'. It's actually quite easy and if you were on the Native side you'd have to make those changes anyway because those APIs changed.
WxWidgets are kind of that in C++ land at least. I know they use GTK on Linux and native widgets on Windows. They might not have good OSX support though.
> 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?
Platform independence
Choice of tools/language
Control of customer data
Hardware independence
Here is what corporate platform owners (Google, Apple, Microsoft, Amazon etc) want:
Platform lockin
Minimal support costs (one language, one SDK)
Control of customer data
Control of the ecosystem
Hardware independence
A vig on every transaction
There are very few intersections between the interests of developers and the interests of platform owners (be that Apple with iOS or MacOS, Google with Android, or MS with Windows). This is why the web will win IMO, it's one of the few platforms focussed on what customers and developers want, and not owned by a single corporation (though Google has come close).
I would hardly agree with the modern web being focused on what "customers" want. How many web pages today hijack scrolling, fill the screen with ads that lie on top of the content and don't scroll with the page, and so on? How much bloat is there? How many MB of unnecessary JS frameworks must be downloaded, often on a metered data plan, to support all of that? The web is a horrible mess these days. It may be a rip-roarin' good time for (some) developers, but it's absolutely awful for users.
Compared to app platforms, I think it is more open and more focussed on readers and devs. The problems you list are annoyances of some websites, not even the majority. For example they don't apply to the site you are currently on not hard limitations.
In contrast iOS forbids other payment systems (see deliberately limited kindle app) and browser engines. Android forces manufacturers to prominently feature lots of google products.
I don't know how good it is, but there is a company called RemObjects Elements http://www.elementscompiler.com/elements/ which cross compile Windows (.NET), Android (Java), iOS (Object C / Swift), Linux/Android (C++).
I'm developing a game with React Native [1], and I have a single codebase that works on iOS, Android, Windows, and web (via react-native-web, although it needs a lot of work.)
I've had to write a few 'native modules' for various platforms, but it has to be platform-specific code anyway (e.g. ad networks, in-app purchases, game services)
I've been looking for a way to write some native code that I can compile to JS, and have decided to use C (or C++) with emscripten [2]. Rust or Kotlin might be fun, but I'm comfortable with C and it's easy to compile for iOS, Android (NDK), and Windows.
Yeah, that recent post [1] gave me a bit more confidence. Ooh, and it looks like I can compile Rust to wasm with emscripten! [2] I might have to reconsider Rust.
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.
I guess your definition of 'app' is a lot more liberal than most other people's. iOS, Android, Blackberry, Windows Mobile has a combined 7m apps on their respective stores.
Do you work for Codename One? Your HN history seems to suggest you're quite 'involved' with it.
It's a partial gallery and keep in mind it's installed apps. There aren't 180M apps in existence so interpreting that number in that way wouldn't make sense...
My point was how bad they looked, not their quantity. If I was going to showcase my product I would select the best of the best. If that's the best this product has to offer then you should probably reconsider your statement that Codebase One runs circles around Dart/Flutter because from the look of the Dart/Flutter apps I've seen they're on another level.
And if the look of the Codebase One apps weren't enough to make you turn and run the ridiculous pricing strategy of Codebase One would. Why would I pay a fee for unrestricted cross platform development when better alternatives that are free already exist.
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.