Google's cross-platform Flutter UI toolkit goes 1.0
techcrunch.com
techcrunch.com
Which is sad because I would really want to have some fast and easy access to useful c++ libraries without wasting lots of time writing and maintaining tons of bindings for Java, ObjC, C.
We are on the verge of VR and AR and I don't see how flutter can help e.g. processing >100fps Video Feed using OpenCV library. The demo they presented on stage with ML and smile detection had quite big latency. I wouldn't call it real time.
So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
https://github.com/flutter/flutter/blob/master/examples/plat...
I really hope flutter can provide a guide for FFI though.
I can't find any claim from Flutter team that 100fps video processing is even their goal. So that's a strange metric to measure it by - especially since it's competing against Javascript interpreted code which is far from fast by any metric.
> So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
On mobile? Qt really isn't pleasant or usable on mobile.
C++ is probably not the most productive language to write business logic but on the bright side Qt Company recently started supporting Qt for python (Pyside2) - sadly not on mobile devices for now. However it seems you can use PyQT5 on mobiles nowadays. This would be the best of all worlds IMO: 3 highly popular languages with rich libraries, tools and ecosystem -> C++ for speed critical code, Javascript/QML for UI and layout, Python for business logic and as a glue.
Qt also gives me more confidence that is not going away anytime soon. It survived many years and acquisitions (Trolltech, Nokia, Digia) and have some big clients/users in automobile and open source (KDE).
I will closely follow Flutter thought as well as React Native. The latter one also it seems noticed what a pain is writing all those bridges and looks like they are working on it to fix it with new architecture.
https://github.com/qmlnet/qmlnet
note: I'm the author.
Yum install qt5-
You can use it, but is it easy to use and build and deploy?
Can't confirm. We've been using QML (part of Qt) and C++ to write cross-platforms applications (Android, Windows, Mac) for many years now without any major hiccups.
What's wrong with it?
That being said - my personal usecase would like a direct C++ interop, and flutter is working on it. See https://github.com/flutter/flutter/issues/7053
Since flutter runs as native ARM they can directly call C++ instead of having an expensive JNI bridge on android. If you're wanting something fast with native processing - flutter will be the best option out there IMO if that issue is resolved.
Dart C/C++ interop hasn't been a super-bright spot so far, and I am _beyond_ glad to see it's about to change.
The rest is UI and application boilerplate
I did some research and found that Dropbox open sourced their internal tool for building cross-platform mobile apps in C++. Djinni (https://github.com/dropbox/djinni) uses an interface definition language to generate bindings between C++ & ObjC & Java (via JNI). From this, I added some tooling to help get the build setup and define some basic UI elements while trying to keep it simple. If you happen to give it a try, I'd love to hear your thoughts: https://github.com/adamtait/ctheworld
e.g. iOS HID requires navigation buttons for obvious reasons & not so for android.
Use the right tool for the job. Always.
If Flutter can't handle it, it's not the right tool for the job.
- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
- they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
- Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
- there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
- dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
- devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
- many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Building and maintaining an app twice is a very serious expense. But the expense of dealing with the issues with crosss-platform frameworks can be pretty big as well. Of course it depends on what you’re doing (shorter term and longer term) whether or not it makes sense. But go in with your eyes open. Consider other options (like examining your app architecture and see if you can’t find a way to factor some of your naturally cross-platform stuff into a shared library usable by the native apps of each platform you support).
We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
- Facebook doesn't use standard share sheets or web views. So if you're viewing an article, you can't use reader mode and you lose the (considerable) power of share sheets to do things like sending an article to another app or take an action on it.
- Gsuite doesn't register left swipe as back even though 99% of apps on iOS do. Icons for common actions are subtly different and make you double-take while you understand what they do. Accessibility options like larger text do not work, so if you're vision impaired good luck trying to figure out what you're looking at. And there's a ton of other quirks that have existed over the years including scaling to new resolutions/ipads, problematic text selection, performance, etc. It's not as bad as it used to be, but it's still not a pleasure to use Gsuite or any material design on iOS.
While many apps may use cross-platform frameworks solely for saving developer/designer time, the bigs use them for an additional strategic purpose that is detrimental to users.
- Google wants you to be familiar with their apps regardless of platform, so that its easier to get you to switch to Android or Chromebooks.
- Facebook wants to keep you in the app as long as possible, limit social sharing outside of their app, and spy on your browsing activity, so they add friction and don't use modern iOS web views that prevent that.
I wouldn't take cues from the bigs and just assume because they do it, it's the best course of action.
For us, we want to use the web stack so our stuff works across all platforms. So we use Cordova. We realize that over 90% of users just want to use the main interface and not some fancy OS feature. All our effort goes into making the product rock solid stable, engaging and easy to use. We aren’t actually interested in making it feel exactly like a native iOS or Android app.
Looking at the last 30 years of software development, it's pretty clear that users don't care very much.
"My app is a snowflake and needs a custom design language and UI." You're vim or Photoshop or AutoCAD or Excel: you're targeting dedicated users who are prepared to invest in learning a specialized UI. Fair enough.
But if you're not one of these highly professional apps, then custom control just makes the app less predictable, harder to use, and often inaccessible for users with disabilities. Not good.
Consider the humble popup button. A user may open the menu via touch, or with a mouse click, or tab to it and open it with spacebar, or via accessibility support, or via scripting support. Once the menu is open, the user may choose to select an item via touch, or trackpad, or key equivalent, or arrow keys and return, or accessibility, or scripting...
When the control is obviously normal, all of these interaction modes are available. If it's something custom, then probably only a few work and I don't want to subject myself to the frustrations of figuring out which one.
Native UI controls allow the user to exercise their built-up vocabulary.
> I'd say that, if someone puts enough attention into it, custom design / controls are probably mostly superior to the native UI, in terms of UX.
Broadly false, but true in highly specialized apps where the investment in custom flows is worth it. (vim, Photoshop, etc). If you're building one of these apps, by all means, think deeply about a specialized interaction vocabulary. But if your app isn't designed to be absolutely central to a specialized workflow, PLEASE leverage the ecosystem and use the native stuff.
> Not to mention how often people want something different and fancy over "boring" bland look of native controls
This doesn't actually happen.
Then using the native wrappers, like wxWidgets is often cumbersome to create customized control, and if you do you end up with some platform specific version (not end of the world, but pretty much why not use the OS toolkit directly). Also any wrapper soon or later suffers from "leaky abstraction" - where you hide things behind interfaces, but can't hide different performance characteristics, and getting the current line in a log dialog might just kill you, because underneath it might be scanning all '\n', '\r' until your cursor position.
This is hinted at where I say "Google, Facebook, _and other top dogs_", and "_e.g._ Material UI" -- emphasis mine.
Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market.
It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's".
Which means that in this scenario:
> devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
.. It becomes moot whether you're using an engine or an OS's own specific platform. You have either an 'engine developer' or a 'user-facing developer', where the former does everything needed on the target OS to support the latter.
My personal preference: treat onboard native UI frameworks as a plug-out interface to the engine, port the engine everywhere, have my apps look and feel and function the same, no matter where they are running. Screw the OS vendors and their UI's - they change their frameworks so frequently and for no good reason other than to lock in the poor developer who thinks he has to learn their framework, or else not be competitive.
That may be true, but the real competition is in building an app that functions - and functions well - wherever you port it. To accomplish that, you've gotta be willing to be both an expert at the native framework, while also abandoning it ...
However, apps are not games. They're tools. And tools are not about giving your users challenges. They're about fulfilling a purpose as easily as possible. UI frameworks and conventions matter here because they lower the learning curve and cognitive switching cost, and they respect a user's preferences for how they wish to engage with their device (including valuable OS-wide capabilities like accessibility).
Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience.
- Some do it accidentally, because they don't know the UX guidelines or subtleties of the platform
- Some do it for expedience, because they need to put out a product quickly with few resources
- Some do it strategically, because they want the user experience worse since it serves other purposes for them
Yes, UI frameworks change as OSes change, but it's rarely for 'no reason'. Stepping back, devices have gotten way more capable and their UX way more sophisticated... which does necessitate change. Though that's some extra work for developers, it's not about you. It's about your users.
And in that sense, its quite possible to make a non-native UI that is more productive than the OS-provided UI - you merely have to take responsibility for the user experience, obviously.. So yes, its about the user. One reason for going non-native and rolling-your-own, is to ensure that your user has a positive experience, no matter what platform they are using - and this directly competes with the platform-vendors ability to woo new users with fancy, game-like, UI elements.
So I don't think this point is quite correct:
>Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience.
Developers that choose to use their own UI framework win or lose on the basis of how responsible they are for making sure the user has a good time with their UI. This has nothing to do with whether the app is a game or a tool or whatever. Its a matter of competence.
A product that looks the same across platforms is better than a product that adapts itself to the platform it is on, in part because platforms have a lot of UX that isn't good.
My argument for why its better to adapt a product to the platform is threefold:
1. Users have made the choice to use a particular platform and either like or at least tolerate that platform's approach to UX.
When in Rome.
2. Users are using many apps not just the one you made.
This is about scope. You can't just optimize your app in isolation, you have to take into consideration the entire scope of usage on a platform. It's certainly possible to create the perfect UX for a given set of tasks a user has to perform in an app, but drop that into a platform and its likely you've just added a huge learning curve and ongoing cognitive load.
3. Users mostly do not use your app on different platforms.
Users probably own either iOS or Android. If they own one, they aren't even aware of how the other one works. And on desktop, who cares because screen size and pointing device differences necessitate different UX anyway.
----
I think there are some instances where having the exact same UX on very different platforms is more ideal UX for the user, but only after it's acknowledged that a) its not just a proxy argument for being easier on the developer/designer, b) its not just the result of developer/company tunnel vision which leads to the assumption that users care about the app as much as the developer/company does, c) users actively want a different experience (e.g. immersive game), and/or d) users are moving more frequently between platforms than different apps on platforms (e.g. a business use case).
From a business perspective it's certainly fine to choose to use a cross-platform kit as there's many reasons to do so, I'm just arguing that it's not ideal for the user the majority of the time.
As far as whether platforms have not-good UX, I mostly disagree. I'd need to see examples of what you're talking about. If by swipe scroll you mean momentum scrolling I disagree. That has great utility on small screens to traverse large lists and it grounds the device in physical metaphors. It's a fantastic UX innovation.
I'd imagine it will take much more than 1.0 to get close to parity with the OS. Even if we assume it will always be 90% of the full OS experience (which is fine for the vast majority of use cases).
And in cases where you're using platform-specific feature that Flutter doesn't support yet, then your experience will be no different -- the burden remains on you to write platform-specific code.
It's unclear to me that this is a sticking point.
It's also assuming that the Flutter team wouldn't consider do that considering they have that kind of information available to them -- it's in their best interest, after all.
I agree with the other commenter -- don’t expect any close cooperation between Flutter and Android because that’s just not how Google (and other huge companies) tends to work.
Good product is a team effort. The question is: Can you find the right people - not just any people but the right people - to come on-board, use / learn the tools you've chosen, and make magic happen?
Sheer technical prowess of tools and/or people is not enough.
That aside, to your points, there are __always__ tradeoffs. Some more detrimental than others. But again, preserving is a function of team. Someone somewhere is doing what your team is doing, and doing it better. They have the same technologies. So then the question is: why.
>> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not.
>> they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
If people are writing cross-platform apps and want to use new platform-specific features, wouldn't they have to write platform-specific code anyway if they were native? I'm not sure this is a newly introduced problem in any sense.
>> - Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
I guess that's valid; but I'm curious about cases where code-heavy app sizes have actually hindered app downloads. I don't really know, but I haven't heard that this has been a big problem? For reference, a hello world flutter apk clocks in at 5 MB.
>> - there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
>> - dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
>> - many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?
>> - devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
This feels like an emotional assessment of having to learn something new. If this technology is meant to simplify/remove problems that people have today, then isn't it worth learning? I guess you might feel this way if you felt that flutter isn't adding anything of value to other popular solutions today.
On iOS, the extent of "branding themes" end up is often limited.
> Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
There is no Chrome on iOS. So Flutter is different from everything else out there.
> Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?
Flutter, and almost every other cross-platform framework, have this problem.
Ha, I wish! I've been down this road a few times and this list came from contemplating some of my old battle scars.
> ...as `coldtea` points out below, this is not really an issue in today's ecosystem.
That's not quite the same thing as it not being a problem. I know it can be done, but it's harder than when using native controls. This is something the "big dogs" can handle (they can bring massive resources to high-profile projects if need be) -- especially if they control the framework.
> ...cases where code-heavy app sizes have actually hindered app downloads... Well, look around for people complaining about bloat. It's not usually the download itself, by the way. Memory is filled and runtimes have to initialize, buffers allocated, etc. It all takes time and uses runtime resources. This is fine to a point, but once you use too many resources or take too much time, it has a negative impact on the app (and as the developer, you have to deal with it in some way... e.g., perhaps spend time to alleviate the issues or perhaps walk away from lower-end devices). Any app, no matter the tech used to develop it can face these issues as it grows. But with an engine you start off closer to the limits and have less control over resource usage, so you generally reach them more quickly.
> Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
Hey, if flutter solves cross-platform text in 1.0 as you suggest, then good for them. Believe me, that's a massive accomplishment. (Though I'll note: if they aren't using native facilities, they'll have to duplicate them, which goes back to the point on bloat.)
> Is this a remark on an incomplete cross platform framework...? No, I'm saying apps -- at some point -- generally eventually need to incorporate third-party libraries/tools to best accomplish their purpose. A PDF generator, a .csv parser, an image processor, an AI library, whatever. (A framework can't include an API for everything and shouldn't try, so it's not a matter of an incomplete framework). However whatever third-partly library you're interested in probably won't provide direct support for your framework, so you'll have to figure it out and do it yourself. It really depends on the library and the framework and how/whether they overlap how much harder this is.
E.g., suppose you want to incorporate an image rendering library of some sort into your app. The library supports iOS and Android and can output to UIImage on iOS and Bitmap on Android and their site provides samples showing how each of these work. But you're using a framework that has "XImage" and "XImageView". So now you need to delve into the platform's "XImage" to figure out how to load a UIImage into it on iOS and a Bitmap on Android. Maybe you find it works in terms of OpenGL textures and you realize going through a UIImage/Bitmap is an extra, inefficient step, so now you're learning about how to load directly from the library output into an OpenGL texture and you learn OpenGL textures can have different color formats so you start using the complicated low-level API of the image library to get output in the color format of the OpenGL texture. Whew! What would have been a few lines of code in each native app turned into a couple days of work, but you're done and release it.... and shortly thereafter, you start getting reports that the images are flipped on certain devices. Uh Oh... Now, maybe flutter doesn't have this particular problem, but this is just an example. This kind of thing will pop up as you integrate the third-party libraries you use with the UI platform. The more "opinionated" the UI platform is, the more quickly you'll run into these kinds of problems.
> This feels like an emotional assessment of having to learn something new. Oh, come on. I'm pointing out an additional cost to adopting this kind of platform. That's a real concern to anyone developing apps, not something you can dismiss as an "emotional assessment" (Not sure even what that means -- laziness?). Note, this is an additional cost since you'll need native expertise in any case.
Whithout having any Dart or frontend or UI experience (I have always progammed backend and CLI apps), I could make a simple working game in maybe 10 hours - and it is mainly due to the instant feedback cycle.
The whole thing is less than 600 lines of Dart code. (and about 100 lines is to deep copy game state objects (for the undo functionality) as Dart can't do that automatically.
The design is simple, just circles, shadows and small animations (the player in turn gets magnified)[1], but with zero experience in the UI domain I actually barely beleive that I have made it ;)
Of course games are absolutely not affected by the native or not native widget issues, and also I did not use any advanced services from the platform, so can't say much about those weaknesses.
I was really happy with it, I would definitely recommend it to similar hobby/beginner projects.
I was looking for some new dev challenges and wanted to mess with some mobile app development that is outside of the React Native / Ionic / js world.
Gave Flutter a serious look, loved it, but ultimately decided to just skip and mess with Swift and Apple's tools - so no Android stuff for me for now. I just don't trust it to be around long enough to be an investment for me.
I know I'm just 1 developer working on a crappy hobby app for fun, but Google's quick lifecycle of products has real impact. But then on the other hand I love Firebase. Just wanted to share.
Normally I would be inclined to agree with you given that this is Google, but the good news is that Flutter is open source. So even if Google discontinues internal development on it, it's likely that the community will continue it anyway.
I would be willing to bet my retirement that none of the now-popular presentation technologies will be mainstream 30 years from now. They just don't have that kind of shelf life.
If Flutter lasts a decade, it will have lived gloriously. React should be so lucky.
Flutter could be even worse off, as mobile/web development is often corp development, i.e. not something people do because it's enjoyable. Even more people used MFC and Motif, but I don't see a lot of fansites dedicated to those.
I have nothing against React (I use it) but I see no reason to believe it will not follow the lifecycle of every presentation technology that came before. Ten years is a long time. Of course people will be still be using React, but then people are still using GWT today.
People attribute the JS presentation library churn to fadism, but I’ve seen it as a response to everything being pretty bad before React. Can’t blame people for desperately trying everything when everything is bad. React was really the first one for JS that really empowered people and every year it gets better.
Anyway in the sense that Reactive rendering is apparently a core element of flutter, all I care about is that the future is React-like, and in that sense React will be around for a long time....
X-Windows? That thing started life more than 30 years ago, and still going strong on Linux.
Dart for web underlies Hummingbird, Google's Flutter-for-web effort that was also announced as a sneak peak alongside the Flutter 1.0 announcement, so Dart for web is very much alive and maintained at Google.
Even if it's not popular elsewhere, with its use inside Google, it won't be going away anytime soon.
Read this interview if you're interested to learn more on their reasoning: https://news.dartlang.org/2016/03/the-new-adwords-ui-uses-da...
The point being that just because Google uses something for AdWords doesn't mean Google will maintain it for the long run. I might find other arguments more convincing.
This is not entirely true, although the goal shifted over the years and progress (outside Google) is very slow. See J2CL, jsinterop, and elemental2.
That's factually incorrect. Development of Dart for the Web has never stopped. AngularDart is still officially supported, and under active development.
That's where it's best to explore and take chances. The only risk is wasting time.
UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I enjoy it more than Javascript but like Kotlin much more.
The app I built with Flutter was pretty straightforward, so I haven't stretched the platforms capabilities, but hoping I get the chance to.
Flutter doesn't use any of that, you just code and thats pretty much it. No XML or anything, and you can use VSCode which is a lot lighter than android studio.
Yes, tremendously so. It's still XML for basic UI, but Kotlin is the primary language of choice these days, Android Studio is a solidly world-class IDE, and the emulator is very fast.
> but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Flutter uses the regular Android emulator, and although you have more editor choice the recommended was to just use a plugin for Android Studio.
It works fine.
Kotlin, swift, rust, etc are more fun languages for me but Flutter is productive enough with Dart I am not about to ditch if becasue the language is decent at best.
Have you implemented any layouts using the Constraint Layout? Normally, I'd agree with you, but I find the Constraint Layout pretty great for designing UI's. The "glued together" approach makes responsiveness a breeze, imo.
I am a C++/mobile dev and I couldn't get myself amped about React Native because you have to do all the layouts through style-sheets. I am not a web dev, so style-sheets are pretty foreign to me beyond the basics. With flutter I can do all the same stuff but with auto-complete and in a hierarchy I understand.
I do wish the controls were native, but the customization you get instead is pretty powerful.
Followed later by the Oberon OS.
Eiffel also offered a similar experience with their MELT VM and compilation to native code via C code generation.
What I take from that is this: if your toolchain makes rapid iteration easy people will figure out how to work around almost anything else.
Language/framework/tool creators rarely put enough time into the developer experience. And by that I mean the experience of a developer working with your tool for 8 hours a day. I can get more done with a crappy tool with 500ms compile time versus a perfect tool with 10s compile time.
I'm happy there's another platform but they really should use some existing language with mature tools and libs. Why reinvent everything again? Unless their real intent is to lock you to their own ecosystem and then mildly steer you to using or preferring to integrate with their own products.
BTW: Is dart really open? Publishing sources does not mean a thing, is Google making choices?
"Is dart really open? Publishing sources does not mean a thing"
BSD license, ECMA standard.... https://github.com/thosakwe/xart
Try it, you'll love Dart.
I've tried Xamarin, React Native and Cordova (god forbids) and native development on iOS and Android. My preference is Flutter.
I've done one big(ish) project with Flutter and it's called "My Leaf" and it is a third party alternative to the NissanConnect EV app. It's used for controlling the Nissan Leaf and Nissan e-NV200 (both EV's). It's open source and available on Android and iOS;
https://play.google.com/store/apps/details?id=dk.kjeldsen.ca...
https://itunes.apple.com/us/app/my-leaf-for-nissan-leaf/id14...
I've seen some of the comments in this post talk about developing plugins for Flutter. I actually think it is easy and does not require much boilerplate contrary to what people say. My guess is that they really haven't tried writing a plugin but only peeked at the documentation.
[edit]: It looks like this has been addressed with the PlatformView widget: https://developers.googleblog.com/2018/12/flutter-10-googles...
[edit]: Sorry, bluetidepro - this was supposed to be a reply to you.
A full Chrome copy for your desktop app is whatever, we have the resources, but on smartphones this is actively harmful. It bypasses the hardware compositors. Displaying a video, they have to render that to a graphics texture; on many smartphones, the IP that is doing hardware video decoding has nothing to do with the GPU and they might very well not use the same formats, requiring CPU conversion (if it's at all possible).
I haven't looked deeply at the HTML5 APIs but if you wanted to say port Flutter to HTML5 Canvas you may run into problems where you can't expose rich enough a11y primitives on something that was just meant to be a bitmap.
As for new Flutter features, Google today announced ‘Add to App,’ a new feature that makes it easier for developers to slowly add Flutter code to existing apps. In its early days, Flutter’s focus was squarely on building new apps from scratch, but as it has grown in popularity, developers now want to use it for parts of their existing applications as they modernize them.
In this aspect it's very similar to Flash or QT.
You also don't get to use the wealth of libraries that target native development.
Cross platform always has trade-offs.
The comment from pzo points out an even worst of an adoption showstopper.
> There’s a lot of nice properties of Dart, we talk some about this on our website at our frequently asked questions. One of the nice properties of Dart is that it has a really fast garbage collector, one of the choices that we made in Flutter was to have this reactive style system where it’s very common to allocate thousands of objects in a – if not, tens of thousands of objects in a single frame.
> In a span of a few milliseconds and then immediately let go of those objects again. There’s a variety of ways to do that but Dart, having a generational garbage collector, can handle large volumes of short lived objects very quickly. Dart also has some really nice performance characteristics, it has an ahead of time compiled back end which allows us to compile straight to native arm code, allow us to achieve really fast startup on really consistent performance and Dart also has a nice focus on developer experience which really got along well with my team.
From https://softwareengineeringdaily.com/2018/07/09/flutter-with...
It took me few days to pick it up when moving from JS to typescript. I don't get it when people say it is complex or adds complexity.
They needed to be AOT compiled. Can't ship a JIT on iOS, after all. And JS is very unfriendly to static compilation. Dart is considerably better suited for AOT due to static typing.
There are other languages that are GC'd & AOT friendly, though, so I can't help you with why they didn't use any of those, though. But why they wouldn't use JS is pretty straightforward.
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.
Calling React Native “not native” while eschewing platform UI widgets is a bit thick. I’d actually of the opinion that React Native is “more native” than Flutter is; it might be a bit slower but it is much easier to build apps that could pass as actual “native” apps because the React Native team doesn’t need to try to emulate system controls.
The solutions for push navigation across Android and iOS using React Native were pretty poor and didn't emulate system controls the last time I used them. Has that changed?
(I’ve been doing native iOS since 2009)
There are people working on it. The progrss has been slow. I checked a couple of weeks ago and the issue was still open.
But as far as I know you can have a native view in its own activity.
Though not a blocker for simple apps which previously used Cordova or ionic, I don't think Flutter is ready to replace native development for immersive apps.
Embedding a native view in cross platform UI is possible with Xamarin and React Native, so they are more practical choice for certain types of apps that need this.
https://developers.googleblog.com/2018/12/flutter-10-googles...
Will Google really support all three over the long term?
Android and Chrome are both heavily invested in by Google, with massive external ecosystems too. Speaking in a personal capacity with no insider knowledge, I'd be shocked if Google stopped supporting either.
The UI for Fuchsia is written in Flutter, so it's got a pretty big internal customer too: https://fuchsia.googlesource.com/topaz/+/HEAD/shell/
Since this is Google we are talking about, no warranty that this will ever go on one of their flagship phones.
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.com/2018/03/02/fuchsia-friday-first-fuchs...
It's a bit cynical but I think they might even want to just bin linux as a base for Android and migrate off of it completely, get their notebooks/chromebooks on Fuchsia, and make a play for OSes to run on. Think of how much data they could get for the industrial advertising complex at the OS level.
That's what everyone wants to do. Guess what, Google might be big, but Android is big because Google has many partners.
If they try to pull that off, all their partners will drop them like a hot potato.
And I agree with you it's probably to ditch Linux cause Linux has too much political baggage, i.e. they want to fully control Fuchsia.
For us, it's probably better if Fuchsia fails.
At that point, will they have a choice? I mean most partners already bow to Google's control over AOSP -- if they said tomorrow that android was actually switching to run on top of fuchsia (let's say they did all the work to make it happen, so it was "seamless"), everyone would just be like... "ok".
While I'm not sure I necessarily want Fuchsia to fail, I'm 100% with you on it being likely better for the world if google didn't own everything...
Whoever wins, we loose.
Meanwhile, there are plenty of other Java vendors that are able to create their own Java implementations and play ball with the rest of the eco-system.
And if you squint a bit through how modern Treble drivers work, Google has turned their Linux usage into a kind of micro-kernel OS flavour.
And web: https://medium.com/flutter-io/hummingbird-building-flutter-f...
https://developers.googleblog.com/2018/12/flutter-10-googles...
I still prefer RN, and I don't my opinion changing in the future. I prefer controlling a native view for the apps I make. Maybe a game would be easier with Flutter?
- https://news.ycombinator.com/item?id=16818170 (42 comments)
- https://news.ycombinator.com/item?id=18399542 (version 2.0, 2 comments)
Does anyone know its name?
1: https://techcrunch.com/wp-content/uploads/2018/12/pasted-ima...
https://github.com/robbyrussell/oh-my-zsh/wiki/Themes#agnost...
PS Java (or Kotlin) are AOT compiled in all recent versions of Android.
Ah, that's how they do it. That's neat! But the language still has to deal with JavaScript compatibility.
> PS Java (or Kotlin) are AOT compiled in all recent versions of Android.
But it's still a mess to call native code. And still has Java garbage collection.
As a UI dev, I'd much prefer the hot-reloading that you get from Flutter, React Native, and web UI development though. But I still care about battery life and global warming so it can be hard to justify the flashy new stuff for most the UI development I do, which is mostly just list views.
I'm also weary of the post-mortem debugging experience for these higher level frameworks. C++ is nice for this given that usually the OS and UI frameworks are implemented in it too, at least on Windows.
Disclosure: I work at Microsoft.
https://www.adobe.com/devnet/air/articles/aot-or-interpreter...
Air supports native compilation since 2012!
To be able to publish on iOS, there Adobe AIR compile to native binary.
On Android, Windows, and macOS (also Linux) it does not to do that (eg. it is fast enough), so instead you have the choice to publish an app that need the AIR runtime, OR to publish a captive runtime (it bundle inside the app).
In general, most dev use captive runtime and so you don't need the AIR runtime installed first.
Now, keeping a runtime bundled vs compiling to native have numerous advantages, for ex you can make part of your app dynamically updatable without re-installing the whole app.
Technically Adobe have the tech in the AIR SDK to compile to any native target, they just use it for iOS.
Anyone has any experience with how well those work with React Native, and could share their experiences?
Could someone explain the difference between Kotlin and Flutter given that they are both being pushed for app development now?
For reasons of business strategy. With this toolkit, the AppStore might lose its exclusivity on a lot of apps.
Exactly what Google wants, and Apple does not want.
I mean, it better be damn good
Why isn’t there an equivalent of Interface Builder for React Components?
Another example of where they follow standards/stick to browser specs is their use of web workers for background tasks [1]. In comparison Flutter uses dart isolates[2] which makes sense of course, since they use Dart -- similar performance models (do hard stuff in another thread).
[0]: https://www.nativescript.org/
[1]: https://www.nativescript.org/blog/using-workers-in-nativescr...
[2]: https://api.dartlang.org/stable/2.0.0/dart-isolate/Isolate-c...
DISCLAIMER: Opinions expressed are my own and do not reflect my employers views.
https://techcrunch.com/2018/12/04/googles-flutter-toolkit-go...
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 with GUI nodes of native GUI toolkit.
So now going from each OS to another, you don't have to learn gazillion different ways to specify the layout. The type of nodes displayed on your GUI app changes from each environment to another. So you get to have the same programming techniques and you can get a web-app or a desktop app.
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 mess.
There is no simple and obvious solution that tackles all of the above. The reactive UI model (not just Flutter, but all React-like frameworks) is an ongoing attempt to do a better job of all of it, with varying success. Existing UI toolkits, before the introduction of this model, were not designed for it. They were built on the assumption that the future would be a giant object graph caught in a tangle of callback methods. If you want to make a reactive UI populated by native widget objects, you have to figure out how to plumb all their mutable state back into the reactive model. That's an enormous investment of labor. Writing a new toolkit from the ground up is a huge amount of work in absolute terms, but in relative terms it's the easy way out.
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?
not investing my time or effort into anything google has done until i know it wont be wasted.
I think they've made it pretty clear by now that they don't have intentions of switching from Dart. Heck, they've published an entire "Why Flutter uses Dart" article explaining their reasoning.
It's like beating a dead horse.
Besides, you could always just not use Flutter if you dislike it that much.
I guarantee to you that if they had choosen a proper modern language, Flutter's uptake would be much higher.
As it is, you will see many of us complain about Dart until Flutter ends up being replaced by something else, unless they force Android developers to actually use it.
"Fool me once, shame on you; fool me twice, shame on me"
I also would welcome an XML based, declarative approach to GUI. Makes cross-platform development even more easy.
Somehow I find it hard not to believe, that XML won't come back. One day :(
Honestly, the entire industry is shifting towards JavaScript/Typescript and the only language that they could think of for Flutter is Dart ?
This is even more Hypocrite knowing that Flutter doesn’t actually run the Dart VM, it uses AOT and compile to native code.
Meaning we could use literally any ECMAScript language to run with Flutter instead of Dart.
There is nothing that Dart does that justify the choice of this language.
Should have gone with Kotlin. Would just sweep over huge amounts of existing Andoid devs too.
I'm pretty sure if anyone was justified to create a new language here it would be those guys.
That's the whole point - you can't compile JS to fast native code. It also does use the DartVM for hot-reloading development cycles.
And in what sense it is hypocrisy to compile?