So, all slack group. Is anybody putting multiplatf...

# multiplatform

[kpgalligan]

So, all slack group. Is anybody putting multiplatform in production for mobile, including native? Also interested in web, but I'm giving a talk that will focus more on mobile in a couple weeks. Would love to highlight some stories.

[ankushg]

Not using native (yet), but at Quizlet we've migrated a bunch of business logic from shared JS -> shared Kotlin and it's (unknowingly) being used by tens of millions of users a month.

We're spitting out a few JVM artifacts for Android, and JS on web. Our benchmarks showed negligible performance differences for our use case between our Kotlin/JS and "Pure" JS when run through iOS's JavascriptCore, so we're still using the Kotlin/JS artifacts with the old wrappers we'd already written to support the "Pure" JS artifacts.

We're doubling down on 100% eliminating shared JS from Android before circling back to spit out a real Native iOS framework and exploring WebAssembly, since the Native tooling is evolving a bit more speedily than JS/JVM.

[kpgalligan]

To racap, you were sharing code between web and mobile with JS, and are rewriting that to use Kotlin?

[kpgalligan]

How do you find Kotlin JS? Any major issues?

[ankushg]

Yup exactly!

The main thing we bumped against with Kotlin's JS is that it's tricky to get the method signatures to exactly match up with the "real" JS that we used to use. It's super easy to use things like `data class`es internally within pure Kotlin, but due to how Kotlin types map to JS types (https://kotlinlang.org/docs/reference/js-to-kotlin-interop.html#representing-kotlin-types-in-javascript), a drop-in replacement of our shared JS code required a little bit extra work. When the JS calling into your shared library is expecting you to return and accept raw Json objects instead of real instances of classes, you end up having to do stuff like wrap your external methods with facades that basically just transform your `data class`es to/from Json objects.

Another thing that's tricky/annoying with Kotlin/JS is that most of the JS-specific tooling that Jetbrains is investing in is focused on building full-on apps, rather than libraries written in Kotlin/JS and designed to be consumed from real JS. Kotlin spits out ES 5.1 modules, and not the newer ES2015 modules. ES2015 modules support webpack's tree-shaking, which is pretty much the standard dead-code elimination technique in the web world. If you want to keep your JS bundle size small (which anyone using Kotlin/JS in production does) you basically are stuck with Kotlin/JS's Dead Code Elimination instead of being able to use more industry-standard tooling.

Kotlin's DCE tool is pretty decent at picking out what things are used and what things are unused for webapps. With libraries written in Kotlin and distributed as JS though, it gets a bit more annoying. You have to manually specify what methods you want it to keep (and not mangle the names of), and the process for doing so is clunky, even compared to Proguard on Android.

Additionally, since you're stuck using Kotlin's DCE instead of more standard JS DCE tools, it complicates distributing these libraries internally via NPM. We basically have to DCE the Kotlin/JS Standard Lib against our codebase and redistribute it internally, instead of being able to pull the real, official, un-DCEd library from NPM.

Finally, the last real issue we've had is that we currently use Flow (https://flow.org/) for static type-checking in JS, and Kotlin/JS is completely agnostic of both Flow and Typescript. This means that folks working on libraries designed to be consumed from more modern JS projects basically have to handwrite these definitions themselves.

That being said, all of these problems are things we've been able to work around... it's just not ideal and I haven't seen much public commentary from Jetbrains on this use case.

[ankushg]

happy to talk more in-depth about this -- I've been meaning to write up a blog post (or two or three) 😄

[kpgalligan]

Would definitely like to hear more. I'm light on the JS world of 2018. Where are you based, btw?

[ankushg]

I'm in SF! I'm also not exactly a JS fanatic -- I'm an Android dev turned multiplatform dev, so I had to pick all this JS knowledge up out of necessity 🙃

[coletz]

I'm actually working on a project that will be in production in a couple of months (probably), both android and iOS with kotlin. Right now everything is working as expected (thanks to your project with sqldelight 😛 - and ktor client for consuming APIs)

[kpgalligan]

@ankushg I’m flying out to sf today and staying through the 21st. Part of the trip is to sit down and chat this stuff, so let’s see if we can figure out a time

[kpgalligan]

@coletz what kind of project is it (if you can share)?

[coletz]

basically an "advanced" agenda where doctors can annotate stuff about appointments with their patients (symptoms of sickness, photos of injuries, prescribed drugs etc)