In order to say something positive and constructiv...

# tornadofx

[melatonina]

In order to say something positive and constructive about TornadoFX, since I criticized it several times here, I want to mention that IMHO a new version of TornadoFX should separate the "builder DSL" from the other components. The DSL should be generate as much as possible via metaprogramming, and not by hand. The team working on this DSL should cooperate with the JavaFX team in order to synchronize the releases and possibly evolve the JavaFX API to make the metaprogramming easier (even if just by annotating the classes and the methods). Annotating the JavaFX API where necessary for making metaprogramming the DSL effective would lay the basis for libraries of JavaFX controls to using the same annotations and get the DSL for free.
The other features should be moved in other modules (as it was already planned somehow). Some of the features, like serialization and networking via HTTP, should be removed and replaced by the equivalent "standard" libraries in the Kotlin ecosystem. And coroutines.
With "should" here I mean that in my opinion these are the minimal set of changes required to make the project maintainable and appealing to as much of the the Kotlin developer audience as possible, so that it can make any sense and possibly gain some kind of financial support.
It's very hard for just one developer to guide TornadoFX through this evolution through the years. This is probably why TornadoFX went from being innovative to being covered by a certain layer of dust. Not because the author is not good. This is not a personal attack. A project like this requires more than one pair of hands and more than one head.

[Joe S]

I'm not sure what the purpose of your rants are? Are you regretful of your choice of tech stack and just trying to turn people away? Seems like you're just trying to advocate for not having a community rather than help build one.

Yes, the documentation could be better. Yes, to build anything of enough complexity you are going to need to understand JavaFX. Yes desktop doesn't have as cohesive of an application framework as Mobile- the one in TornadoFX is primitive and JavaFX itself is only a widget toolkit.

Sounds like you learned a lot. You can submit PRs if you like; or maybe even try to take on the role of maintainer. You could create some tutorials around best practices, or better explain some of the framework things like Fragments/Views/Workspaces/Scopes etc.

Jetpack Compose is in Alpha. It's going to have even less features than Tornado right now. It's going to have less established best practices. It's subject to change as anything bleeding edge would be in Alpha (worse yet, it's an alpha port of an alpha product in a different platform). It also doesn't have a lot of support outside of the UI itself (backstack, navigation, stuff like that). It's also going to have poor documentation and out of date documentation. You could also use Swing or go for a webapp.

Yeah, desktop as a platform is not in a great place in general. If the point is "is it worth learning TornadoFX in 2020?" for me the answer is still the same as it was in 2017 when I started my app that needed to be virtually identical to an Android version- Yes, there's not really an alternative currently.

[melatonina]

"Are you regretful of your choice of tech stack and just trying to turn people away?"
No, but sincerely I don't appreciate people manipulating other people in the opposite direction, either: implicitly stating the equation "using JavaFX with Kotlin means using TornadoFX". No, you can use JavaFX without using TornadoFX. It's not a ridiculous choice. Each for the two choices has advantages and disadvantages, and to try and make the best choice for each project, you have to understand that.
"Seems like you're just trying to advocate for not having a community rather than help build one."
No, I'm advocating for its community to have a reality check and do not fall into traps of thinking things like "TornadoFX is not being developed because it lost the popularity contest against the paradigms of web development". No, the paradigm of TornadoFX (the underlying paradigm of JavaFX) are going out of favor because people develop application on multiple platforms and they desire to write application in similar ways for the mobile devices and the desktop, in order to save time and provide similar experiences. That's why Compose is being developed like it is.
"Yes, there's not really an alternative currently."
As I said, one alternative is use JavaFX directly. You suggested other alternatives, too.
"Yes desktop doesn't have as cohesive of an application framework as Mobile- the one in TornadoFX is primitive and JavaFX itself is only a widget toolkit."
An application framework is not required in order to build an application. A GUI toolkit may be more than enough to build a GUI application. That's why I suggested that the DSL should be separated from the rest of TornadoFX, so that that part can be appealing to the widest audience possible.
On mobile systems, application frameworks are basically part of the OS because the OS needs to manage the applications very tightly.
"Jetpack Compose is in Alpha. It's going to have even less features than Tornado right now"
True. It also developed by Google and Jetbrains with dedicated teams and public release schedules.
And sometimes one may choose to (gradually) adopt a technology that will be ready in future to not make their code base old at birth.

What was the purpose of my rant? In my last message, I stated it quite explicitly: TornadoFX has a niche audience; an audience that nonetheless exists; in order to serve that audience and to attract as much as possible of it, people should focus on those area, instead of being blind and complaining that TornadoFX is not developed because it's someone else's fault.

That was an attempt to help create a community, even if I may end not being a part of it.

I'm still using TornadoFX, so far. Even if it possible (likely but not certain) that I'll drop it, I thank you for sharing with me an example of using JavaFX through a Kotlin DSL.

[Samkeene]

I used JavaFX in hobby projects for a few years. Never liked using FXML or SceneBuilder. I was aware of TornadoFX for a while but wasn't confident in switching to a new language with another API layer. Eventually I switched last year for my third year project at university and found out I really liked how TornadoFX builders work. Eventually I learned about the Workspace and Scopes and really felt like things came together well.

I'm in the progress at the moment of re-writing my 3rd year project from scratch (hopefully to become an actual product at the end). As I've got more familiar with TornadoFX I do concede some of your points. Why would I use TornadoFX's JSON serialisation when I can use the much richer moshi or kotlinxserialisation? There's no need to mess around with TornadoFX's http features when I can just throw in a ktor engine in a Controller and inject that wherever I need it.

Once I understood the basics of Views and Scopes, then implementing features and quickly building software become far smoother than other libraries. I can't think of any abstraction library for JavaFX that is as nice to work with.

The documentation is both excellent and bad at the same time. There were many times during my project where I was stuck for days because of some important aspect of how the library works that was hidden away in some single line in the documentation, or in some cases wasn't mentioned at all and I had to ask for help 😕 It could do with a lot more best-practice examples.

I do wish this reworking into modules would happen in TornadoFX2. I don't think Craig Tadlock (ctadlock) is in this slack to ask. Might drop him a message sometime soon asking.

[Samkeene]

@geepawhill said in a previous thread he would be interested in being a maintainer. If that is still the case might be an idea for him to talk to @edvin?

[jschneider]

I think you have made a few good points. At least extracting the DSL into an own module, seems to be a very good idea in my eyes.

[melatonina]

Thanks for sharing your experience, @Samkeene.

"Once I understood the basics of Views and Scopes"
View and Fragments are an artifact of the limitation of the "builder DSL". A Builder DSL is not friend with subclassing, because you would need to (manually) extend the DSL for each and every subclass you make. So you need other entities to aggregate JavaFX nodes. But then you would like to operate on the aggregate like if it were a node, without using the root property each and every time, so you have to duplicate methods for them to work both on a node or a UIComponent. Notice also how you have builder which elegantly builds, configures and adds a node to the parent at once but there is nothing like that for a UIComponent. So the "builder DSL" abstraction falls apart when you attempt to reuse a combination of elementary nodes with some added functionality. The Kotlin support for DSLs is not good enough for using it for GUIs or any other domain where substantial subclassing is involved. That's why they extended Kotlin with a compiler plugin to properly implement a declarative GUI toolkit in Jetpack Compose.
Scopes are provided by any dependency injection framework, which you would need to use anyway, in a bigger application. Now you have to learn two of them, and most importantly know the limitation and bugs of two of them.
Of course, for some uses and for some people these two abstraction, as provided by TornadoFX, may be perfectly fine, even if they are clunky.
There are other things to say. I'll stop here because it looks like I'm here to criticize Edvin's work and Edvin through his work. I don't enjoy this role. In the good and the bad, I'm really thankful to Edvin for sharing this piece of code, and to the people who gave me suggestion in this channel. Please pardon me, if I offended anyone.