Google Flutter - What could be their reason for choosing Dart (over Kotlin)

Multiplatform
1

I’ve never understood Google’s decision to seemingly simultaneously push for Kotlin on Android and at the same time, introduce a completely new (or at least to that date pretty unknown) language for their cross-platform framework. It really seems as if they are cannibalizing on their own platform.

I recently looked at the Flutter website again, and they advertise that with this framework, it is now possible to develop web-apps, Windows-apps, Linux-apps, iOS apps and Android apps with mostly the same codebase. So if all that is really as easy as it looks, it’d be awesome!

But on the other hand, multiplatform is exactly what Kotlin is striving for, so why on earth did they choose Dart? I think anyone registered in this forum will know of the (theoretical) advantages there would have been if they chose Kotlin for that.

So there must have been even better reasons for Google to use their own language rather than to (re-)use Kotlin. But what do you think, what reasons could these have been?

10 Likes
2

Google has a history of throwing things at the wall and see what sticks. They also have a history of axing things that did not stick.

12 Likes
3

I wouldn’t be much surprised if the 2 choices were made indipendently by 2 different groups of people, Google is a big organization with lots of people and teams with different goals.
I don’t know Flutter, so take the rest with a grain of salt; I imagine flutter can’t really do everything you can do with the “native” java API, so they need to keep Java/JVM around, after all they write the framework itself in Java, so whatever new feature/API will have a java API inially and then flutter can play catch-up with that.
Furthermore Google and Oracle had some serious legal issues around the usage Google has made of Java, so Google on one hand has to keep Java as 90% of android is written in it, BUT if they switched to kotlin and provieded a user facing API which is just kotlin they might solve some of the outstanding issues with Oracle.

So in the long run they might have Kotlin as the android API and Flutter as a higher level language for multiplatform.

2 Likes
4

When they decided to use Dart, Kotlin Native was not ready.

2 Likes
5

The Android part is not quite correct - Android is mostly C++. Android apps on the other hand, yes, run in the JVM (if not built and/or compiled to native code). That doesn’t mean they cannot live alongside Kotlin and go away slowly without any significant friction. Google does not have to keep Java around, until Kotlin really catches on.

1 Like
6

That’s very correct and many people fail to realise that. Then they find themselves using abandonware.

I, for one, would not trust something built by Google alone - not because of the quality, but because they’re not committed to making a real product out of it.

2 Likes
7

I did not mean to qualify whether they will axe flutter or Kotlin. Anyone of those is fair game to loose Google’s support. However your argument is valid: thankfully Kotlin is not developed by Google. They are just supporting it, and loosing that support would not be the death of Kotlin. Flutter, on the other hand, would probably not live on without Google’s support.

8

Yeah, I was touching on a broader subject - devs tend to jump on board with new tech right away and it’s the downfall of many projects. Kotlin (like Swift) seems to have crossed the maturity Rubicon now, so I’m not concerned by Google’s support or lack of thereof - I’ve just chosen it for a backend microservices project and it seems to be working really well.

3 Likes
9

Same here. Kotlin + Ktor for REST API is a great combination. Compared to Java-based projects of similar magnitude I worked on before, Kotlin’s code is much more succinct and readable.

10

Kotlin and KMP (Kotlin Multi Platform) are made by Jetbrains. Flutter is made by Google.

Flutter aims to share code between platforms even on the UI level. KMP does not, it’s for sharing logic only. Which is a bad or great thing depending on if you like or hate cross-platform UI code.

11

Haven’t used Dart/Flutter yet, but programming UI for the Web with JS/React etc could count as cross platform UI code and I can definitely say that I like/hate it :wink:

12

I have read most of the comment and I am consigned. I am a newbie in Kotlin and now I am having second thought in learning it. Will kotlin. Be as big as Java, c, JS, or even python. Or is it going to be as “go”

13

I’d say if you come from Java, it’s bliss. It’s the “better Java”, everything seems easier. However, it is also more complex overall and there is a functional programming component one needs to get used to first to understand it all. So yes, Kotlin is “as big as Java etc.”.
As for Dart, I always saw it as “a better JavaScript” but it is also as complex or more complex than JS (disclaimer: I did not do any proper programming in Dart yet).

So, depends on what you want to do. If you want to do some app, maybe try Dart/Flutter. If you want to learn a more general-purpose language (but also do an app), maybe Kotlin. That’s my opinion on that.

1 Like
14

As for Java and JavaScript, nothing will ever be as “big” as those (in foreseeable future). Those are not just languages, but platforms and eco systems.

For example Kotlin-JVM, Scala, Groovy all contribute to the Java eco system and make it more popular.

Kotlin-Js and Typescript contribute to JavaScript’s popularity .

Every Kotlin-Jvm developer will end up on Stack Overflow asking Java/JVM specific questions, contributing to it’s popularity.

Modern language ratings are not capable of distinguishing the languages and platforms.

So, if the question is whether Kotlin will come near Java/JS in language ratings, then I would doubt that. At the same time though, this is not a very important question to ask in my opinion.

I would first choose a popular platform , like JVM or JS Node etc. Then I would choose on that platform whatever language I like more.

8 Likes
15

From my point of view, this is how I understood it.

At first, Dart was developed as a replacement for javascript. It didn’t succeed in gaining sufficient traction and was close to being abandoned. Flutter was the way for the team to survive.

So it was not the choice of a language for the Flutter team but the choice of a project for the Dart team.

16

As someone that does Kotlin Multiplatform mobile as my day job and Flutter on the side I feel uniquely qualified to weigh in on this.

The first thing that must be made clear in any discussion on cross-platform mobile development is that XCode, iOS storyboards, and Swift REALLY, REALLY SUCK!! They are absolute torture to use. And I mean torture in the sense that they should be outlawed by the Geneva Conventions kind of torture. If given a choice between XCode/Swift development and water boarding I would suggest water boarding. And note that 10 years ago I used to do iOS development in Objective-C but that was not cross-platform. Realize that anything Apple does is not to make your life better, but to lock you into their ecosystem.

On the other hand you have Kotlin which is a pleasure to develop in. You have excellent tools in Idea/AndroidStudio, though I understand people who wish for VSCode support.

So where does Dart/Flutter fall here. Dart as a language I would put in between Java and Kotlin. It is better than Java and while it has recently moved closer to Kotlin with things like null-safety and extensions there will probably always be a gulf between it and Kotlin. Some of the notable things separating it:

  • semicolons: Seriously sucks to have to terminate every line
  • Inferior lambdas: Syntax is closer to Java syntax. No implicit it, no lambdas with receivers, no putting a lambda outside the parentheses
  • No function receivers. While they do now have extensions it is not as powerful without this
  • Primitive enums, they are just names for integer constants
  • No reflection at all
  • No data classes

Some of these are worked around by builders that can generate code for you, which works but is sometimes cumbersome and I would choose Kotlin over that any day.

So with KMM you end up writing your common business logic in Kotlin. You have to write your UIs separately. For Android that is not too bad as you are still in Kotlin. For iOS that means submitting to the torture of XCode, Swift and Storyboards. Storyboards are a nightmare on a team as they are the source of indecipherable merge conflicts. There are also difficulties here because the way Kotlin is exposed to Swift in often less than ideal. You can use SwiftUI (if you don’t want to support older devices) which improves things a bit, but I am less familiar with it, though we are moving to it on my project. If you need platform-specific code you can also do that in Kotlin.

So by lines of code probably 60% of your code is the common business logic, 15% Android UI, and 25% iOS UI. That is by lines of code, by development time the iOS side is probably 50%.

There are 3 major pieces I see that differentiats Flutter in this discussion:

  1. A cross-platform, declarative UI framework that is built on top of Skia that allows building the UI once and still achieving a native look and feel. This is Flutter’s killer feature
  2. A mechanism to make calls to platform specific code. The is done through channels where data can be sent back and forth, which is sort of like API calls to a server. You have to provide serialization/deserialization on either end and the two ends do not share common memory. But to write that Platform specific code you are using platform-specific tools and languages (Java/Kotlin on Android and Swift/Objective-C on iOS)
  3. An incredible hot reload functionality that makes changes to the running app without even doing a build. Just save the file and it can show up instantly in the running app.

1 and 3 are the big plusses here for Flutter. Number 2 along with Dart being an inferior language to Kotlin are minuses in comparison to KMM. So can you put up with an inferior language and harder platform-specific code (which is rare) to get the benefits of 1 and 3.

What I want to see is #1 the cross platform UI framework in KMM. I would gladly give up #3, the hot-reload technology in order to get this. Jetpack Compose is very much like Flutter’s UI framework, but is Android (and soon desktop as well) only.

But the thing is there is actually nothing stopping a team from being able to accomplish this. Flutter is open-source and there is nothing stopping anyone from porting that UI to be KMM based. Or alternatively, Jetpack Compose could be extended to include UI for iOS.

If I had that ability to do cross-platform UI in KMM like I can in Flutter and never have to touch Swift or XCode, I would never write another line of Flutter. That would be the best of all worlds. Unfortunately, I know I am too old to take on such a project.

10 Likes
17

I love your post, thank you for your insight!

I used to do some iOS programming myself and I have the same experience with storyboards. Hopefully Swift UI will make things better.

Do you have some experience with Jetpack compose and Swift UI? Is Jetpack compose similar to Swift UI, (even if just concept-wise)?

18

I have not done any Jetpack Compose and Swift UI personally yet (will eventually) but have done some investigation and they are both very similar to Flutter in that they are a lightweight, declarative, immutable UI . Instead of widgets that have mutable state, widgets are lightweight and immutable and when state changes you rebuild the UI. It is also similar to how React works.

Some people fear that Flutter and Jetpack Compose (not sure about SwiftUI) do not use the native widgets and instead are rendering them will lead to non-native look and feel. I find they actually render better than native and allow for more customization. Also not being a slave to the differences and bugs between versions of the native widgets is a big plus. The way your flutter UI renders will look and behave the same on any version of the device.

The difference from Flutter is that they are not cross-platform. So yes very similar concept-wise but the ability to only write in Flutter and target both platforms rather than coding in both Jetpack Compose and redo it in SwiftUI is a win for Flutter.

Jetpack Compose and Swift UI have some neat tricks regarding how only parts of the UI are rebuilt when state changes, where that is a bit more explicit in Flutter, but Flutter with Riverpod library is now a bit less explicit.

1 Like
19

Just a small side note:

It’s a big plus for Flutter that it has a platform-independent UI framework, and I don’t care whether components are rendered natively or not as far as users are okay with it.

However, there is also a considerable minus for Flutter. Generated binaries are huge comparing them to Kotlin/Swift counterparts.

I’m already receiving a lot of feedback to decrease the size of my app (~30MB). It comes with a lot of features and the size is one of the costs. I would never use Flutter for it because it would piss even more users.

20

Size can be a bit misleading sometimes and it is easy to incorrectly measure the size of a flutter app as explained here: Measuring your app's size | Flutter.

Looking at the size of a debug build or the size of the bundle sent to the play store are not representative. Since Dart is compiled to native machine language make sure you are not looking at a “fat” binary which contains code for all processors.

I haven’t checked sizes in a production app, but from what I know there is a bit of overhead say for a hello world app, but as features are added it’s rate of growth will probably be smaller.

Bottom line is that the app’s will be bigger but probably not as big as you think they will be and there are tools to combat that size and measure it accurately.