The implementation is pretty impressive. It's not as slow as some other previous attempts. It's "only" 1mb for a hello world 3+ for anything "decent". Both of these numbers are good for Java FX but they come with a lot of caveats. E.g. accessibility seems to be broken. Performance is lagging and rendering looks "off" because it uses the FX rendering instead of system rendering.
Ultimately, FX lost the battle for the desktop, mobile, etc. this is an attempt to make it relevant again but unfortunately nothing will help FX at this point. It's a solution designed to combat Adobe Flash trying to compete in 2022. The RIA wars are over.
So the text selection is done by javafx too? But the comment above implied that the text selection was done by the browser
Is there something from JavaFX that can't be represented in the DOM and then you need to lower to <canvas>? I'm thinking for example JavaFX charts, or maybe custom widgets
> The scrolling is also (sometimes) from JavaFX. (...) Your observation with the scrolling is right. https://www.jpro.one/ uses the browser scrolling. https://www.jfx-central.com/ uses the scrolling of JavaFX, which is still a bit slow due to the hight traffic.
But does JavaFX scrolling requires network requests? Are you like running JavaFX in the backend and making a network request for each scroll in https://www.jfx-central.com/? And https://www.jpro.one/ doesn't need this because the scroll is handled by the browser
> You are right, behaving like a normal website is very important.
Well I think that if you have this as a goal your project will surely improve. The text hovering one seems like a low hanging fruit: if you go through each widget you can verify what mouse cursor browsers typically use for that by default (for example, <button> is a normal cursor, <textarea> is an edit cursor, <a> is a clicking hand, etc), and use this by default (perhaps with an option to use the JavaFX defaults if someone wants them).