Live data from Hacker News

Kotlin Multiplatform for Android and iOS

kotlindevelopment.com

31–38 of 38 posts

Re: Kotlin Multiplatform for Android and iOS

#31
post #30
post #27

Earlier quoted context omitted.

JavaScript is also an impedance mismatch.

> JavaScript is also an impedance mismatch. Yet both Android and iOS allow embedding a Javascript engine in an native application with no effort whatsoever.

I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static.

Re: Kotlin Multiplatform for Android and iOS

#32
post #31
post #30

Earlier quoted context omitted.

> JavaScript is also an impedance mismatch. Yet both Android and iOS allow embedding a Javascript engine in an native application with no effort whatsoever.

I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static.

> I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static.

Well like it or not JS is first class on both platforms as they both have a JS engine at the developer's disposal, Kotlin or C# aren't.

Re: Kotlin Multiplatform for Android and iOS

#33
post #32
post #31

Earlier quoted context omitted.

I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static.

> I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static. Well like it or not JS is first class on both platforms as they both have a JS engine at the developer's disposal, Kotlin or C# aren't.

I don't know about iOS, but on Android it surely isn't first class, the development experience is even worse than using the NDK.

If it was first class, there would be official Android APIs for JavaScript, debugging support on Android Studio, project templates on Android Studio.

Instead it is a web widget with its own little island of HTML 5/CSS 3, hardly first class.

The support is not much different than getting chromium and compiling it with the NDK.

The only mobile platforms where JavaScript is first class, alongside the other platform languages is on ChromeOS and UWP.

Re: Kotlin Multiplatform for Android and iOS

#34
post #33
post #32

Earlier quoted context omitted.

> I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static. Well like it or not JS is first class on both platforms as they both have a JS engine at the developer's disposal, Kotlin or C# aren't.

I don't know about iOS, but on Android it surely isn't first class, the development experience is even worse than using the NDK. If it was first class, there would be official Android APIs for JavaScript, debugging support on Android Studio, project templates on Android Studio. Instead it is a web widget with its own little island of HTML 5/CSS 3, hardly first class. The support is not much different than getting chr…

First class because there is no need to deploy your own JS engine on both these platforms, you can argue all you want, both have a webview/js engine API that are part of their respective SDK.

Re: Kotlin Multiplatform for Android and iOS

#35
post #34
post #33

Earlier quoted context omitted.

I don't know about iOS, but on Android it surely isn't first class, the development experience is even worse than using the NDK. If it was first class, there would be official Android APIs for JavaScript, debugging support on Android Studio, project templates on Android Studio. Instead it is a web widget with its own little island of HTML 5/CSS 3, hardly first class. The support is not much different than getting chr…

First class because there is no need to deploy your own JS engine on both these platforms, you can argue all you want, both have a webview/js engine API that are part of their respective SDK.

That is not what first class means.

A language is first class when the complete SDK stack tooling has support for it.

IDE, debugger, docs, project templates, profiler, OS APIs.

Re: Kotlin Multiplatform for Android and iOS

#36
post #35
post #34

Earlier quoted context omitted.

First class because there is no need to deploy your own JS engine on both these platforms, you can argue all you want, both have a webview/js engine API that are part of their respective SDK.

That is not what first class means. A language is first class when the complete SDK stack tooling has support for it. IDE, debugger, docs, project templates, profiler, OS APIs.

> That is not what first class means.

That's not what first class means to you. You can't just make up the definition you want just because it's convenient for your. First class means it runs on the platform without any form of external or third party runtime.

Re: Kotlin Multiplatform for Android and iOS

#37
post #36
post #35

Earlier quoted context omitted.

That is not what first class means. A language is first class when the complete SDK stack tooling has support for it. IDE, debugger, docs, project templates, profiler, OS APIs.

> That is not what first class means. That's not what first class means to you. You can't just make up the definition you want just because it's convenient for your. First class means it runs on the platform without any form of external or third party runtime.

The point is that you want JavaScript to be seen as first class no matter what, because it fits the React Native story, even though it requires manually written FFI for the platform APIs.

Hey, by your definition even web pages are first class on mobile devices, as they don't require any form of external or third party runtime, maybe we can even call them native apps!

If JavaScript doesn't require any form of external or third party runtime, then why does React Native bundle JavaScriptCore?!?

https://github.com/react-community/jsc-android-buildscripts

Re: Kotlin Multiplatform for Android and iOS

#38

Seems like a gimmick to me. In a nutshell this has the same limitation has Xamarin. The Business Logic is shared , but the UI Logic and the Technical Logic aren't shared or not completely. The Xamarin community has been struggling with this issue for half a decade and they ended up re-writting their own rendering engine[0] (similar to Flutter) in C# on top of Xamarin to obtain truly MVVM Cross-Platform Framework. My…

It's similar, but not the same. The details matter. They're different because you don't need to deal with a complex abstraction layer to share logic. As in, you can expose an iOS Framework and call it from swift/Objc just like any other library. That lets you share tested logic and architecture, and do so optionally. It's not all-or-nothing. Xamarin is a different approach. Flutter is a very different approach.

Part of the issue when evaluating frameworks is expectations and not understand the plusses/minuses. If you are looking for a framework that will do 1 codebase for all logic and UI, without sacrificing any UX or capabilities, you'll probably be let down. Kotlin Multiplatform will be great for sharing logic and architecture. UI is somewhat of a different case. Why Xamarin wasn't great here is you need to do EVERYTHING in Xamarin, and write custom bridge code when not. It's an entirely different world, which bad IDE support for most of it's history. Jetbrains makes excellent tools, and if you understand that the UI will be "native", then there's a lot of efficiencies you can leverage here. If you get frustrated because you can't make one thing do all things, then yeah, it'll let you down.

Anyway, yeah, they're different.

Post reply on HN