https://kotlinlang.org logo
Join Slack
Powered by
Trying to describe in the simplest way the differe...
# multiplatform
d
Trying to describe in the simplest way the difference between KMP, Flutter and ReactNative
j
This is an apples-to-oranges comparison as it stands. KMP is about taking code and compiling it to the native language execution binary of multiple platforms. Flutter and React Native are frameworks for building cross-platform applications. Nothing about KMP has to do with UI, for example. You are free to target native UI or to write your own toolkit (e.g., Compose). Also React Native targets native UI widgets on every platform (I guess you're implying you write against an abstraction? I see below it shows native toolkit use) A direct comparison would be KMP to Dart AOT compilation to native code which runs on multiple platforms and Javascript which can be run in a VM on every platform. But KMP is not a framework, it's a technology. To compete with Flutter and React Native you have to drag in numerous libraries, but selecting those libraries is up to you and you get to pick which values you want from them. Maybe you want to target native UI–you can! Maybe you want to write-one-run-everywhere and ship a UI toolkit–you can!
If i had to illustrate the difference between these three I would say that Flutter and React Native are extremely opinionated frameworks for building cross-platform solutions with little-to-no flexibility in the technology choices. KMP is the exact opposite. It's a means for targeting multiple platforms and then choosing what you want to run. It's a recipe for competing with Flutter and React Native, but it is not a baked cake. You are on the hook for many choices. How do you do persistence on each platform? How do you talk to the UI? How do you talk to the network? How do you embed the multiplatform code into a larger platform-specific app? All of these have multiple options and you are responsible for not only choosing which one you want for each but also the integration between them all. Flutter and React Native are pre-made cakes. Don't like the frosting they chose? Too bad. Don't like the batter? Too bad. KMP is a cake recipe! Don't want chocolate frosting? Switch it out. Want to add sprinkles to the batter? Go for it.
❤️ 1
💯 11
➕ 15
🍰 13
d
Jake, you are technically right. But when talking about shared-code options, the main 3 choices are named as KMP, Flutter, ReactNative. They are not exactly the same thing, but when you talk about KMP you imply that you are going to use platform-native UI toolkits. That’s the assumption. My attempt is to summarize the 3 options in one slide, which as you can see it’s already quite full.
👍 1
j
When Compose targets iOS a lot of people will use it instead of Swift UI too.
And the same for webs instead of using React for example
j
Yep. And you don't even need Compose. We've experimented with an abstract Canvas API into shared code for common widgets.
➕ 3
Anyway, I've made my point. I think the slide is wildly misleading and pigeonholes KMP. Frankly, in a direct comparison KMP loses badly because it's so much extra work to compete on that platform. Its greatest advantage and why you should use it is because it's not competing directly.
☝️ 5
👍 8
d
@Javier if you don’t want flexibility in terms of UI, there is already an established option, and that is Flutter. No need to wait for Compose being ported to iOS.
d
JW makes good points, but i always view these slides as more appropriate for managers/people less familiar with the intricacies
KMP is so much more flexible than rn, flutter, because you can target native platforms and plugin to standard build tooling
d
The greatest advantage of KMP in my opinion is to be able to organize your project in a way that UI and business logic are fully decoupled. That provides you with the great flexibility to target any kind of device in the future. With Flutter and ReactNative, that opportunity is lost.
j
But the reason you can do that is because KMP doesn't care. You could just as easily have shared UI and platform-specific business logic. Kotlin does prescribe what you share and what you don't. Doing it the way you describe is merely a pattern.
d
As I said, I am implying (like 99% of the people, I guess) that with KMP, the UI layer is not part of the share-code. That is the kind of KMP I mean in that slide.
j
If you're presenting to managers don't forget to put KMP is ~3x the effort for 1/3rd the result. It's a choice that only makes sense if you value the technical aspect that differentiates it.
Sure, that's fine. But it's not intrinsic to KMP. It's merely one variation of a configuration of disparate things which leverage KMP.
d
Jake, these are not the number I am experiencing. At all. If you are using Compose and SwiftUI, you can easily share 85% of the code with KMP.
j
If you use Flutter you can share closer to 95% which less effort
d
yes, surely, but then you are stuck for ever.
what about if you want to design a TV app, using the same ViewModel and Data Layer?
j
Yep, and you've just illustrated why being precise about the technical underpinnings is important when comparing them!
➕ 5
d
There are also advantages like being able to share a common model across back and front that fluttrt and rn struggle with
d
With Flutter you can’t. With KMP, you just need an extra 15%, probably less.
j
You are making my point for me now
These details are important when comparing!
d
Jake, that was not meant to be a deep comparison. But just a simple summary in 1 slide.
not sure how much more you can say in 1 slide
j
Yeah and that's my issue. It's misleading. Compare KMP to Dart and JS. Compare one KMP setup to Flutter and React Native. It's all apples.
☝️ 5
d
I will start using the D-KMP acronym more. With D-KMP, I mean KMP with Declarative UIs, and that’s a setup.
I wrote an article about what I call the D-KMP architecture, which is based on 3 pillars: • Declarative UIs (Compose, SwiftUI) • KMP • MVI pattern
j
@Daniele B Compose really give you the flexibility to do whatever you want. It depends if the things you want to do, but if you want you should be able to get a UI that matches with SwiftUI 1:1. With flutter too. Other thing is if you want to spend the time to create all these components if the framework doesn't give them by default.
d
@jw concerning that, I actually would have a question to ask you, as yesterday you were saying you have been working with KMP and unidirectional data flow for a while now. All articles I found talking about MVI with Kotlin are actually just referring to Android and not to MultiPlatform, and all of them use SealedClassed for Intents. But on iOS you cannot really use SealedClasses. I wonder why not just using, for intents, simple functions (which can easily be translated in any language and any platform) defined on the shared ViewModel instead of SealedClasses. Then if you want to implement any backpressure strategy on a specific intent function, you just do it locally to such events/intents, in the shared code.
j
Maybe Workflow by Square?
j
I don't do iOS. All my stuff is Android, JVM, or JS.
And it's all 100% Kotlin, I never write JS/TS or Java
d
I guess you are using Kotlin/React for the Web UI part?
j
No. Don't like React at all. I usually just hand write the binding to the DOM or extension APIs like Omnibox. I would use Vue if I turned to a framework until Compose can compile to Kotlin/JS and I can write DOM bindings
d
Yes, definitely looking forward to Compose for Kotlin/JS too. It’s going to be a game changer for the Web. And after that, Compose for WASM shouldn’t be too late.
j
@jw is it planned to move Workflow Kotlin to Multiplatform? And the Compose artifact so get support for JB-compose?
j
I have never used Workflow. I know nothing about it.
👍 1
r
KMM would be a better heading for the column than KMP. That is the explicit architecture shown on the KMM home page @ https://kotlinlang.org/lp/mobile/.
Personally (with the change to KMM) I like the slide and find it quite clarifying. The fact that KMM is a technology and not a framework is an important distinction though. Its not a magic bullet. You could add a row in the middle for "Framework", with the values "Unopinionated, bring your own, mix and match", and "Opinionated prebuilt components" for Flutter and React, or something like that.
k
Just saw this thread. Started a long reply, but it's too late in the day for that kind of thing. KMP and the other things are just wildly different. I generally try to shut down comparisons, but I get the urge. I am curious who the audience would be. Technically curious people? OK. "Management"? I'd go right into adoption risk (if you were pushing KMM/P vs the other two). F&RN are what we call Big Decisions. They're hard to mix with "native", or walk back if things don't go well. It's a long, long topic, though.
d
I am summarizing the points here:
j
Are you talking about KMM or still KMP?
k
Who's the audience?
d
@jw I am referring to KMP, even though I am aware that Kotlin/JS won’t become fully attractive until the new IR backend becomes stable and Compose for Web is released @kpgalligan I would say the audience would be anyone who takes part in assessing a new technology (CTOs and senior developers)
j
Ok then I still take issue with this messaging. Especially now it's basically lying as if this configuration is the sole one
d
well, I am referring to what I call D-KMP: DeclarativeUIs + KMP + MVI
I took your suggestion to just compare “apples”, so I also updated the previous diagram:
I am preparing the slides for DroidCon APAC, where I will be talking for the first time about this D-KMP architecture
g
Business logic and UI are fully decoupled.
KMP enforces the boundaries but it doesn't offer that. Those boundaries can be enforce in any project without bringing KMP into play. The decoupling can be blurry now with JB and Jetpack Compose and still use KMP, then the business logic might end up coupled with UI if not careful
➕ 1
d
@Giorgos Neokleous to be clear, once again, I am talking about a specific setup of KMP (called D-KMP) and not about KMP in general. As we discussed earlier, KMP on its own can be anything.
👍 1
38 Views
Open in Slack
PreviousNext
Powered by