What is the off chance that Google will drop Flutter?
back
7 comments
If the Vala folks and Gnome in general could be convinced to drop Vala in favor Dart, or move valac in the direction of accepting a language that looks like (a subset or a complex supersubset of) Dart, it could be an effective hedge against Google pulling out. It would also be an instance of Gnome and the various commercial vendors who rely on it being ahead of the curve—particularly for mobile, while proprietary vendors are still left dealing with the legacy of Android, Dalvik, and Java.
> Gnome in general could be convinced to drop Vala in favor Dart
I would be very surprised if that happens.
The last time I checked it seems that if anything changes then that bit-by-bit some components get replaced with new ones written in rust.
Also I honestly would be very surprised if Gnome would move from gtk-based UI to a flutter based UI interface.
I mean besides political reasons the amount of rework you would have to do is probably in a degree which makes it unpractical.
And in context of libre5 and some other developments there was a lot of effort to make gtk-based UI ready to be used with handheld devices.
Gnome is already adopting Rust, and GJS has been the Vala alternative for ages, so no luck for Dart.
Also Gnome has had multiple language bindings since the early days, most of them have more use across Gnome apps than Vala.
> Gnome is already adopting Rust
That's not accurate. There are some Gnome contributors opting for Rust. Gnome is not adopting Rust.
GUADEC Rust meetings and the GStreamer improvements show another picture.
No, the picture is exactly what I just described—that those contributors are using Rust.
So unless GStreamer isn't a part of Gnome, Gnome is indeed using Rust as well.
You mean the GStreamer bindings? And it would matter—some contributors could choose Rust, but Gnome as a project isn't moving to Rust. What aren't you getting here? Are you going to point at people using C++ or C# next? I'm done with this conversation.
This matters only if Flutter is a closed source project – but it's not. You can fork it on Github right now and continue working on it even if Google pulls its engineers off. I'd assume that those of us (and there seem be a lot of people) invested in it will continue working on it.
> This matters only if Flutter is a closed source project – but it's not
It certainly matters. Without a team of dedicated developers maintaining the project, the APIs it depends on will become deprecated, and it'll slowly become unusable.
Flutter touches a lot of APIs across many platforms. It's a complicated project that needs to support virtually every popular operating system in a visually and behaviorally consistent way.
Flutter also depends on Dart's maintenance, which is another project without significant open-source contributor activity outside of Google employees.
> I'd assume that those of us (and there seem be a lot of people) invested in it will continue working on it.
Having contributed fixes to Flutter and Dart, Google does not go out of their way to build an open-source contributor community around the projects. I would be surprised to learn that any significant support is provided by open-source contributors to Flutter or Dart.
> This matters only if Flutter is a closed source project
Nonsense. Even though it is open source, if Google drops it it will be effectively a dead project since the vast majority of the work is done by Google, and Flutter still isn't a mature project.
I like the architecture that Flutter has chosen where the only thing you need from the OS is a canvas and everything is painted by Flutter. It gets you a good programming model and predictable results regardless of target.
The downside is that in order to produce iOS or Android looking UIs someone needs to create every iOS and Android standard widget, with the same behaviour. If those widgets change in future versions of the OS, or new ones are created then more work needs to be done.
This is fine in the current project setup - the work is worth it to Google, but without a corporate backer that's the sort of thing that will fall behind.
It might make it even more interesting for some people ;-)
Only iff they drop Fuchisa.
And if they drop Fuchisa and flutter has enough (relevant) apps using it in the Android Ecosystem they probably would keep it still around.
But my guess is that one long play Google want's to keep open for them is to start replacing Android with Fuchisa and push for a ecosystem where they have control more similar to apple. I.e. directly push updates to phones without the phone manufacturer as middle man. As this is a source of a lot of problems with Android making it less competitive against iOs.
"Only if they drop Fuchsia."
I hate to say it, but this is beginning to look like a real possibility. It looks like Google has been implementing into Android a lot of the modular, "make the system easier to update" aspects of Fuchsia with each release of Android. I think Oracle's continuing fight to make Google pay financially for using Java is doing more to keep Fuchsia alive anything else. If Oracle relents then it's possible that Nest devices (the only Fuchsia-based products currently shipping afaik) could eventually switch to an IoT version of Android... but since Oracle is a litigation firm that also happens to sell databases I don't see them ever stopping the lawsuits.
If Android switch to openjdk like everybody else, they'll be lawsuit proof
They did: https://arstechnica.com/tech-policy/2016/01/android-n-switch...
The runtime remains ART, though, but that wasn't the issue in the lawsuit.
They did not, that article doesn't show the actual reality.
As one can follow up on AOSP Gerrit comments, code from OpenJDK gets cherry picked into Android.
https://android-review.googlesource.com/q/project:platform%2...
I had read that too and I do not understand at all. What is openjdk beyond a runtime VM ? They do not use what truly qualify as openjdk otherwise they would have C2 and G1 and therefore true java 8+ support, for free.
They're using the libraries - the part that Oracle is claiming is copyrighted. The java.* packages.
javax.* is copyrighted and is now copyleft if you use the jakarta.* namespace instead.
as for java.* I don't see how one could have issues, for example Kotlin use and extend the java standard library without any lawsuit. I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Their reimplementation (dalvik & ci) is the root of all evil and is technically a mess with antic java support. It's such a shame that we can't have ZGC or senandoah on android...
My hunch is that Google is trying to migrate away from Android. Flutter is both the abstraction layer to do that and the new SDK for the new platform.
If that's the case, it's higly unlikely.
I think Google realized they needed a compelling cross-plattform solution because React Native started to gain so much traction.
In terms of migrating away from Android, I think they will use the newer AndroidX packages as the future abstraction layer, which would enable them to replace the underlying runtime with something more native for each platform. It would be a compilation target for Kotlin as well as Dart. All while not deprecating the massive amount of production code out there. But, this is also just a guess.
That's a really wierd take if you actually look at what AndroidX is - it's a set of utility libraries to complement Android so it being some kind of abstraction layer is rather nonsensical. It's like saying boost is an abstraction layer for Linux and it allows its replacement. It's an orthogonal thing that doesn't stand alone.
Yes, it's a set of libraries under one package name. With Google's massive investment in refactoring it has a pretty big surface already, from persistence to UI and almost everything in between.
https://developer.android.com/reference/androidx/packages
It's current implementation uses classes that are part of the Android layer, mostly the old support library plus some new abstractions like LiveData and Room and Navigation. I see no reason why you could not use the public interface of that library as a compatibility layer for application level code and let it run on a different platform.
Not today, but given the fact that you can't just kill the worlds most used operating system, you either use virtualization like Apple now does again for ARM (and before when replacing Motorola with Intel) or you change the underlying dependencies of the libraries used and compile again.
That is more a defense move given that Kotlin cannot rely on Java FFI going forward than anything else.
Except that Android team hasn't got the memo, hence Jetpack Composer, and increased adoption of Kotlin multiplatform as a defensive reaction against Flutter hype.
Google not too long ago released Jetpack Compose which has some overlap with flutter so it's anybody's guess.
The level of redundancy between all these projects never ceases to amaze me.
I think being used with Fuschia is a good sign
It's not so much that they will drop it but they may loose interest in it and let it die off naturally. It all depends if they can convince enough people to use it. I've not actually seen or used any flutter apps yet. I'm sure they exist if you go looking for them but it's early days. Most stuff out there is not flutter based.
Google needs to work on untangling it from Dart and start actively working on Kotlin support. Dart is actually compiled to native code and the most of the UI stuff is basically written in C++. Kotlin has a native compiler already, so that's not necessarily a show stopper. And given the huge amount of Android Kotlin developers out there, it's kind of an obvious thing to do. Yet they choose not to work on this.
Fixing this would result in a lot of existing developers having an easy transition to flutter that are currently not planning to go there.
The reasons they are not doing this are entirely political and can be summarized as "not invented here".
Kotlin is a problem for them because it's 1) popular 2) the main language for Android development and 3) controlled by a company that is not Google.
Flutter is their attempt to fix this. They can't kill Kotlin because it's popular but they can try to replace it and nudge developers away from it. The problem for them is that Dart is not good enough. It's a hard sell and effectively a downgrade if you are used to Kotlin. They've been trying to fix that by adding features to Dart that are clearly intended to narrow the gap.
Fuchsia exists for the same reason. Yes there are technical reasons for it as well but the real reason is control over the ecosystem. The combined strategy is risky and dependent on the success in the market of their pixel phones. So far this is not looking great. Google convincing OEMs to jump on the bandwagon is going to be very dependent on them being able to launch a fuchsia phone. I'm pretty sure none of the OEMs is keen of having more Google control and oversight. So effectively, Google would have to launch a Fuchsia phone, make sure it becomes popular, and then twist the arms of all their OEMs to abandon Android. Failing to do that would result in a new phone platform with tiny marketshare that users, developers and OEMs can safely ignore. The mere prospect of that is the reason I expect it will never make it to market.
Flutter may or may not survive that decision. What's going to be interesting is what everybody else does. Flutter and react native are so far the two dominant cross platform approaches. React native could get a lot more interesting with things like wasm opening up that space for Kotlin and Swift developers. A lot of Kotlin developers favoring React Native over Flutter would be a big problem for Google.