Define 'modern'. JavaFX is/was it. What is specifically wrong with JavaFX - what is so fundamentally different in what you think is neccessary (e.g. SnapKit) that JavaFX doesn't deliver and cannot deliver without completely redefining what JavaFX is and how it works?

A few things come to mind:

-- "Native" --

Nobody, _nobody_ has properly solved this problem. Not even flutter and the like. Native is incredibly complicated. Many frameworks tend to 'zoom in' on the notion of having everything 'look' native, but this is in many ways heading in precisely the wrong direction: Of all frameworks that intend to be platform agnostic, the _only_ one that has seen significant success is the web, which is explicitly not _at all_ native. I'm not saying that 'you should just write desktop apps using web frameworks' - I'm just observing that the push towards platform agnostic native-looking apps has not worked at all.

The point is: _IF_ it's not a web app, you most likely want to integrate into the OS a little more than a web app would: You want to interact with webcams, the file system, integrate into context menus, affect other apps on the system (e.g. accessibility tools), register itself as a 'target' for share menus and the like, and so on.

Such notions are usually quite different between OS platforms, thus trying to provide a unified API _requires_ massively distancing yourself from the 'local' APIs (you have to: Those local APIs are completely different between platforms), and this in turn increases friction to use the best / latest takes. If apple releases a new sharing sheet API, then the makers of flutter or this hypothetical 'modern, native UI toolkit' for java need to figure out how to integrate this stuff into their APIs, deliver on that, test it, and release it. This takes a long time, hence - if you want to write the best iPhone app you can think of, you're probably best off writing it in the same technologies apple itself (the platform owner) would use. So, swift or ObjC, using XCode as editor, developing it all on MacOS.

-- "Modern" --

Whatever API style you think is modern, I'm just not seeing how JavaFX is outdated relative to it. If you specifically do not like what programming in JavaFX feels like, that sounds more like a style debate. The Swing and AWT APIs are severely outdated in objective ways, but JavaFX just isn't. JavaFX is an abject failure, at least if you look at uptake (which majorly used app is written in JavaFX today?) - before bashing your head into the same wall all over again, what did JavaFX do wrong? If there's no satisfactory answer to that question, it seems daft to try again. You'll just fail again in the same ways.

-- "Web based" --

Java has tons of web frameworks already, and there are boatloads of successful websites (in the sense that a lot of money is earned with them and/or eyeballs look at them). Most of them use 'server language agnostic' UI toolkits, i.e. those written in javascript+CSS, where the java server code just serves up JSON.

If you feel that a fundamental disconnect between front and backend is in fact a bad thing and orders-of-magnitude improvement are available if you integrate these, well, there are various frameworks that do just that. They are not as popular as e.g. AngularJS+java backend, so the same question comes up here too: What, specifically, is so wrong with these integrated frameworks?

-- "Deployment" --

Perhaps the right answer is that you write a web app as normal but give tools to deploy it _as_ a desktop app. i.e. the Electron route. But you can do that today fairly easily. The problem there seems to be that these apps never quite feel properly native, and electron is a resource hog.

No matter which way I turn to try to interpret what you're asking for, I end up with: "Sounds like a bad idea" or "the problem isn't technical, so delivering a new framework could not possibly solve it".