Since compose can be used to create any tree struc...

# tornadofx

[andylamax]

Since compose can be used to create any tree structured hierarchy, Is there a plan to mingle it up with tornadofx? something like compose-fx? If so, where do we contribute our thoughts? if not, why not?

[Ahmed Mourad]

I believe Jetbrains are working on adding desktop support to Compose.

[kv]

oh interesting, did they make an annoucement?

[Ahmed Mourad]

@kv Not an announcement, but as close as it gets.

They posted this job a while ago:
https://www.jetbrains.com/careers/jobs/ui-framework-developer-401/
It mentions that they're working on porting it to desktop.

There was also this commit which mentions running compose on desktop:
https://android-review.googlesource.com/c/platform/frameworks/support/+/1290729

There's also a couple of articles that did attempt to run it on desktop:
https://zeromod.in/posts/jetpack-compose-desktop/
https://arnestockmans.be/blog/build-run-jetpack-compose-for-desktop

[kv]

oh wow - ill give it a read thanks!

[Marshall]

The kotlin devs mentioned several times in the AMA that they were working on desktop app support, everyone suspected it was compose for desktop, but I didn't expect something to be ready this soon

[kv]

this is pretty neat

[Marshall]

I am curious about the implementation, I would assume it doesn't require JVM so you can build with kotlin native/kmp

[Ahmed Mourad]

Yup, that was fast!

Compose itself is platform agnostic, but I believe the plugin from the post requires the JVM.

[Ahmed Mourad]

Current recommendation looks like Jetpack Compose for Android, Jetbrains Compose for Desktop and SwiftUI for IOS.

[altavir]

Compose uses completely different principles and I do not thing that it will be ever as good as tornadoFX for complicated desktop logic. Sadly, reconcile approach won the popularity contest right now and Tornado is not actively developed.

[Marshall]

reconcile approach?

[andylamax]

One thing I truly know. Declarative UI is not a step backwards, even at the expense of slight performance. Optimizations can always be made

[altavir]

It is not step backwards, it is a different approach. It is better for something, worse for something else.

[Astronaut4449]

@andylamax tornadofx's DSL is declarative as well. What is your point?

[Astronaut4449]

@altavir could you elaborate on that? I haven't tried Compose yet. But I don't see any advantage from a syntactical point of view, from a performance point of view nor a debuggimg point of view (compiler magic).
Sure, they are developing good tooling. But that tooling would have been possible for tornadofx as well

[andylamax]

@Astronaut4449 I wasn't trying to say that TornadoFX was not declerative. But yes, TornadoFX was in the correct direction from FXML . I also believe that jetbrains-compose is also in the right direction from TornadoFX . Since, it not only is declerative but can also be made pure functional less boiler plate compared to tornado, and every other thing fits in place

[Astronaut4449]

I don't know about the less boilerplate part. I've seen some Jetpack Compose examples that were super boilerplate heavy. It all starts with having to annotate your functions. Then come the `Modifier`s which look super ugly to me. And you don't get rid of observables at all: You even have to wrap your state in remember blocks.

Taken from the Google docs:
val (value, setValue) = remember { mutableStateOf(default) }

[altavir]

Functional and pure are not the aims of API design. Usability is. Compose is more cumbersome than tornado become convention states that only children cold be placed in a lambda. I understand why it is done, but the code looks worse.