I really love the engineering that has been put into dart/flutter and the innovation it has brought to native UI development, but I just can't justify using it for anything. The ecosystem is immature and anything I would use it for could just as easily be written in Kotlin or JavaScript (TS).
Well, Flutter is primarily for apps that work cross platform, if you use Kotlin then you can only run it on Android (yes, Kotlin Multiplatform with Compose Multiplatform exist but they're even less mature than Flutter).
For JS/TS, you could use React Native but you also wouldn't get the full spread of platforms as RN is primarily for mobile and the web and desktop implementations are based on third-party support, plus the developer experience is inferior to Flutter.
So, if you want to make multiplatform apps, use Flutter, but if you only need to make Android or RN apps, use those respective platform tools.
There are usually good libraries for most things today. And with Android / Jetpack ecosystem moving so fast and deprecating things, Flutter is something to consider even if you target just Android.
My biggest two concerns were state management and native interop.
State management is probably biggest concern - there are at least 5 approaches / libraries competing for mind-share - and none of them are particularly ergonomic.
I did get an opportunity to work for a while on native interop for android / java [1]. But I haven't been able to work on that since long time.
> State management is probably biggest concern - there are at least 5 approaches / libraries competing for mind-share - and none of them are particularly ergonomic.
I've heard this critique a lot (particularly about Flutter), but I'm not sure I agree that having multiple state-management approaches is a bad thing. Can you elaborate on why this is painful?
From my perspective, (and to borrow the 'ergonomic' metaphor), it's like opening a toolbox and finding 5 different screwdrivers with similar heads. Some might not be well-suited to your project, and of those that do, one might have a handle that you find more ergonomic. I find it hard to imagine a screwdriver that could fit all screws and feel amazing in all hands at once.
Also, fwiw, I find Riverpod to be very ergonomic ;)
To be honest, I'm glad. No development environment can be as great as to justify the horrible, juddery UX I experience as a user in the few apps that I know use it (and probably a few more where I only have a strong suspicion).
If that's really the case, I hope to be able to see the effects of that soon in Google Pay on iOS, which is even being touted as a showcase application by Flutter/Google: https://flutter.dev/showcase/google-pay
Tldr, it's a different philosophy between Flutter and Swift, of explicit being more useful that implicit, and of performance optimizations that can be made due to that. The second thread has the tech lead of Flutter responding to the claims.
I believe there are very good reasons to design Flutter as it is and I don’t want to denigrate it. I think it is awesome work.
It is just that Swift feels extremely elegant and well-shaped, like a Domain Specific Language, and it didn’t feel this in the beginning. It evolved and did a great job.
Maybe like Java and Kotlin. I like Java after all, however I enjoy Kotlin the way I enjoyed Groovy.
BTW: Hixie, tech lead for Flutter, is my man. Dude was instrumental in establishing HTML5.
Actually, check out this comment [0] I made in another thread that was recently posted (copy pasted below), it's about Compose Multiplatform in Kotlin, it seems to be an upcoming Flutter competitor. It's pretty intriuging as I was initially using Flutter because I didn't want to have different apps for each platform, but it seems like with CM, it can do the same thing as Flutter but with more advantages, as I wrote of below.
Something I thought was really interesting in Compose Multiplatform is that you can transparently use both platform views and CM views together in a way that I haven't seen in Flutter.
I just watched that video [0] as well and I wanted to highlight a few interesting concepts there. Check out the timestamp 41:37 where they talk about the above interoperability. They have an example of a messenger app where the messages are in CM while the text input box is in Swift, so that this ensures that you are not reimplementing the native text editing controls as Flutter does, so I see that as a clear advantage for specific things like that. I don't believe that is quite possible in Flutter, or am I mistaken?
Also see timestamp 51:23 where they talk about graceful decomposition where if you decide to remove CM, you are left with a regular Android app as CM is backwards compatible with Jetpack Compose. It looks like CM can both paint to the screen but also fall back to using pure native Android components.
The way the architecture of CM is set up seems to make CM quite robust. Initially, I wrote off Kotlin Multiplatform because I thought, what's the point of sharing business logic in Kotlin if I still have to write the UI twice for mobile, not to mention for the other platforms like web and desktop. But now with CM, it looks like they're directly addressing Flutter to the point of taking a lot of concepts from it like you mentioned, like painting pixels on the screen (but optionally falling back to native views), or using WASM and canvas for the web which is exactly what Flutter Web does too.
I use Flutter quite a bit but it seems like Compose Multiplatform might be the future, or at least a big competitor, due to Google focusing more on Android dev and the whole Kotlin ecosystem in the past few years, it seems. The only con right now seems to be that CM is way less mature than Flutter, which really reminds me of where Flutter was several years ago.
It's nice but looking into it more, seems like lots of people are having issues getting it working [0]. It's definitely not as smooth as Flutter but that's how alpha software is, I suppose.
