Congrats on their 1.0 launch! I haven't looked too closely at Flutter yet, to be honest. How does it compare to React Native (besides what a basic Google search will yield)? Has anyone jumped ship for either or after trying one of them?
I'm guessing most answers will be about Dart being the hard pill to swallow for most, and the fact that it render by drawing UI instead of orchestrating like React Native.
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?
Dart compiles to native ARM binary; a colleague of mine who uses C++ for cross-platform mobile development made a demo app in Flutter, decompiled it, and said it looked like what his C++ apps produced. The JavaScript in your React Native apps won't perform as fast.
Comparison: React Native (and Xamarin, for that matter) use platform-native widgets with JavaScript composing the UI dynamically in the case of React Native (and UI's either dynamically composed or statically compiled with Xamarin -- depends how you build the app). Flutter brings it's own widget layer to iOS and Android (and Fuchsia?) so it's more like starting with a blank 2D graphics canvas and creating your own controls. Advantages: since this rendering layer and widgets are compiled from C++ the performance is excellent. Disadvantage: if you want a widget that isn't in the current set of controls and your C++ skills aren't up to the task, you'll be left wanting to do things you cannot. Not sure what scenarios are affected by this but it's something to keep in mind.
The widgets are written in Dart, not C++. If you need a new widget, you would write it in Dart, which is the same as the application language. This contrasts with React Native, where new widgets/views would be written natively and wrapped in React Native.
I’m going to be a little bit pedantic, but that’s untrue. On React (DOM, Native…) you create your widgets with React, and compose them as components.
If you need to go deeper (for some specific perf issue, usually for animation stuff) then you go native. But it’s a second class approach — well, it has first class support and is not as “second class” as it is for example in Titanium or “completely out of scope” in Cordova.
Flutter renders the whole UI, like a game engine. In the past, this has meant that if there isn't a Flutter implemention of a component (like a video player or map), you couldn't add it to your app. I don't know if that's still true.
Correct. The XBMC/Kodi UI was developed with game engine tools for the xbox, and the way the UI worked the screen redrew at 60fps, or whatever, whether the content on the screen changed or not.
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.
I hated this about CoronaSDK (how the framework would render everything like a game engine to one canvas). It was so much harder to debug things if the only way you can debug components is only within the scope of the framework, and you don't have any of the benefits of using the native views/containers. This means you can't effectively use Appium or UIAutomator or anything nice like that. If Flutter does render everything like a canvas, then that will pretty negatively affect my impression of it.
That's modern development for you. Shipping a copy of Skia so you can render exact facsimiles of Android widgets to a Vulkan context and avoid having Android render Android widgets with Skia to a Vulkan context.
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).
For bonus points you've probably broken accessibility on many platforms as the way that a11y works is intrinsic to the native widgets used by a platform.
I wouldn't assume that. It's literally the number one thing people bring up with custom UI components, I'd be very surprised if Flutter ignored the issue.
Oh I'm sure they didn't ignore is, just that you're constrained to platforms that allow a side-channel mechanism to expose a11y and handle focus+navigation.
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.
They shown the integration today. Its so cool you would be blown away if you saw that history of everything app demo. I am not able to find the demo app. Its in the live stream.
The widget layer is written in C++ (Skia). There's no reason the Flutter toolkit couldn't be quickly adapted to Linux. Or FreeBSD. Or Windows, macOS, OS/2 or even Windows Mobile.
Google has a history of introducing products and then killing them. For developing mobile apps they currently support "vendor native" via Android Studio using Java or Kotlin, Progressive Web Apps, and now Flutter.
Will Google really support all three over the long term?
If you consider APIs that power its businesses, Google's support history is a lot better. Dart and Closure were never popular outside Google, but they're still invested in because they are used internally.
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.
A Java fork failing to keep up with standard Java, winning on where Microsoft failed (aka Google J++), thus forcing Java library authors to either write two versions or constrain themselves to the common subset.
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.
Maybe that's not that bad, considering the fraction of Java libraries that used simultaneously in Android and Java ecosystems isn't very large. OTOH if Fuchsia wins, we loose the open source mobile OS, the major one, the only one, with tons of apps and ways to ungoogle.
I want to note that Dart and Flutter are being used for Fuchsia it seems like[0]. I'm pretty sure that Fuchsia is a big project Google is not going to abandon so Dart and Flutter are probably safe.
There is the chance of them throwing it away maybe noting it as an experiment on the way to whatever they land on inside Fuchsia but the amount of developer ire they would draw is hard to imagine.
Fuchsia is to Google as Tizen is to Samsung... something keep in the back pocket for a worst-case legal total war, but unlikely to see any real world use.
Really? but Fuchsia isn't just a mobile operating system -- I think they want to own all the software at almost every level. I wouldn't be surprised if they started running their own hardware and laptops with Fuchsia as well if it was good enough.
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.
> If they try to pull that off, all their partners will drop them like a hot potato.
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...
Lets put it this way, Google already made most of the work with Treble and yet it isn't being adopted as they thought it would, making them finally take a stance regarding updates.
Looks cool but not too much of cross-platform - iOS and Android only. It seems the only really cross-platform GUI technologies still are browser-powered and Qt.
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.
"I just don't trust it to be around long enough to be an investment for me."
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.
Flutter is Dart's killer app, and don't think it's unmaintained. Dart 2.0 came out pretty recently with some much needed improvements, probably driven by Flutter.
AdWords previously used GWT, which is no longer maintained by Google. I get the feeling the AdWords team just really doesn't like JavaScript, which is understandable, but it doesn't say anything about whether AdWords will stick with the current non-JavaScript language du jour or move to another.
7+ years from early 2016, which means 4+ years today. Take it as you will.
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.
All technologies will get replaced by something else eventually. Presentation technologies have a short shelf life. GWT is 12 years old now, that's quite a good run.
History here is a bit important. GWT existed before jQuery was a thing. GWT was created for 2 reasons (from what I can tell): remove cross-browser differences and simplify development for a team that was already using Java.
That's factually incorrect. Development of Dart for the Web has never stopped. AngularDart is still officially supported, and under active development.
> Dart (the lang used in Flutter) already failed to gain traction in the web dev community and nobody seems to be maintaining it there.
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.
You're missing the point. OP asked what would happen if Google abandoned the project, and it's pretty obvious Dart would die as it being maintained by Google, not the community.
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.
I wasn't talking about Tcl/Tk's current state, but about the similar situation it "enjoyed". It, too, had a pretty large community, which quickly went on too greener shores. User base is much more fickle than one might think.
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.
As the darling of the tech community? I very much doubt it will make another 5. Everyone I know seems to be starting greenfield projects with Vue. And I would be shocked if there wasn't some revolutionary new thing I've not yet heard of waiting in the wings.
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.
I wouldn’t start a greenfield project with Vue and have no draw toward it. I’d go React. I think React/Vue are the end of the road in terms of JS, Vue for people who think tooling is hard, and React for people who don’t mind the tooling.
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....
The widget layer of flutter is Skia which is written in C++ and Flutter apps compile to ARM binary (native) code. Someone else asked about whether a Flutter app can be ported to Linux; why not compile both the logic and the UI directly to WebAssembly?
WebAssembly compilation is a little orthogonal to getting the framework and rendering system up and running. We do not have to wait for WebAssembly to make progress on the UI side of things. Having said that, when WebAssembly is available for us to try, we certainly will.
I haven't used either, but Kotlin is a programming language you can use on Android -- it's essentially another JVM language as an alternative to Java -- whereas Flutter is a UI toolkit you can use on multiple platforms (mobile and desktop), think of it as analogous to Qt.
There are plenty of languages that compile to fast native code, some of yore (Common Lisp/Eiffel) even offer that amazing live code experience that they sell as unique Dart feature.
I'm not a fan of Dart either, but common JavaScript/TypeScript isn't exactly the holy grail either. JS is basically unusable due to, well lack of types, and TypeScript hacks them into it by hugely increasing complexity of everything.
Should have gone with Kotlin. Would just sweep over huge amounts of existing Andoid devs too.
Flutter looks cool. Dart needs more of an ecosystem though. I was trying to play with flutter last week, gave up when I discovered there is no standard lib FFT implementation in Dart.
I disagree. Something rarely needed like FFT should not be included in any stdlib. Keeping it out too allows better control and more frequent releases.
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.
Haven't tried Flutter yet, but I feel the same way ever since React/Vue hot reload. It's a game changer. I really really miss it whenever I'm working on a site or game that doesn't support it. Once you get used to it, it feels painfully slow developing without.
in today's keynote, google announced that you'll eventually be able to use one dart/flutter codebase for ios, android, mac, windows, linux, and the web. you can't get much more cross-platform than that.
I am aware that you can build one codebase for all those platforms, the question is whether all those platforms are supported. In particular https://github.com/google/flutter-desktop-embedding still says that desktop use of flutter is unsupported.
DISCLAIMER: Opinions expressed are my own and do not reflect my employers views.
It's strange to me that after all this time, every time a thread about Flutter reaches Hn or proggit, there are multiple comments about the choice of the Dart language.
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.
Their whole reasoning just feels like justification after fact. specially when one has experience with older development environments which offered similar developer workflows.
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.
You said you can't be bothered to learn dart because you want to build your skills in c# etc. As a result the only criticisms you can make are devoid of content: It's not a proper, modern language (what?). It's struggling for survival...
Sure, you do what you want, no one is stopping you.
But I guarantee you'd be amazed of just how quickly you could go from installing the Flutter plugin into VS Code to actually developing a fully hot-reloaded app inside an iOS emulator. The DX of Flutter is by far the best I've seen anywhere.
Given the number of times I've seen pjmlp complain about Flutter choosing Dart. I think he/she could have learned the language in less time than writing all of those comments.
Writing plugins/bindings for native code in flutter doesn't look fun. Almost 100 lines of code to write binding for function that doesn't take any parameters and returns simple 'int' (int getBatteryLevel()). This just looks even worse than JNI to me. Don't want to even thing how long time it would take me to write bindings for function that do image processing.
https://github.com/flutter/flutter/blob/master/examples/plat...
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.
> 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.
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.
I have recently gave a look at Qt after 5 years and it seems lots of things have changed for the better. You get the same hot reload like flutter when modifying GUI using QML (with V-Play you can even hot reload not just on simulator/emulator but on real device). Qt material theme has good look and feel. Sadly iOS theme is a little bit lacking.
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.
Try to download it from qt.io. You will have to go through several screens saying "Are you sure you are able to comply with the LGPL? Wouldn't you rather get the commercial version for peace of mind?". If that isn't an implied threat, i don't know what is.
I don't approve of that tactic (in fact it drives me nuts), but I will say, Qt's license fees are quite reasonable, and then you get to link statically with no risk of violating the GPL.
Reasonable? It's about $500 / month / developer with additional royalties if you are shipping devices with Qt firmware. Sure I think Qt/QML is the best UI toolkit available but this crazy pricing is driving me towards any possible alternative. So I'm really hoping Flutter will take off (for desktop/embedded as well, not only mobile).
Note that Qt is GPL3 nowadays so you can't really ship embedded devices with Qt without paying.
Actually what I predict is the return to shareware/public domain models, where the free software is only the tip of the iceberg of the stack one actually needs for production code.
The trend is already visible with SaaS, Cloud, IoT,...
Ok I'll admit I'm not familiar with medical certification. I know that the so called Qt Safe Renderer for ISO26262 compliance is a bit of a joke at least.
I have seen two very big Qt projects being cancelled due to Android. Not the Android Auto app but native Android for IVI.
I don't see any indication of your vision for shareware. The trend is towards more and more software being licensed under licenses such as MIT.
Actually Trolltech was doing pretty well while selling Qt (which was full GPL at that time) for a fixed price per major version.
Then Nokia bought it and made it LGPL because they were planning on using it as the foundation for (some of) their mobile phones. Unfortunately, they couldn't decide which phones and went on a downwards slide.
Then Microsoft bought most of Nokia, and Qt got spun off into an enterprise thingy that takes their sales tactics from Oracle. Yes, I know the LGPL allows me to link dynamically for free, no, I don't trust Digia not to sue me for that.
Their pricing is also out of reach of anyone who's not in an industry that charges an arm and a leg due to regulation or niche.
I don't like this but I also kinda understand why they do so. Many devs around me (I live in Korea) don't care about GPL/LGPL and it is important for Qt to let them know. Qt is commercial software anyway.
> On mobile? Qt really isn't pleasant or usable on mobile.
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.
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.
I came to the same conclusion (and I'm not a big company that can afford Qt), so I built my own. Before Flutter got a new team @ Google ~3 years back, it was a set of tools for building cross-platform apps with C++ shared libs. A few years ago, this is what many of the FAANG companies were doing with their apps. Then, React Native was released and (I guess) the management at Google decided to take a different tack.
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
I have been a freelance Android Dev for past 4 or 5 years. I have recently built out a flutter app for a client. And honestly I am now looking for more Flutter work.
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.
I haven't touched Android development since 2012. I remember the experience being a terrible hodge-podge of XML and Java which effectively required an absolutely attrocious IDE and an impossibly slow emulator. I assume things have changed since then, but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Those are still the not fun parts to work with in Android, although its better now kotlin extensions so you no longer have to refer to the XML directly to manipulate views.
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.
Your layouts & styles are typically all in XML. But honestly I don't find it bad - it's not "proper" XML, so there's not a ton of cruft. It's really more like XHTML.
Dart is "Fine" is the perfect description. It is pretty basic, but pleasant enough to use that it doesn't get in the way.
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.
One of the main issue with Flutter is that you can't embed a native view inside a flutter widget tree. This makes it limited as we can't have inline maps or custom video views.
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.
Cross-platform frameworks that don’t use native controls have suffered from problems...
- 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).
>- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users.
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).
Given the usage of e.g. and offering the most charitable interpretation of coldtea’s comment, I guess it wasn’t supposed to be an exhaustive list, just the first (or most pervasive?) thing that came to mind.
Same in the desktop world - Qt emulates the widgets, but can theme them, then QML is another story. Also WPF (from what I've heard) uses (skia?) to paint own widgets. IMGUI is another example.
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.
To be fair, just because bigs use their own frameworks doesn't mean they produce great UX. There's an added learning curve to any non-native app that users incur when this happens - things are out of place, don't work as expected, features don't exist, etc. For example:
- 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.
Well, such things are causing subtle annoyance for users. This works as long as the value you provide is good, but the more and app is just a bad we view the more likely it becomes that people uninstall it or look for alternatives. Unsurprising consistent behavior is a value.
They do care. Try writing a DOS or Blackberry-style app today and see what happens. Software today has internalized the idioms so much that its developers don't even realize it.
"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.
>They do care. Try writing a DOS or Blackberry-style app today and see what happens.
Nothing much. Some of the most downloaded and bought apps (desktop and mobile) have horrible custom UIs. As long as the app has the crucial functionality, few care. And I'm talking for average users.
As for pros? Well, vim and Emacs are DOS style apps (well, in that they use curses and totally un-native GUI paradigms), and they're still strong.
UI concerns of that level only matter when apps otherwise have marginal utility and small other differences with competitors.
Sure but lets not forget the single most successful consumer product in history (iPhone) owes much of its success to it's clean, consistent UX across a suite of built-in apps. More people probably use those than downloaded apps.
1. People regularly complain about inconsistent web UI.
2. Even web apps often have similar idioms and patterns to their UI that they've settled on. It's their own patterns that are different from desktop OS, it's basically another category.
3. Most web apps are used on desktop, not mobile. On mobile, it's mostly native apps that are used. So they're not substitutes.
Honestly, I expect from a web page to be shitty. I'm surprised when some web page aren't slow, unresponsive, or doesn't distract me with million designer quirks.
My expectations are different with mobile apps. If I'm spending some time to find the app on the app store (and maybe pay for it) and giving the app a place and a storage on my phone, I'm expecting from the app to be polished and give me pleasant experience.
Agreed - I never could quite understand that argument and what is so intuitive and familiar with native UI controls when looking from perspective of a new app to the user. Depending on the app functionality, achieving good UX could be very hard and sub-optimal using only native controls, and impact of a well-thougth-out flow through the app, specialized controls where helpful and polished design should not be underestimated...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. Not to mention how often people want something different and fancy over "boring" bland look of native controls...Granted, there are a lot of small usability aspects and behaviors to consider, as pointed out by others.
> I never could quite understand that argument and what is so intuitive and familiar with native UI controls when looking from perspective of a new app to the user
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
These are all excellent points. I'm curious how Flutter stands to address these risks/issues in the early days.
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).
It helps that the Flutter and Android teams can talk to each other (they're both part of Google). So atleast for Android, you might be able to expect Android platform features appearing on Flutter in sync'd release cycles.
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.
Only one team needs to sync with another in this scenario.
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.
If only one team needs to sync, how is it any advantage for Flutter and Android to be within the same company? How is the situation any different from Flutter and iOS?
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.
There's one place where none of this matters: Games engines.
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 ...
Game engines are a place where it makes sense to roll your own UI framework many times, so on that point I agree with you. The purpose of a game is generally immersion and escape, so makes sense to remove users from their device's UI in many instances. Game UIs tend to have their own conventions so frequent players don't have much of a learning curve. But in general players accept some learning curve because games are about taking on a challenge.
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.
There are so many aspects of modern UI that are not functional, and serve only to distinguish one platform from another in the wider market-place - so I feel that your statement that the OS-provided UI is a 'tool' is misguided. There is nothing tool-like about making me wait for a swipe scroll to complete - this is a game mechanic designed to entertain.
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.
Let me restate what you're saying to see if I understand it:
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.
These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory).
>> - 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.
> 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.
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.
>... but I feel these are not really issues in practice (only in theory).
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...
I share your concern regarding text fields. That's the one area where I never want to mess with native behavior. The search results for "flutter ios text field copy paste" aren't encouraging.
> "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."
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.
How does flutter handle BLE/WiFi communication to hardware, rendering graphs, NFC, device sensors? Any comments on the experience? Do you recommend it?
Don't think there are builtins for that, Flutter is more focused on drawing UI. For functions like these it usually just makes sense to call the native APIs over a bridge (there's a bridging mechanism included in Flutter - you pass messages over channels to and from the native code).
I've been using Flutter for a little over a year and I absolutely love it. Hot reloading, Dart tree shaking, Static type checking, etc. What's not to love? Dart widgets are consistent, making UI design easy peasy. UI widgets are definitely skewed to Android (for now), but iOS work is moving quite fast.
342 comments
[ 3.2 ms ] story [ 227 ms ] threadI 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://webdev.dartlang.org/articles/performance/event-loop#...
If you need to go deeper (for some specific perf issue, usually for animation stuff) then you go native. But it’s a second class approach — well, it has first class support and is not as “second class” as it is for example in Titanium or “completely out of scope” in Cordova.
[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.
In this aspect it's very similar to Flash or QT.
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.
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.
You also don't get to use the wealth of libraries that target native development.
Cross platform always has trade-offs.
Anyone has any experience with how well those work with React Native, and could share their experiences?
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.
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.
https://source.android.com/devices/architecture/hidl
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...
https://android-developers.googleblog.com/2018/11/an-update-...
https://techcrunch.com/2018/12/04/googles-flutter-toolkit-go...
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...
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.
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.
And Google hasn't maintained it for five years now, which is the point.
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.
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.
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.
X-Windows? That thing started life more than 30 years ago, and still going strong on Linux.
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....
That's where it's best to explore and take chances. The only risk is wasting time.
And web: https://medium.com/flutter-io/hummingbird-building-flutter-f...
Could someone explain the difference between Kotlin and Flutter given that they are both being pushed for app development now?
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.
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.
Should have gone with Kotlin. Would just sweep over huge amounts of existing Andoid devs too.
And in what sense it is hypocrisy to compile?
I'm pretty sure if anyone was justified to create a new language here it would be those guys.
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.
DISCLAIMER: Opinions expressed are my own and do not reflect my employers views.
in the google keynote today, they revealed that the app they were using for showing slides was a flutter app running on a mac.
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.
React Native uses a programming language widely accepted, no need for complains.
C# was just an example of a language that is actually worthwhile to have on a CV. I could have given many other examples.
Ad Words team rescued Dart from certain death and Flutter it is attempt to come play into the ring.
I already jump between a few languages on a daily basis but it's getting ridiculous especially when it's related to fairly mundane UI work
in reality it's yet another x-platform 2d ui framework, who cares.
But I guarantee you'd be amazed of just how quickly you could go from installing the Flutter plugin into VS Code to actually developing a fully hot-reloaded app inside an iOS emulator. The DX of Flutter is by far the best I've seen anywhere.
So no surprises there.
"Fool me once, shame on you; fool me twice, shame on me"
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.
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.
What's wrong with it?
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.
Note that Qt is GPL3 nowadays so you can't really ship embedded devices with Qt without paying.
They are pretty cheap considering the typical prices on their target markets, embedded tooling, medical devices, enterprise solutions.
Naturally they decided to pivot to those markets, as Trolltech has hardly seen any significant monetary profit from FOSS.
So it is only fair that those that don't want to pay, also ship code free to the others.
I will use a free UI toolkit when I can. Qt will kill itself with their current pricing model.
Automotive is moving towards Android. Qt is not good for medical either because it is not really certifiable.
The trend is already visible with SaaS, Cloud, IoT,...
Qt is certainly certified for medical use, https://www.qt.io/qt-in-medical/.
I have hardly seen any big Android Auto adoption.
The biggest foe of Qt in Automotive is Web stack.
I have seen two very big Qt projects being cancelled due to Android. Not the Android Auto app but native Android for IVI.
I don't see any indication of your vision for shareware. The trend is towards more and more software being licensed under licenses such as MIT.
Which is exactly my point.
Give the tip of the iceberg for free, charge for everything else and give as little back to upstream, if anything.
Then Nokia bought it and made it LGPL because they were planning on using it as the foundation for (some of) their mobile phones. Unfortunately, they couldn't decide which phones and went on a downwards slide.
Then Microsoft bought most of Nokia, and Qt got spun off into an enterprise thingy that takes their sales tactics from Oracle. Yes, I know the LGPL allows me to link dynamically for free, no, I don't trust Digia not to sue me for that.
Their pricing is also out of reach of anyone who's not in an industry that charges an arm and a leg due to regulation or niche.
Yum install qt5-
https://github.com/qmlnet/qmlnet
note: I'm the author.
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.
https://github.com/flutter/flutter/blob/master/examples/plat...
I really hope flutter can provide a guide for FFI though.
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.
Use the right tool for the job. Always.
If Flutter can't handle it, it's not the right tool for the job.
The rest is UI and application boilerplate
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.
e.g. iOS HID requires navigation buttons for obvious reasons & not so for android.
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
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.
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...
- 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).
This is hinted at where I say "Google, Facebook, _and other top dogs_", and "_e.g._ Material UI" -- emphasis mine.
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.
- 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.
Nothing much. Some of the most downloaded and bought apps (desktop and mobile) have horrible custom UIs. As long as the app has the crucial functionality, few care. And I'm talking for average users.
As for pros? Well, vim and Emacs are DOS style apps (well, in that they use curses and totally un-native GUI paradigms), and they're still strong.
UI concerns of that level only matter when apps otherwise have marginal utility and small other differences with competitors.
A framework for mobile uses custom UIs and everyone loses their minds?
2. Even web apps often have similar idioms and patterns to their UI that they've settled on. It's their own patterns that are different from desktop OS, it's basically another category.
3. Most web apps are used on desktop, not mobile. On mobile, it's mostly native apps that are used. So they're not substitutes.
This needs some citation
My expectations are different with mobile apps. If I'm spending some time to find the app on the app store (and maybe pay for it) and giving the app a place and a storage on my phone, I'm expecting from the app to be polished and give me pleasant experience.
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.
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.
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.
>> - 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...
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.
Try it, you'll love Dart.