Replies: 1 comment 2 replies
-
|
Hey 👋 Thanks for the questions!
The main goal of Dirt and it's relation to Dart is similar as that of Kotlin to Java: Bringing a fluent, more modern language to an existing ecosystem. This means that in Dirt, you can seamlessly call Dart code, either from existing Dart dependencies or in the same project. This also means you will still use Besides that, Dirt tries to also introduce more interesting features such as:
Yes, Flutter interop is definitely a goal! It kinda comes "automatically" by having Dart interop 😄
I haven't thought about this yet, but I assume incremental compilation on the Dirt side should go a long way!
Yeah, I am quite interested in this, although depending on how things go I think it will be a post-1.0 goal. Ideally I would like to call Kotlin and Swift code "directly", where it would seem in Dirt as if you're calling these native methods as-is, but in reality you'd be using method channels. This is very tricky to implement of course, so if that doesn't work out I'll go for a middle road where you can define methods/classes in Dirt that under the hood call method channels. Kinda like Hope that answers your questions 😄 Klutter looks cool as well btw! |
Beta Was this translation helpful? Give feedback.
-
|
Your method channel idea is basically what I'm doing with Klutter. You'd best use protobuf for performance though. Or FFI/JNI might be a better (performing) option. I prefer Kotlin over Dart myself too but keep in mind Dart is still relatively young and improving as a language pretty steadily. But if Dirt could handle native operations without any method/event-channel hassle then that's a huge selling point! I'd be happy to help out if you want to get started with native interop. Feel free to reach out anytime. |
Beta Was this translation helpful? Give feedback.
-
Ahh cool, I didn't know! Indeed if FFI/JNI is feasible that'd be great.
Yes definitely. I don't even think Dart is a bad language, they've just made the design choice (making it as familiar as possible) that makes it not-so-pretty and means they won't introduce more exotic features. And with the improvements they made, unfortunately their own legacy cruft is visible, such as the fact that
Awesome, will do! That feature is quite far away, and I would also like to use Dirt to make Dart as a backend ecosystem more attractive, so not sure when I'll start on native interop. But when I do I'll let you know! And likewise, if you have any input/suggestions/collaboration for Dirt, let me know 👍 |
Beta Was this translation helpful? Give feedback.
-
Hey Wilko,
Been following you're work on dotlin/dirt since day one (literally). It's intriguing to me because I've been working on Kotlin Multiplatform - Flutter interop.
I do wonder what the intended use case is for dirt? What problem are you trying to solve? How do you plan to position dirt? Is for example Flutter interop a goal? If yes, how do you plan to support hot reload? Is native interop a goal?
I myself love working with Kotlin but also still prefer Flutter for mobile development instead of Jetpack Compose/SwiftUI (hence my own Flutter-KMP hobby project). I think if you could use dirt to write UI (well it compiles to dart so basically you can ofcourse, but you'd want hot reload) ánd have native interop it would be a gamechanger.
But it's not clear to me if that's your goal. I remember Flutter being on your dotlin roadmap though. So basically, just curious what your plan is. 🙂
Beta Was this translation helpful? Give feedback.
All reactions