3 ms·

Please consider that many of us have been burned before. I've been in business for over 25 years now and I am still supporting several apps built with now forsa

Please consider that many of us have been burned before. I've been in business for over 25 years now and I am still supporting several apps built with now forsaken technologies. That includes a web app built with Dart back when Google claimed that its Dart VM would be bundled into every browser. Now, I like Flutter and I like Kotlin. Jetpack Compose is really nice. But if I am starting an app today and in a year or two, Google decides that developing two competing frameworks is too expensive, they'll discontinue one. If it is the one that I chose, I'll be sooooo bitter. So yes, right now, they're pushing both and they claim not to have a preference but we need some reassurance that it'll stay that way.

mdhb 2y ago
I mean we could take a look at where they are investing their own resources for multi platform development as one way of doing that. Ads is where the overwhelming majority of their money comes from. It’s all Dart (and Flutter specifically on non web platforms). They also just got done rewriting all of Google’s Earths UI in Flutter. It might be my ignorance but what multi platform stuff do they have in production with Kotlin?
- pjmlp 2y ago
  Ads is the reason Dart is still around, back when Dart VM was discontinued, they had just recently migrated from GWT into Angular Dart, and they weren't going to rewrite it yet again. Had it not been the case, Flutter team would never had reached for Dart.
  - mdhb 2y ago
    You say that and yet they continue to use it and are choosing to do so even when it means rewriting huge and complicated bits of software from scratch. What something from over a decade has to do with its value today I’m not sure.
    - pjmlp 2y ago
      One decade later, Ads is still one of the main reasons Dart matters to Google, that is the value. That alone would be enough, Google has plenty of internally used languages.
- ChrisMarshallNY 2y ago
  Reminds me of Microsoft’s Visual SourceSafe[0]. They sold it, but didn’t use it. They had their own custom, in-house tool. I’m a believer in eating your own dog food. On-topic, I write native (iOS, in Swift), so have no opinion, as I don’t use either tool. [0] https://en.m.wikipedia.org/wiki/Microsoft_Visual_SourceSafe https://en.m.wikipedia.org/wiki/Microsoft_Visual_SourceSafe
- kuschku 2y ago
  Quoting another user in this thread: > One datapoint is that Google rewrote their Google Docs app in KMM (which doesn't include UI, that's Compose Multiplatform), replacing their legacy in-house framework. They intend to write more of their apps in it. https://touchlab.co/KMP-at-google https://touchlab.co/KMP-at-google
  - ralferoo 2y ago
    Interesting take - the way you cite this as an example makes it sound like they rewrote it from Flutter to Kotlin Multiplatform, but the actual article doesn't seem to support that claim. It actually says: > Cross-Platform Evolution: Google Docs now uses KMP for shared business logic. Android, iOS, and Web are now more unified than ever. Which suggests to me that the code base for Google Docs had very little shared code between the different flavours, probably native code for each platform, and they've since done a refactoring job so that the Android code (that obviously would have used Kotlin) for the business logic is now interfacing with the existing native code for UI for each platform, and they used the KMP libs to do that. This seems like an entirely reasonable and sensible decision to make - they still have the pain points in multiple UI code bases, but the common stuff isn't now replicated in 3 different languages with 3 different sets of bugs. That's all good. However, I don't see any reason why you'd see that as a loss/negative for Flutter. Obviously they already had an existing code base that used Kotlin for the Android native implementation, so there were many advantages to promoting that to the authorative version shared across the others. Rewriting the whole project in a completely different language (i.e. shifting to Flutter and using Dart) would have been a significantly bigger undertaking, and likely would have introduced many more bugs by starting again from a new implementation rather than just refactoring an existing code base that had already been extensively tested. If you already have a project using Flutter, it'd be just as foolish to attempt to rewrite it in Kotlin Multiplatform as it would the other way around. The real question is what the best choice is for starting a new application? Having used Flutter quite a bit now and then looking at Kotlin Multiplatform, I can see that Flutter is great for smaller teams that want fewer developers and the ability to share as much UI code as possible, wherease Kotlin Multiplatform seems more suited for bigger teams who can have dedicated resources for each platform, because they've made the choice that they want to leverage platform-specifc features for each of their targets. For me personally, I dislike doing UI code, so I'm going to choose Flutter every time because I don't want to do that work multiple times. At the same time, I've found that doing UI work in Flutter on this project has felt more rewarding than every time I've had to do UI work before, because it's relatively easy to get some amazing results but you can also modify anything you don't like, as well as being able to read the source for the standard widgets if you want to base your widget on something similar.

mdhb 2y ago

I mean we could take a look at where they are investing their own resources for multi platform development as one way of doing that. Ads is where the overwhelming majority of their money comes from. It’s all Dart (and Flutter specifically on non web platforms). They also just got done rewriting all of Google’s Earths UI in Flutter. It might be my ignorance but what multi platform stuff do they have in production with Kotlin?

pjmlp 2y ago
Ads is the reason Dart is still around, back when Dart VM was discontinued, they had just recently migrated from GWT into Angular Dart, and they weren't going to rewrite it yet again. Had it not been the case, Flutter team would never had reached for Dart.
- mdhb 2y ago
  You say that and yet they continue to use it and are choosing to do so even when it means rewriting huge and complicated bits of software from scratch. What something from over a decade has to do with its value today I’m not sure.
  - pjmlp 2y ago
    One decade later, Ads is still one of the main reasons Dart matters to Google, that is the value. That alone would be enough, Google has plenty of internally used languages.
ChrisMarshallNY 2y ago
Reminds me of Microsoft’s Visual SourceSafe[0]. They sold it, but didn’t use it. They had their own custom, in-house tool. I’m a believer in eating your own dog food. On-topic, I write native (iOS, in Swift), so have no opinion, as I don’t use either tool. [0] https://en.m.wikipedia.org/wiki/Microsoft_Visual_SourceSafe https://en.m.wikipedia.org/wiki/Microsoft_Visual_SourceSafe
kuschku 2y ago
Quoting another user in this thread: > One datapoint is that Google rewrote their Google Docs app in KMM (which doesn't include UI, that's Compose Multiplatform), replacing their legacy in-house framework. They intend to write more of their apps in it. https://touchlab.co/KMP-at-google https://touchlab.co/KMP-at-google
- ralferoo 2y ago
  Interesting take - the way you cite this as an example makes it sound like they rewrote it from Flutter to Kotlin Multiplatform, but the actual article doesn't seem to support that claim. It actually says: > Cross-Platform Evolution: Google Docs now uses KMP for shared business logic. Android, iOS, and Web are now more unified than ever. Which suggests to me that the code base for Google Docs had very little shared code between the different flavours, probably native code for each platform, and they've since done a refactoring job so that the Android code (that obviously would have used Kotlin) for the business logic is now interfacing with the existing native code for UI for each platform, and they used the KMP libs to do that. This seems like an entirely reasonable and sensible decision to make - they still have the pain points in multiple UI code bases, but the common stuff isn't now replicated in 3 different languages with 3 different sets of bugs. That's all good. However, I don't see any reason why you'd see that as a loss/negative for Flutter. Obviously they already had an existing code base that used Kotlin for the Android native implementation, so there were many advantages to promoting that to the authorative version shared across the others. Rewriting the whole project in a completely different language (i.e. shifting to Flutter and using Dart) would have been a significantly bigger undertaking, and likely would have introduced many more bugs by starting again from a new implementation rather than just refactoring an existing code base that had already been extensively tested. If you already have a project using Flutter, it'd be just as foolish to attempt to rewrite it in Kotlin Multiplatform as it would the other way around. The real question is what the best choice is for starting a new application? Having used Flutter quite a bit now and then looking at Kotlin Multiplatform, I can see that Flutter is great for smaller teams that want fewer developers and the ability to share as much UI code as possible, wherease Kotlin Multiplatform seems more suited for bigger teams who can have dedicated resources for each platform, because they've made the choice that they want to leverage platform-specifc features for each of their targets. For me personally, I dislike doing UI code, so I'm going to choose Flutter every time because I don't want to do that work multiple times. At the same time, I've found that doing UI work in Flutter on this project has felt more rewarding than every time I've had to do UI work before, because it's relatively easy to get some amazing results but you can also modify anything you don't like, as well as being able to read the source for the standard widgets if you want to base your widget on something similar.