Only 2 families of DeclarativeUIs in the future?

I think Compose will be applicable also on Apple's *OS.

google tv is just android tv with a google launcher tho

@Joseph D I am not too sure iOS is a priority for Compose. It will never be able to match SwiftUI’s native UI/UX for Apple devices. And if you want to build first-class apps you want to use native UI/UX.

My opinion is that Web is a strong platform to be accepted in. I love Kotlin as much as anyone here but TypeScript is a great language to write UI applications with. Also, React and Vue ecosystems are very matured at this point. No matter how nice of a translation layer we can have from Kotlin to JavaScript. it is never going to be (imo) as smooth as TypeScript. My hope is that Compose and SwiftUI will bring the sweet justice and destroy Electron apps once and for all.

It think it depends much on the new IR compiler for Kotlin/JS, which should be released in Kotlin 1.5. Anything below +50% bundle size compared to React/Vue, would make Compose for Web a feasible choice. Also consider that the future of Web is WebAssembly, and Compose fits very well for that.

You can't to forgot Flutter. It still a valid player to declarative UI and it is more stable than them because has more lifetime.

I specified "for the future", which means by the end of next year. I would be very surprised if, after that, most greenfield projects would be built using Dart/Flutter instead of KMP/Compose+SwiftUI.

@Daniele B Flutter's growth is insane...

@Javier Yes, I know. Flutter proved that mobile development could be greatly simplified with a Declarative UI toolkit, instead of the traditional Android and iOS view systems. But the future is declarative UIs, not Flutter. If I have the freedom of choosing Kotlin or Dart, I would never choose Dart to develop a long-lasting project.

Really that is your choice. But what will be the world choice? I just rather hit my head with a rock instead of using JavaScript, and it is the language more used for example.

Clearly everyone has the freedom to make its own choices. I am just providing some insights. It's my point of view. I am just saying that if I have the choice, I would not use Flutter to start a new project. As it's not providing any significant benefit, but mainly the disadvantage of not being able to use the latest UI/UX, while being stuck to a mediocre language like Dart.

Google Pay is using Flutter for example, I think it is a important app and I think you are discarding Flutter too quickly

I would be surprised if GooglePay used JetpackCompose, while it's still in Alpha.

I did read "for the future" but you can't say that Flutter will be replaced with Compose/Swiftui. It's consolidated and works very well. You're predicting the same as "Java will die because we have new better languages" and Java still like a stone in the development ecosystem.

No technology will be completely replaced. But we can understand what the trends are, which are also the ones that attract the most talented developers. Companies struggling with legacies have bigger problems in hiring the best people.

Do you can explain more why a company should wait until Android Team launch a technology that solve it engineering problems instead of use an already existing technology as Dart/Flutter? 👀

I never said that Flutter is not a declarativeUI. I said it's the one that proved that mobile development could be greatly improved with a declarativeUI toolkit.

PS: I'm not Flutter advocate. I'm just saying that it is consolidated and it'll survive for many years. It is a big player that Compose/SwiftUI needs to beat. You wrote that above: "*But the future is declarative UIs, not Flutter.*" 😬

If you use KMP for the 85% shared code, you don't have to wait anything. Everything works already. You then just need to add 15% JetpackCompose and 15% SwiftUI on top. But this can be done at a later stage. I suggest to wait at least JetpackCompose Beta and SwiftUI 3.0 for the final release, which both will be available in June.