Takeaways from KotlinConf 2017

Post by peoplewindow » Fri, Jan 12, 2018, 8:24 AM UTC

crispinb wrote: post #7

gman83 wrote: post #5

Earlier quoted context omitted.

I think Kotlin/Native's approach of sharing business logic while keeping the UI stuff native is probably the right choice. Although something like Flutter which render's all their own widgets is interesting because it allows you to share even more code. The question there is whether they'll be able to truly match the native widgets and have all the accessibility stuff working. In any case it's good that different pro…

I'd love to see a React Native style kotlin library to enable cross-platform UI choreography using native widgets. Having done some RN stuff lately, the prospect of going back to go back to Activities and view controllers seems very dreary (I'm with Andy Matuschak on the superiority of the React model). Ditching the whole javascript toolchain for kotlin, gradle et al, while keeping components and UI-as-function-of-st…

Post by pjmlp » Fri, Jan 12, 2018, 8:56 AM UTC

abiox wrote: post #22

pjmlp wrote: post #17

Earlier quoted context omitted.

In five years the Electron craziness will be gone.

what will replace it?

Post by kodablah » Fri, Jan 12, 2018, 9:00 AM UTC

peoplewindow wrote: post #20

kodablah wrote: post #15

Earlier quoted context omitted.

> For Kotlin Native to truly deliver on the promise of cross-platform business logic, a Kotlin library ecosystem independent of the JVM will need to develop. Or someone writes a bridge between native Kotlin code and AOT'd JVM code. Or someone writes a kind of reverse compiler from JVM bytecode to Kotlin. Not sure how practical either is due to sheer JRE stdlib size.

Look at SubstrateVM. It's capable of making fully stripped AOT compiled binaries with a bundled JVM that only use the parts of the JRE library that are needed. Sort of like what Go can do.