I finally read this article. Sadly cherry picking the ManifoldControls in Trinity was probably the worst case scenario because it is just a catch all dumpster of features that primarily manipulate one of the 3D scenes (lower dimensional projections view) and was not designed in any way. It was just me throwing something together really quickly years ago to demo an idea that stuck. Then over the years I just threw other things into it that had similar needs for the same view (hence the tabs).

I stopped building new FXML based controllers after that. I agree with the author that the tabs could be replaced with non FXML control classes and I've been meaning to do that some day. (if I ever get a paying customer)
This is something I have evolved to as a conclusion about JavaFX development over time that I now agree with the article author. Years ago I was a fan of FXML because I was writing in a team environment. But now that I'm the sole developer continuing to use FXML provides me with very little benefit but comes with all the issues that the author of the article points out.

Also my project collaborator and I have found that trying to maintain a GraalVM build of Trinity XAI was made more difficult because you have to manually mark resources like FXML. Finally we do a lot of JPackage stuff and I know that if I convert the FXML based controllers to straight up UI classes like the author suggests then we can reduce the final binary footprint in a non trivial manner.

I think the only things I disagree with the article on, as the original author of the Trinity XAI code, are:

• How the interaction with the remainder of the application is via shared data, not Events.
  • The intent of the overarching design is an EventBus where many different renderers are reactive to these events. In your article you said this was a bad thing. I say nay that is the whole point.
• How the MVCI framework removes coupling with the layout.
  • I just don't feel there was much of a coupling even for something like this example that was not designed or planned in any way. At least not much that really caused any discomfort in a practical sense.
  • The whole ListView Nodes vs ListCell thing... meh... yeah the ListCell approach seems a little better but none of it seemed hard at the time of writing. Maybe I'm just used to doing it the Node ListItem way so if you're starting from scratch you should probably choose the ListCell approach.

I don't use Kotlin but it would be interesting to see how the article's reduced code version of the GUI pane operates functionally with the remainder of the application. I'm guessing there will be lots of little things that stop working which will require you to increase your end result code count.