Give it a year ...
... then it'll be dragged behind the bike sheds and shot.
Fancy a Flutter? Google is hoping users will take a bet on its new cross-platform mobile development framework, whose first beta was announced at Mobile World Congress last week. Flutter is based on Dart, an object-oriented C-style language developed at Google, where it was designed by Lars Bak and Kasper Lund. It was first …
About time they did this. Let's hope they learn from the mistakes of Xaramin.
Dart is a really good language, from what I've seen.
I think if they didn't try to put the VM into the browser so soon, then it wouldn't have had so much rejection by web "developers" who are unable or unwilling to learn anything beyond JS.
I don't see the point of this really, ReactNative targets both iOS and Android, has a couple of years head start, and, well, you know - actually compiles to Native code instead of crappy JS - hence the name.
Classic case of "not invented here so let's reinvent the wheel"...
huh? React Native is crappy JS. It doesn't compile to native - it just lets you call native code and use native widgets, from JS.
That's what Flutter (appears) to also do, except it's not crappy JS - it's optimised JS created from a "real" language... but they also have a native VM, which has been in development for at least 5 years.
Today every dog and cat design its own language to target its own platform, and maybe one nearby. Maybe more than one. Go, Dart, what's next from Google alone?
The landscape is fragmenting so fast, that every application not made from a single simple app risks to become a Frankenstein one made of several incompatible languages, libraries, frameworks and runtimes. Which will be obsoleted in a few years because some newcomers will feel the urgent need to come up with his or her new languages as well.
Look a very silly approach to me, especially as the sprout everywhere to care for the needs of a single company.
I've never understood the desire to stick to a single language. I like having a choice, just like you can go to B&Q and pick a certain drill based on your needs.
To me, Language is irrelevant, as long as it's the most suited for whatever it is I'm doing - unless I'm doing corporate work, in that case the one that's the easiest for others to learn.
It's not sticking to a single language - I fully understand the need for specific languages better aimed at different kind of applications, but I thing they're becoming too many, with people writing languages "compiling" to another, just because the already existing one doesn't have a very specific corner case feature they need to borrow from another one without which they can't really work.
This breeding of languages will become a maintenance nightmare in the near future, when people will have layers and layers of different languages because their fashion changes with seasons...
We have two Cordova apps, in the Apple and Google stores, "Jambuster" and "Jambuster Blackwall Tunnel". They provide personalised London traffic information and use a wide range of IOS and Android features. Both are written in TypeScript using Cordova and Ionic. Both work quite well. Whilst they aren't as fast as a native app, for us they're fast enough and look pretty native, e.g. dialogue boxes, notifications etc etc.
We also have a lot of plugins that work very well. The cordova plugin infrastructure is very important so unless this new framework from Google supports all the plugins, we won't be using it. We would also be concerned that Google will kill it in a years time leaving us high and dry. We've been burnt before.
We'll wait a year and see what happens. Let somebody else blaze the trail
The app for our local Bowls club changed recently so that is consistent across Android & iOS and they chose the iOS look and feel rather than native which means in Android they have broken navigation all over the place when you use the hardware back button instead of the back button built into the header ala iOS. The club has wasted hours of its staff time having staff show those used to the Android way of doing things how to do it the Apple way.
For the most part I don't either, but often the cross-platform toolkits fixate on getting the look right and neglect other bits like tabbing order or (system-wide) keyboard shortcuts. It's especially bad where those shortcuts are configurable and the native-looking application behaves differently only in some cases. We've been at this since Motif, wxWidgets, Qt, etc. Some more equal than others.
Google is unlikely to adopt Swift for Android because it has barely adopted it for iOS owing to terrible internal build tools: they're just not particularly equipped for client software, and especially not for anything that doesn't use the same compilers and libraries as their usual back-end. That flows against Apple's desire tightly to control and to bind the build tools and the IDE.
So internal familiarity with Swift is very low.
There is a presentation on Flutter from when it was in Alpha given by Michael Thomsen and Tim Sneath when they were in London in December...
"The idea is that a framework that simplifies building Android applications that conform to Google’s design guidelines will also benefit Android as a whole"
I understand the sentiment, but as I strongly dislike Material Design, I don't really want to see anything that makes its use more common.
Biting the hand that feeds IT © 1998–2019