<@U4KT0HPHR> TornadoFX attempts in a few ways to b...
# tornadofx
m
@amiracam TornadoFX attempts in a few ways to build a more Kotlin-friendly abstraction over JavaFX. It does it in a cheap manner, so you'll find its shortcomings appearing here and there. I prefer using naked JavaFX, and write few utility functions. In particular, its "builder DSL" metaphor implementation is very fragile. I wrote about it in previous messages. Don't expect the degree of care in design that you are accustomed in the Smalltalk culture. You'll find that TornadoFX is the more useful to you the more you write applications that are similar to the ones written by the author of the framework. If that's the case, use it. Otherwise, plain JavaFX is less of a problem, because you have to fight against less tools: just one (JavaFX, which was never developed to its maturity for historical reasons), instead of two (TornadoFX and JavaFx, which, as you saw, is not abstracted away by the first). I ignored the first signals of mismatch between me and TornadoFX, and currently (several months after I started using it), I'm still rewriting pieces of my code base to remove the dependencies from it.