Quick article about why Kotlin Multiplateform is b...

# multiplatform

[Nathan Fallet]

Quick article about why Kotlin Multiplateform is better than React Native and Flutter 😝
https://medium.com/@nathan.fallet/why-we-dont-need-libraries-in-kotlin-multiplatform-298053c79a77

[Cédric Bahirwe]

Absolutely loved this piece👏🏽

[Filip Wiesner]

JavaScript code can’t directly call native APIs, everything must be serialized, sent across the bridge, executed on the native side, and then the result serialized back.

I am not sure if this is completely true anymore since the "New Architecture". They mention this in their documentation.

The New Architecture removes the asynchronous bridge between JavaScript and native and replaces it with JavaScript Interface (JSI). JSI is an interface that allows JavaScript to hold a reference to a C++ object and vice-versa. With a memory reference, you can directly invoke methods without serialization costs.

[Filip Wiesner]

But I don't really understand it. I just remember that I've read this somewhere

[Nathan Fallet]

Not sure what that JSI is. But not sure it’s as good as what we have with expect/actual in Kotlin 🤷‍♂️

[Filip Wiesner]

I am not saying that. I overall agree with your article. It's just that it might not be fully accurate about this point. I also don't know how JSI works and if it only applies to C++.

[Hesam]

I liked it, thanks for sharing 👍

[Nathan Fallet]

@Filip Wiesner I took a look at JSI and TurboModules since another person told me something similar, so I’m sharing you the answer:

[Nathan Fallet]

Image from iOS.jpg

[Filip Wiesner]

Thank you! kodee loving So if JSI "allows direct calls between JS and native," is "native" meant to refer to the target platform or really to "native," as in C/C++? Because if it's truly just native, it does nothing for the communication between a custom platform-native component and JS.

[Nathan Fallet]

After more research: JSI enables direct calls between JavaScript and C++, not the platform. You still need bridging: on iOS, you go JS ←→ C++ (JSI) ←→ Objective-C++ ←→ Swift/iOS APIs. On Android: JS ←→ C++ (JSI) ←→ JNI ←→ Kotlin/Java ←→ Android APIs. That's why TurboModules require Objective-C++ (.mm files) and JNI glue code.

[Filip Wiesner]

I see, thank you

[Karen Frangulyan]

@Nathan Fallet your KMP example worked so well because you were importing a platform class import platform.UIKit.UIDevice . I’m not sure if it would be that easy if you would like to use anything else that’s not part of the system and not available out of the box. Although it will cover almost all of the developer needs. Just to be clear - to me KMP/CMP is incomparably better than any other multiplatform framework, so I totally agree with your message.

[Nathan Fallet]

@Karen Frangulyan You can also import anything outside platform declarations https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-ios-dependencies.html I’ve done it once and it works really well 😄

[Nathan Fallet]

(From Swift package manager or Cocoapods, and access it from Kotlin)

[Nathan Fallet]

Eventually you might have to create a few .h files to expose the Swift/Objc code to Kotlin, but that’s all it takes

[Nathan Fallet]

I wrote a new one about the future of the market, and why I think that KMP/CMP will replace Flutter in the upcoming years (with only KMP & RN surviving)
https://medium.com/@nathan.fallet/flutter-will-disappear-soon-and-this-time-its-not-a-joke-500d5a4e8454

[Oliver.O]

Well analyzed. Makes a lot of sense to me. 👏

[Oliver.O]

In my view, that article deserves a separate mention in #C0BJ0GTE2.

[Karen Frangulyan]

I remember a while ago I did a quick research to check flutter vs react native “market share” (whatever that means) and had a feeling that flutter was “bigger” than react native. To this day I cannot find an explanation for that. Maybe my research was wrong? Because I tried to learn flutter and it was one of the worst things I experienced.

[Nathan Fallet]

I removed it and I’ll rewrite a part of it, since I got a lot of feedbacks from the Flutter community saying my data was too outdated and I was not objective enough being strongly using Kotlin and not Flutter (which is true, I agree)
So I’ll do more research about Flutter and update it appropriately

[Karen Frangulyan]

I remember last year I was in Berlin for droidcon, which is combined with fluttercon, so on the opening keynote the half of the hall were flutter devs. And in one of the slides the presenter showed a graveyard of dead technologies, with their logos on tombstones, like xamarin, etc. The last one was empty and then slowly the flutter logo appeared with a question mark 😄 You can imagine the mixed reactions from the audience, half of which were native devs and half flutter devs 🙂 That was the year Google announced it will be making most of their libs KMP-compatible, and Google booth spent a lot of time on that conference answering the "what the hell?" questions from flutter devs. Googlers came up with a nice response saying they officially recommend sharing logic with KMP and sharing UI with flutter. That calmed flutter devs a bit down. Haven't been there this year though to see how did the atmosphere change since then.

[Oliver.O]

I have deep respect for re-publishing an updated version of the article. If there is updated information regarding Flutter and the article's accuracy can be improved, I'd much appreciate it. But I'd also warn against some calls demanding "objectivity". Neuroscience tells it is impossible, as we all make choices based on our preferences. So if we stick to the facts, it's totally OK to voice an opinion based on factual information. There is no need to introduce some false balance with a motive of pleasing everyone or not to offend a louder group.

[Michael Paus]

@Karen Frangulyan Why should anybody be "sharing logic with KMP and sharing UI with flutter"?

[Oliver.O]

We probably should not take that too seriously. Flutter and KMP have been separate developments inside Google without any overarching "grand plan". So now we have both, and my impression is that like all of us, Googlers are mostly watching how this plays out.

[Nathan Fallet]

@Oliver.O I’ll update the article because some facts were outdated apparently. Also, by objectively I mean by reading the article you clearly understand that I push KMP. I would like to do it more like my previous article in which I mainly focused on the fact without giving too much “opinion” about my preference for KMP

[Nathan Fallet]

@Michael Paus Because initially CMP was not stable so they recommended to use Flutter to share UI. Now you can do both with KMP/CMP directly

[Karen Frangulyan]

@Michael Paus alao, there is politics involved, since flutter is their own product, while CMP is done by jetbrains. It's also an additional reason to stick with CMP - google is a huge company and can drop flutter and not notice it, while jetbrains is much smaller than google and I assume cannot "afford" such a move towards one of its important technologies.

[Oliver.O]

@Nathan Fallet Not drowning people in opinion is certainly a good trait. But if one solution is clearly superior in a certain context, why not just say it? As long as it is based on facts, and an attempt is made to provide context as completely as possible, I'd appreciate it over trying to beat around the bush.

[Oliver.O]

@Karen Frangulyan While CMP is a JetBrains development, Google did a lot to make Jetpack Compose multiplatform-capable, and has began pushing for multiplatform even more over the years. Big parts of the Jetpack universe are multiplatform these days.