Takeaways from KotlinConf 2017
vokal.io
Takeaways from KotlinConf 2017
1–10 of 26 posts
Re: Takeaways from KotlinConf 2017
#2Looking forward to hearing more about Kotlin/Native. We need a proper solution for this problem.
Re: Takeaways from KotlinConf 2017
#3> The organizers developed conference apps for both iOS and Android using Kotlin. They also built the API in Kotlin using Ktor, a framework for building server-side business logic with Kotlin.
This is really cool! Excited to dig into their repo: https://github.com/jetbrains/kotlinconf-app
Re: Takeaways from KotlinConf 2017
#4Looking forward to hearing more about Kotlin/Native. We need a proper solution for this problem.
I've done some work with it just recently. Happy to answer any questions, though I am not an expert. Overall, I think it fits very well in the Swift space and the tooling is clean. I wrote a sample DLL in it yesterday to become more familiar with it and work through some of the FFI challenges [0]. I have found it much easier to use than Scala Native (especially if you're a Windows person).
Re: Takeaways from KotlinConf 2017
#5Looking forward to hearing more about Kotlin/Native. We need a proper solution for this problem.
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 projects are approaching this from different angles.
Re: Takeaways from KotlinConf 2017
#6Looking forward to hearing more about Kotlin/Native. We need a proper solution for this problem.
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…
History says no.
Any widget toolkit, on any platform ever, that has tried to provide it's own cross-platform widgets, has been completely terrible and ends up being native-nowhere instead of native-everywhere.
Re: Takeaways from KotlinConf 2017
#7Looking forward to hearing more about Kotlin/Native. We need a proper solution for this problem.
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-state, would be very appealing. I wish I had the chops to create such a library myself.
Re: Takeaways from KotlinConf 2017
#8Earlier 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…
What exactly is wrong with view controllers..? That strikes me as rather like saying there's something wrong with 3GLs. Are you suggesting React solves the programming language problem completely? If not, I'd like to ask you again what is wrong with view controllers. I've had frankly endless success with them once I got over my lackings.
Re: Takeaways from KotlinConf 2017
#9Earlier 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…
History says no. Any widget toolkit, on any platform ever, that has tried to provide it's own cross-platform widgets, has been completely terrible and ends up being native-nowhere instead of native-everywhere.
I tend to agree with this. We need a way to natively address the complete set of each platform's capabilities without needing to worry about them falling out of lockstep if some centralized maintenance entity decides they're no longer sufficiently incentivized to maintain their social contract with their framework adopters. It may indeed be the case that we can already accomplish this with properly written (concrete implementation agnostic) modular code but fmpov there's no complete solution being offered to the public at present. My hope is that in the next few years we get to see Google adopt Swift. Then it's just a matter of reinventing the browser so we can build native web apps in Swift as well. :P
Re: Takeaways from KotlinConf 2017
#10Earlier quoted context omitted.
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…
What exactly is wrong with view controllers..? That strikes me as rather like saying there's something wrong with 3GLs. Are you suggesting React solves the programming language problem completely? If not, I'd like to ask you again what is wrong with view controllers. I've had frankly endless success with them once I got over my lackings.
Well there's nothing absolutely 'wrong' with them. You can write good and bad apps with view controllers (I've done both). But they're an architectural blank slate, mainly offering access to UI objects & lifecycle callbacks. You need some architecture on top in anything but the most trivial app. The naive approach is to have 'no architecture', which actually is an architecture of just throwing masses of state, ad hoc, into the view controller, and using this to effect the UI any old how (so a 3rd party has no idea where to look to find out where things happen). Or you can go maximalist and select from MVC, MVP, etc, all of which are an improvement on the naive approach.
It just so happens that I've found RN (React Native) to be the nicest improvement, to my taste. Simple unidirectional data flow & UI state being a simple function of app state make for a beautifully clean and unambiguous model for how everything fits together.
One can argue the costs and benefits of app architectures all day, but there's really no substitute for trying them out, for the sake of curiosity & learning. All the devs I know who have written RN groan a bit when they're back in iOS and/or Android native development, and absolutely not because they love javascript!
Check out Andy Matuschak's celebrated Tweet on RN (https://twitter.com/andy_matuschak/status/560511204867575808). I point to it not as an argument from authority. But if one of the people who wrote UIKit thinks RN's model is the superior one, surely that should pique curiosity just a bit?
> Are you suggesting React solves the programming language problem completely
I'm not sure what you're getting at here. What 'programming language problem'? And why would an improvement have to solve something 'completely' to be of value?