Only 2 families of DeclarativeUIs in the future?

# compose

[Daniele B]

Only 2 families of DeclarativeUIs in the future?

[Joseph D]

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

[Cyril Find]

google tv is just android tv with a google launcher tho

[Daniele B]

@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.

[Halil Ozercan]

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.

[Daniele B]

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.

[Thiago]

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.

[Daniele B]

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.

[Javier]

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

[Daniele B]

@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.

[Daniele B]

Also in terms of native UI/UX, Flutter is not giving me any freedom.

[Daniele B]

[Daniele B]

Having a platform-specific UI is not a burden anymore. It's now purely an advantage, for providing the most native look-and-feel to an app.

[Javier]

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.

[Daniele B]

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.

[Daniele B]

I don't see Flutter as a future-safe investment for a company that wants to ship first-class native apps.

[Javier]

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

[Daniele B]

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

[Daniele B]

Google-branded apps might even make sense to be written in Flutter, as Google doesn't feel the need to adapt its look-and-feel to iOS. Flutter provides Material Design, and Google is not shy to build iOS apps with that. It's actually part of its brand.
But for any other company, using the platform-specific look and feel is very important.

[Thiago]

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.

[Thiago]

Where did you read that Flutter is not a declarative UI? You forget that all frameworks you had cited here are implementing things that born with web technologies like React and declarative pattern? 👀

[Daniele B]

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.

[Thiago]

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? 👀

[Daniele B]

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.

[Thiago]

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.*" 😬

[Daniele B]

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.

[Daniele B]

I meant the future is about DeclarativeUIs in general, not restricted to Flutter